PKIaaS-governanceframework: rollen, beleid, auditlogboeken en certificaatprofielen

De meeste organisaties die PKIaaS implementeren, beschouwen het als een infrastructuurbeslissing, niet als een governancebeslissing. Ze kiezen een CA-provider, configureren een roothiërarchie, zetten een ACME-endpoint op en beschouwen het als afgerond. Zes maanden later voert het beveiligingsteam een certificaatinventarisatie uit en vindt 300 certificaten uitgegeven met wildcard SAN's, 50 verlopen certificaten uit een buiten gebruik gestelde omgeving die niemand heeft ingetrokken, en geen auditlogboek dat laat zien wie ze heeft aangevraagd. De PKI is functioneel. De governance ontbreekt.

PKI-governance gaat niet over het toevoegen van bureaucratie aan de uitgifte van certificaten. Het gaat erom het PKI-programma controleerbaar, verdedigbaar en beheersbaar te maken naarmate het aantal certificaten groeit. Een PKI-governancekader definieert wie de CA-hiërarchie beheert, wie de certificaatprofielen mag wijzigen, wie de uitgiftegebeurtenissen controleert, hoe het naamgevingsbeleid wordt gehandhaafd, welke documentatie beschikbaar is ter ondersteuning van compliance-audits en hoe het programma in de loop der tijd wordt verbeterd. In dit artikel wordt dat kader laag voor laag opgebouwd, in termen die direct bruikbaar zijn voor eigenaren van PKI-programma's binnen een organisatie, compliance-verantwoordelijken en infrastructuurarchitecten.

Kort antwoord: Wat is een PKIaaS-governanceframework?

Een PKIaaS-governanceframework is het operationele model dat de infrastructuur van certificeringsinstanties controleerbaar en compliant maakt. Het bestaat uit vijf componenten: de organisatiestructuur (wie de CA-hiërarchie beheert en welke rollen verantwoordelijk zijn voor uitgifte, beheer en audit); de beleidsdocumentatie (certificaatbeleid en certificeringspraktijkverklaring); de technische beheersmaatregelen (certificaatprofielen, SAN-whitelists, configuraties van de inschrijvingsworkflow); het auditspoor (uitgebreide logboeken van elke certificaatgebeurtenis via alle inschrijvingskanalen); en het verbeteringsproces (regelmatige evaluaties, volwassenheidsbeoordeling en beleids-als-code-wijzigingsbeheer). Samen vormen deze componenten een PKI-programma dat een SOC 2-audit, een WebTrust-beoordeling of een regulatoire controle kan doorstaan zonder dat achteraf records hoeven te worden gereconstrueerd die al die tijd bewaard hadden moeten worden.

Key Takeaways

PKI-governance is iets anders dan PKI-infrastructuur. Infrastructuurbeslissingen (CA-provider, HSM-model, inschrijvingsprotocol) zijn eenmalige keuzes. Governancebeslissingen (wie de CA bezit, wat het certificaatbeleid inhoudt, hoe auditlogboeken worden bewaard) worden continu herhaald en bepalen of het PKI-programma controleerbaar, compliant en in de loop der tijd verbeterbaar is.
Rolscheiding vormt de structurele basis van PKI-governance. De persoon die certificaatprofielen definieert, mag niet dezelfde persoon zijn die certificaten onder die profielen uitgeeft. De persoon die certificaten uitgeeft, mag niet dezelfde persoon zijn die het auditlogboek van die uitgiften controleert. Deze scheidingen zijn geen procedurele suggesties; het zijn de structurele controles die compliance-frameworks verifiëren tijdens PKI-audits.
Voor elk PKI-programma dat onderworpen is aan een externe audit, zijn een certificeringsbeleid (CP) en een certificeringspraktijkverklaring (CPS) vereist. Het CP definieert wat vereist is; de CPS beschrijft hoe de PKIaaS-certificeringsinstantie (CA) deze vereisten implementeert. Zonder deze documenten kan het PKI-programma niet worden gecontroleerd en kan de organisatie de naleving niet aantonen aan auditors, toezichthouders of andere partijen die op de certificering vertrouwen.
Certificaatprofielen vormen de technische handhaving van het certificaatbeleid. Een goed ontworpen profielset maakt het technisch onmogelijk om een certificaat uit te geven dat in strijd is met het beleid, ongeacht welke inschrijfinterface de aanvrager gebruikt. Profielen zijn betrouwbaarder dan beleidsdocumenten alleen, omdat ze beperkingen afdwingen bij de certificeringsinstantie in plaats van te vertrouwen op naleving door de aanvrager.
Policy-as-code is de volwaardige implementatie van het beheer van wijzigingen in PKI-governance. Certificaatprofieldefinities, SAN-whitelists en roltoewijzingen worden opgeslagen in versiebeheerde repositories en geïmplementeerd via een gecontroleerde CI/CD-pipeline. Dit levert het auditspoor voor wijzigingsbeheer op dat compliance-frameworks vereisen, zonder dat er papieren goedkeuringsworkflows nodig zijn die op grote schaal moeilijk te onderhouden zijn.

Laag 1: Organisatiestructuur en roltoewijzing

Het governancekader voor PKIaaS begint bij mensen, niet bij technologie. Wie is de eigenaar van de CA-hiërarchie? Wie kan deze wijzigen? Wie niet? De meeste mislukkingen op het gebied van PKI-governance zijn terug te voeren op een gebrek aan verantwoordelijkheid: de CA werd geïmplementeerd door iemand die de organisatie verliet, er werd geen opvolger aangewezen en de CA-configuratie is al twee jaar niet gecontroleerd. Formele roltoewijzing elimineert dit probleem.

