Cloudgebaseerd certificaatbeheer

Certificaatbeheer in de cloud is het proces van het ontdekken, uitgeven, verlengen, intrekken en controleren van digitale certificaten in cloudinfrastructuren, containers en hybride omgevingen vanuit een gecentraliseerd platform. Dit is belangrijk omdat cloudomgevingen certificaten genereren op een schaal en met een snelheid die handmatige registratie niet kan bijhouden, en een enkel verlopen certificaat in een load balancer of API gateway een volledige servicestoring kan veroorzaken. De aanbevolen actie is om een ​​gecentraliseerd platform voor certificaatlevenscyclusbeheer (CLM) met geautomatiseerde ACME-gebaseerde verlenging te implementeren voordat het SC-081v3-schema van het CA/Browser Forum de geldigheidsduur van TLS-certificaten tegen maart 2029 reduceert tot 47 dagen.

Kort antwoord: Wat is er nodig voor cloudgebaseerd certificaatbeheer?

Certificaatbeheer in de cloud vereist vier functionaliteiten die samenwerken: continue detectie van alle certificaten in elk cloudaccount, elke regio en elke service, zodat geen enkel certificaat onzichtbaar is voor het beveiligingsteam; geautomatiseerde verlenging via ACME of cloud-native API's voordat certificaten verlopen; bescherming van privésleutels in hardware-ondersteunde sleutelarchieven in plaats van in applicatieconfiguratie of omgevingsvariabelen; en een gecentraliseerd auditlogboek van elke uitgifte-, verlengings- en intrekkingsgebeurtenis gekoppeld aan een geauthenticeerde identiteit. Elk van deze functionaliteiten is afzonderlijk noodzakelijk; geen enkele is op zichzelf voldoende.

Key Takeaways

• De wildgroei aan certificaten is het grootste risico voor CLM in de cloud: Cloud-autoscaling, containers en microservices genereren programmatisch certificaten, vaak zonder dat IT daar zicht op heeft. De meeste organisaties ontdekken na een volledige cloudscan dat ze drie tot vijf keer meer certificaten hebben dan ze dachten.
• Kortere geldigheidsperioden maken automatisering noodzakelijk: Het CA/Browser Forum SC-081v3-schema verkort de maximale geldigheidsduur van TLS-certificaten tot 200 dagen vanaf maart 2026, 100 dagen vanaf maart 2027 en 47 dagen vanaf maart 2029. Bij een geldigheidsduur van 47 dagen is handmatige verlenging op grote schaal operationeel onmogelijk.
• Native cloud CLM en CLM van derden hebben verschillende toepassingsgebieden: Native services (AWS Certificate Manager, Azure App Service-certificaten, GCP Certificate Manager) automatiseren de verlenging binnen het ecosysteem van één cloudprovider. Platforms voor certificaatbeheer van derden bieden uniforme zichtbaarheid en beleidshandhaving voor alle cloudproviders, on-premises systemen en certificaattypen.
• De bescherming van privésleutels is net zo belangrijk als het vernieuwen van certificaten: Een geautomatiseerd vernieuwingsproces dat de nieuwe privésleutel in platte tekst opslaat in een omgevingsvariabele of configuratiebestand, zorgt voor een slechtere beveiliging dan het verlopen certificaat dat het vervangt.
• Compliancekaders vereisen nu expliciet certificaatbeheer: PCI DSS v4.0.1 (verplicht vanaf maart 2025), DORA (van toepassing vanaf januari 2025), HIPAA, FedRAMP en GDPR vereisen allemaal gedocumenteerde controlemechanismen voor de levenscyclus van certificaten, niet alleen encryptie tijdens de overdracht.

Wat is cloudgebaseerd certificaatbeheer?

Een digitaal certificaat is een cryptografische authenticatie die een publieke sleutel koppelt aan een identiteit (een domeinnaam, een service, een apparaat of een persoon) en is ondertekend door een certificeringsinstantie (CA) om die koppeling betrouwbaar te maken voor de partijen die erop vertrouwen. TLS/SSL-certificaten zijn het meest voorkomende type in cloudomgevingen: ze authenticeren webservers, API-eindpunten, loadbalancers en interne microservices bij clients en versleutelen de verbinding ertussen.

Certificaatbeheer in de cloud omvat de volledige levenscyclus van deze certificaten in cloudomgevingen: ontdekking (het vinden van elk certificaat in elk cloudaccount en elke regio), uitgifte (het aanvragen van certificaten bij een openbare of private CA), implementatie (het installeren van certificaten op de juiste eindpunten), verlenging (het vervangen van certificaten voordat ze verlopen), intrekking (het ongeldig verklaren van gecompromitteerde of buiten gebruik gestelde certificaten) en audit (het vastleggen van elke gebeurtenis in de levenscyclus als bewijs van naleving). Het handmatig beheren van deze levenscyclus via spreadsheets en agendaherinneringen schiet tekort in cloudomgevingen waar duizenden certificaten aanwezig zijn en hun geldigheidsperioden steeds korter worden, tot wel 47 dagen.

