Alles wat u moet weten over PKI-as-a-Service (PKIaaS)

Op 21 juli 2024 legde een verlopen certificaat binnen de infrastructuur van de Bank of England de CHAPS- en retailbetalingssystemen van de bank gedurende 91 minuten plat, aldus de bank zelf. Dat is geen klein IT-probleem. Het is een waarschuwing dat verlopen of slecht beheerde certificaten een betalingssysteem volledig kunnen lamleggen. PKI-as-a-service is er juist om dat scenario te voorkomen door de volledige certificaatlevenscyclus, van het opzetten van een certificeringsinstantie (CA) tot het uitgeven, verlengen en intrekken van eindgebruikerscertificaten, te verplaatsen naar een beheerd cloudplatform.

In plaats van hardware aan te schaffen, software te implementeren en speciaal PKI-personeel in te huren, krijgt u dezelfde vertrouwensinfrastructuur als een service, met geautomatiseerde procedures en lagere overheadkosten doordat de certificaatlevenscyclus voor u wordt afgehandeld.

Samenvatting

PKI-as-a-Service (PKIaaS) host de root- en uitgevende certificeringsinstanties van een organisatie in de cloud en automatiseert de uitgifte, verlenging en intrekking van certificaten. Dit zijn de belangrijkste punten voor een PKI- of beveiligingsteam dat PKI evalueert:

• PKIaaS host uw root- en uitgevende certificeringsinstanties in de cloud en beheert namens u de volledige certificaatlevenscyclus.
• Het maakt gebruik van dezelfde PKI-bouwstenen als een on-premises implementatie: publieke/private sleutelparen, digitale certificaten en een vertrouwensketen die is gebaseerd op een certificeringsinstantie (CA).
• CA/Browser Forum-stemming SC-081v3 verkort de maximale levensduur van openbare TLS-certificaten tot 200 dagen vanaf 15 maart 2026, en tot 47 dagen in maart 2029, waardoor handmatig certificaatbeheer steeds minder praktisch wordt.
• Geautomatiseerde inschrijvingsprotocollen (ACME, SCEP, EST, WSTEP) stellen PKIaaS in staat certificaten uit te geven en te verlengen zonder dat een mens elke keer op 'verlengen' hoeft te klikken.
• PKIaaS ruilt de initiële kosten voor hardware en personeel in voor een abonnementsmodel, terwijl u toch de controle behoudt over het certificaatbeleid en, in het model van Encryption Consulting, over uw eigen privésleutels.

Nu je in één oogopslag weet wat PKIaaS is, laten we eens kijken naar de relatie met Public Key Infrastructure zelf. PKIaaS vervangt de PKI-concepten immers niet, maar verandert alleen wie ze beheert.

Hoe PKI-as-a-Service zich verhoudt tot Public Key Infrastructure (PKI)

PKI geeft digitale certificaten uit (zoals SSL/TLS-certificaten) om datacommunicatie te authenticeren met behulp van asymmetrische encryptie. Hierbij worden X.509-certificaten gegenereerd op basis van publieke en private sleutelparen. Of u dit nu intern beheert of als PKIaaS afneemt, de vertrouwensketen bestaat uit dezelfde vier componenten.

Publieke en private sleutels

Asymmetrische encryptie wordt uitgevoerd met behulp van publieke en private sleutels. Wanneer een client gevoelige informatie moet ontvangen, deelt deze zijn publieke sleutel met de afzender om de gegevens te versleutelen. Alleen de houder van de bijbehorende private sleutel kan de gegevens ontsleutelen en lezen.

Digitale certificaten

De privésleutel van de certificeringsinstantie (CA) ondertekent het digitale certificaat . Deze handtekening bevestigt zowel de identiteit van de certificaathouder als diens eigendom van de bijbehorende publieke sleutel.

Certificeringsinstantie: Hoofd-CA en uitgevende CA

De certificeringsinstantie ondertekent en verstrekt het digitale certificaat met haar eigen privésleutel. Er zijn twee niveaus:

• Root-CADe hoogste autoriteit die de basis legt voor vertrouwen in de PKI-hiërarchie. Deze autoriteit geeft certificaten uit en ondertekent deze voor intermediaire certificeringsinstanties (CA's) en wordt doorgaans offline bewaard in een zeer veilige omgeving om het vertrouwen op lange termijn te beschermen.
• Uitgevende CADeze dienst verwerkt en ondertekent certificaataanvragen van eindgebruikers (bijvoorbeeld SSL/TLS-certificaten), ongeacht of deze via een Microsoft CA-proxy of een andere registratiemethode binnenkomen. De dienst werkt online en verzorgt de dagelijkse uitgifte, verlenging en intrekking van certificaten.

Registratie Authoriteit

De registratieautoriteit fungeert als schakel tussen gebruikers en de certificeringsinstantie (CA). De registratieautoriteit verifieert de identiteit van iedereen die een certificaat aanvraagt ​​en stuurt gevalideerde aanvragen door naar de CA voor uitgifte.

PKI-as-a-Service versus zelfbeheerde (traditionele) PKI: welke is de juiste keuze voor u?

De bovenstaande componenten zijn hetzelfde, ongeacht of u PKI on-premises implementeert (zelfbeheerd) of het als PKIaaS aanschaft. Wat wel verschilt, is wie ze beheert, en dat verschil heeft invloed op de kosten, snelheid en schaalbaarheid.

Factor	PKI-as-a-Service	Zelfbeheerde (traditionele) PKI
Deployment	Snelle, beheerde installatie met minimale infrastructuurvereisten vanuit uw organisatie.	Voor de configuratie van hardware, software en netwerk zijn aanzienlijke tijd, expertise en middelen nodig.
Management	De uitgifte, verlenging en intrekking van certificaten worden door de dienstverlener afgehandeld, waardoor de operationele kosten worden verlaagd.	Wordt intern beheerd, waardoor speciaal personeel nodig is voor de lopende certificeringstaken en het onderhoud.
Schaalbaarheid	De cloudinfrastructuur past zich automatisch aan naarmate het aantal certificaten toeneemt of fluctueert.	Opschalen vereist extra hardware, softwarelicenties en configuratiewijzigingen.
Kosten	Het abonnementsmodel elimineert de kosten voor hardware, software en doorlopend onderhoud, waardoor de initiële investering lager uitvalt.	Vereist een hoge investering vooraf in hardware, software-installatie en doorlopend beheer.
Verlengingsfrequentie na 47 dagen.	Geautomatiseerde uitgifteprotocollen (ACME, SCEP, EST) vangen de verlengingsfrequentie op zonder extra personeel.	Handmatige verlengingsprocessen lopen al vast ruim voordat certificaten 100 dagen, laat staan ​​47 dagen, geldig zijn.

PKI-as-a-Service is de beste keuze voor organisaties die prioriteit geven aan gebruiksgemak, kostenbesparing en snellere implementatie, vooral omdat de levensduur van certificaten steeds korter wordt. Organisaties met strikte vereisten voor dataresidentie of zeer gespecialiseerde CA-configuraties kunnen nog steeds geldige redenen hebben om PKI zelf te beheren, maar die lijst wordt steeds korter naarmate automatiseringsprotocollen zich verder ontwikkelen.

Koopbeslissingstabel: Welk PKI-implementatiemodel past het beste bij uw organisatie?

Gebruik deze tabel om de beperkingen van uw organisatie te koppelen aan een implementatiemodel voordat u leveranciers evalueert.

Criterium	On-Prem PKI	SaaS PKI	PKIaaS
Speciaal opgeleid PKI-personeel beschikbaar	Nodig	Verminderd, maar nog steeds nodig voor beleid.	Niet verplicht
Groei van het certificaatvolume	Opschaling vereist nieuwe hardware.	Schaalbaar binnen uw cloudomgeving	Schaalt automatisch, beheerd door de zorgverlener.
Tijd tot het eerste certificaat	Weken tot maanden	Dagen tot weken	dagen
Budgetmodel	Hoge investering vooraf	Cloudverbruik plus interne personeelstijd	Abonnement, minimale kosten vooraf
Controle van privésleutels	Volledig, in je eigen HSM's	Volledig, in uw eigen cloudomgeving.	Volledig, in door de provider gehoste HSM's (in het model van Encryption Consulting)
Beste geschikt voor	Strikte gegevensresidentie of zeer gespecialiseerde CA-configuraties	Organisaties hebben al een cloudplatform als standaard gebruikt.	Organisaties die prioriteit geven aan snelheid, automatisering en lagere overheadkosten.

Hoe PKI-as-a-Service werkt: de workflow voor certificaataanvragen

Vanaf het moment dat een apparaat een certificaatondertekeningsverzoek indient tot het moment dat het een ondertekend certificaat ontvangt, doorloopt een PKIaaS-platform vijf stappen:

1. Aanvraag voor certificaat starten. Een klant vraagt ​​een certificaat aan met behulp van een protocol zoals ACME, SCEP of AfgestemdHet verzoek gaat naar de Certificate Enrollment Gateway (CEG), die een beveiligde verbinding met de Certificate Authority Gateway (CAGW) tot stand brengt met behulp van een eigen clientcertificaat.
2. Verzoekverwerking. De CAGW, die draait op een containersysteem, ontvangt het verzoek en stuurt het via een beveiligde proxy door naar de juiste beheerde CA.
3. Verbinding met de uitgevende CA. De proxy vormt de verbinding tussen de CAGW en de aangewezen uitgevende CA, waarbij de verbinding wordt beveiligd door wederzijdse client- en servercertificaten.
4. Certificaatverlening. De uitgevende certificeringsinstantie (CA) geeft het certificaat voor de eindgebruiker uit, vaak via Active Directory-certificaatservices (AD CS).
5. Certificaatuitreiking. Het ondertekende certificaat wordt via de proxy teruggestuurd naar de CAGW, die het vervolgens doorstuurt naar de CEG voor levering aan de aanvragende client.

Elke stap in deze keten is beveiligd door wederzijdse certificaatverificatie, waardoor het hele traject, van aanvraag tot levering, plaatsvindt zonder dat iemand elk certificaat handmatig hoeft goed te keuren.

Belangrijkste kenmerken van PKI-as-a-Service

PKI-as-a-Service biedt een uitgebreide set mogelijkheden voor het beheren van digitale certificaten en sleutelparen. De belangrijkste functies vallen in vier groepen uiteen:

• PKI-infrastructuurbeheer: gecentraliseerde configuratie van beheerde PKI, inclusief optionele scheiding van Root CA, waarbij de volledige CA-levenscyclus de beste praktijken in de branche volgt, zoals FIPS 140-3 Level 3 HSM's om de privésleutels van CA's met hoge beschikbaarheid te beveiligen. NIST zal FIPS 140-2-validatiecertificaten op 21 september 2026 als 'historisch' bestempelen, dus nieuwe HSM-implementaties moeten FIPS 140-3 specificeren.
• Beveiliging van certificeringsinstantiesRoot CA-sleutels worden veilig en transparant gegenereerd, met automatische inschrijvingsprotocollen zoals SCEP, EST en ACME, plus REST API's die de uitgifte en verlenging automatiseren.
• Beleids- en compliancebeheerCertificaatprofielen, geldigheidsperioden en gebruiksbeperkingen voor sleutels worden gedefinieerd om te voldoen aan de beveiligingsvereisten van uw organisatie, met inachtneming van standaarden zoals NIST, FIPS en GDPR.
• Integratie en automatiseringRESTful API's verbinden PKI-services met andere applicaties en systemen, waarbij scripts en tools de uitgifte en het beheer van begin tot eind automatiseren.

Gebruiksscenario's en ondersteunde protocollen voor PKI-as-a-Service

PKIaaS ontleent zijn waarde aan automatisering, en automatisering werkt met gestandaardiseerde inschrijvingsprotocollen. Hieronder leggen we uit wat elk protocol doet en waar het in past.

Geautomatiseerde omgeving voor certificaatbeheer (ACME)

• Automatiseert de communicatie tussen certificeringsinstanties (CA's) en clients die servercertificaten aanvragen voor een domein, zoals gedefinieerd in RFC 8555.
• Valideert domeineigendom via HTTP-01 (het plaatsen van een bestand op de webserver) of DNS-01 (het aanmaken van een DNS-record) uitdagingen.
• De communicatie verloopt via HTTPS, waardoor het certificaatbeheerproces veilig en fraudebestendig blijft.
• Is dit het protocol dat het Chrome Root Program sinds februari 2024 van CA-aanvragers vereist, en is het protocol dat het CA/Browser Forum het meest direct beloont met verkorte certificaatlevensduren, omdat het is ontworpen voor volledige automatisering zonder handmatige verlengingsstap?

Eenvoudig certificaatinschrijvingsprotocol (SCEP)

• Automatiseert de certificaatregistratie voor apparaten zoals routers en switches, waardoor handmatige inspanningen in omgevingen met veel apparaten worden verminderd.
• Gebruikt PKCS#10 (Standaarden voor openbare sleutelcryptografie) voor certificaatverzoeken, gestandaardiseerd in RFC 8894 (2020) na decennialang een de facto standaard te zijn geweest.
• Verifieert de identiteit van het aanvragende apparaat of de gebruiker via een gedeeld wachtwoord voordat een certificaat wordt uitgegeven.
• Het wordt nog steeds veel gebruikt in mobiel apparaatbeheer (MDM) en oudere netwerkhardware, hoewel EST de modernere, veiligere opvolger is.

Inschrijving via beveiligd transport (EST)

• Gedefinieerd in RFC 7030 als de moderne vervanging voor SCEP, werkend via HTTPS met wederzijdse TLS-authenticatie.
• Zowel de client als de server verifiëren elkaar, waardoor een vertrouwenskloof wordt gedicht die het gedeelde-wachtwoordmodel van SCEP openlaat.
• Geschikt voor PKI- en IoT-implementaties binnen bedrijven die al gebruikmaken van een TLS-infrastructuur en behoefte hebben aan een sterkere wederzijdse authenticatie dan SCEP biedt.

WSTEP (Windows-inschrijving)

• Hiermee kan een Windows-inschrijvingsclient via de webservice voor certificaatinschrijvingsbeleid verbinding maken met een domeincontroller en certificaten aanvragen bij meerdere certificeringsinstanties (CA's).
• Beperkt de toegang tot certificaten tot geautoriseerde apparaten, waardoor de algehele netwerkbeveiliging wordt verbeterd.
• beschermt certificaatinschrijving Gegevens worden via beveiligde kanalen en versleuteling verzonden.

Microsoft Intune-integratie

• De Certificate Enrollment Gateway kan SCEP-aanvragen met een CSR van Windows-clients ontvangen en deze doorsturen naar Intune voor validatie, waardoor het apparaatbeheer voor mobiele apparaten, desktops en virtuele eindpunten wordt gestroomlijnd.
• Cryptografische beleidsregels en algoritmen blijven afgestemd op de wettelijke en nalevingsvereisten.
• Automatische intrekking in Intune versnelt de ongeldigverklaring van certificaten, wat bijdraagt ​​aan een robuuster noodherstelplan.

Eindpuntverificatie (UEM/MDM)

• Controleert of certificaten zijn uitgegeven met sterke beveiligingsinstellingen, waardoor inzicht wordt verkregen in het gebruik en de geldigheid van certificaten.
• Vereist dat Mobile Device Management (MDM)-clients zich bij de Certificate Enrollment Gateway authenticeren met geldige inloggegevens, waarbij per client ten minste één gebruikersnaam/wachtwoordcombinatie is gedefinieerd.
• Zorgt voor gedetailleerde toegangscontrole en op rollen gebaseerde machtigingen, een compliance-vereiste volgens NIST en FIPS 140-3, zodat alleen bevoegd personeel gevoelige certificaatfuncties kan beheren.
• Certificaten worden pas verstrekt na controle van de integriteit en de beveiligingspatches op het aanvragende apparaat.

S / MIME

• Biedt end-to-end-versleuteling van e-mailberichten.
• Scheidt de functionaliteit voor ondertekening en versleuteling, waardoor S/MIME-certificaten zowel niet-afwijzing als vertrouwelijkheid kunnen bieden.
• Maakt gebruik van sleutelgeschiedenisbeheer en geautomatiseerde back-up om cryptografische sleutels ononderbroken beschikbaar te houden.
• Werkt op Windows, macOS, iOS en Android.

Beheerde PKI

• Beveiligt de infrastructuur van de Root CA volgens de ISO/IEC 27001-normen en beschermt cryptografische activa.
• Hiermee behoudt u volledige controle over uw privésleutels, met compleet overzicht van certificaten en cryptografische bewerkingen.
• Bewaart privésleutels in een FIPS 140-3 Level 3-gecertificeerde omgeving. Hardware-beveiligingsmodules (HSM's) om ongeautoriseerde toegang of manipulatie te voorkomen.
• Controleert de geldigheid en status van het certificaat via de CRL (Certificate Revocation List) en OCSP (Online Certificaat Status Protocol) services.

Checklist voor SLA en beveiligingscontroles bij de evaluatie van een PKIaaS-provider

Controleer voordat u een PKIaaS-contract ondertekent of de provider voldoet aan de volgende SLA- en beveiligingsvereisten:

• Gepubliceerde uptime-SLA (99.9% of hoger) voor uitgifte-, verlengings- en intrekkingspunten, met gedocumenteerde responstijden bij incidenten.
• De privésleutels van de root- en uitgevende CA worden gegenereerd en opgeslagen in FIPS 140-3 Level 3 gevalideerde HSM's, niet in algemene servers.
• De beschikbaarheidsverplichtingen van CRL en OCSP-responders worden afzonderlijk van de SLA voor de kernuitgifte gepubliceerd.
• Gedocumenteerde sleutelceremonieprocedures en auditrechten voor het genereren van Root CA-sleutels.
• Een aangegeven doorlooptijd voor de intrekking van certificaten na een gemelde inbreuk op de bedrijfssleutel.
• Op rollen gebaseerde toegangscontrole en autorisatie door meerdere personen voor gevoelige CA-activiteiten.
• Duidelijke vermelding van waar certificaatmetadata en auditlogboeken worden opgeslagen, om de locatie van de gegevens te bevestigen.
• Gedocumenteerde architectuur voor noodherstel en failover op het niveau van de uitgevende certificeringsinstantie.
• Actuele compliance-certificeringen (ISO/IEC 27001, SOC 2, PCI-DSS, HIPAA, GDPR) met recente auditdata.
• Contractvoorwaarden die het eigendom van de privésleutel en de overdraagbaarheid ervan garanderen bij een latere overstap naar een andere provider.

HSM- en compliancevereisten voor PKI-as-a-Service

De betrouwbaarheid van een PKIaaS-platform hangt af van de hardware die de privésleutels van de certificeringsinstantie beschermt en het nalevingskader dat de werking ervan regelt.

• FIPS 140-3 niveau 3 HSM'sDe privésleutels van de root-CA en de uitgevende CA moeten worden gegenereerd en opgeslagen in hardwarebeveiligingsmodules (HSM's) die zijn gevalideerd volgens FIPS 140-3 niveau 3. NIST zal FIPS 140-2-validatiecertificaten op 21 september 2026 als 'historisch' bestempelen. Controleer daarom of elke HSM die uw provider gebruikt, is gevalideerd volgens FIPS 140-3 en niet afhankelijk is van een verlopend FIPS 140-2-certificaat.
• ISO / IEC 27001Het informatiebeveiligingsbeheersysteem van de provider moet beschikken over een actuele ISO/IEC 27001-certificering voor de systemen waarop uw CA-infrastructuur draait.
• HIPAA, PCI-DSS en GDPRAls uw certificaten persoonsgebonden gezondheidsinformatie (PHI), kaartgegevens of persoonsgegevens uit de EU beschermen, controleer dan of de PKIaaS-omgeving van de provider expliciet is opgenomen in hun HIPAA-, PCI-DSS- of GDPR-complianceprogramma, en niet alleen in het algemene compliancebeleid van het moederbedrijf.
• SleutelbewaringsmodelMaak vooraf duidelijk of uw organisatie of de provider de uiteindelijke controle over de privésleutel van de Root CA heeft. Het PKIaaS-model van Encryption Consulting zorgt ervoor dat die controle bij de klant blijft, iets wat niet elke provider biedt.

Waarom certificaatautomatisering nu belangrijk is: de deadline van 47 dagen

Dit is het punt waar de meeste uitleggers van PKI aan voorbijgaan: de argumenten voor PKIaaS zijn in 2026 veel sterker geworden, en het gaat niet meer alleen om gemak.

In april 2025 keurde het CA/Browser Forum wetsvoorstel SC-081v3 goed, dat een gefaseerde verkorting van de maximale geldigheidsduur van openbare TLS-certificaten vaststelt: 200 dagen vanaf 15 maart 2026 (reeds van kracht), 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Dat is een daling van de oude standaard van 398 dagen naar verlengingen om de 47 dagen, ongeveer acht keer per jaar, binnen drie jaar.

De operationele berekeningen kloppen niet met handmatige vernieuwing met die frequentie, en de branchegegevens bevestigen dit. Het CyberArk State of Machine Identity Security Report 2025, gebaseerd op een enquête onder meer dan 1,200 beveiligingsleiders, toonde aan dat 72% van de organisaties het afgelopen jaar minstens één certificaatgerelateerde storing heeft ondervonden en 50% een beveiligingsincident of -inbreuk meldde die verband hield met gecompromitteerde machine-identiteiten. Automatisering is ook een voorwaarde geworden voor openbare CA's: het Chrome Root Program vereist sinds februari 2024 dat CA-aanvragers ten minste één geautomatiseerde oplossing voor uitgifte en vernieuwing ondersteunen voor elk certificaatbeleid dat ze uitgeven, en vanaf 15 juni 2026 vereist het bovendien dat openbaar vertrouwde TLS-certificaten alleen de serverauthenticatie-EKU bevatten, waardoor elke organisatie die nog steeds openbare certificaten gebruikt voor clientauthenticatie of mTLS gedwongen wordt over te stappen naar een private CA.

Onze mening: als uw team certificaten nog steeds handmatig verlengt of bijhoudt in een spreadsheet, dan is de periode van 100 dagen in maart 2027 het moment waarop dat proces vastloopt, niet de periode van 47 dagen in 2029. Beschouw 2026-2027 als de periode om over te stappen op automatisering op basis van ACME, SCEP of EST, of dat nu via een intern platform of een PKIaaS-provider is, voordat de frequentie van de verlengingen de handmatige verwerking door uw team overstijgt.

Waarom encryptieconsulting voor PKI-as-a-Service?

Implementeer PKI-as-a-Service in uw omgeving.

Encryption Consulting biedt een flexibele, zeer betrouwbare PKIaaS-oplossing met schaalbare ondersteuning die de volledige levenscyclus van digitale certificaten voor uw organisatie beheert. Twee gebieden springen eruit:

• Aanpasbare en schaalbare oplossingenEen framework dat is afgestemd op de beveiligingsvereisten van uw organisatie, met brede CA-ondersteuning en de mogelijkheid om het aantal certificaten en gebruikers op te schalen zonder de prestaties te belemmeren.
• Consistente ondersteuning: sterke beveiligingsfuncties afgestemd op HIPAAPCI-DSS en GDPR, plus dagelijkse operationele ondersteuning om het certificaatbeleid onder controle te houden.

Implementatiemodellen: on-premise, SaaS PKI en PKIaaS

Encryption Consulting biedt drie implementatiemethoden aan, zodat u het model kunt afstemmen op uw omgeving:

• On-premise PKI: Beheerde PKI geïmplementeerd binnen uw eigen infrastructuur, met root- en uitgevende CA's gehost op locatie.
• SaaS PKICertificaatlevenscyclusbeheer geconfigureerd binnen het eigen cloudplatform van uw organisatie.
• PKIaaSGeautomatiseerd certificaatlevenscyclusbeheer en een op maat gemaakte Managed PKI, volledig gehost in de cloudomgeving van Encryption Consulting en afgestemd op uw domein en beveiligingsvereisten.

Conclusie

PKIaaS is de in de cloud gehoste evolutie van hetzelfde PKI-vertrouwensmodel waarop organisaties al decennia vertrouwen, maar dan zonder de hardware, het personeel en de handmatige verlengingskosten. Elke organisatie die gevoelige gegevens verwerkt, of het nu gaat om persoonsgegevens (PII) of beschermde gezondheidsinformatie (PHI), heeft de authenticatie en encryptie nodig die een PKI biedt. PKIaaS levert dit als een beheerde cloudservice in plaats van een intern infrastructuurproject.

Nu de CA/Browser Forum-campagne de levensduur van certificaten al verkort, is de vraag niet of certificaatbeheer geautomatiseerd moet worden, maar hoe snel. Een PKIaaS-platform gebouwd op ACME, SCEP en EST biedt die automatisering zonder extra personeel aan te nemen, terwijl u toch de controle behoudt over het certificaatbeleid en, afhankelijk van de provider, over uw eigen privésleutels.

Veelgestelde vragen over PKI-as-a-Service

Wat is de belangrijkste conclusie uit deze handleiding over PKI-as-a-Service?

PKIaaS verplaatst de activiteiten van de root- en uitgevende certificeringsinstantie, het beheer van HSM's en de volledige certificaatlevenscyclus naar een beheerd cloudplatform. Hierdoor kan een onderneming de kapitaalkosten en personeelslast van een zelfbeheerde PKI inruilen voor een abonnement dat automatisch schaalt en gelijke tred houdt met de steeds korter wordende geldigheidsperioden van certificaten.

Waarom is PKI-as-a-Service met name belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams authenticeren elke server, elk apparaat en elke service op het netwerk. Omdat de geldigheidsduur van openbare TLS-certificaten daalt van 398 dagen naar 47 dagen in 2029, wordt handmatige uitgifte en verlenging operationeel onhoudbaar op bedrijfsniveau. PKIaaS biedt deze teams geautomatiseerde inschrijvingsprotocollen (ACME, SCEP, EST), waardoor het aantal certificaten kan toenemen zonder dat er extra personeel nodig is.

Welke risico's nemen toe als PKI handmatig wordt beheerd in plaats van via PKIaaS?

Handmatig PKI-beheer vergroot het risico op storingen door verlopen certificaten, zoals de 91 minuten durende CHAPS-storing bij de Bank of England, gemiste verlengingen die verborgen zitten in spreadsheets, inconsistente sleutelbeveiliging buiten FIPS-gevalideerde HSM's en vertraagde intrekking na een inbreuk. Uit een onderzoek van CyberArk uit 2025 bleek dat dergelijke risico's de meeste bedrijven al treffen.

Welke teams moeten verantwoordelijk zijn voor de implementatie en het voortdurende beheer van PKI-as-a-Service?

De teams die zich bezighouden met beveiligingsarchitectuur en identiteit/PKI zouden verantwoordelijk moeten zijn voor het ontwerp van de CA-hiërarchie en de beleidsbeslissingen, terwijl de IT-operations- of platformengineeringteams doorgaans de dagelijkse integratie van inschrijvingen in Intune, DevOps-pipelines en netwerkapparaten beheren. Compliance-teams moeten inzicht hebben in auditlogboeken en voorwaarden voor sleutelbeheer, aangezien de HSM- en wettelijke vereisten uiteindelijk bij hen liggen.

Hoe is PKIaaS gekoppeld aan certificaatlevenscyclusbeheer (CLM)?

PKIaaS vormt de infrastructuurlaag, de root- en uitgevende certificeringsinstanties zelf, terwijl certificaatlevenscyclusbeheer de operationele laag is die de uitgifte, verlenging, intrekking en vervaldatum van elk certificaat dat door de certificeringsinstantie wordt uitgegeven, bijhoudt. Door een PKIaaS-implementatie te combineren met een CLM-platform zoals CertSecure Manager krijgt u volledig inzicht, van de certificeringsinstantie tot aan individuele certificaten, iets wat handmatige tracking op grote schaal niet kan evenaren.

Hoe moeten organisaties het succes van een PKIaaS-implementatie meten?

Houd het aantal certificaatgerelateerde storingen bij (doel: nul), de gemiddelde tijd tussen het indienen van een CSR en het uitgeven van een certificaat, het percentage certificaten dat via geautomatiseerde protocollen wordt uitgegeven versus handmatige aanvragen, de bevindingen van HSM- en CA-audits per cyclus, en de naleving van de verkorte geldigheidsperioden van het CA/Browser Forum zonder handmatige tussenkomst. Een daling van ongeplande verlengingsincidenten is het duidelijkste signaal van succes.

Wat moet er in een PKIaaS-omgeving regelmatig gecontroleerd of gemonitord worden?

Controleer de logboeken voor het beheer van privésleutels van de certificeringsinstantie (CA) en de toegang tot de hardware-simulatieserver (HSM), de logboeken voor certificaatuitgifte en -intrekking, de uptime van de CRL/OCSP-responder, authenticatiegebeurtenissen van het inschrijvingsprotocol (ACME-uitdagingsvalidatie, SCEP-gedeelde geheimen, EST-wederzijdse TLS) en de naleving van ISO/IEC 27001, HIPAA, PCI-DSS of GDPR, afhankelijk van welke van toepassing zijn op uw organisatie.

Welke invloed heeft PKIaaS op cloud-, hybride- of multi-CA PKI-omgevingen?

PKIaaS is ontworpen om te werken in cloud-, hybride- en multi-CA-omgevingen. De Certificate Authority Gateway routeert aanvragen naar de juiste Managed CA via een beveiligde proxy, zodat een organisatie die meerdere CA's beheert, bijvoorbeeld aparte CA's voor interne apparaten en publiekelijk toegankelijke TLS, één geautomatiseerde inschrijvingslaag krijgt in plaats van het vernieuwingsproces van elke CA afzonderlijk te beheren.

Welke veelgemaakte fouten moeten teams vermijden bij de implementatie van PKI-as-a-Service?

De meest voorkomende fouten zijn: PKIaaS beschouwen als een simpele overname van bestaande handmatige processen in plaats van een herontwerp rond automatisering; niet controleren waar de provider de privésleutels genereert en opslaat voordat een contract wordt getekend; de validatievereisten van FIPS 140-3 voor HSM's overslaan; en failover naar een redundante uitgevende CA niet testen voordat dit nodig is tijdens een storing.

Wat moet er in een PKI-as-a-Service-programma elk kwartaal worden vernieuwd?

Controleer de CA-certificaatprofielen en geldigheidsperioden aan de hand van het huidige CA/Browser Forum-schema, herbevestig de HSM FIPS-certificeringsstatus, met name omdat FIPS 140-2-certificaten op 21 september 2026 de status 'Historisch' krijgen, vernieuw de inventaris van de gebruikte inschrijvingsprotocollen per apparaattype en bevestig de SLA- en beveiligingscontroleverplichtingen met uw PKIaaS-provider.