CA-eigenaar (PKI-programmaleider)

De CA-eigenaar is eindverantwoordelijk voor het PKI-programma. Deze persoon is verantwoordelijk voor: het ontwerp van de CA-hiërarchie en het bijbehorende certificaatbeleid; het goedkeuren van wijzigingen in certificaatprofielen en SAN-toegangslijsten; het beoordelen en publiceren van het CPS; het beheren van het wijzigingsbeheerproces voor CA-configuratie; het waarborgen dat roltoewijzingen actueel zijn en dat het proces voor het toetreden, verplaatsen en verlaten van medewerkers certificaatgerelateerde toegang omvat; en het presenteren van de governance-status van het PKI-programma aan auditors, juridisch adviseurs en leidinggevenden.

De CA-eigenaar mag niet dezelfde zijn als de certificaatbeheerder die de reguliere uitgifte van certificaten verzorgt. Door deze rollen in één persoon te combineren, wordt de scheiding tussen beleidsdefinitie en beleidsuitvoering, die compliance-frameworks vereisen, opgeheven. In de praktijk is de CA-eigenaar doorgaans de PKI-architect, de CISO of het hoofd van de beveiligingsafdeling, afhankelijk van de structuur van de beveiligingsfuncties binnen de organisatie.

Certificaatbeheerder

Certificaatbeheerders verstrekken, verlengen en trekken certificaten in binnen de profielen en SAN-toegangslijsten die de CA-eigenaar heeft geconfigureerd. Voor geautomatiseerde inschrijvingsprocessen (ACME, SCEP, MDM, WSTEP) wordt de rol van certificaatbeheerder functioneel vervuld door de serviceaccounts of API-referenties die de inschrijvingsautomatisering gebruikt. Voor handmatige inschrijvingsprocessen (eForm-goedkeuringsworkflows, CSR-gebaseerde uitgifte voor externe partners) vervullen aangewezen personen de rol van certificaatbeheerder en beoordelen zij aanvragen voordat de uitgifte wordt goedgekeurd.

Certificaatbeheerders kunnen geen profielen, SAN-toegangslijsten, CA-configuratie of roltoewijzingen wijzigen. Ze kunnen certificaten uitgeven die voldoen aan het geconfigureerde beleid; ze kunnen niet wijzigen wat het beleid toestaat. Deze beperking wordt afgedwongen door de op rollen gebaseerde toegangscontrole van de PKIaaS CA, niet alleen door het beleid.

CA-auditor

De CA-auditor heeft alleen-leestoegang tot alle gegevens over certificaatuitgifte, gebeurtenissen in de inschrijvingsworkflow en auditlogboeken voor alle inschrijvingskanalen en CA-partities. De auditor kan geen certificaten uitgeven, geen certificaten intrekken en geen CA-configuratie wijzigen. De rol van auditor is onafhankelijk: deze moet worden vervuld door iemand van het beveiligingsteam, het compliance-team of een externe auditor, en niet door iemand met toegang als certificaatbeheerder of CA-beheerder.

De onafhankelijkheid van de CA Auditor-rol is de eigenschap die het auditspoor betekenisvol maakt. Een auditlogboek dat door het uitgevende team kan worden gewijzigd, is geen auditlogboek; het is een registratie van wat het uitgevende team heeft gekozen om vast te leggen. De CA Auditor-rol, geconfigureerd in de PKIaaS CA en afgedwongen door het toegangscontrolemodel van de CA, zorgt ervoor dat het auditspoor zichtbaar is voor een onafhankelijke waarnemer die door niemand met operationele toegang kan worden belemmerd om het in te zien.

Beheerders en auditors van de inschrijvingsworkflow

Beheerders van de inschrijvingsworkflow configureren de geautomatiseerde inschrijvingsworkflows (ACME-eindpunten, SCEP-profielen, MDM-integraties, WSTEP-agents) die platformteams en apparaatbeheersystemen gebruiken om certificaten te verkrijgen. Ze hebben geen directe bevoegdheid om certificaten uit te geven; ze configureren de automatiseringspaden waarlangs de uitgifte plaatsvindt. Door het beheer van de inschrijvingsworkflow te scheiden van het CA-beheer, kan het team dat de automatiseringsintegratie bouwt de profielen of whitelists die bepalen wat de automatisering kan aanvragen, niet wijzigen.

Auditors van de inschrijvingsworkflow hebben alleen-leestoegang tot de gebeurtenislogboeken van de inschrijvingsworkflow. Dit biedt inzicht in de auditmogelijkheden per kanaal voor teams die specifieke inschrijvingsautomatisering moeten bewaken zonder bredere CA-toegang.

Alle roltoewijzingen moeten worden beheerd via de identiteitsprovider van de organisatie (Entra ID, Okta of een vergelijkbaar systeem) in plaats van via lokale PKIaaS-gebruikersaccounts. Door de identiteitsprovider beheerde toewijzingen genereren een auditlogboek van de roltoewijzing in het toegangslogboek van de identiteitsprovider, vallen onder de procedures voor het toetreden, overstappen en verlaten van medewerkers binnen de organisatie en zijn, samen met alle andere toegangstoewijzingen, zichtbaar voor het IAM-team.

Laag 2: Certificaatbeleid en verklaring inzake certificeringspraktijken