Waarom cloudomgevingen certificaatbeheer lastiger maken

In on-premises omgevingen is de inventaris van servers en services doorgaans beperkt en relatief statisch, en elk server en service beschikt over certificaten met een geldigheidsduur van één tot twee jaar. Cloudomgevingen verschillen fundamenteel op vier manieren, die elk het probleem van certificaatbeheer verergeren.

Schaalbaarheid en snelheid: Automatisch schaalbare groepen, containerorkestratieplatforms (Kubernetes), serverloze functies en microservice-implementaties genereren en gebruiken certificaten programmatisch. Een enkel Kubernetes-cluster kan honderden pods draaien, elk met een eigen servicecertificaat, waarbij pods continu worden aangemaakt en verwijderd. De certificaatinventaris in een cloudomgeving verandert sneller dan welk handmatig proces dan ook kan bijhouden.

Gedistribueerd eigenaarschap: In cloudomgevingen worden certificaten verstrekt door applicatieteams, DevOps-pipelines, platformontwikkelingsteams en soms individuele ontwikkelaars, vaak zonder centrale IT-betrokkenheid. Dit creëert een schaduwinventaris van certificaten die het beveiligingsteam niet kan inzien, waardoor certificaten zonder waarschuwing verlopen en privésleutels onveilig worden opgeslagen in applicatierepositories.

Complexiteit van multi-cloud en hybride omgevingen: De meeste bedrijven voeren workloads gelijktijdig uit op AWS, Azure en GCP, naast hun eigen infrastructuur. Elke cloudprovider heeft zijn eigen certificeringsservices met verschillende API's, certificaattypen en vernieuwingsmechanismen. Om certificaatbeleid consistent te beheren in dit landschap is een beheerlaag boven de individuele cloudproviders nodig.

Kortere geldigheidsperioden: Het CA/Browser Forum-voorstel SC-081v3 verkort de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten gefaseerd: 200 dagen vanaf 15 maart 2026; 100 dagen vanaf 15 maart 2027; en 47 dagen vanaf 15 maart 2029. Bij een geldigheidsduur van 47 dagen moet elk certificaat in een grote cloudomgeving ongeveer acht keer per jaar worden vernieuwd. Dit maakt geautomatiseerde vernieuwing niet langer een aanbevolen werkwijze, maar een operationele noodzaak.

Native cloud CLM versus CLM-platform van derden: wat elk platform biedt

Elke grote cloudprovider biedt een eigen certificaatbeheerservice aan. Het is essentieel om te begrijpen wat elke service inhoudt en waartoe deze beperkt is, voordat u een CLM-strategie kiest.

AWS Certificate Manager (ACM): Geeft openbare TLS-certificaten uit en vernieuwt deze automatisch voor AWS-resources (Elastic Load Balancers, CloudFront-distributies, API Gateway, Elastic Beanstalk). Privésleutels worden door AWS beheerd in HSM-opslag en worden nooit openbaar gemaakt; u kunt ze niet exporteren. ACM ondersteunt ook een Private CA-add-on voor het uitgeven van privécertificaten. ACM beheert geen certificaten op niet-AWS-infrastructuur, biedt geen inzicht in certificaten die rechtstreeks op EC2-instanties zijn geïmplementeerd en beheert geen certificaten van externe CA's buiten het ACM-ecosysteem.

Azure Key Vault-certificaten: Hiermee worden certificaten opgeslagen, beheerd en automatisch vernieuwd binnen Azure Key Vault, met integratie met Azure-services (App Service, Application Gateway, Front Door). Ondersteunt certificaten van DigiCert en GlobalSign via de CA-partnerintegraties van Key Vault en ondersteunt het importeren van certificaten van andere CA's. Azure Key Vault beheert geen certificaten in AWS- of GCP-omgevingen en inzicht in certificaten buiten Key Vault vereist aanvullende tools.

GCP Certificate Manager: Beheert SSL-certificaten voor Google Cloud load balancers en Cloud CDN, met ACME-gebaseerde geautomatiseerde verlenging voor door Google beheerde certificaten. GCP Certificate Authority Service (CAS) biedt een beheerde privé-CA voor het uitgeven van interne certificaten. GCP Certificate Manager beheert geen certificaten in omgevingen buiten GCP.

De reikwijdtebeperking van elke native service is hetzelfde: deze beheert certificaten binnen het ecosysteem van de eigen cloudprovider. Een organisatie die workloads uitvoert bij alle drie de providers heeft drie afzonderlijke certificaatsilo's zonder uniforme inventaris, zonder consistente beleidshandhaving en zonder centraal auditlogboek.

