En cloud-migration ændrer næsten alt om hvordan infrastruktur deployes og styres. Den indfører nye netværkstopologier, ny load balancing, nye DNS-konfigurationer og ofte nye tilgange til certifikathåndtering — AWS Certificate Manager, Azure Key Vault, cloud-native ACME-integration. Hver af disse ændringer har certifikatimplikationer. At styre dem godt kræver at behandle certifikater som et førsteklasses hensyn i migrationsplanlægning, ikke en eftertanke.
Hvad der ændres under migration — og hvorfor det betyder noget for certifikater
IP-adresser og hostnavne ændres. Tjenester der flyttes til cloud-infrastruktur får nye IP-adresser. Load balancers ændrer sig. I nogle tilfælde ændres fuldt kvalificerede domænenavne — interne tjenester der tidligere havde hostnavne på privat DNS kan få nye navne. Hver af disse ændringer har certifikatimplikationer: det nye endepunkt har brug for et gyldigt certifikat, og det gamle endepunkt kan stadig køre i en overgangsperiode.
Certifikathåndteringsværktøj ændres. On-premises certifikathåndtering involverer ofte en blanding af CA-portalprocesser, manuel filstyring og brugerdefinerede scripts. Cloud-miljøer tilbyder typisk managed certifikattjenester — AWS Certificate Manager, Azure Key Vault med certifikatstøtte, GCP Certificate Manager. Disse tjenester har forskellige fornyelsesmodeller, forskellige API-grænseflader og forskellige begrænsninger. At migrere fra én tilgang til en anden er i sig selv en certifikatmigration.
Ejerskabsmodellen kan ændres. I traditionelle on-premises miljøer styrer et centralt IT-team ofte alle certifikater. I cloud-miljøer kan individuelle applikationsteams bruge cloud-native certifikattjenester til egne deployments. Denne decentralisering kan forbedre agilitet men komplicerer synlighed — certifikater der tidligere var i en central inventar kan sprede sig over snesevis af cloud-konti og -tjenester.
Nye certifikatkrav opstår. Cloud-miljøer indfører ofte nye TLS-kommunikationsstier der ikke eksisterede on-premises: inter-service mTLS i et service mesh, load balancer til backend TLS, privat CA til interne Kubernetes-tjenester. Disse kræver certifikater der måske ikke er overvejet i den eksisterende certifikathåndteringsproces.
Dual-miljøperioden
De fleste migrationer kører begge miljøer parallelt i en periode — det gamle miljø håndterer trafik mens det nye valideres, med en omskæring når tilliden er etableret. Denne dual-miljøperiode skaber specifikke certifikatrisici:
Certifikater der udløber i det gamle miljø under overgangen. Hvis migrationen kører længere end planlagt og certifikater i det gamle miljø udløber under overgangsperioden, stopper det gamle miljø med at virke inden migrationen er komplet. Dette er særlig farligt når det gamle miljø stadig håndterer produktionstrafik mens det nye valideres.
Certifikater udstedt til nye endepunkter der ikke dækker gamle endepunkter. Nye certifikater udstedt til cloud-miljøet kan dække nye hostnavne men ikke gamle. Under overgangen kan trafik stadig nå gamle hostnavne der har brug for deres egne aktuelle certifikater.
Certifikatinventars divergens. Under overgangsperioden skal certifikatinventaret afspejle begge miljøer. Hvis overvågning kun dækker ét — typisk det originale miljø — er det nye miljøs certifikater uovervågede og kan udløbe uden at udløse advarsler.
Certifikatplanlægning til migrationer
Den praktiske tilgang er at behandle certifikatmigrationen som et eksplicit arbejdsspor ved siden af infrastrukturmigrationen, ikke som noget der håndteres implicit. Det betyder:
Inden migrationen begynder:
- Oprid alle certifikater i det eksisterende miljø — ikke kun dem du kender til, men alt, inklusiv certifikater på tjenester der migreres og måske ikke er i det nuværende sporsystem.
- Kontroller udløbsdatoer for alle certifikater mod den forventede migringstidslinje. Ethvert certifikat der udløber under migrationsvinduet skal fornyes inden migrationen eller have en specifik fornyelsesplan som del af migrationsplanen.
- Dokumenter certifikathåndteringstilgangen til målmiljøet — hvilke managed tjenester der vil bruges, hvordan fornyelse håndteres, hvem der er ansvarlig.
Under migrationen:
- Tilføj nye miljøendepunkter til certifikatovervågning efterhånden som de oprettes — vent ikke til migrationen er komplet.
- Verificer certifikatdækning for hver tjeneste inden omskæring — kontroller at det korrekte certifikat er på plads, at kæden er gyldig og at TLS-konfiguration opfylder krav.
- Vedligehold overvågning af det gamle miljø indtil det er fuldt udfaset. Certifikater i det gamle miljø er stadig produktionscertifikater mens det håndterer trafik.
Efter migrationen:
- Fjern gamle miljøendepunkter fra den overvågede inventar når de er udfaset — efterlad ikke forældede endepunkter der genererer falske advarsler.
- Ryd DNS op. Fjern CNAME-records og A-records der peger på udfaset infrastruktur. Dangling DNS efter en migration er en almindelig kilde til subdomain takeover-sårbarheder.
- Verificer at det nye miljøs certifikathåndteringstilgang — hvad enten det er managed tjeneste eller ACME-automatisering — virker korrekt og er dækket af overvågning.
Private CA'er og interne certifikater i cloud-miljøer
Cloud-migrationer afslører ofte intern certifikatkompleksitet der tidligere var skjult. On-premises tjenester der kommunikerer over private netværk har måske slet ikke brugt TLS — netværket blev anset for betroet. I cloud-miljøer skubber den delte ansvarsmodel og zero-trust sikkerhedsprincipper mod at kryptere al intern kommunikation, inklusiv service-til-service trafik.
Dette skaber behov for intern certifikatinfrastruktur der måske ikke har eksisteret før. Cloud-udbydere tilbyder managed private CA-tjenester (AWS Private CA, Azure Private CA) der kan håndtere dette, men de skal planlægges, konfigureres og integreres med de tjenester der har brug for interne certifikater.
Hvordan CertControl understøtter migrationer
CertControls evne til at tilføje og overvåge endepunkter i både gamle og nye miljøer simultant gør den velegnet til dual-miljø migrationsperioden. Efterhånden som nye tjenester kommer online i cloud-miljøet kan de tilføjes til overvågning øjeblikkeligt — giving samme dækning til det nye miljø som det eksisterende miljø allerede har.
CT-log-enumeration brugt af den eksterne scanner opdager automatisk nye underdomæner efterhånden som de får certifikater — så nye cloud-tjenester der skaffer offentligt betroede certifikater vises i certifikatinventaret inden for minutter efter udstedelse, uden at kræve manuelle inventaropdateringer under en allerede kompleks migrationsproces.