Het certificeringsbeleid (CP) en de certificeringspraktijkverklaring (CPS) zijn de beheersdocumenten die het PKI-programma controleerbaar maken voor externe partijen. Zonder deze documenten heeft een auditor die het PKI-programma beoordeelt geen document om de daadwerkelijke praktijk mee te vergelijken; ze kunnen niet vaststellen of het programma functioneert zoals bedoeld, omdat er geen expliciete intentie is om mee te vergelijken.

Wat het certificeringsbeleid inhoudt

Het certificaatbeleid is een document met vereisten, geen implementatiedocument. Het beschrijft waaraan certificaten moeten voldoen die door de PKIaaS CA worden uitgegeven voor elk certificaattype dat de organisatie uitgeeft. Een goed gestructureerd certificaatbeleid voor een PKIaaS-implementatie binnen een onderneming behandelt de volgende punten:

Certificaattypen en hun doeleinden: Elk benoemd certificaattype (interne service TLS, gebruikersauthenticatie, S/MIME, smartcardaanmelding, codeondertekening, apparaatidentiteit) wordt gedefinieerd met de beoogde gebruiksscenario's, de partijen die erop zullen vertrouwen en de vereisten voor uitgifte (wie kan een aanvraag indienen, hoe de identiteit wordt geverifieerd, welke goedkeuring vereist is);
Belangrijkste algoritmevereisten: Minimale sleutelgroottes en algoritmen voor elk certificaattype, afgestemd op de huidige NIST-richtlijnen (momenteel minimaal RSA-2048; RSA-3072 of ECDSA P-256 heeft de voorkeur voor nieuwe uitgiften; er wordt verwezen naar het PQC-algoritmemigratieplan);
Geldigheidsperioden van certificaten: Maximale geldigheidsperioden voor elk certificaattype, met toelichting (kortere geldigheidsperiode voor certificaten met hoge privileges, zoals smartcard-aanmelding en codeondertekening; langere geldigheidsperiode voor infrastructuurcertificaten waarbij automatische verlenging gegarandeerd is);
Verplichtingen van de abonnee: Wat certificaathouders moeten doen (de privésleutel beschermen, een inbreuk op de sleutel onmiddellijk melden, het certificaat alleen gebruiken voor het beoogde doel, intrekking aanvragen wanneer het certificaat niet langer nodig is);
Voorwaarden voor intrekking: Wanneer certificaten moeten worden ingetrokken (sleutelcompromis, vertrek van abonnee, einde van gebruiksscenario, CA-compromis) en de maximale tijd tussen het intrekkingsbesluit en de CRL/OCSP-update.

Wat de CPS inhoudt

De Certification Practice Statement (CPS) beschrijft hoe de PKIaaS CA de in de CP gestelde eisen implementeert. De CPS is het implementatiedocument dat auditors beoordelen om te bevestigen dat de werkwijzen van de CA overeenkomen met de eisen van de CP. Belangrijke onderdelen zijn onder andere:

Beschrijving van de CA-hiërarchie: De structuur van de root CA, intermediaire CA's en uitgevende CA's; hun belangrijkste algoritmen, geldigheidsperioden en HSM-beveiligingsmodel (FIPS 140-2 Level 3 of FIPS 140-3 gecertificeerde HSM's voor CA-ondertekeningssleutels);
Inschrijfprocedure: Hoe elk certificaattype wordt aangevraagd, hoe de identiteit en bevoegdheid van de aanvrager worden geverifieerd, welke goedkeuring vereist is vóór uitgifte en welk inschrijvingsprotocol wordt gebruikt;
Specificatie van het certificaatprofiel: De technische parameters van elk certificaatprofiel (sleutelalgoritme, EKU OID's, SAN-typen, geldigheidsperiode, regels voor onderwerpvelden), waaruit blijkt hoe elk profiel de certificaattypedefinitie van de CP implementeert;
Beschrijving van het auditlogboek: Welke gebeurtenissen worden geregistreerd, welke velden worden per gebeurtenis vastgelegd, hoe worden logbestanden beschermd tegen manipulatie, hoe worden logbestanden bewaard en wie heeft er toegang toe?
Veranderingsbeheerproces: Hoe wijzigingen in certificaatprofielen, SAN-toegangslijsten, CA-configuratie en roltoewijzingen worden voorgesteld, beoordeeld, goedgekeurd en geïmplementeerd;
Belangrijkste procedures tijdens de ceremonie: Hoe CA-sleutelparen worden gegenereerd, hoe M-van-N-gesplitste sleutelbewaring wordt geïmplementeerd, hoe de root-CA offline wordt gehouden en hoe sleutelceremoniegegevens worden bijgehouden.

Bij PKIaaS-implementaties onderhoudt de PKIaaS-provider een CPS voor de gedeelde CA-platforminfrastructuur (HSM-beheer, fysieke beveiliging, beschikbaarheids-SLA's). De klant moet een CPS-sectie onderhouden met daarin de certificaatprofielen en -beleidsregels die ze configureren, de inschrijvingsprocedures die ze implementeren en de organisatorische controles (roltoewijzingen, wijzigingsbeheer, abonnementsovereenkomsten) die ze hanteren.

Laag 3: Certificaatprofielen en SAN-toegangslijsten

Certificaatprofielen en SAN-toegangslijsten zijn de technische beheersmaatregelen die ervoor zorgen dat de vereisten van het certificaatprotocol (CP) automatisch worden afgedwongen door de certificeringsinstantie (CA). Een CP dat stelt dat "codeondertekeningscertificaten minimaal een RSA-4096-sleutel vereisen" en een profiel dat deze beperking afdwingt, resulteert in een CA die technisch gezien geen codeondertekeningscertificaat met een RSA-2048-sleutel kan uitgeven, ongeacht wat de aanvrager specificeert. Dit is betrouwbaarder dan een beleidsdocument dat ervan uitgaat dat aanvragers het beleid lezen en naleven.

Certificaatprofiel Bestuur

Elk certificaatprofiel in de PKIaaS CA moet overeenkomen met precies één certificaattypedefinitie in de CP. De technische beperkingen van het profiel moeten voldoen aan de vereisten van de CP voor dat certificaattype. De profielset voor een volwaardige PKIaaS-implementatie omvat doorgaans de volgende benoemde categorieën, elk met specifieke beperkingen:

Interne TLS-service: ECDSA P-256 of RSA-2048, maximale geldigheidsduur van 90 dagen, TLS Server Auth EKU (OID 1.3.6.1.5.5.7.3.1), alleen DNS SAN, CN moet een volledig gekwalificeerde domeinnaam zijn;
mTLS-clientidentiteit: ECDSA P-256, geldigheidsduur van 24 tot 48 uur, TLS Client Auth EKU (OID 1.3.6.1.5.5.7.3.2), URI SAN (SPIFFE ID-formaat) of DNS SAN, export van privésleutel niet toegestaan;
VPN- en 802.1X-authenticatie voor gebruikers: ECDSA P-256 of RSA-2048, maximale geldigheidsduur van 1 jaar, TLS Client Auth EKU, UPN SAN ingevuld vanuit IdP tijdens inschrijving;
S/MIME: RSA-2048 of ECDSA P-256, maximale geldigheidsduur van 2 jaar, Email Protection EKU (OID 1.3.6.1.5.5.7.3.4), RFC 822 Name SAN (e-mailadres), geen sleutelexport indien opgeslagen in hardware;
Aanmelden met smartcard: RSA-2048 minimaal, geldigheidsduur van 1 tot 3 jaar, Smart Card Logon EKU (OID 1.3.6.1.4.1.311.20.2.2) en TLS Client Auth EKU, UPN SAN, hardwarematige sleutelopslag vereist, eForm handmatige goedkeuringsworkflow;
Codeondertekening: RSA-4096 of ECDSA P-384, geldigheidsduur van 1 tot 4 uur voor pijplijncertificaten of 1 jaar voor organisatorische codeondertekeningscertificaten, Code Signing EKU (OID 1.3.6.1.5.7.3.3), hardwarematige sleutelopslag vereist voor organisatorische certificaten, handmatige goedkeuringsworkflow via eForm.

Profielwijzigingen vereisen goedkeuring van de CA-beheerder en moeten het wijzigingsbeheerproces doorlopen zoals beschreven in de CPS. Het wijzigingsbeheerrecord (pull request in de policy-as-code repository of het formele goedkeuringsrecord van de wijziging) vormt het auditbewijs dat de profielwijziging is geautoriseerd.

SAN-toelatingslijstbeheer

SAN-toegangslijsten handhaven het naamgevingsbeleid op CA-niveau. Het beheerproces van de toegangslijst definieert hoe nieuwe namen aan de lijst worden toegevoegd, hoe namen worden verwijderd wanneer services worden uitgefaseerd en hoe naamgevingsconflicten tussen teams worden opgelost.

Een volwaardig beheerproces voor de SAN-whitelist omvat:

Naam eigendomsregister: Een register koppelt elk toegestaan SAN-patroon aan het team dat het bezit, de goedkeurder die het heeft geautoriseerd en de datum waarop het is toegevoegd. Dit register dient als controletrail voor beslissingen over naamautorisatie;
Optelproces: Nieuwe SAN-patronen vereisen goedkeuring van de CA-beheerder en van het team dat eigenaar is van het domein of de namespace waartoe het patroon behoort. De goedkeuring wordt vastgelegd in het register van domeinnamen.
Verwijderingsproces: Wanneer een service wordt buiten gebruik gesteld of het domein van een team verandert, moet het bijbehorende SAN-patroon van de whitelist worden verwijderd om te voorkomen dat er in de toekomst nog onder dat patroon licenties worden uitgegeven. De verwijdering wordt in het register vastgelegd met de datum van buitenbedrijfstelling.
Conflictoplossing: Wanneer twee teams overlappende SAN-patronen aanvragen, lost de CA-beheerder het conflict op basis van domeineigendomsgegevens (DNS-registratiegegevens, interne documentatie over naamgevingsconventies) en documenteert de oplossing.

Laag 4: Auditlogboeken en bewijsverzameling

Het auditlogboek is de belangrijkste bron van bewijsmateriaal voor PKI-nalevingsbeoordelingen. Een auditor die het PKI-programma beoordeelt, zal om gegevens van specifieke gebeurtenissen vragen: welke certificaten zijn uitgegeven tijdens de auditperiode, wie ze heeft aangevraagd, welk profiel is gebruikt, of de aanvraag een handmatige goedkeuringsprocedure heeft doorlopen en wat de goedkeuringsbeslissing was. Als het PKIaaS-auditlogboek niet al deze velden voor alle inschrijvingskanalen registreert, kan de audit niet naar behoren worden afgerond.

Wat het auditlogboek moet vastleggen

Voor elke certificaatgebeurtenis (uitgifte, verlenging, intrekking, administratieve handeling) moet het auditlogboek minimaal het volgende registreren:

Type evenement: Certificaat uitgegeven, certificaat verlengd, certificaat ingetrokken, profiel aangemaakt, profiel gewijzigd, roltoewijzing gewijzigd, CA-configuratie gewijzigd, inschrijvingsworkflow aangemaakt of gewijzigd;
Certificaatidentiteit: Het serienummer van het betreffende certificaat, de subject DN, alle SAN-waarden, het gebruikte certificaatprofiel, de uitgevende CA en de geldigheidsperiode van het certificaat;
Identiteitsverzoek: Voor geautomatiseerde inschrijving: de ACME-account-ID, de SCEP-uitdagings-ID, de MDM-inschrijvingsgegevens of de gebruikte API-gegevens; voor handmatige inschrijving: de naam en rol van de goedkeurende certificaatbeheerder.
Tijdstempel: De UTC-tijdstempel van de gebeurtenis, met voldoende precisie om de opeenvolging van gebeurtenissen binnen een kort tijdsvenster te reconstrueren;
Goedkeuringsbesluit: Voor aanvragen die handmatig zijn goedgekeurd, moeten de identiteit van de goedkeurder, het tijdstempel van de goedkeuringsbeslissing en eventuele notities van de goedkeurder worden vastgelegd.

Bescherming en bewaring van logbestanden

Auditlogboeken moeten worden beschermd tegen manipulatie en bewaard gedurende de toepasselijke nalevingsperiode. De vereisten variëren per framework:

SOC 2: De SOC 2 Trust Service Criteria specificeren geen minimale bewaartermijn voor logbestanden, maar typische SOC 2-auditperioden beslaan 6 tot 12 maanden en auditors verwachten dat logbestanden gedurende de volledige auditperiode beschikbaar zijn. Het bewaren van PKI-auditlogbestanden gedurende ten minste 12 maanden is de standaard.
WebTrust voor certificeringsinstanties: WebTrust vereist dat CA-auditgebeurtenissen worden bewaard en beschikbaar zijn voor inzage door de WebTrust-auditor. De bewaartermijn moet worden gespecificeerd in het CPS (Certified Professional Studies) van de CA; 7 jaar is een veelvoorkomende bewaartermijn voor CA-auditgegevens in door WebTrust gecontroleerde programma's.
FedRAMP en FISMA: NIST SP 800-53 vereist dat auditlogboeken worden bewaard in overeenstemming met de beveiligingscategorisatie van het systeem; doorgaans 3 jaar voor systemen met een gemiddelde impact;
DORA (Digital Operational Resilience Act): DORA vereist dat incidenten met betrekking tot ICT worden geregistreerd en vastgelegd; het PKI-auditlogboek valt binnen dit toepassingsgebied voor financiële instellingen en hun ICT-leveranciers in de EU.

Logbeveiliging vereist het exporteren van PKIaaS-auditlogs naar een SIEM-systeem of een fraudebestendig logarchief dat losstaat van het PKIaaS-platform. Een logbestand dat alleen in de PKIaaS-beheerconsole bestaat, is niet onafhankelijk fraudebestendig en is mogelijk niet beschikbaar als het PKIaaS-account is gecompromitteerd of verkeerd geconfigureerd. Exporteren naar een apart logarchief zorgt ervoor dat de auditgegevens bewaard blijven, onafhankelijk van de beschikbaarheid en toegangscontrole van het PKIaaS-platform.

Het samenstellen van het bewijsmateriaal voor auditors

Een PKI-nalevingsaudit vereist meer dan alleen het auditlogboek. Het bewijsmateriaal omvat doorgaans:

CP- en CPS-documenten: De huidige versies met publicatiedatums en versienummers, plus eerdere versies die de auditperiode bestrijken indien de CP/CPS gedurende die periode is bijgewerkt;
Bewijs van roltoewijzing: Screenshots of exports van de IdP die de huidige roltoewijzingen (CA-eigenaar, certificaatbeheerders, CA-auditors) weergeven, met de toewijzingsgeschiedenis die laat zien wie elke rol tijdens de auditperiode heeft bekleed;
Bewijs van HSM-certificering: Het FIPS 140-2 Level 3- of FIPS 140-3-validatiecertificaat voor het HSM-model dat wordt gebruikt om CA-ondertekeningssleutels te beschermen, of het bewijs van de PKIaaS-aanbieder dat het platform gevalideerde HSM's gebruikt;
CA-certificaatketen: De volledige certificaatketen van root-CA tot uitgevende CA, met vermelding van de belangrijkste algoritmen, geldigheidsperioden en onderwerpgegevens voor elk CA-certificaat;
Certificaatprofielconfiguraties: De huidige profielconfiguraties, geëxporteerd vanuit de PKIaaS-beheerinterface of de policy-as-code-repository, tonen de technische parameters van elk gedefinieerd profiel;
Wijzigingsbeheerrecords: Het wijzigingslogboek voor alle CA-configuratiewijzigingen gedurende de auditperiode, met daarin de wijzigingsbeschrijving, de aanvrager, de beoordelaar, het goedkeuringsbesluit en het implementatietijdstempel;
Voorbeelden van auditlogboeken: Voorbeelden van registraties van uitgifte-, verlengings-, intrekkings- en administratieve gebeurtenissen, waaruit blijkt dat de vereiste velden voor elk type gebeurtenis zijn vastgelegd.

Laag 5: Beleid als code en wijzigingsbeheer

De meest operationeel volwassen PKI-governanceprogramma's beheren certificaatprofielen, SAN-whitelists, roltoewijzingen en configuraties van de inschrijvingsworkflow als versiebeheerde code in plaats van als handmatige consoleconfiguraties. Policy-as-code produceert governance-artefacten die anders moeilijk te genereren zijn: een complete geschiedenis van elke configuratiewijziging, de identiteit van de reviewer die elke wijziging heeft goedgekeurd en de mogelijkheid om de exacte configuratie op te vragen die op een willekeurige datum in het verleden van kracht was.

De policy-as-code-architectuur voor PKIaaS-governance werkt als volgt:

Profieldefinities in versiebeheer: Certificaatprofielconfiguraties worden opgeslagen als JSON- of YAML-bestanden in een versiebeheerde repository. Deze repository is de gezaghebbende bron voor de configuratie-eisen waaraan de PKIaaS CA moet voldoen. Wijzigingen in profielconfiguraties worden voorgesteld als pull requests, beoordeeld door de CA-beheerder (en, bij belangrijke wijzigingen, door de CA-eigenaar) en pas na goedkeuring samengevoegd.
Geautomatiseerde implementatie via de PKIaaS REST API: Een CI/CD-pipeline bewaakt de repository op samengevoegde wijzigingen en implementeert goedgekeurde configuraties naar de PKIaaS CA via de REST API voor beheer. De implementatie wordt vastgelegd in het auditlogboek van de CI/CD-pipeline, waarin de commit-hash, het implementerende serviceaccount en het implementatietijdstempel worden geregistreerd.
Afwijkingsdetectie als continue nalevingscontrole: Een geplande taak vergelijkt de actuele PKIaaS CA-configuratie met de verwachte configuratie van de repository. Elke afwijking (een profiel dat buiten het IaC-proces is gewijzigd, een rol die is toegewezen zonder een overeenkomstige wijziging in de repository) wordt als waarschuwing gemeld aan de CA-eigenaar en de CA-auditor.
Branchebescherming en vereiste controles: De hoofdbranch van de repository is beveiligd, waardoor directe commits niet zijn toegestaan; alle wijzigingen moeten via een pull request met ten minste één verplichte reviewer verlopen. De pull request-geschiedenis van de repository vormt het auditspoor voor wijzigingsbeheer dat door auditors wordt gecontroleerd.

PKI Governance Maturity Model

De volwassenheid van PKI-governance beschrijft hoe systematisch en consistent een organisatie het hierboven beschreven governancekader toepast. De vier volwassenheidsniveaus bieden een gemeenschappelijke taal voor het beoordelen van de PKI-volwassenheid binnen een organisatie en voor het plannen van de route van de huidige naar de gewenste situatie.

Niveau 1: Informeel. Het PKI-programma heeft geen gedocumenteerd certificaatbeleid of CPS. Er bestaan certificaatprofielen, maar deze worden inconsistent toegepast; sommige certificaataanvragen ontvangen aangepaste parameters die niet in een gedefinieerd profiel zijn opgenomen. Auditlogboeken zijn aanwezig in de PKIaaS-console, maar worden niet geëxporteerd of bewaard na de standaard bewaartermijn. Roltoewijzingen zijn informeel; dezelfde persoon die certificaten uitgeeft, beheert ook de CA-configuratie. Er is geen formeel wijzigingsbeheerproces voor wijzigingen in de CA-configuratie.

Niveau 2: Gedefinieerd. Het PKI-programma heeft een gedocumenteerd CP en CPS, gepubliceerd voor de relevante belanghebbenden (IT-beveiligingsteam, juridische afdeling, compliance). Certificaatprofielen zijn gedefinieerd voor elke certificaatcategorie en worden consistent toegepast via de profielhandhaving van de PKIaaS CA. Rollen zijn formeel toegewezen, hoewel de rollen van CA-eigenaar en certificaatbeheerder nog steeds door meerdere personen kunnen worden vervuld. Auditlogboeken worden geëxporteerd naar een SIEM, maar worden alleen reactief (naar aanleiding van incidenten, niet proactief) gecontroleerd. Wijzigingsbeheer is gedocumenteerd, maar wordt inconsistent toegepast.

Niveau 3: Beheerd. Het governancekader is volledig geïmplementeerd: CP en CPS zijn actueel en worden jaarlijks gecontroleerd, certificaatprofielen worden beheerd en versiebeheerd, rolscheiding wordt afgedwongen via de IdP zonder overlappingen, auditlogboeken worden geëxporteerd met geconfigureerde bewaartermijnen en proactief gecontroleerd door de CA-auditor volgens een vastgestelde frequentie, en wijzigingsbeheer wordt consistent toegepast met een volledig wijzigingslogboek. CLM-monitoring biedt continu inzicht in de naleving van de gedefinieerde profielen door het certificaatportfolio. Het programma is beoordeeld aan de hand van ten minste één extern compliancekader (SOC 2, WebTrust, FedRAMP of branchespecifiek).

Niveau 4: Continu verbeteren. Het programma opereert op niveau 3 en daarnaast: certificaatprofielen en de CP/CPS worden volgens een vast ritme herzien, afgestemd op de updates van de algoritmevereisten van NIST, het CA/B Forum en ETSI; beleids-als-code-wijzigingsbeheer is volledig geïmplementeerd met detectie van afwijkingen; een cryptografische inventaris (CBOM) wordt continu bijgehouden en dient als input voor de jaarlijkse herziening van het algoritmebeleid; het programma heeft een vastgesteld PQC-migratieplan met meetbare voortgangsindicatoren; en de volwassenheid van de governance wordt jaarlijks beoordeeld aan de hand van een gepubliceerde analyse van de tekortkomingen en een verbeteringsplan.

Hoe encryptieconsultancy kan helpen

PKI-diensten (CP/CPS-ontwikkeling): Encryptie Consulting's PKI-diensten Dit omvat de ontwikkeling van certificaatbeleid en certificeringspraktijkverklaringen voor PKIaaS-implementaties binnen bedrijven. De CP/CPS-documenten beschrijven de certificaattypen, de belangrijkste algoritmevereisten, de geldigheidsperioden, de inschrijvingsprocedures, de procedures voor auditlogboeken en de processen voor wijzigingsbeheer die vereist zijn door SOC 2, WebTrust, FedRAMP, DORA, NIS2 en andere compliance-frameworks. Encryption Consulting heeft CP/CPS-documentatie ontwikkeld voor PKI-programma's, variërend van interne CA's van één organisatie tot hiërarchieën met meerdere CA's en honderdduizenden actieve certificaten. Neem contact met ons op via Encryptie Consulting.
PKI als een service: Encryptie Consulting's PKIaaS-aanbod Biedt de beheerde CA-infrastructuur waarop het governanceframework draait: certificaatprofielen met de volledige set beperkingen zoals beschreven in dit bericht (sleutelalgoritmen, EKU OID's, maximale geldigheidsduur, SAN-typen), op rollen gebaseerde toegangscontrole (CA-eigenaar/beheerder, certificaatbeheerder, CA-auditor, beheerder van de inschrijvingsworkflow, auditor van de inschrijvingsworkflow), beheer van de SAN-whitelist, export van auditlogboeken met vastlegging van gebeurtenissen per inschrijvingskanaal en REST API-toegang voor beleids-als-code-implementatie van profiel- en configuratiewijzigingen.
CertSecure Manager: Encryptie Consulting's CertSecure Manager Biedt de CLM-zichtbaarheidslaag die het governance-model van niveau 3 en 4 vereist: continue certificaatinventarisatie van alle door PKIaaS uitgegeven certificaten, monitoring van profielconformiteit (waarbij certificaten die de huidige profielbeperkingen schenden, worden gemarkeerd, profielafwijkingen worden aangegeven of verouderde certificaten van vóór de implementatie van governance-maatregelen aanwezig zijn), vervaldatummonitoring met configureerbare waarschuwingsroutering, SIEM-integratie voor het exporteren van auditlogboeken en het correleren van gebeurtenissen, en dashboards voor compliance-rapportage voor de kwartaal- en jaarlijkse governance-evaluaties.
PKI-beoordelingsservice: Voor organisaties die hun huidige PKI-governance-volwassenheid beoordelen of zich voorbereiden op een compliance-audit, biedt Encryption Consulting de volgende diensten aan. PKI-beoordelingsservice Het rapport evalueert de huidige situatie aan de hand van de vier volwassenheidsniveaus, identificeert lacunes in de governance met betrekking tot de CP/CPS-documentatie, rolverdeling, profielconfiguraties, auditlogdekking en wijzigingsbeheerpraktijken, en stelt een prioriteitsplan voor herstelmaatregelen op. Het beoordelingsrapport kan direct als bewijsmateriaal worden gebruikt bij de voorbereiding op compliance-audits.
Compliance-adviesdiensten: Voor organisaties die vallen onder DORA, NIS2, FedRAMP, CMMC, HIPAA, PCI DSS of andere raamwerken met specifieke PKI-governancevereisten, biedt Encryption Consulting de volgende oplossingen: Nalevingsadviesdiensten Koppel het PKIaaS-governancekader aan de specifieke vereisten van elke toepasselijke compliance-standaard met betrekking tot documentatie van het certificaatbeleid, het bewaren van auditlogboeken, bewijs van rolscheiding, normen voor sleutelbescherming en wijzigingsbeheer, en stel het compliance-bewijspakket samen dat klaar is voor toezicht door de regelgevende instantie.
CBOM Secure: Voor organisaties met een volwassenheidsniveau van 4 die een continue cryptografische inventaris bijhouden als onderdeel van hun governanceprogramma, biedt Encryption Consulting de volgende oplossingen: CBOM Secure Het systeem biedt geautomatiseerde cryptografische ontdekking en CBOM-generatie die de basis vormt voor de jaarlijkse herziening van het algoritmebeleid, identificeert certificaten van niet-geregistreerde uitgevers (wat wijst op ongecontroleerde PKI-activiteiten buiten het governancekader) en brengt lacunes in de naleving van algoritmen aan het licht voordat de deadlines voor de afschaffing van NIST IR 8547 noodmaatregelen vereisen.

Conclusie

PKI-governance is geen simpel vinkje bij de compliance-eisen. Het is het operationele model dat een PKI-programma betrouwbaar, controleerbaar en in de loop der tijd verbeterbaar maakt. De zes lagen die in dit artikel worden beschreven (organisatiestructuur, beleidsdocumentatie, certificaatprofielen, SAN-toegangslijsten, bewijsmateriaal uit auditlogboeken en beleids-als-code-wijzigingsbeheer) pakken de governance-lacunes aan die leiden tot de problemen waarmee organisaties in PKI-programma's daadwerkelijk te maken krijgen: certificaten die niemand bezit, profielen die niemand handhaaft, auditsporen die niemand controleert en compliance-beoordelingen die niet kunnen worden voltooid omdat de vereiste documentatie ontbreekt.

Het volwassenheidsmodel biedt eigenaren van PKI-programma's een gemeenschappelijke taal om te beoordelen waar hun programma zich bevindt en wat de volgende stap is. De meeste organisaties die lacunes in hun PKI-governance ontdekken, doen dit tijdens een compliance-audit of na een incident met certificaten. Op dat moment is herstel urgent en ingrijpend. Door het governancekader proactief toe te passen, zelfs op niveau 2 (gedefinieerde beleidsregels en consistente profielen), wordt de basis gelegd voor het bereiken van niveau 3 door middel van stapsgewijze verbetering in plaats van noodmaatregelen.

Als uw organisatie de volwassenheid van haar PKI-governance beoordeelt of zich voorbereidt op een compliance-audit die een PKI-programma-evaluatie omvat, neem dan contact op met Encryption Consulting.

Dit bericht wordt elke zes maanden herzien en wanneer de CA/B Forum Baseline Requirements, NIST SP 800-57, WebTrust for CA criteria of belangrijke compliance frameworks updates publiceren die van invloed zijn op de documentatievereisten voor PKI-governance of de vereisten voor auditbewijs.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen een certificeringsbeleid en een certificeringspraktijkverklaring?

Een certificaatbeleid (CP) definieert wat vereist is: de regels waaraan certificaten moeten voldoen om een specifiek doel te dienen. Een certificeringspraktijkverklaring (CPS) beschrijft hoe de certificeringsinstantie (CA) deze vereisten in de praktijk implementeert. Het CP beantwoordt de vraag "wat moet waar zijn?"; de CPS beantwoordt de vraag "hoe zorgen we ervoor dat het waar is?". Bij PKIaaS-implementaties onderhoudt de provider een CPS voor de gedeelde platforminfrastructuur; de klant moet een CPS onderhouden voor de certificaatprofielen, inschrijvingsprocedures en organisatorische beheermaatregelen die zij bovenop het platform configureren.

Welke rollen zijn vereist in een PKIaaS-governancemodel en wat zijn hun verantwoordelijkheden?

Er zijn vijf rollen vereist: de CA-eigenaar (definieert beleid, keurt profielwijzigingen goed, mag niet routinematig certificaten uitgeven); de certificaatbeheerder (geeft certificaten uit binnen gedefinieerde profielen, kan profielen niet wijzigen); de CA-auditor (alleen-leestoegang tot alle uitgiftegegevens en auditlogboeken, onafhankelijk van het operationele team); de beheerder van de inschrijvingsworkflow (configureert geautomatiseerde inschrijvingspaden, geen directe uitgiftebevoegdheid); en de auditor van de inschrijvingsworkflow (alleen-leestoegang tot logboeken van inschrijvingsgebeurtenissen). Niemand mag zowel de rol van CA-beheerder als die van CA-auditor vervullen, omdat dit de onafhankelijke controle die het auditspoor beoogt te bieden, tenietdoet.

Welke bewijsstukken zijn nodig voor een PKI-audit en hoe levert PKIaaS deze?

Een PKI-compliance-audit vereist: de CP- en CPS-documenten; auditlogboeken van alle certificaatgebeurtenissen (uitgifte, verlenging, intrekking) met de identiteit van de aanvrager, tijdstempel, gebruikt profiel en goedkeuringsbeslissing; bewijs van rolscheiding van de IdP; bewijs van HSM FIPS-certificering; de CA-certificaatketen; exports van profielconfiguraties; en wijzigingsbeheergegevens voor alle CA-configuratiewijzigingen gedurende de auditperiode. PKIaaS levert het auditlogboek, de HSM-sleutelbeveiliging en de CA-hiërarchie. De klant moet de CP/CPS, het bewijs van roltoewijzing en de wijzigingsbeheergegevens aanleveren.

Wat is PKI-volwassenheid en hoe wordt deze beoordeeld?

De PKI-volwassenheid beschrijft hoe systematisch een PKI-programma governance-controls toepast. Niveau 1 (Informeel) heeft ad-hocprocessen, geen CP/CPS, inconsistente profielen en geen formeel auditspoor. Niveau 2 (Gedefinieerd) heeft gedocumenteerd beleid en consistente profielen, maar een inconsistente toepassing. Niveau 3 (Beheerd) heeft volledig geïmplementeerde controls, actieve CLM-monitoring en ten minste één externe compliance-beoordeling. Niveau 4 (Continu Verbeterend) voegt daar policy-as-code change management, continue CBOM, jaarlijkse algoritme-beleidsbeoordelingen en een PQC-migratie-roadmap aan toe. De beoordeling vergelijkt de huidige controls met de vereisten van elk niveau.

Hoe werkt policy-as-code voor PKI-governance en wat zijn de voordelen ervan?

Policy-as-code slaat certificaatprofieldefinities, SAN-whitelists en roltoewijzingen op als versiebeheerde bestanden. Wijzigingen worden beoordeeld via een pull request voordat ze via de REST API naar de PKIaaS CA worden geïmplementeerd. Voordelen: elke wijziging heeft een gedocumenteerde reviewer en een tijdstempel van goedkeuring (de pull request); de configuratie op elke datum in het verleden kan worden opgevraagd via de versiegeschiedenis; een detectietaak voor afwijkingen vergelijkt de live configuratie met de verwachte configuratie en waarschuwt voor ongeautoriseerde wijzigingen; en de pull request-geschiedenis is het wijzigingsbeheerdocument dat auditors nodig hebben, zonder een apart papieren proces.