Bekwaamheid	Native Cloud CLM (per provider)	CLM-platform van derden
Omvang van de inzage in certificaten	Binnen één cloudprovider	Alle cloudproviders, on-premises, SaaS
Beheerde certificaattypen	TLS voor de resources van die provider	TLS, codeondertekening, S/MIME, apparaat, SSH
CA-integraties	Eigen CA (en commanditaire vennoten) van de aanbieder	Elke openbare CA, elke particuliere CA, ACME
Automatische verlenging	Ja (binnen die aanbieder)	Ja (voor alle aanbieders via ACME/API)
Uniforme handhaving van het beleid	Nee (alleen per aanbieder)	Ja (één beleid voor alle omgevingen)
Gecentraliseerd auditlogboek	Nee (alleen logboeken per provider)	Ja (één enkel controletraject voor naleving)
Zichtbaarheid van privésleutels	Beheerd door de provider (niet exporteerbaar in ACM)	Configureerbaar; opties met HSM-ondersteuning beschikbaar
Best voor	Eén cloud, eenvoudige workloads	Multicloud, gereguleerde, grootschalige omgevingen

Bescherming van privésleutels in cloudcertificaatbeheer

Een compromittering van een privésleutel is een ernstiger beveiligingsincident dan het verlopen van een certificaat. Een verlopen certificaat veroorzaakt een storing; een gecompromitteerde privésleutel kan een aanvaller in staat stellen zich voor te doen als uw service, historisch verkeer te decoderen of kwaadaardige inhoud te ondertekenen. Cloudomgevingen brengen diverse risico's met zich mee met betrekking tot de blootstelling van privésleutels die bij on-premises implementaties doorgaans niet voorkomen.

De meest voorkomende manieren waarop privésleutels in de cloud kunnen worden blootgesteld zijn: privésleutels die in platte tekst zijn opgeslagen in applicatieconfiguratiebestanden of omgevingsvariabelen die zichtbaar zijn in versiebeheer; privésleutels die zijn opgenomen in containerimages die naar openbare of gedeelde registers worden gepusht; privésleutels die zijn opgeslagen in S3-buckets, Azure Blob-containers of GCS-buckets met te ruime toegangsbeleidsregels; en privésleutels in CI/CD-pipelinegeheimen die toegankelijk zijn voor alle pipelines in een repository zonder bereikbeperking.

De juiste architectuur voor de bescherming van privésleutels in cloudomgevingen hangt af van de vraag of de privésleutel tijdens de uitvoering toegankelijk moet zijn voor de applicatie of niet.

Sleutels beheerd door de cloud-CLM-service (niet toegankelijk voor de applicatie): Gebruik voor TLS-certificaten op loadbalancers, API-gateways en CDN-eindpunten de eigen certificaatbeheerservice van de cloudprovider. AWS ACM, Azure Key Vault Certificate Integration en GCP Certificate Manager slaan privésleutels op in een door HSM ondersteunde infrastructuur en presenteren het certificaat aan de service zonder de privésleutel aan de applicatie of een IAM-principal bloot te stellen. Dit is het veiligste model en moet worden gebruikt wanneer de applicatie geen directe toegang tot de sleutel nodig heeft.

