TLS patikra turi atsakyti į tris atskirus klausimus: ar ryšys apsaugotas tinkamais protokolo nustatymais, ar klientas patikrina tikrojo serverio tapatybę ir ar organizacija geba saugiai pakeisti sertifikatą bei raktą. Naršyklėje matomas saugaus ryšio ženklas neapima viso duomenų kelio. Tarp tarpinio serverio, programos ir duomenų saugyklos gali likti kitokių jungčių.
Šis patikros lapas skirtas sudaryti galinių taškų inventorių ir įrodyti pasirinktos konfigūracijos veikimą. Jį galima naudoti viešai svetainei, API, administravimo sąsajai ir vidinėms paslaugoms, įvertinus kiekvienos specifiką. Pateikti sprendimai yra techninės praktikos pavyzdžiai; jų nereikia pristatyti kaip universalių Lietuvos teisėje nustatytų parametrų.
Pirmiausia nupieškite tikrą ryšio kelią
Informacinių sistemų žemėlapyje atskirai parodykite kliento ryšį su CDN ar apkrovos paskirstymo įrenginiu, to įrenginio ryšį su programa ir programos jungtis su kitomis paslaugomis. Prie kiekvienos atkarpos pažymėkite, kas inicijuoja ryšį, kas užbaigia TLS ir kas gali matyti iššifruotą turinį. Tas pats domeno vardas gali slėpti kelias skirtingas konfigūracijas.
Į inventorių įtraukite rečiau naudojamus domenus, seną administravimo prievadą, bandomąją aplinką ir tiesioginį prieigos prie programos adresą. Jei tikrinamas tik pagrindinis svetainės vardas, galima nepastebėti kelio, kuriuo apeinamas teisingai sukonfigūruotas tarpinis serveris. Patikrinkite ir IPv4 bei IPv6 atsakymus, kai abu naudojami.
| Inventoriaus laukas | Užpildyto įrašo pavyzdys | Patikros paskirtis |
|---|---|---|
| Galinis taškas | Klientų portalo HTTPS sąsaja | Susieti bandymą su realia paslauga |
| Ryšio atkarpa | Naršyklė → tarpinis serveris | Atskirti nuo ryšio su programa |
| Savininkas | Portalo eksploatavimo komanda | Paskirti pakeitimo ir incidento vykdytoją |
| Sertifikato valdymas | Automatinis išdavimas ir diegimas | Tikrinti visą atnaujinimo grandinę |
| Priklausomybė | Mobilioji programa ir partnerio klientas | Suplanuoti suderinamumo bandymus |
| Priėmimo įrodymas | Bandymo data, priemonės versija, rezultatas | Pakartoti patikrą po pakeitimo |
Protokolo taisykles skaitykite pagal jų taikymo sritį
2026 m. liepos RFC 9852 atnaujina RFC 9325 naujiems protokolams, naudojantiems TLS: TLS 1.3 turi būti numatytoji versija, o dėl diegimo aplinkybių TLS 1.2 gali būti papildoma nenumatytoji parinktis. Šis pakeitimas netaikomas DTLS. Jis taip pat nėra universalus teisinis terminas išjungti visus jau veikiančius TLS 1.2 galinius taškus.
Esamam paslaugų parkui pasirinkite konfigūraciją, įvertinę dabartines rekomendacijas, palaikomus klientus ir riziką. RFC 9325 pateikia saugaus TLS naudojimo rekomendacijas; skaitykite jas kartu su vėlesniais atnaujinimais. Sena taisyklė apie privalomą TLS 1.2 palaikymą neturi būti be konteksto perkeliama į naujo protokolo projektą.
Užrašykite, kokią specifikacijos versiją ir programinės įrangos leidimą naudojote sprendimui. TLS bibliotekos numatytosios reikšmės gali keistis, todėl ankstesnio serverio konfigūracijos kopija nėra pakankamas dabartinės būsenos įrodymas. Operacinių sistemų saugos konfigūravimo eiga padeda šią patikrą susieti su palaikymu ir atnaujinimais.
Parenkite konkretų, išbandytą konfigūracijos profilį
Hipotetinis naujo portalo profilis galėtų būti toks: „Klientų ryšiui naudojame TLS 1.3; prieš paleidimą patikrinamos palaikomos naršyklės ir mobilioji programa; senos SSL ir TLS versijos nepriimamos; išimtis dėl konkretaus partnerio kliento nagrinėjama atskirai.“ Šis pavyzdys parodo užpildytą pasirinkimą, bet neįrodo, kad toks pat palaikymas tinka kiekvienai organizacijai.
Jei esamai integracijai laikinai paliekamas TLS 1.2, išimtyje įvardykite klientą, priežastį, pasirinktas saugias parametrų grupes ir peržiūros sąlygą. Patikrinkite tinkamą raktų apsikeitimą ir autentifikuotą šifravimą pagal aktualias rekomendacijas; nepalikite visų bibliotekos siūlomų rinkinių vien dėl suderinamumo. Bendras leidimas „TLS 1.2 palaikomas“ neatskleidžia, kokia konfigūracija iš tiesų veikia.
Konfigūracijos sprendimo negrįskite vien vienu ilgu šifrų sąrašu, nukopijuotu iš senos instrukcijos. Rinkinių pavadinimai skirtinguose serveriuose gali skirtis, o TLS 1.3 kai kuriuos parametrus derina atskirai nuo ankstesnių versijų. Sutikrinkite savo serverio ir bibliotekos oficialią dokumentaciją, tada išmatuokite, ką galinis taškas iš tikrųjų priima.
Tikrinkite serverio tapatybę, ne vien šifravimą
RFC 9525 aprašo paslaugos tapatybės patikrą TLS kontekste. Praktinėje užduotyje patikrinkite, kad klientas tikrina numatomą paslaugos vardą, tinkamą sertifikato grandinę ir pasitikėjimo šaltinį. Šifruotas ryšys su nepatikrintu gavėju nesuteikia tos pačios apsaugos kaip ryšys su tinkamai patvirtintu serveriu.
Bandymo aplinkoje pateikite netinkamam vardui išduotą sertifikatą, nepatikimos grandinės sertifikatą ir pasibaigusio galiojimo sertifikatą. Klientas turi reaguoti pagal saugų projektą, o ne tęsti perdavimą tyliai išjungęs tikrinimą. Patikrinkite programos biblioteką ir fonines užduotis: naršyklės atsisakymas jungtis neįrodo, kad tuo pačiu adresu saugiai elgiasi serverio integracija.
Vidinei paslaugai naudojama privati sertifikavimo infrastruktūra taip pat reikalauja aiškaus pasitikėjimo valdymo. Nustatykite, kas gali išduoti sertifikatus, kaip paskirstomos patikimos šaknys ir kaip pašalinamas nebereikalingas pasitikėjimas. Techninės pagalbos metu įjungta parinktis netikrinti sertifikato neturi nepastebėta likti gamybinėje konfigūracijoje.
Sertifikato atnaujinimą vertinkite kaip visą procesą
Sertifikato gavimas ir jo įdiegimas yra skirtingi etapai. Automatinė užduotis gali sėkmingai išduoti naują sertifikatą, bet neperkrauti paslaugos arba nepaskirstyti jo visiems mazgams. Stebėkite iš išorės matomą galiojimą ir visų aktualių atkarpų būseną, o ne vien išdavimo sistemos žurnalą.
Pranešimą apie artėjančią galiojimo pabaigą siųskite komandai, kuri tikrai gali imtis veiksmų, ir paskirkite pavaduotoją. Priėmimo bandyme simuliuokite atnaujinimo klaidą: pasibaigusį leidimą valdyti domeno patvirtinimą, nepasiekiamą diegimo mazgą arba netinkamas failo teises. Užrašykite, ar įspėjimas pasiekė žmogų ir ar buvo aišku, kuri paslauga paveikta.
Viešai patikimiems sertifikatams taikomas aktualias išdavimo ir galiojimo taisykles tikrinkite CA/Browser Forum reikalavimuose ir pas savo sertifikato išdavėją. Nenustatykite viso automatizavimo remdamiesi senoje skaidrėje pateiktu vienu galiojimo dienų skaičiumi. Privati infrastruktūra turi kitą pasitikėjimo apimtį ir turi būti valdoma pagal jos paskirtį.
Privatų raktą atskirkite nuo viešo sertifikato
Viešą sertifikatą galima pateikti klientui, tačiau privatus raktas turi būti pasiekiamas tik būtiniems procesams ir administravimo funkcijoms. Inventoriuje užrašykite jo saugojimo vietą, prieigos savininką ir keitimo eigą. Nekopijuokite rakto į bendrą užduoties priedą ar pokalbį tam, kad kitas darbuotojas greičiau įdiegtų paslaugą.
Šifravimo plane numatykite, ką daryti įtarus rakto atskleidimą: pakeisti raktą ir sertifikatą, įvertinti atšaukimo galimybes, užtikrinti naujos konfigūracijos išplatinimą ir ištirti aplinkybes. Vien išduoti naują sertifikatą su tuo pačiu galimai kompromituotu raktu gali nepašalinti pagrindinės problemos. Patikrinkite ir senų kopijų prieigos ribas.
Po TLS užbaigimo patikrinkite likusią atkarpą
CDN arba apkrovos paskirstymo įrenginys dažnai iššifruoja ryšį prieš perduodamas užklausą programai. Atskirai įvertinkite šios atkarpos apsaugą, tapatybės patikrą ir tinklo prieigos ribas. Negalima iš viešo HTTPS patikros rezultato daryti išvados, kad visi vidiniai perdavimai turi tokią pačią apsaugą.
Pavyzdiniame sprendime tarpinis serveris su programa jungiasi šifruotu ryšiu ir tikrina numatytą programos sertifikatą; programa nepriima tiesioginių užklausų iš neleistinų šaltinių. Patikros lape pažymėkite, kur išbandoma kiekviena iš šių sąlygų. Prireikus abipusio TLS, atskirai suplanuokite kliento sertifikatų išdavimą, atšaukimą ir pakeitimą.
Žiniatinklio apsaugas taikykite su atskiru bandymu
HSTS specifikacija RFC 6797 aprašo mechanizmą, kuriuo naršyklei nurodoma naudoti saugų ryšį. Diegiant reikia įvertinti domenų ir subdomenų apimtį bei paslaugų parengtį. Vienas ilgas galiojimo nustatymas, įjungtas nepatikrinus visų susijusių paslaugų, gali sukelti pasiekiamumo problemų.
Prieš išplėsdami nustatymą patikrinkite prisijungimą, atsisiuntimus ir peradresavimus. Ieškokite iš neapsaugotų adresų įkeliamų priklausomybių ir klaidingų nuorodų. HSTS nepakeičia serverio prieigos kontrolės ar pačios programos saugumo; įsiskverbimo bandymo užduotyje tokios sritys vertinamos atskirai.
Išsaugokite patikros įrodymą ir atkūrimo sprendimą
Saugumo audito užduotyje nurodykite tikslų domeną, prievadą, laiką, testuotą ryšio vietą ir priemonės versiją. Išsaugokite reikšmingus parametrus bei išvadą, nes vien bendras balas nepaaiškina, ar tikrinta programa už tarpinio serverio. Galinių taškų, kuriuos leidžiama tikrinti, apimtį suderinkite su jų savininkais.
Keitimui paruoškite IT atkūrimo pratybose išbandomą grįžimo arba alternatyvaus paleidimo eigą. Grįžimas neturi reikšti automatinio nesaugios versijos įjungimo be sprendimo. Pavyzdžiui, sugedus sertifikato diegimui gali būti atkurtas teisingas ankstesnis dar galiojantis komplektas, jei jo raktas nekompromituotas; rakto atskleidimo atveju toks pasirinkimas netinka. Užbaigimo kriterijus — patikrintas saugus ryšys ir veikianti paslauga, o ne vien sėkmingai paleista konfigūravimo komanda.
Automatinio domeno patvirtinimo paskyrai suteikite tik jos užduočiai reikalingas teises. Jeigu atnaujinimo sistema valdo DNS įrašus, patikrinkite, ar jos prieigos raktas nesuteikia neriboto valdymo visoms organizacijos zonoms. Užfiksuokite, kas gali pakeisti automatizavimo konfigūraciją ir kur saugoma paslaptis. Pakeitus tiekėją ar pašalinus paslaugą, panaikinkite ir nebereikalingus patvirtinimo leidimus. Ši priklausomybė svarbi todėl, kad sertifikato procesas gali veikti teisingai, nors jo administravimo paskyra palieka per plačią galimybę keisti organizacijos domenų nustatymus. Kontrolės bandyme įsitikinkite, kad paskyra negali atlikti veiksmų už patvirtintos apimties ribų.