Kodėl sertifikatų valdymas tampa vis didesniu galvos skausmu
Prisimenu, kaip prieš kokius dešimt metų SSL sertifikato įdiegimas buvo tarsi šventė – padarei kartą ir galėjai ramiai gyventi metus ar net trejus. Dabar situacija pasikeitė kardinaliai. Let’s Encrypt atsiradimas pakeitė žaidimo taisykles, sertifikatai galioja 90 dienų, o kai kurie jau kalba apie 30 dienų galiojimą. Pridėkime prie to mikroservisų architektūras, konteinerius, cloud infrastruktūrą – ir gauname tikrą sertifikatų valdymo košmarą.
Problema ta, kad daugelis organizacijų vis dar bando valdyti sertifikatus rankiniu būdu arba naudoja pusiau automatizuotus sprendimus, kurie veikia tik tam tikrose aplinkose. O kai turite šimtus ar tūkstančius domenų, API endpointų, vidinių servisų – rankinis valdymas tiesiog nebeįmanomas. Esu matęs situacijų, kai production aplinkoje krito servisai vien todėl, kad kažkas pamiršo atnaujinti sertifikatą. Ir tai nutinka net didelėse kompanijose su brandžiomis DevOps komandomis.
Automatizacija – ne prabanga, o būtinybė
Šiandien automatizuotas sertifikatų valdymas turėtų būti default pasirinkimas, o ne kažkoks „nice to have” dalykas. ACME (Automatic Certificate Management Environment) protokolas tapo de facto standartu, ir jei jūsų infrastruktūra jo nepalaiko – laikas rimtai pagalvoti apie migraciją.
Certbot yra populiariausias įrankis, bet toli gražu ne vienintelis. Kubernetes aplinkoje daug kas naudoja cert-manager, kuris puikiai integruojasi su Ingress kontroleriais. Jei dirbate su AWS, Certificate Manager gali automatiškai valdyti sertifikatus jūsų load balanceriams ir CloudFront distribucijai. Azure turi savo App Service Certificates, o Google Cloud – Certificate Manager.
Bet štai ką pastebėjau praktikoje – daugelis žmonių tiesiog įdiegia Certbot su cron job’u ir mano, kad viskas tvarkoje. Realybėje reikia pagalvoti apie daug daugiau dalykų. Kas nutiks, jei ACME challenge’as nepavyks? Ar gausite įspėjimą prieš 30 dienų iki sertifikato pabaigos? Ar jūsų monitoring sistema stebi sertifikatų galiojimo terminus? Ar turite backup planą, jei Let’s Encrypt bus nepasiekiamas?
Praktinis automatizacijos setup’as
Jei naudojate tradicinius serverius su Nginx ar Apache, Certbot su systemd timer’iu yra geras startas:
sudo certbot renew --deploy-hook "systemctl reload nginx"
Bet pridėkite monitoring’ą. Galite naudoti Prometheus su ssl_exporter arba tiesiog paprastą bash skriptą, kuris tikrina sertifikato galiojimą ir siunčia alert’ą:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates
Kubernetes aplinkoje cert-manager konfigūracija atrodo maždaug taip:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com
spec:
secretName: example-com-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- example.com
- www.example.com
Svarbu suprasti, kad cert-manager ne tik išduoda sertifikatus, bet ir automatiškai juos atnaujina, kol galiojimo laikas lieka apie 30 dienų.
Vidiniai sertifikatai ir Private CA
Dabar pereikime prie dalies, kurią daugelis ignoruoja – vidinių sertifikatų valdymo. Jūsų mikroservisai tarpusavyje bendrauja per HTTPS? Jūsų duomenų bazės naudoja TLS? Internal API? Visur reikia sertifikatų, ir Let’s Encrypt čia nepadės, nes jie neišduoda sertifikatų privatiems IP adresams ar internal domenams.
Čia reikia savo Certificate Authority. Galite naudoti įrankius kaip Vault iš HashiCorp, CFSSL, ar net sukurti savo CA su OpenSSL (nors tai rekomenduočiau tik labai mažoms aplinkomms ar testavimui). Vault PKI engine yra ypač galingas – jis gali dinamiškai generuoti trumpalaikius sertifikatus, kurie galioja vos kelias valandas ar dienas.
Štai kodėl trumpalaikiai sertifikatai vidinėje infrastruktūroje yra gera idėja: jei kažkas pavogs sertifikatą, jis bus nenaudingas po kelių dienų. Tai drastiškai sumažina attack surface. Bet čia vėl grįžtame prie automatizacijos – niekas nebus kas kelias dienas rankomis atnaujinęs šimtų servisų sertifikatų.
Vault PKI praktikoje
Vault setup’as gali atrodyti sudėtingas iš pradžių, bet apsimoka. Jūs sukuriate root CA (kurį laikote offline), intermediate CA (su kuriuo dirbate kasdien), ir tada aplikacijos gali automatiškai gauti sertifikatus per API.
Pavyzdžiui, jūsų aplikacija gali kas 24 valandas gauti naują sertifikatą:
vault write pki_int/issue/my-role common_name="service.internal" ttl="24h"
Ir tai gali būti integruota į jūsų deployment pipeline arba init container’į Kubernetes’e.
Certificate pinning ir jo problemos
Kai kurie saugumo entuziastai vis dar rekomenduoja certificate pinning, ypač mobiliose aplikacijose. Idėja paprasta – aplikacija „žino” tikslų sertifikatą ar public key, kurį turėtų matyti, ir atmeta bet ką kitą. Teoriškai tai apsaugo nuo MITM atakų, net jei užpuolikas turi validų sertifikatą iš patikimo CA.
Bet praktikoje certificate pinning yra maintenance košmaras. Kas nutiks, kai reikės atnaujinti sertifikatą? Jei pin’inote leaf certificate, turite išleisti aplikacijos update’ą. Jei pin’inote intermediate CA, esate šiek tiek saugesni, bet vis tiek priklausomi nuo CA infrastruktūros stabilumo.
Esu matęs atvejų, kai kompanijos dėl certificate pinning negalėjo greitai pakeisti CDN provider’io ar migruoti į kitą cloud platform’ą. Arba dar blogiau – išleido aplikacijos versiją su pin’u, kuris netrukus paseno, ir vartotojai negalėjo naudotis aplikacija, kol neišėjo update’as.
Jei vis tiek norite naudoti pinning, bent jau pin’inkite kelis sertifikatus (current ir backup), naudokite public key pinning vietoj certificate pinning, ir turėkite emergency bypass mechanizmą.
Multi-cloud ir hybrid aplinkų iššūkiai
Kai jūsų infrastruktūra išsidėsčiusi keliuose cloud provider’iuose ir on-premise datacenter’iuose, sertifikatų valdymas tampa dar sudėtingesnis. Kiekvienas cloud turi savo certificate management sprendimą, kuris puikiai veikia jų ekosistemoje, bet ne už jos ribų.
AWS Certificate Manager sertifikatų negalite eksportuoti (bent jau tų, kuriuos jie išduoda nemokamai). Azure App Service Certificates galite eksportuoti, bet tai ne visai trivialus procesas. Google Cloud Certificate Manager turi panašių apribojimų.
Praktikoje tai reiškia, kad jums reikia centralizuoto sprendimo, kuris veikia visur. Čia populiarūs variantai yra:
– Naudoti Let’s Encrypt su DNS-01 challenge visur (veikia bet kurioje aplinkoje, kol turite DNS kontrolę)
– Turėti savo PKI infrastruktūrą su Vault ar panašiu įrankiu
– Naudoti komercines certificate management platformas kaip Venafi, DigiCert CertCentral, ar Sectigo
DNS-01 challenge yra ypač naudingas, nes nepriklausote nuo HTTP prieigos prie serverio. Jūs tiesiog sukuriate TXT įrašą DNS zone, ir ACME serveris jį patikrina. Tai veikia net internal servisams, jei turite public DNS zoną.
Wildcard sertifikatai – ar verta?
Wildcard sertifikatai (*.example.com) atrodo kaip paprasta išeitis – vienas sertifikatas visiems subdomenams. Bet yra keletas aspektų, apie kuriuos verta pagalvoti.
Pirma, jei šis sertifikatas nutekės, užpuolikas gali impersonate bet kurį jūsų subdomeną. Su individual sertifikatais žala būtų ribota. Antra, wildcard sertifikatai veikia tik vieno lygio subdomenams – *.example.com veiks su api.example.com, bet ne su v1.api.example.com.
Trečia, kai naudojate Let’s Encrypt, wildcard sertifikatams privalomas DNS-01 challenge, kuris reikalauja DNS API prieigos. Ne visi DNS provider’iai turi gerą API, o kai kurie ima už tai papildomai.
Mano rekomendacija – naudokite wildcard sertifikatus tik ten, kur tikrai turi prasmę (pvz., multi-tenant SaaS platformoje, kur kiekvienas klientas gauna subdomeną), o kitur geriau individual sertifikatai su automatizuotu valdymu.
Monitoring ir alerting – nematoma, bet kritinė dalis
Geriausias sertifikatų valdymo procesas vis tiek gali sužlugti, jei nežinote, kad kažkas nutiko. Monitoring’as turi būti daugiasluoksnis.
Pirmiausia, stebėkite sertifikatų galiojimo terminus. Ne tik production aplinkoje, bet ir staging, development, internal servisams. Įprastas pattern’as – alert’inti 30, 14 ir 7 dienas prieš pabaigą. Bet jei naudojate 90 dienų sertifikatus su automatiniu atnaujinimu, galbūt pakaks 7 ir 3 dienų alert’ų – jei atnaujinimas nepavyko, turite laiko išsiaiškinti kodėl.
Antra, stebėkite sertifikatų atnaujinimo procesus. Jei naudojate Certbot, loginkite visus bandymus ir sėkmingus atnaujinimus. Jei naudojate cert-manager Kubernetes’e, stebėkite Certificate resource status. Jei Vault – audit log’us.
Trečia, darykite išorinius patikrinimus. Net jei jūsų vidinis monitoring’as rodo, kad viskas gerai, patikrinkite iš išorės, ar sertifikatas tikrai validus. Galite naudoti įrankius kaip SSL Labs API, arba paprastą curl komandą iš external monitoring serverio:
curl -vI https://yourdomain.com 2>&1 | grep -A 5 "SSL certificate"
Ketvirta, stebėkite certificate transparency logs. Kai išduodamas naujas sertifikatas jūsų domenui, jis atsiranda CT log’uose per kelias minutes. Tai gali padėti aptikti neleistinus sertifikatų išdavimus (kas reiškia, kad kažkas kompromitavo jūsų domeną ar DNS).
Kai viskas eina ne pagal planą
Nepaisant visos automatizacijos ir monitoring’o, kartais sertifikatai vis tiek pasibaigia netikėtai. Galbūt ACME challenge’as nepavyko dėl firewall konfigūracijos pasikeitimo. Galbūt DNS API buvo nepasiekiamas kritiniu momentu. Galbūt kažkas rankomis pakeitė konfigūraciją ir sulaužė automatizaciją.
Turėkite emergency runbook’ą. Jame turėtų būti:
1. Kaip greitai patikrinti, kurie sertifikatai pasibaigę ar baigiasi
2. Kaip rankiniu būdu išduoti naują sertifikatą (taip, net jei viskas automatizuota)
3. Kaip deploy’inti naują sertifikatą be downtime
4. Kontaktai atsakingų žmonių ir vendor’ių (jei naudojate komercines CA)
5. Backup sertifikatai kritiniams servisams
Praktinis patarimas – laikykite backup sertifikatus iš kito CA provider’io. Jei naudojate Let’s Encrypt production, turėkite backup iš ZeroSSL ar kito ACME provider’io. Jei naudojate komercinį CA, turėkite Let’s Encrypt backup’ą.
Dar vienas dalykas – mokykite savo on-call komandą, kaip spręsti sertifikatų problemas. Tai turėtų būti dalis incident response training’o. Esu matęs situacijų, kai 3 AM incident’o metu on-call engineer’ius nežinojo, kaip atnaujinti sertifikatą, nes „tai visada veikdavo automatiškai”.
Rate limiting ir backup planai
Let’s Encrypt turi rate limit’us – 50 sertifikatų per savaitę vienam domenui, 300 pending authorization’ų per account. Jei hit’inate šiuos limit’us (pvz., dėl bug’o deployment pipeline’e), negalėsite gauti naujų sertifikatų kelias dienas.
Todėl naudokite Let’s Encrypt staging environment’ą testavimui. Jis turi tokius pat API endpoint’us, bet daug didesnius rate limit’us ir išduoda netrusted sertifikatus. Testuokite visus automation script’us staging’e prieš production.
Ir turėkite backup CA. Kai Let’s Encrypt turėjo incident’ą 2020-ais ir revoke’ino milijonus sertifikatų dėl bug’o, daugelis organizacijų, kurios neturėjo backup plano, patyrė downtime.
Ateities perspektyvos ir ką daryti dabar
Industrija juda link vis trumpesnių sertifikatų galiojimo terminų. Apple jau riboja sertifikatų galiojimą iki 398 dienų naršyklėse. CA/Browser Forum diskutuoja 90 dienų maksimumą visiems publicly-trusted sertifikatams. Kai kurie siūlo net 30 dienų ar trumpesnius terminus.
Tai reiškia, kad jei dar neautomatizavote sertifikatų valdymo – dabar pats laikas. Rankinis valdymas tiesiog nebus įmanomas. Ir tai gerai – trumpesni terminai reiškia mažesnę riziką, jei sertifikatas kompromituojamas.
Kitas trend’as – post-quantum cryptography. NIST jau standartizavo post-quantum algoritmus, ir artimiausiais metais matysime jų integraciją į TLS. Tai reikš naujus key type’us, didesnius sertifikatus, ir potencialiai suderinamumo problemas su senesniais sistemomis. Bet tai tema kitam straipsniui.
Dabar svarbu susitvarkyti fundamentus. Įsitikinkite, kad:
– Visi jūsų sertifikatai valdomi centralizuotai (turite inventory, žinote, kas kur yra)
– Atnaujinimas automatizuotas visur, kur įmanoma
– Monitoring’as veikia ir alert’ina tinkamus žmones
– Turite disaster recovery planą
– Komanda žino, kaip spręsti problemas rankiniu būdu
Jei dirbate su legacy sistemomis, kurios nepalaiko automatizacijos – pradėkite nuo inventory. Bent jau žinokite, kokie sertifikatai kur naudojami ir kada pasibaigia. Tada galite planuoti migraciją ar wrapper’ių kūrimą automatizacijai.
Jei kuriate naują sistemą – certificate management turėtų būti įtrauktas į architektūrą nuo pat pradžių, ne kaip afterthought. Tai reiškia ACME support’ą, API endpoint’us sertifikatų valdymui, proper secret management (niekada nehardcode’inkite sertifikatų į container image’us!).
Ir galiausiai – dokumentuokite viską. Jūsų automation script’ai turėtų turėti komentarus. Jūsų runbook’ai turėtų būti up-to-date. Kai kas nors naujas prisijungia prie komandos arba kai jūs patys grįžtate po atostogų, turėtumėte sugebėti greitai suprasti, kaip viskas veikia. Sertifikatų valdymas nėra glamorous darbas, bet kai jis veikia sklandžiai, niekas apie tai negalvoja – o tai ir yra tikslas.