Sleutels die tijdens runtime toegankelijk zijn voor de applicatie: Voor wederzijdse TLS (mTLS) tussen services, codeondertekening of certificaattypen waarbij de applicatie rechtstreeks cryptografische bewerkingen moet uitvoeren, slaat u de privésleutel op in een cloudgeheimbeheerder (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Vernieuw het geheim volgens hetzelfde schema als de certificaatvernieuwing. Sla de sleutel nooit op als een Kubernetes-geheim in platte tekst (YAML); gebruik een externe geheimoperator om deze vanuit de geheimbeheerder te injecteren bij het opstarten van de pod.

Voor de hoogste eisen aan sleutelbeveiliging (FIPS 140-2 Level 3, FedRAMP High of geclassificeerde workloads) gebruikt u een speciale Hardware Security Module (HSM) voor het genereren en opslaan van privésleutels. Cloudproviders bieden HSM-ondersteunde sleutelopslag aan via AWS CloudHSM, Azure Dedicated HSM en GCP Cloud HSM. HSM as a Service van Encryption Consulting biedt een speciale FIPS 140-2 Level 3 HSM-infrastructuur die integreert met cloudgebaseerde certificaatbeheerworkflows.

IAM-model voor cloudcertificaatbeheer

Toegangscontrole voor cloudcertificaatbeheer moet het principe van minimale bevoegdheden op drie niveaus toepassen, waarbij onderscheid wordt gemaakt tussen wie certificaten mag uitgeven, wie toegang heeft tot privésleutels en wie het CLM-platform zelf mag beheren.

Machtigingen voor het afgeven van certificaten: Alleen geautoriseerde identiteiten (applicatie-implementatiepipelines, CLM-serviceaccounts of goedgekeurde DevOps-rollen) mogen een certificaat aanvragen bij de CA. In AWS ACM betekent dit dat IAM-beleid dat certificaten verleent, dit mogelijk maakt. acm:RequestCertificate Alleen voor specifieke rollen. In Azure Key Vault betekent dit dat de rol 'Key Vault Certificates Officer' wordt toegewezen aan specifieke serviceprincipals. Ontwikkelaars en applicatie-runtime-rollen mogen geen machtigingen hebben om certificaten uit te geven.

Toegangsrechten voor privésleutels: De toegang tot privésleutels die zijn opgeslagen in Secrets Managers of Key Vault moet worden beperkt tot de specifieke applicatie-identiteit die de sleutel nodig heeft, met behulp van machtigingen op resourceniveau in plaats van algemene leesrechten voor Secrets Manager. In AWS kunt u Secrets Manager-resourcebeleid gebruiken om de toegang te beperken. secretsmanager:GetSecretValue aan de specifieke IAM-rol van de toepassing. In Azure kunt u toegangsbeleid voor Key Vault of RBAC gebruiken om toegang te verlenen. Key Vault Secrets User alleen voor de specifieke beheerde identiteit van de applicatie.

CLM-platformbeheer: De mogelijkheid om CA-integraties te configureren, certificaatbeleid in te stellen, de uitgifte van gevoelige certificaattypen goed te keuren en toegang te krijgen tot het CLM-auditlogboek, moet een aparte, gecontroleerde CLM-beheerdersrol vereisen, die verschilt van de rollen die door applicatiepipelines worden gebruikt. Geen enkel CI/CD-serviceaccount mag CLM-beheerdersrechten hebben. Dwing MFA af voor alle CLM-beheerderstoegang.

ACME Automation: Hoe geautomatiseerde certificaatvernieuwing in de cloud werkt

ACME (Automatic Certificate Management Environment) is een IETF-protocol, gedefinieerd in RFC 8555, dat de uitgifte en verlenging van certificaten automatiseert. Een ACME-client bewijst aan een ACME-compatibele CA dat deze een domein (of, voor IP-certificaten, een IP-adres) beheert via een van de verschillende uitdagingstypen, waarna de client zonder menselijke tussenkomst een ondertekend certificaat ontvangt. ACME is het protocol achter de gratis openbare certificaatuitgifte van Let's Encrypt en wordt ondersteund door een groeiend aantal zakelijke CA's.

In cloudomgevingen werkt ACME met drie primaire soorten uitdagingen:

• HTTP-01-uitdaging: De ACME-client plaatst een token op een bekende HTTP-URL op het te valideren domein. De certificeringsinstantie (CA) haalt de URL op en verifieert het token. Dit werkt voor via internet toegankelijke eindpunten, maar niet voor interne services of wildcardcertificaten.
• DNS-01-uitdaging: De ACME-client maakt een TXT-record aan in de DNS-zone voor het te valideren domein. De certificeringsinstantie (CA) voert een DNS-query uit om het record te verifiëren. Dit werkt voor wildcardcertificaten en voor interne services waar HTTP-validatie niet mogelijk is. Cloud-DNS-providers (Route 53, Azure DNS, Cloud DNS) ondersteunen allemaal het programmatisch aanmaken van DNS-records, waardoor DNS-01 het voorkeurstype voor verificatie in de cloud is.
• TLS-ALPN-01-uitdaging: De ACME-client reageert op een TLS-handshake op poort 443 met behulp van een speciaal certificaat dat het validatietoken bevat. Dit wordt minder vaak gebruikt in cloudomgevingen vanwege de complexiteit van load balancers.

Een ACME-implementatie in een productieomgeving voor cloudcertificaatbeheer voert ACME-clientagents (zoals Certbot, acme.sh of de ingebouwde ACME-client van een CLM-platform) uit volgens een schema dat certificaten vernieuwt wanneer ze nog ongeveer 30 dagen geldig zijn. Aangezien het SC-081v3-schema vanaf maart 2029 overgaat op certificaten met een geldigheidsduur van 47 dagen, betekent vernieuwing bij 30 dagen resterende geldigheidsduur dat certificaten elke 17 dagen worden vernieuwd. Dit vereist een volledig geautomatiseerde vernieuwing zonder menselijke goedkeuring in het kritieke pad.

Wanneer een privé-CA te gebruiken in cloudomgevingen?

Niet elk certificaat in een cloudomgeving hoeft te zijn uitgegeven door een openbare CA. Openbaar vertrouwde certificaten zijn vereist voor elk eindpunt dat verbindingen ontvangt van browsers of besturingssystemen die de openbare rootcertificaatwinkel vertrouwen. Interne service-naar-servicecommunicatie (microservice mTLS, interne Kubernetes-services, API-aanroepen tussen backendservices), ontwikkelaarstools en IoT-apparaatidentificatie kunnen certificaten van een private CA gebruiken, wat voor deze toepassingen verschillende voordelen biedt ten opzichte van openbare CA-certificaten.

Privé-CA-certificaten zijn niet onderworpen aan de geldigheidsbeperkingen van het CA/Browser Forum die gelden voor openbare certificaten. U kunt interne certificaten uitgeven met geldigheidsperioden die zijn afgestemd op uw implementatiecyclus. Privé-CA's geven u volledige controle over het certificaatprofiel: u kunt aangepaste extensies, Subject Alternative Names voor interne DNS-namen en IP-adressen en Extended Key Usage-waarden toevoegen die specifiek zijn voor uw toepassing (zoals clientAuth voor mTLS). Het uitgeven van privé-CA's is bovendien sneller en vereist geen domeinvalidatie tegen externe DNS.

Cloud-native opties voor private CA's zijn onder andere AWS Private CA (voorheen ACM Private CA), dat $400 per CA per maand kost voor een algemene CA of $50 per CA per maand voor een CA met een kortlopende certificering, en GCP Certificate Authority Service (CAS), dat een beheerde private CA biedt met cloud-HSM-ondersteunde CA-sleutelopslag. Voor organisaties die een private CA nodig hebben die meerdere cloudproviders omvat of integreert met on-premises PKI, biedt Encryption Consulting's PKI as a Service een beheerde private CA met ACME-ondersteuning, AD Connector voor Windows-omgevingen en integratie met alle belangrijke cloudplatformen.

Auditlogboekregistratie voor cloudcertificaatbeheer

Een volledig auditspoor voor certificaatbeheer vereist twee logstromen: gebeurtenissen in de levenscyclus van certificaten en gebeurtenissen met betrekking tot toegang tot privésleutels. Compliancekaders zoals PCI DSS v4.0.1, FedRAMP (NIST SP 800-53 AU-controles) en DORA vereisen allemaal gedocumenteerd bewijs van beheer van de levenscyclus van certificaten.

Certificaatlevenscycluslogboeken Leg alle gebeurtenissen met betrekking tot uitgifte, verlenging, intrekking en implementatie vast. Op AWS verschijnen ACM-certificaatgebeurtenissen in AWS CloudTrail onder de acm: gebeurtenisnaamruimte. Op Azure worden Key Vault-certificaatbewerkingen vastgelegd in de diagnostische logboeken van Azure Monitor. Op GCP verschijnen Certificate Manager- en CAS-bewerkingen in de Cloud Audit Logs. Deze logboeken moeten expliciet worden ingeschakeld voor dataplane-bewerkingen en worden doorgestuurd naar een fraudebestendige logboekbestemming (een schrijfbeveiligde S3-bucket, een Azure Storage Account met onveranderlijkheid of een GCS-bucket met Object Lock).

Toegangslogboeken voor privésleutels Leg elke keer vast dat een geheim of sleutel wordt gelezen door een applicatie of identiteit. In AWS Secrets Manager wordt elke keer dat een geheim of sleutel wordt gelezen, dit vastgelegd. GetSecretValue Het gesprek wordt vastgelegd in CloudTrail. In Azure Key Vault wordt elke leesbewerking van een geheim vastgelegd in de diagnostische logboeken van Key Vault. In GCP Secret Manager wordt elke toegang vastgelegd in de Cloud Audit Logs. Er wordt een waarschuwing gegenereerd voor: elke toegang tot een sleutel door een identiteit die niet in de lijst met goedgekeurde toepassingsrollen staat; elke export of download van een sleutel door een menselijke identiteit; elke intrekking van een certificaat dat niet is verlengd; en elke certificaatvervaldatum binnen 30 dagen waarvoor geen verlenging in behandeling is.

Architectuur voor certificaatbeheer in meerdere clouds

Organisaties die certificaatworkloads uitvoeren op AWS, Azure en GCP, worden geconfronteerd met hetzelfde consistentieprobleem in CLM als bij sleutelbeheer: de native tools van elke cloudprovider zijn specifiek voor die provider ontwikkeld. Drie architectuurpatronen bieden oplossingen voor certificaatbeheer in meerdere clouds:

• Gecentraliseerd CLM-platform met connectoren per cloud: Implementeer een CLM-platform van een derde partij dat verbinding maakt met alle drie de cloudproviders via hun respectievelijke API's (ACM, Azure Key Vault, GCP Certificate Manager). Het CLM-platform beheert een uniforme certificaatinventaris, handhaaft consistente certificaatbeleidsregels (minimale sleutellengte, toegestane CA's, maximale geldigheidsduur, vereiste SAN's) en activeert verlenging via de native API's van elke provider of via ACME. Dit is de aanbevolen aanpak voor organisaties met een aanzienlijke multi-cloudomgeving en compliance-vereisten.
• Privé-CA als enige uitgiftebasis: Implementeer een eigen CA (cloud-native of van een derde partij) die certificaten uitgeeft aan alle interne services in alle cloudomgevingen. Alle service-naar-service-certificaten zijn terug te voeren op dezelfde eigen root, ongeacht in welke cloud de service draait. Publiekelijk toegankelijke eindpunten gebruiken nog steeds openbare CA-certificaten via native cloud-CLM-services. Dit zorgt voor consistentie bij de interne certificaatuitgifte zonder dat een volledig CLM-platform van een derde partij nodig is.
• ACME met een gedeelde CA voor alle aanbieders: Configureer ACME-clients op services bij alle cloudproviders om hun certificaten te vernieuwen via dezelfde ACME-compatibele CA. De CA kan een openbare CA zijn (voor publiek toegankelijke certificaten) of een private ACME CA (voor interne certificaten). Het certificaatbeleid wordt afgedwongen op CA-niveau en is uniform van toepassing, ongeacht in welke cloudomgeving de ACME-client draait. Deze aanpak biedt de eenvoudigste automatisering, maar vereist wel dat de CA de benodigde certificaattypen en -profielen in alle omgevingen ondersteunt.

Nalevingseisen voor cloudcertificaatbeheer

Verschillende compliance-frameworks vereisen nu expliciet beheersmaatregelen voor de levenscyclus van certificaten, en niet alleen versleuteling tijdens de overdracht.

PCI DSS v4.0.1 (verplicht sinds 31 maart 2025): Vereiste 4.2.1 vereist dat alle certificaten die worden gebruikt om primaire rekeningnummergegevens (PAN-gegevens) tijdens de overdracht te beveiligen, worden bevestigd als geldig, vertrouwd en niet verlopen. Vereiste 12.3.3 vereist een gedocumenteerde inventaris van alle cryptografische cipher suites en certificaten die worden gebruikt in de Cardholder Data Environment (CDE), die ten minste eens per 12 maanden wordt gecontroleerd. Deze vereiste maakt een certificaatbeheerplatform dat een inventarisrapport genereert een directe compliancecontrole, en niet slechts een best practice.

DORA (Digital Operational Resilience Act, van kracht vanaf 17 januari 2025): Artikel 9 vereist dat financiële instellingen in de EU gebruikmaken van sterke encryptie en cryptografische controles, en artikel 10 vereist mogelijkheden voor het detecteren van ICT-gerelateerde incidenten. Storingen als gevolg van verlopen certificaten die leiden tot onbeschikbaarheid van diensten zijn meldingsplichtige ICT-incidenten onder DORA; certificaatbeheermaatregelen die dergelijke storingen voorkomen, zijn daarom een ​​vereiste voor ICT-risicobeheer onder DORA.

HIPAA: De HIPAA-beveiligingsregel Technical Safeguard 164.312(e)(2)(ii) vereist encryptie tijdens de overdracht van elektronische beschermde gezondheidsinformatie (ePHI). In cloudomgevingen betekent dit dat geldige TLS-certificaten moeten worden onderhouden op alle eindpunten die ePHI verzenden, met gedocumenteerd bewijs van controles op het certificaatbeheer.

FedRAMP (NIST SP 800-53 Rev. 5): De IA-3-controle (Device Identification and Authentication) vereist dat cloudsystemen de identificatiegegevens van apparaten beheren, inclusief certificaten die worden gebruikt voor wederzijdse authenticatie. De SC-17-controle (Public Key Infrastructure Certificates) vereist een certificaatbeleid voor uitgifte, verlenging en intrekking. FedRAMP High vereist bovendien FIPS 140-2- of FIPS 140-3-gevalideerde cryptografische modules voor certificaatbewerkingen.

Implementatiechecklist voor cloudcertificaatbeheer

1. Voer een volledige certificaatdetectiescan uit: Gebruik uw CLM-platform, cloud-native discovery-tools of de oplossingen van Encryption Consulting. CBOM Secure Om alle certificaten in alle cloudaccounts, regio's en on-premises systemen te ontdekken. Verwacht aanzienlijk meer certificaten te vinden dan uw huidige inventaris aangeeft.
2. Certificaten classificeren op type en eigendom: Identificeer voor elk gevonden certificaat de uitgevende CA, het certificaattype (openbare TLS, privé TLS, codeondertekening, S/MIME, apparaat), het eigenaarsteam, de implementatielocatie en het verlengingsmechanisme (handmatig, ACME, cloud-native automatische verlenging).
3. Identificeer certificaten zonder automatische verlenging: Elk certificaat zonder een automatisch verlengingsmechanisme vormt een toekomstige storing. Geef prioriteit aan de implementatie van ACME of cloud-native automatische verlenging voor deze certificaten, te beginnen met de certificaten die het snelst verlopen.
4. Audit van de opslag van privésleutels: Controleer of de privésleutels voor alle gevonden certificaten op goedgekeurde locaties zijn opgeslagen (cloud HSM, secrets manager, CLM-platform). Identificeer en verhelp eventuele sleutels die zijn opgeslagen in versiebeheer, containerimages of applicatieconfiguratiebestanden.
5. Implementeer certificaatbeleid in uw CLM-platform: Definieer de minimaal acceptabele certificaatparameters: minimale RSA-sleutellengte (minimaal 2048 bits; 4096 bits voor CA-certificaten), toegestane ondertekeningsalgoritmen (SHA-256 of sterker), maximale geldigheidsduur (conform het SC-081v3-schema), vereiste SAN's (geen wildcardcertificaten waar specifiekere SAN's mogelijk zijn) en goedgekeurde uitgevende CA's.
6. Stel waarschuwingen voor verlopen gegevens in: Stel waarschuwingen in voor certificaten zonder automatische verlenging, 60 dagen, 30 dagen en 14 dagen vóór de vervaldatum. Stuur de waarschuwingen door naar het verantwoordelijke team en naar het beveiligingsteam.
7. Auditlogboeken inschakelen en doorsturen: Schakel logboekregistratie van de levenscyclus van certificaten en logboekregistratie van toegang tot privésleutels in bij alle cloudproviders. Routeer naar een fraudebestendige bestemming. Configureer waarschuwingen voor de belangrijkste beveiligingsgebeurtenissen die in het bovenstaande gedeelte over auditlogboekregistratie worden beschreven.
8. Evalueer en test het verlengingsproces elk kwartaal: Controleer voor elk certificaattype met automatische verlenging of het verlengingsproces succesvol is afgerond en of het verlengde certificaat correct is geïmplementeerd. Test de intrekkingsprocedures voor ten minste één certificaat per kwartaal om te controleren of de intrekkingsinfrastructuur functioneert.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is een bedrijf gespecialiseerd in toegepaste cryptografie met ISO/IEC 27001:2022- en SOC 2-certificeringen. Wij helpen organisaties bij het ontwerpen, implementeren en auditeren van cloudcertificaatbeheerprogramma's, van de eerste inventarisatie tot het continu genereren van bewijsmateriaal voor naleving.

