Verschil tussen verschillende Public Key Infrastructures (PKI's)

Introductie

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA en Google Cloud Certificate Authority Service lossen allemaal hetzelfde onderliggende probleem op: het uitgeven en beheren van vertrouwde digitale certificaten. Ze doen dit echter op zeer verschillende manieren. Het kiezen van de verkeerde oplossing, of het tegelijkertijd gebruiken van alle vier zonder een gedocumenteerd besluitvormingsproces, kan ertoe leiden dat organisaties te maken krijgen met dubbele CA-hiërarchieën, inconsistente sleutelbeveiliging en onverwachte certificaatuitval. In dit artikel wordt uitgelegd waaruit een PKI bestaat, hoe elk van deze vier platforms deze implementeert, een volledige vergelijking op basis van elf categorieën, en een praktische beslissingsmatrix en checklist voor het kiezen (of controleren) van de juiste oplossing voor een specifieke use case.

Kort antwoord: Wat is het verschil tussen deze PKI-platformen?

Leveranciers van Public Key Infrastructure (PKI) verschillen voornamelijk in de locatie van de CA-sleutels en wie de hiërarchie beheert: Microsoft PKI (ADCS) draait on-premises met een offline Root CA, AWS Certificate Manager automatiseert openbare TLS-certificaten en AWS ACM Private CA en Google Cloud CAS draaien private CA-hiërarchieën native in de cloud met HSM-ondersteunde sleutels en ingebouwde auditregistratie.

Key Takeaways

• Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA en Google Cloud CAS lossen verschillende problemen op: respectievelijk beheer van CA's op locatie, geautomatiseerde openbare TLS, cloud-native private CA-hiërarchieën en GCP-geïntegreerde CA-pools.
• Alle vier de platforms hanteren dezelfde kernprincipes op het gebied van beveiliging: offline of beveiligde root-CA's, door HSM ondersteunde privésleutels, hashing met SHA-256 of beter, en auditregistratie.
• AWS heeft de HSM-beveiliging van ACM Private CA geüpgraded naar FIPS 140-3 niveau 3. NIST beëindigt de FIPS 140-2-validaties en geeft ze de status 'Historisch' op 21 september 2026. Daarom is voor elke Microsoft PKI- of on-premises-implementatie die nog steeds naar 140-2 verwijst, een vernieuwingsplan nodig.
• Door de verkorte geldigheidsduur van openbare TLS-certificaten, die volgens CA/Browser Forum Ballot SC-081v3 in 2029 wordt teruggebracht tot 47 dagen, worden automatiseringsvriendelijke platforms zoals ACM en cloud-native CAS steeds belangrijker, zelfs voor organisaties die begonnen zijn met Microsoft PKI.
• De juiste keuze is zelden één enkel platform. De meeste bedrijven gebruiken een hybride mix en hebben een gedocumenteerde beslissingsmatrix nodig, geen ad-hockeuze, om dubbele CA-hiërarchieën en inconsistente sleutelbeveiliging te voorkomen.

Waarom dit nu van belang is

Uit het Trust Pulse-onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat bijna de helft van de bedrijven het afgelopen jaar te maken heeft gehad met een storing die verband hield met certificaten. 37.5% van de incidenten was specifiek gerelateerd aan verlopen certificaten en 18.5% van de getroffen organisaties meldde verliezen van meer dan $ 250,000. Het naast elkaar gebruiken van Microsoft PKI-, AWS- en Google Cloud CA-hiërarchieën zonder een consistent monitoring- en vernieuwingsproces is precies het soort inconsistentie dat deze storingen veroorzaakt.

De foutmarge voor handmatige handelingen neemt ook snel af. Volgens CA/Browser Forum Ballot SC-081v3 , goedgekeurd op 11 april 2025, daalt de geldigheidsduur van publiek vertrouwde TLS-certificaten van 398 dagen naar 200 dagen vanaf 15 maart 2026, vervolgens naar 100 dagen vanaf 15 maart 2027 en naar 47 dagen vanaf 15 maart 2029. Een platformkeuze die afhankelijk is van handmatige uitgifte, zoals gebruikelijk bij oudere Microsoft PKI-implementaties, kan dit schema niet bijhouden zoals AWS Certificate Manager of Google Cloud CAS-automatisering dat wel kan.

Op de langere termijn heeft NIST op 13 augustus 2024 de standaarden voor post-kwantumcryptografie, FIPS 203, 204 en 205, afgerond. Elk platform dat in dit artikel wordt vergeleken, ondertekent nog steeds certificaten met RSA of ECDSA. Ongeacht welke leverancier een organisatie momenteel gebruikt, hoort een plan voor cryptografische flexibiliteit ter voorbereiding op de uiteindelijke overgang naar post-kwantumcryptografie (PQC) op de roadmap te staan, ongeacht welke CA-hiërarchie van kracht is.

Wat is Public Key Infrastructure (PKI)?

PKI, de afkorting voor Public Key Infrastructure , is een geheel van rollen, procedures en beleidsregels die nodig zijn voor het creëren, distribueren, beheren, gebruiken en intrekken van digitale certificaten en voor het beheren van publieke-sleutelversleuteling. PKI bevestigt de identiteit van een gebruiker door het eigendom van een privésleutel te verifiëren en fungeert als een vertrouwde dienst die verifieert dat de verzender of ontvanger van gegevens daadwerkelijk is wie hij of zij beweert te zijn.

Wat zijn de kerncomponenten van een PKI?

PKI is opgebouwd rond componenten en procedures voor het beheren van sleutelparen (publieke en privésleutelparen). Een typische PKI bestaat uit de volgende componenten:

1. Certificeringsinstantie (CA): Een vertrouwde CA is de enige entiteit binnen PKI die vertrouwde digitale certificaten kan uitgeven. De CA accepteert aanvragen voor certificaten en verifieert de door aanvragers verstrekte informatie op basis van certificaatbeheer Het bedrijf ondertekent vervolgens certificaten met zijn privésleutel en geeft deze uit als de informatie geldig is.
2. Registratieautoriteit (RA): Een RA (Registered Application) is verantwoordelijk voor het ontvangen van certificaatondertekeningsverzoeken voor de initiële registratie of verlenging van certificaten van gebruikers, servers en andere applicaties. De RA verifieert de identiteit van een eindgebruiker en stuurt het verzoek door naar een certificeringsinstantie (CA).
3. Publieke Sleutel: Een publieke sleutel kan breed verspreid worden en hoeft niet veilig opgeslagen te worden. De bijbehorende privésleutel kan berichten of gegevens die met de publieke sleutel zijn versleuteld, decoderen.
4. Prive sleutel: De ontvanger gebruikt privésleutels om het bericht of de gegevens te decoderen die met de bijbehorende publieke sleutel zijn versleuteld. Dit bevestigt het eigendom van het sleutelpaar, waardoor het bericht alleen door bevoegde partijen kan worden gelezen.
5. Root-certificeringsinstantie (Root CA): Een certificaat wordt als geldig beschouwd wanneer het is ondertekend door een vertrouwde root-CA. Een root-CA is bevoegd om de identiteit van een persoon te verifiëren en ondertekent het rootcertificaat dat aan een gebruiker wordt verstrekt.
6. Certificeringsinstantie voor het tussenliggende niveau: Een intermediaire CA is ook een vertrouwde CA en fungeert als schakel in de keten tussen de root-CA en het clientcertificaat dat de gebruiker aanvraagt. Omdat de root-CA de intermediaire CA heeft ondertekend en vertrouwt, worden certificaten die door de intermediaire CA worden gegenereerd, ook vertrouwd.
7. Hardwarebeveiligingsmodule (HSM): A Hardwarebeveiligingsmodule Het is geen verplicht onderdeel van een PKI, maar de implementatie ervan verbetert de beveiliging. Dit apparaat beschermt en beheert digitale sleutels en vormt de basis voor het bouwen van een veilig PKI-systeem. ondernemings-PKI infrastructuur, die de volledige levenscyclus van cryptografische sleutels beheert, inclusief het aanmaken, roteren, verwijderen, controleren en ondersteunen van cryptografische sleutels. APIs om te integreren met verschillende applicaties.

Hoe implementeren grote PKI-leveranciers deze componenten?

Nu de belangrijkste PKI-componenten duidelijk zijn, volgt hier hoe vier veelgebruikte platforms deze implementeren, samen met de aanbevolen best practices voor elk platform.

Microsoft PKI

Hieronder volgen enkele aanbevelingen voor een effectief gebruik van Microsoft PKI (Active Directory Certificate Services).

• Maak een gedetailleerd plan van uw PKI-infrastructuur vóór de implementatie.
• Installeer ADCS niet op een domeincontroller.
• Root CA moet zelfstandig en offline zijn.
• Geef geen certificaten uit aan eindgebruikers vanuit een root-CA.
• Schakel controlegebeurtenissen in voor zowel root- als uitgevende CA.
• Beveilig de privésleutel met een HSM (FIPS 140-3 niveau 3(De FIPS 140-2-validaties krijgen op 21 september 2026 de status 'Historisch'.)
• Installeer Enterprise CA alleen als uw CA certificaten uitgeeft voor apparaten of gebruikers.
• Het wordt niet aanbevolen om standaard certificaatsjablonen te gebruiken.
• Het distributiepunt voor CRL moet goed bereikbaar zijn.
• Publiceer de CRL van de root-CA naar Active Directory.
• Het hash-algoritme moet minimaal SHA-2 (SHA-256 of hoger).
• De geldigheidsperiode van het certificaat voor de eindgebruiker mag maximaal twee jaar bedragen.

AWS-certificaatbeheerder

Hieronder vindt u de beste werkwijzen voor AWS Certificate Manager (ACM):

• Controle op vervaldatum ACM-certificaat: zorg ervoor dat verlopen certificaten worden verwijderd. SSL/TLS-certificaten Beheerd door ACM. Dit elimineert het risico van het implementeren van een ongeldig certificaat op resources die toegankelijk zijn voor de front-end, wat ook de geloofwaardigheid van het bedrijf kan schaden.
• Geldigheidscontrole van het ACM-certificaat: zorg ervoor dat verzoeken die binnenkomen tijdens het uitgifte- of verlengingsproces van het SSL/TLS-certificaat regelmatig worden gevalideerd.
• Gebruik van de root-CA: het is altijd raadzaam om het gebruik van de root-CA te minimaliseren. AWS raadt aan een apart account aan te maken voor de root-CA.
• Bescherming op de transportlaag is essentieel voor de beveiliging. Gebruik alleen TLS versie 1.2 of hoger; SSL is niet langer veilig.
• Bij het importeren van certificaten in plaats van het gebruik van door ACM uitgegeven certificaten, moet u ervoor zorgen dat de sleutels die worden gebruikt om SSL/TLS-privésleutels te genereren een hoge sleutelsterkte hebben om datalekken te voorkomen.
• Vermijd wildcard-domeincertificaten. Geef in plaats daarvan voor elk domein en subdomein een ACM-certificaat uit met een eigen privésleutel.
• Sta alleen geïmporteerde certificaten toe van geverifieerde en vertrouwde partners van uw organisatie. Wildcardcertificaten die in ACM worden geïmporteerd, verhogen het beveiligingsrisico, omdat een gebruiker mogelijk een onversleutelde kopie van de privésleutel van het certificaat in handen heeft.
• Gebruik in SSL/TLS ACM-certificaten altijd een volledig gekwalificeerde domeinnaam (FQDN).
• Om misbruik van gegenereerde certificaten te voorkomen, dient u regelmatig de AWS-omgeving te controleren op vertrouwde certificaten en de auditrapporten te valideren.
• Schakel AWS CloudTrail- en CloudWatch-alarmen in: CloudTrail registreert de geschiedenis van AWS API-aanroepen en bewaakt AWS-implementaties. Het kan worden geïntegreerd met applicaties voor geautomatiseerde logging. CloudWatch-alarmen waarschuwen u wanneer geconfigureerde meetwaarden drempelwaarden overschrijden.

AWS ACM Private CA (ACM PCA)

Hieronder vindt u aanbevolen best practices die u kunnen helpen AWS ACM Private CA effectiever te gebruiken.

• AWS raadt aan om al uw beleidsregels en werkwijzen voor het beheren van uw CA te documenteren, inclusief de CA-hiërarchie, het architectuurdiagram en het beleid voor de validatieperiode van de CA. Dit kan worden vastgelegd in een certificaatbeleid (CP) en een certificaatpraktijkverklaring (CPS); raadpleeg RFC 3647 voor een raamwerk voor het vastleggen van deze informatie.
• De root-CA mag in principe alleen worden gebruikt om certificaten uit te geven voor intermediaire CA's.
• Het aanmaken van een root-CA en een ondergeschikte CA in twee verschillende AWS-accounts wordt aanbevolen als beste werkwijze.
• De CA-beheerdersrol moet gescheiden zijn van gebruikers die alleen toegang nodig hebben om certificaten voor eindentiteiten uit te geven.
• Schakel CloudTrail-logging in voordat u een privé-CA aanmaakt en in gebruik neemt, zodat u een geschiedenis van AWS API-aanroepen kunt ophalen om uw implementaties te bewaken.
• Werk de privésleutel van uw private CA periodiek bij, door een nieuw CA-certificaat te importeren of de private CA te vervangen door een nieuwe.
• Verwijder permanent alle ongebruikte privé-CA's.
• Gebruik de Amazon S3 Block Public Access (BPA)-functie voor buckets die CRL's bevatten om te voorkomen dat details van uw privé-PKI onnodig openbaar worden gemaakt. BPA is een aanbevolen werkwijze voor S3 en is standaard ingeschakeld voor nieuwe buckets.

Google Cloud Certificate Authority Service

In dit gedeelte worden enkele best practices beschreven die u helpen om de Certificate Authority Service (CAS) van Google Cloud effectiever te gebruiken.

• Rol- en toegangsbeheer: personen mogen niet meer dan één rol tegelijk toegewezen krijgen, en iedereen met een rol moet voldoende geïnformeerd zijn over zijn of haar verantwoordelijkheden. Om diverse machtigingen toe te wijzen, kunt u een aangepaste rol aanmaken met behulp van IAM.
• Gebruik in de meeste gevallen de Enterprise-laag om een ​​CA-pool te creëren die certificaten uitgeeft aan andere CA's en eindgebruikers.
• Houd bij het aanmaken van een CA-pool zorgvuldig rekening met de DevOps-laag, aangezien deze geen ondersteuning biedt voor het intrekken van certificaten.
• Beveilig CA-ondertekeningssleutels door gebruik te maken van Cloud HSM.
• Schakel cloudauditlogboeken in om de toegang tot en het gebruik van Cloud HSM-ondertekeningssleutels te controleren.
• Vermijd het importeren van een bestaande externe CA met reeds uitgegeven certificaten in de CA-service.
• Voor een Root CA en Subordinate CA gebruikt u de grootste sleutelgrootte die beschikbaar is voor die algoritmefamilie: voor RSA is de grootste ondersteunde sleutelgrootte 4096 bits; voor ECDSA is de grootste ondersteunde sleutelgrootte 384 bits. Subordinate CA's met een kortere levensduur kunnen kleinere sleutelgroottes gebruiken, zoals 2048 bits. RSA of 256 bits voor ECDSAHoud er rekening mee dat Ed25519-ondertekeningssleutels niet worden ondersteund voor CA-services en dat er op het moment van schrijven geen post-quantum-ondertekeningsalgoritme wordt ondersteund voor CA-sleutels.
• Wijs de gebruikersrol CA Service alleen toe aan organisatieleden die een bepaalde certificaatsjabloon moeten gebruiken.

Overzicht van leveranciersvergelijkingen

De onderstaande tabel vergelijkt alle vier de platforms aan de hand van elf categorieën die het belangrijkst zijn bij het kiezen of controleren van een PKI-leverancier.

#	Categorie	Microsoft PKI	AWS Certificaatbeheerder (ACM)	AWS ACM Private CA (ACM PCA)	Google Cloud Certificate Authority Service (CAS)
1	Root-CA	De root-CA wordt lokaal geïmplementeerd en offline gehouden.	AWS Certificate Manager is een service voor het aanmaken, beheren en implementeren van openbare/privé SSL/TLS-certificaten voor AWS-services en verbonden resources.	De root-CA kan in de AWS-cloud worden geïmplementeerd, of de CSR van de uitgevende CA kan worden ondertekend door een externe root-CA.	De root-CA kan worden geïmplementeerd in Google Cloud CAS, of de CSR van de uitgevende CA kan worden ondertekend door een externe root-CA.
2	Certificaat sjabloon	Het gebruik van standaard certificaatsjablonen wordt afgeraden; sjablonen kunnen worden geconfigureerd.	Gebruik AWS CloudFormation-sjablonen om privécertificaten uit te geven met ACM.	ACM Private CA ondersteunt vier soorten certificaatsjablonen: Base, CSRPassthrough, APIPassthrough en APICSRPassthrough.	In Google Cloud CAS kan voor elk project en elke locatie een nieuwe certificaatsjabloon worden aangemaakt.
3	Sleutelalgoritme en sleutelgrootte	Ondersteunt sleutelgroottes volgens NIST SP 800-57. De minimale sleutelgrootte is 2048-bit; voor CA's met een certificaatvervaldatum van meer dan 15 jaar, moet RSA 4096-bit of groter zijn, of moeten ECC-sleutels de P-384- of P-521-curve gebruiken.	Ondersteunt 2048-bit RSA, 3072-bit RSA, 4096-bit RSA en ECDSA P-256 en P-384.	Ondersteunt RSA 2048, RSA 4096, ECDSA P-256 en ECDSA P-384 voor certificaten die rechtstreeks door ACM Private CA worden uitgegeven.	Ondersteunt 2048-bits RSA, 3072-bits RSA, 4096-bits RSA, ECDSA P-256 en ECDSA P-384. Voor langlevende root- of ondergeschikte CA's raadt Google de grootste beschikbare sleutelgrootte voor de gekozen algoritmefamilie aan. Ed25519 en post-quantum CA-ondertekeningssleutels worden momenteel niet ondersteund.
4	Hashing-algoritme	Voor nieuwe implementaties en bestaande PKI-netwerken wordt SHA-256 of hoger aanbevolen.	ACM-beheerde certificaten gebruiken RSA-sleutels met een modulus van 2048 bits en SHA-256; ACM beheert momenteel geen ECDSA-certificaten.	Ondersteunt SHA256WITHECDSA, SHA384WITHECDSA, SHA512WITHECDSA, SHA256WITHRSA, SHA384WITHRSA en SHA512WITHRSA voor certificaten die rechtstreeks door ACM Private CA worden uitgegeven.	Ondersteunt SHA-256 en SHA-384.
5	RFC-naleving	CA-certificaten moeten voldoen aan X.509 v3 en aan RFC 5280 (nog steeds het huidige basis X.509/PKIX-certificaatprofiel) en de huidige basisvereisten van het CA/Browser Forum.	AWS beschermt de infrastructuur waarop ACM in de AWS-cloud draait; de effectiviteit wordt getest door externe auditors in het kader van AWS Compliance Programs.	Dwingt bepaalde beperkingen af ​​volgens RFC 5280, hoewel niet alle in RFC 5280 gedefinieerde beperkingen worden afgedwongen.	Gebruikt de ZLint-tool om X.509-certificaten te valideren aan de hand van RFC 5280, hoewel niet alle vereisten van RFC 5280 worden afgedwongen.
6	CRL-distributiepunt	Microsoft PKI deponeert de CRL onder LDAP en HTTP.	Het intrekken van certificaten voor ACM verloopt via AWS Support; hiervoor moet een supportticket worden aangemaakt.	ACM Private CA plaatst de CRL automatisch in een daarvoor bestemde Amazon S3-bucket.	CRL-publicatie moet expliciet worden ingeschakeld voor een CA-pool, wat kan worden gedaan tijdens het aanmaken van de pool.
7	Opslag van privésleutels	Het wordt aanbevolen om privésleutels op te slaan in een FIPS 140-3 Level 3-compatibele HSM (FIPS 140-2-validaties krijgen op 21 september 2026 de status 'Historisch').	ACM slaat het certificaat en de bijbehorende privésleutel op en maakt gebruik van AWS Key Management Service (KMS) om de privésleutel te beschermen.	Standaard worden privésleutels voor private CA's opgeslagen in door AWS beheerde HSM's die voldoen aan de FIPS PUB 140-3 Level 3-beveiligingsvereisten voor cryptografische modules.	CA-sleutels worden opgeslagen in Cloud HSM, gevalideerd volgens FIPS 140-2 niveau 3, en zijn beschikbaar in Noord- en Zuid-Amerika, Europa en Azië-Pacific.
8	Auditrapporten	Auditing kan worden ingeschakeld op een CA in Windows Server om een ​​auditlogboek bij te houden voor alle beheertaken van certificaatservices.	ACM is geïntegreerd met AWS CloudTrail, dat acties registreert die door een gebruiker, rol of AWS-service worden uitgevoerd en standaard is ingeschakeld.	Auditrapporten bevatten een lijst van alle certificaten die ACM Private CA heeft uitgegeven of ingetrokken, opgeslagen in een nieuwe of bestaande S3-bucket.	Cloudauditlogboeken bevatten auditlogboeken voor beheerdersactiviteiten, gegevenstoegang, systeemgebeurtenissen en geweigerde beleidsregels voor elk project, elke map en elke organisatie.
9	Beste praktijken (op hoog niveau)	Plan voorafgaand aan de implementatie, houd de root-CA offline, vermijd het uitgeven van eindgebruikerscertificaten door de root-CA, schakel auditing in en beveilig sleutels met een FIPS 140-3 Level 3 HSM.	Controleer regelmatig de vervaldatum en geldigheid van certificaten, minimaliseer het gebruik van root-CA's en dwing TLS 1.2 of hoger af.	Documenteer de CA-structuur en het beleid, minimaliseer het gebruik van Root CA's, scheid de rollen van beheerder en uitgever, schakel CloudTrail in en vervang de privésleutels van de CA's periodiek.	Pas het principe van minimale bevoegdheden toe op de roltoewijzing, gebruik de Enterprise-laag voor meerdere CA-pools, beveilig ondertekeningssleutels met Cloud HSM en schakel auditregistratie in.
10	CA-hiërarchie	Bij hiërarchische PKI-implementaties worden doorgaans hiërarchieën met één, twee of drie lagen gebruikt.	ACM levert, beheert en implementeert certificaten voor AWS-services en verbonden resources, in plaats van een eigen CA-hiërarchie te beheren.	Ondersteunt het ontwerpen van een hiërarchie van certificeringsinstanties met maximaal vijf niveaus.	Wanneer een ondergeschikte CA een certificaatketen vormt met een externe Root CA, moeten de eigenschappen in de door CAS gegenereerde CSR behouden blijven in het ondertekende CA-certificaat, inclusief eventuele beperkingen met betrekking tot de padlengte.
11	Redundantie en herstel na een ramp	Redundantie- en noodherstelplannen moeten worden opgenomen in de ontwerp- en implementatieplanningsfase van een PKI-implementatie.	ACM zelf heeft geen eigen SLA, hoewel de door ACM Private Certificate Authority beheerde service dat wel heeft.	Beschikbaar in meerdere AWS-regio's voor redundante CA's, met een SLA-doelstelling van 99.9% beschikbaarheid.	Beschikbaar in meerdere Google Cloud-regio's voor redundantie, met een SLA-doelstelling van 99.9% beschikbaarheid.

Voordelen en nadelen per platform

Microsoft PKI (ADCS)

Pluspunten: volledige controle over de CA-hiërarchie en het beleid, nauwe integratie met Active Directory, geen terugkerende kosten voor de cloudservice van de CA zelf, en wordt door de meeste Windows-beheerders in bedrijven goed begrepen.

Nadelen: vereist interne aanschaf van HSM en offline Root CA-ceremonies, handmatige processen voor de certificaatlevenscyclus tenzij automatisering apart wordt toegevoegd, en de operationele last komt volledig voor rekening van het interne personeel.

AWS Certificaatbeheerder (ACM)

Pluspunten: gratis openbare TLS-certificaten voor gebruik met geïntegreerde AWS-services, automatische verlenging, minimale operationele kosten, nauwe CloudTrail-integratie voor inzicht in auditgegevens.

Nadelen: beperkt tot AWS-geïntegreerde resources en openbare/geïmporteerde certificaten, geen eigen native privé-CA-hiërarchie en geen specifieke SLA voor de gratis openbare-certificaatservice.

AWS ACM Private CA

Pluspunten: volledig beheerde privé-CA-hiërarchie tot vijf niveaus diep, standaard FIPS 140-3 Level 3 HSM-ondersteunde sleutels, native CloudTrail-auditing, 99.9% SLA.

Nadelen: doorlopende kosten per CA en per certificaat, AWS-gericht en dwingt niet automatisch alle RFC 5280-beperkingen af.

Google Cloud Certificate Authority Service

Pluspunten: flexibele Enterprise- en DevOps-lagen, door Cloud HSM ondersteunde ondertekeningssleutels, gedetailleerde IAM-gebaseerde roltoewijzing, uitstekende geschiktheid voor GCP-georiënteerde infrastructuren.

Nadelen: de DevOps-laag biedt geen ondersteuning voor het intrekken van certificaten, publicatie van CRL's moet expliciet worden ingeschakeld en er wordt niet aan alle vereisten van RFC 5280 voldaan.

De juiste PKI kiezen: beslissingsmatrix

Use Case	Beveiligingsimpact	Operationele inspanning	Automatisering Fit	Aanbevolen eigenaar
TLS-certificaten voor publiekelijk toegankelijke websites/apps op AWS-infrastructuur	Medium — openbare vertrouwensketen, korte geldigheidsperioden	Laag, eenmaal geconfigureerd	Hoog — AWS Certificate Manager verlengt automatisch	Platform-/DevOps-teams
Volledig offline, luchtgeïsoleerde interne Root CA voor wettelijke of hoge betrouwbaarheidsvereisten.	Hoog — vertrouwensbasis voor de gehele interne PKI	Hoog — handmatige ceremonies, HSM-management	Laag door ontwerp (opzettelijk offline)	PKI-beheerders, beveiligingsarchitecten
Privé CA-hiërarchie volledig gehost in AWS voor interne services en apparaatidentificatie	Hoog — beschermt het interne vertrouwen tussen diensten.	Gemiddeld — beheerde HSM, maar het ontwerpen van beleid en hiërarchie is nog steeds vereist.	Hoog — AWS ACM Private CA-automatisering en CloudTrail	PKI-beheerders, platformteams
Multicloud- of GCP-gebaseerde infrastructuur die CA-pools per project nodig heeft.	Hoog — bepaalt het vertrouwen binnen GCP-projecten	Medium — IAM-rolontwerp en CA-poolindeling	Hoog — Google Cloud CAS met Cloud HSM	Platformteams, beveiligingsarchitecten
Hybride PKI met on-premises en multi-cloudomgevingen die één governance-laag nodig hebben.	Hoog — omvat alle platforms daarboven	Gemiddeld, bij gebruik van een beheerde laag; hoog bij zelfintegratie.	Hoogwaardig met een beheerde PKI-as-a-Service en een laag voor certificaatlevenscyclusbeheer.	CISO's, beveiligingsarchitecten, compliance

Praktische checklist: Audit van een PKI met meerdere leveranciers

Issue	Business Impact	Aangeraden actie	Eigenaar
Er is geen gedocumenteerd besluitvormingsproces voor welk platform welke certificaten uitgeeft.	Dubbele CA-hiërarchieën, inconsistente sleutelbeveiliging tussen teams.	Gebruik een gedocumenteerde beslissingsmatrix (gebruiksscenario, impact op de beveiliging, benodigde inspanning, geschiktheid voor automatisering, verantwoordelijke) voordat u een nieuwe CA instelt.	Beveiligingsarchitecten, CISO's
Elke CA-hiërarchie die nog steeds afhankelijk is van FIPS 140-2 gevalideerde HSM's	Validaties krijgen de status 'Historisch' op 21 september 2026.	Plan een migratie naar FIPS 140-3 Level 3 gevalideerde HSM's waar het platform dit ondersteunt.	PKI-beheerders, naleving
Handmatige uitgifte of verlenging van certificaten op elk platform.	Kan het tempo van de steeds korter wordende geldigheidsperiode van CA/Browser Forum niet bijhouden.	Stap over op platformspecifieke automatisering (ACM, ACM Private CA of Google Cloud CAS) of een beheerde PKI/CLM-laag.	Platformteams, PKI-beheerders
Er is geen consistente auditregistratie bij Microsoft PKI, AWS en Google Cloud CA's.	Nalevingstekortkomingen komen pas aan het licht tijdens een incident of een externe audit.	Schakel CloudTrail, cloudauditlogboeken en Windows Server-auditing in en centraliseer deze in één monitoringweergave.	Compliance, beveiligingsarchitecten
Er is geen plan voor crypto-flexibiliteit bij de uiteindelijke PQC-overgang.	Alle vier platformen hebben vandaag de dag nog steeds contracten met RSA of ECDSA.	Voeg de PQC-gereedheidsbeoordeling en de crypto-agilityplanning toe aan de PKI-roadmap.	Beveiligingsarchitecten, CISO's

Wie zou zich hier druk over moeten maken?

De keuze tussen PKI-platformen is niet alleen een architectuurbeslissing. Dit is wat elke betrokkene moet onthouden.

PKI-beheerders

Verantwoordelijk voor de dagelijkse operationele taken van het platform (of de platforms) dat de organisatie gebruikt. Actiepunt: controleer of elke gebruikte CA-hiërarchie, of het nu Microsoft PKI, AWS of Google Cloud betreft, is opgenomen in een FIPS 140-3 Level 3 HSM-roadmap en of automatische verlenging is ingeschakeld waar het platform dit ondersteunt.

Beveiligingsarchitecten

Beheer de beslissingsmatrix en het hiërarchische ontwerp voor alle platformen. Actiepunt: documenteer waarom elke bestaande CA-hiërarchie zich op die plek bevindt en markeer elke hiërarchie die alleen bestaat vanwege historische inertie in plaats van een weloverwogen toepassing.

Platformteams

Beheer de automatiseringslaag die het uitgeven en verlengen van certificaten overbodig maakt. Actiepunt: identificeer welke van uw AWS-, Google Cloud- of Microsoft PKI-certificaten nog steeds handmatig via een console moeten worden uitgevoerd in plaats van via een geautomatiseerd protocol.

Compliance

Er bestaat eigen, bevestigende auditregistratie en CP/CPS-documentatie voor elke gebruikte CA-hiërarchie. Actiepunt: controleer of de FIPS-validatiestatus (140-2 versus 140-3) per HSM en per platform wordt bijgehouden en niet als vanzelfsprekend wordt beschouwd.

CISO's

Neem de algehele beslissing over zelf bouwen, kopen of multi-cloudoplossingen voor PKI. Actiepunt: weeg de operationele kosten af ​​van het afzonderlijk beheren van Microsoft PKI, AWS en Google Cloud CA's ten opzichte van consolidatie onder een beheerde PKI-as-a-Service en certificaatlevenscyclusbeheerlaag.

Onze visie: Hoe encryptieconsultancy de selectie van PKI-leveranciers ondersteunt.

Bij Encryption Consulting zijn we gespecialiseerd in het ontwerpen en migreren van PKI-infrastructuren die aansluiten op de unieke beveiligingsbehoeften van een organisatie, ongeacht welk platform of welke combinatie van platforms het meest geschikt is. We bieden uitgebreide PKI-ontwerp- en implementatiediensten voor zowel bestaande als nieuwe PKI-infrastructuren. Onze on-premises oplossingen omvatten Microsoft PKI, terwijl onze cloudgebaseerde PKI-oplossingen werken met toonaangevende cloudserviceproviders zoals AWS Certificate Manager, AWS ACM Private CA, Azure PKI en Google Cloud Certificate Authority Service.

Voor organisaties die deze beslissing, of de daaruit voortvloeiende hiërarchie, liever niet volledig intern beheren, biedt ons PKI-as-a-Service- platform een ​​volledig beheerde, cloudgebaseerde PKI met FIPS 140-3 HSM-ondersteunde sleutels vanaf dag één. De platformvergelijking hierboven wordt dan de taak van ons team in plaats van die van u. Onze CertSecure Manager- laag verzorgt vervolgens het certificaatlevenscyclusbeheer en de geautomatiseerde detectie van alle Microsoft PKI-, AWS- en Google Cloud-CA's die een organisatie al gebruikt, waarmee de handmatige uitgiftekloof die in de bovenstaande checklist werd genoemd, wordt gedicht. Wat betreft de eerder gestelde vraag over crypto-flexibiliteit, helpen ons PQC Center of Excellence en de PQC Readiness Assessment teams bij het plannen van de uiteindelijke overstap van RSA en ECDSA. Ons CBOM Secure cryptografische detectie- en inventarisatieplatform biedt beveiligingsarchitecten de machine-identiteitsinventaris die nodig is om precies te weten wat er momenteel op elke CA-hiërarchie draait. Voor een diepere analyse van het automatiseren van certificaatlevenscyclusbeheer nadat een platform is gekozen, kunt u ons gerelateerde artikel raadplegen over hoe CLM helpt bij het beperken van veelvoorkomende SSL/TLS-aanvallen.

Verder lezen

AWS ACM Private CA-gebruikershandleiding

Google Cloud Certificate Authority Service

Microsoft PKI-servicecertificaatbeleid

Conclusie

Public Key Infrastructure (PKI) speelt een cruciale rol in het waarborgen van veilige communicatie via digitale certificaten. Certificeringsinstanties (CA's) en registratie-instanties (RRA's) werken samen om entiteiten te authenticeren en de levenscyclus van certificaten te beheren. Verschillende leveranciers bieden op maat gemaakte PKI-oplossingen, elk met verschillende sterke punten voor verschillende gebruiksscenario's: Microsoft PKI pleit voor veilig sleutelbeheer op locatie met offline root-CA's en HSM's, AWS Certificate Manager en ACM Private CA bieden geautomatiseerd, cloud-native certificaatbeheer met FIPS 140-3 Level 3 HSM-bescherming, en Google Cloud's Certificate Authority Service legt de nadruk op op rollen gebaseerd toegangsbeheer en door cloud-HSM's ondersteunde ondertekeningssleutels. De juiste oplossing is zelden één platform op zich; het is een gedocumenteerde beslissing, afgestemd op het gebruiksscenario, de beveiligingsimpact, de operationele inspanning en het eigenaarschap, die wordt herzien naarmate de geldigheidsperioden korter worden en de industrie zich voorbereidt op het post-quantum tijdperk.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit de vergelijking van deze PKI-platformen?

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA en Google Cloud CAS geven allemaal vertrouwde digitale certificaten uit en beheren deze, maar verschillen in waar de CA-sleutels worden opgeslagen, hoe geautomatiseerd de uitgifte is en wie de operationele verantwoordelijkheid draagt. De juiste keuze hangt af van de specifieke toepassing, niet van één enkel "beste" platform.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams gebruiken steeds vaker meer dan één van deze platforms tegelijk. Zonder een gedocumenteerd besluitvormingsproces leidt die mix tot dubbele CA-hiërarchieën, inconsistente niveaus van sleutelbeveiliging en hiaten in de auditregistratie die pas aan het licht komen tijdens een incident.

Welke risico's nemen toe als de selectie van een PKI-leverancier zonder een gedocumenteerd proces verloopt?

Ad-hoc leveranciersselectie vergroot het risico op certificaten die zijn uitgegeven door HSM's met inconsistente beveiligingsniveaus, CA-hiërarchieën waar niemand controle over heeft en handmatige verlengingsprocessen die de steeds korter wordende geldigheidsduur van de CA/Browser Forum niet kunnen bijbenen.

Welke teams zouden de beslissing over de PKI-leverancier moeten nemen?

Beveiligingsarchitecten zijn doorgaans verantwoordelijk voor het ontwerp van de beslissingsmatrix en de hiërarchie, PKI-beheerders zijn verantwoordelijk voor de dagelijkse werking van de gekozen platforms, platformteams beheren de automatiseringslaag, compliance controleert de documentatie en de FIPS-status, en de CISO neemt de uiteindelijke beslissing over zelf ontwikkelen, kopen of een multi-cloudoplossing implementeren.

Hoe hangt de keuze van een PKI-leverancier samen met het beheer van de certificaatlevenscyclus?

Elk platform in deze vergelijking vereist nog steeds dat de uitgifte, verlenging en intrekking van certificaten betrouwbaar verloopt. De tools voor certificaatlevenscyclusbeheer, die Microsoft PKI, AWS en Google Cloud omvatten, zorgen ervoor dat dit betrouwbaar blijft, ongeacht welk platform een ​​bepaald certificaat heeft uitgegeven.

Hoe kunnen organisaties meten of hun keuze voor een PKI-leverancier succesvol is?

Houd storingen en incidenten met verlopen certificaten bij die verband houden met certificaten, of de uitgifte en verlenging geautomatiseerd of handmatig verlopen, of de auditregistratie gecentraliseerd is over alle platformen, en of het HSM-beveiligingsniveau van elke CA-hiërarchie actueel is.

Wat moet er regelmatig gecontroleerd of gemonitord worden binnen een PKI met meerdere leveranciers?

Controleer regelmatig de CA-hiërarchiedocumentatie (CP/CPS), de FIPS-validatiestatus per HSM, de vervaldatum van certificaten op alle gebruikte platforms en of CloudTrail, Cloud Audit Logs en Windows Server-auditing daadwerkelijk zijn ingeschakeld en worden bewaakt.

Welke invloed heeft de keuze van een PKI-leverancier op cloud-, hybride- of multi-CA-omgevingen?

Hybride en multi-cloudomgevingen draaien vaak Microsoft PKI on-premises naast AWS- en Google Cloud CA's, elk met een eigen console, automatiseringsmodel en auditlogboek. Een enkele governance-laag of beheerd PKI/CLM-platform zorgt er meestal voor dat deze mix consistent blijft in plaats van gefragmenteerd.

Welke veelgemaakte fouten moeten teams vermijden bij de keuze tussen deze platforms?

Veelgemaakte fouten zijn onder andere het kiezen van een platform op basis van de cloud waarop de rest van de workload draait in plaats van de daadwerkelijke use case, het jarenlang ongecontroleerd laten van de FIPS-validatiestatus van een Root CA en het parallel uitvoeren van CA-hiërarchieën over verschillende platforms zonder een gedocumenteerde reden voor elk platform.

Wat moet er elk kwartaal worden vernieuwd voor een PKI met meerdere leveranciers?

Controleer de dashboards voor het verlopen van certificaten, bevestig de voortgang van de FIPS 140-3-migratie voor alle HSM's die nog steeds onder 140-2 vallen, herzie de beslissingsmatrix voor alle nieuwe use cases die sinds de laatste beoordeling zijn toegevoegd en bevestig dat wijzigingen in de geldigheidsperiode van CA's/Browser Forums worden weerspiegeld in de automatische verlenging.