• CertSecure Manager: Encryptie Consulting's CertSecure Manager CertSecure Manager is een gecentraliseerd platform voor certificaatlevenscyclusbeheer dat geautomatiseerde detectie biedt voor cloudproviders en on-premises systemen, ACME-gebaseerde geautomatiseerde verlenging, bescherming van privésleutels, handhaving van certificaatbeleid, waarschuwingen bij vervaldatum en een uniform auditlogboek. CertSecure Manager integreert naadloos met AWS, Azure en GCP, ondersteunt ACME voor elke ACME-compatibele CA en bevat een AD-connector voor Windows-omgevingen die gebruikmaken van Microsoft Auto-Enrollment.
• PKI als een service: Voor organisaties die een beheerde private CA nodig hebben voor interne cloudcertificaten, biedt Encryption Consulting de oplossing. PKI als een service Biedt een volledig beheerde private CA met ACME-ondersteuning, integratie met alle belangrijke cloudplatformen en FIPS-gevalideerde sleutelopslag. Geschikt voor Kubernetes service mesh-certificaten, mTLS tussen microservices en apparaatidentificatieprogramma's.
• HSM als een service: Voor certificaatbeheerscenario's die FIPS 140-2 Level 3-bescherming van privésleutels vereisen, biedt Encryption Consulting de oplossing. HSM als een service Biedt een speciale HSM-infrastructuur die integreert met CLM-platformen en cloudcertificaatdiensten, waarbij CA-privésleutels en waardevolle privésleutels van eindgebruikers in hardwarematige opslag worden bewaard.
• CBOM Secure: Encryptie Consulting's CBOM Secure Voert geautomatiseerde detectie uit in AWS-, Azure-, GCP- en on-premises omgevingen om een ​​cryptografische stuklijst (CBOM) in CycloneDX-formaat te genereren. Dit levert de certificaatinventaris op die vereist is door PCI DSS v4.0.1 vereiste 12.3.3 en FedRAMP IA-3-controles, en identificeert schaduwcertificaten en certificaten met onveilige configuraties.
• Compliance-advies: We brengen uw beheermaatregelen voor cloudcertificaten in kaart en koppelen deze aan de specifieke vereisten van PCI DSS v4.0.1, DORA, HIPAA, FedRAMP, NIS2 en andere toepasselijke frameworks. We identificeren hiaten in de beheermaatregelen, stellen een herstelplan op en produceren het auditbewijsmateriaal. Bekijk onze Nalevingsadviesdiensten.
• PQC-gereedheid: NIST heeft in augustus 2024 de post-kwantumcryptografiestandaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) afgerond. NIST IR 8547 wijst erop dat RSA en ECC rond 2030 zullen worden uitgefaseerd voor nieuwe toepassingen. De overgang naar post-kwantumalgoritmen vereist dat elk certificaat in uw cloudomgeving opnieuw wordt uitgegeven. Encryption Consulting's PQC-gereedheid De service brengt uw volledige certificaat- en cryptografische status in kaart ten opzichte van de migratietijdlijn na de quantumovergang en ontwerpt de migratievolgorde voor cloudcertificaatomgevingen.

Neem contact op met Encryption Consulting om uw wensen met betrekking tot het beheer van cloudcertificaten te bespreken.

Conclusie

Het beheer van certificaten in de cloud is verschoven van een wenselijk operationeel proces naar een verplichte beveiligings- en compliancecontrole. Het CA/Browser Forum SC-081v3-schema maakt geautomatiseerde verlenging tegen 2029 een operationele noodzaak. PCI DSS v4.0.1 en DORA stellen een gedocumenteerde certificaatinventaris en lifecycle governance expliciete compliancevereisten. En de wildgroei aan cloud-native certificaten in automatisch schaalbare groepen, containers en multi-cloud workloads maakt handmatig beheer op enige zinvolle schaal operationeel onmogelijk.

De organisaties die deze overgang zonder storingen of complianceproblemen kunnen doorstaan, zijn de organisaties die nu al continue certificaatdetectie implementeren, ACME-automatisering inzetten vóór de vervaldatum van 100 dagen in maart 2027, beleid voor de bescherming van privésleutels opstellen dat de migratie naar certificaten met een kortere geldigheidsduur overleeft, en het auditspoor opbouwen dat compliancekaders steeds vaker vereisen. De organisaties die wachten tot certificaten met een geldigheidsduur van 47 dagen verplicht worden in maart 2029, zullen te maken krijgen met een gehaaste, risicovolle herstelprocedure onder tijdsdruk.

Veelgestelde Vragen / FAQ

Wat is cloudgebaseerd certificaatbeheer?

Certificaatbeheer in de cloud is het proces van het ontdekken, uitgeven, verlengen, intrekken en controleren van digitale certificaten in cloudinfrastructuren, containers en hybride omgevingen vanuit een gecentraliseerd platform. Het vervangt handmatige certificaatregistratie door geautomatiseerd levenscyclusbeheer dat storingen door verlopen certificaten voorkomt, de bescherming van privésleutels waarborgt en bewijsmateriaal genereert voor compliance-audits in multi-cloudomgevingen.

Waarom hebben cloudomgevingen een specifiek certificaatbeheer nodig?

Cloudomgevingen genereren certificaten op een schaal en met een snelheid die handmatig beheer niet kan bijhouden. Automatisch schaalbare groepen, containers, microservices en API-gateways hebben allemaal geldige certificaten nodig, en veel daarvan worden geprovisioneerd zonder centraal IT-overzicht. Een enkel verlopen certificaat in een cloud load balancer of API-gateway kan een volledige servicestoring veroorzaken. Een dedicated CLM-oplossing biedt continue detectie, geautomatiseerde verlenging en gecentraliseerd inzicht in vervaldatums, uitgevende CA's, belangrijkste beveiligingskenmerken en compliance-status voor alle cloudaccounts en -regio's.

Wat is het verschil tussen native cloudcertificaatbeheer en een CLM-platform van een derde partij?

Native cloudservices (AWS Certificate Manager, Azure Key Vault Certificates, GCP Certificate Manager) automatiseren de vernieuwing van certificaten voor resources binnen het ecosysteem van die ene cloudprovider. Ze bieden geen inzicht in certificaten in andere clouds, on-premises systemen of certificaattypen buiten hun eigen toepassingsgebied. Een CLM-platform van een derde partij biedt een uniforme certificaatinventaris en consistente beleidshandhaving voor alle cloudproviders, on-premises infrastructuur en certificaattypen, waaronder codeondertekening, S/MIME en apparaatcertificaten.

Hoe moeten privésleutels worden beschermd in een cloudomgeving voor certificaatbeheer?

Privésleutels moeten worden opgeslagen in hardware-ondersteunde geheime archieven, nooit in platte tekstconfiguratiebestanden, omgevingsvariabelen of versiebeheer. Voor certificaten van load balancers en API gateways gebruikt u de beheerde certificeringsservice van de cloudprovider, waar de sleutel nooit wordt blootgesteld. Voor certificaten waarbij de applicatie directe toegang tot de sleutel nodig heeft, slaat u de sleutel op in een cloudgeheimbeheerder met automatische rotatie. Voor FIPS 140-2 niveau 3-vereisten gebruikt u een dedicated HSM via cloud-HSM-services of een externe HSM-as-a-Service-provider.

Wat is ACME en hoe maakt het geautomatiseerde certificaatvernieuwing in de cloud mogelijk?

ACME (Automatic Certificate Management Environment) is een IETF-protocol (RFC 8555) dat de uitgifte en verlenging van certificaten automatiseert. Het stelt een client in staat om domeinbeheer aan een certificeringsinstantie (CA) te bewijzen en een certificaat te ontvangen zonder menselijke tussenkomst. In cloudomgevingen draaien ACME-clients als agents op compute-instances of in containers en verlengen ze certificaten automatisch vóór de vervaldatum. Aangezien TLS-certificaten vanaf maart 2029 een geldigheidsduur van 47 dagen krijgen volgens het schema van het CA/Browser Forum SC-081v3, is ACME-automatisering essentieel voor elke cloudomgeving met meer dan een handvol certificaten.

Welke compliance-frameworks vereisen certificaatbeheer in cloudomgevingen?

PCI DSS v4.0.1 (verplicht sinds 31 maart 2025) vereist een gedocumenteerde inventaris van certificaten en geldige certificaten voor kaartgegevens die worden verzonden. DORA (van toepassing vanaf januari 2025) vereist ICT-risicobeheermaatregelen die het beheer van de levenscyclus van cryptografische certificaten omvatten. HIPAA vereist geldige TLS-certificaten op alle eindpunten die beschermde gezondheidsinformatie verzenden. FedRAMP (NIST SP 800-53 Rev. 5) vereist een certificaatbeleid dat de uitgifte, verlenging en intrekking van certificaten omvat. GDPR vereist passende technische maatregelen voor gegevens die worden verzonden, inclusief certificaathygiëne.