PKIaaS för plattformsteknikteam: Självbetjäningscertifikat med styrning

Självbetjäning för utfärdande av certifikat låter som att det borde vara enkelt: utvecklare begär certifikat, de får dem, PKI-teamet är inte involverat i varje transaktion. Det problem som hindrar de flesta organisationer från att implementera det är certifikatspridning: om utvecklare kan få certifikat fritt förlorar säkerhetsteamet insyn i vad som har utfärdats, namngivningskonventioner bryts ner, giltighetsperioder blir okontrollerade och certifikattillgångarna som automatisering skulle förenkla blir mer kaotiska än den manuella process den ersatte.

Svaret är inte att undvika självbetjäning. Det är att bygga självbetjäning ovanpå en styrningsmodell som gör spridning tekniskt omöjlig snarare än att bara avrådas från policyer. Certifikatprofiler som definierar vad som kan utfärdas. SAN-godkännandelistor som definierar giltig namngivning. RBAC som separerar vem som kan utfärda från vem som kan administrera. Arbetsflöden för registreringsgodkännande som gatar icke-automatiserade förfrågningar. Granskningsloggar som lyfter fram varje utfärdandehändelse oavsett vilken kanal som används. Utgångskontroller som förhindrar långvarig certifikatackumulering. Det här inlägget förklarar varje styrningslager och hur de fungerar tillsammans för att göra PKI as a Service -självbetjäning säker för tekniska beslutsfattare som inte kan acceptera ett spridningsproblem i utbyte mot utvecklarnas bekvämlighet.

Snabbt svar: Hur får man självbetjäning utan att det blir för mycket?

Självbetjäning utan spridning kräver fem styrningskontroller som arbetar tillsammans. Certifikatprofiler definierar det tekniska ramverket för vad som kan utfärdas, vilket upprätthålls av CA innan ett certifikat signeras. SAN-godkännandelistor begränsar vilka namn som kan visas i utfärdade certifikat. RBAC separerar de roller som definierar policy från de roller som utför utfärdandet. Registreringsarbetsflöden definierar godkännandevägen för varje certifikattyp, vilket automatiserar godkännande för lågriskförfrågningar och dirigerar högriskförfrågningar genom ett mänskligt granskningssteg. Granskningsloggar ger fullständig insyn i varje utfärdandehändelse i alla team och registreringskanaler. Med alla fem på plats är självbetjäning kontrollerad utfärdande, inte okontrollerad utfärdande.

Key Takeaways

• Certifikatprofiler är den primära styrningskontrollen i PKIaaS. En profil är en namngiven uppsättning begränsningar för vad certifikatutfärdaren kommer att utfärda: nyckelalgoritmer, minsta nyckelstorlekar, EKU OID:er, maximal giltighetsperiod och SAN-typer. Varje certifikatbegäran refererar till en profil. Varje utfärdat certifikat överensstämmer med den refererade profilens begränsningar. Det är tekniskt omöjligt att utfärda ett certifikat som bryter mot profilen, oavsett vilket registreringsgränssnitt begäranden använder.
• SAN-tillåtelselistor förhindrar namnspridning. En tillåtelselista anger vilka SAN-värden eller SAN-värdemönster som är tillåtna för certifikat som utfärdats till ett givet team eller namnrymd. En utvecklare kan inte begära ett certifikat för ett namn som inte matchar tillåtelselistan. Detta förhindrar oavsiktliga domänägarskapskonflikter mellan team, certifikatutfärdande som möjliggör nätfiske och brott mot namnkonventioner som granskare flaggar under granskningar av certifikattillgångar.
• Rollseparation är lika viktig som tekniska kontroller. En styrningsmodell där samma person definierar certifikatprofiler, utfärdar certifikat och granskar granskningsloggen har inga effektiva kontroller av beslut på policynivå. Att separera rollen som CA-administratör (som definierar policy) från rollen som certifikatadministratör (som utfärdar inom policy) från rollen som CA-revisor (som granskar utfärdandeposter) upprätthåller principen om minsta möjliga behörighet på administrativ nivå, inte bara på certifikatnivå.
• Alla certifikatförfrågningar bör inte automatiseras. Automatiserad registrering (ACME, SCEP, MDM autoenrollment, WSTEP) är lämplig för certifikattyper som överensstämmer med en väldefinierad, maskinverifierbar profil. Certifikatförfrågningar som involverar ovanliga giltighetsperioder, icke-standardiserade namn, EKU OID:er med hög behörighet (kodsignering, smartkortsinloggning) eller namn utanför standardgodkännandelistan bör dirigeras genom ett arbetsflöde för mänskligt godkännande. PKIaaS-registreringsarbetsflöden stöder båda sökvägarna från samma CA-backend.
• Policy-as-code är den mogna implementeringen av PKIaaS-styrning. Certifikatprofildefinitioner, SAN-tillåtelselistor, RBAC-rolltilldelningar och konfigurationer av registreringsarbetsflöden som underhålls som versionskontrollerad kod, distribueras genom en granskad ändringshanteringsprocess och granskas via commit-historik producerar en styrningsmodell som kan granskas av revisorer, granskas av juridiska rådgivare och reproduceras från källkodskontroll efter varje konfigurationsincident.

Hur certifikatutbredningen ser ut i praktiken

Certifikatspridning är inte en teoretisk risk. Det är vad som händer när certifikatutfärdande är bekvämt men ostyrt. Ett team behöver ett certifikat för en ny tjänst; den snabbaste vägen är ett självsignerat certifikat som är dedikerat till arkivet. Ett annat team är blockerat i PKI-förfrågningskön; de startar en intern CA på en utvecklingsserver, avaktiverar den aldrig formellt, och tre år senare vet ingen vilka tjänster som litar på den. En utvecklare testar en ACME-klient mot produktionsslutpunkten och utfärdar av misstag ett 1-årigt certifikat för en utvecklingsunderdomän som hamnar i certifikatdatabasen utan tillhörande ägare. Ett migreringsprojekt lämnar 200 certifikat på en äldre CA som aldrig avaktiveras eftersom ingen kan bekräfta om någon aktiv tjänst fortfarande är beroende av dessa certifikat.

Var och en av dessa scenarier ger samma resultat: certifikat i miljön som inget team äger, inga systemspår, inga CLM-plattformsövervakare och inga förnyelseprocesser. DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 % av företagen upplevde certifikatrelaterade driftstopp och 37.5 % spårade denna driftstopp till ett utgånget certifikat. De flesta av dessa utgångna certifikat glömdes inte bort av team som var slarviga; de glömdes bort av team som aldrig hade en reglerad process för att spåra dem från första början.

Självbetjänings-PKI löser fel hälft av problemet om den bara lägger till en bekväm utfärdandekanal utan att lägga till de styrningskontroller som skapar ett spårbart, policykompatibelt certifikatsystem. Rätt modell lägger till både ett självbetjäningsgränssnitt som utvecklare faktiskt kan använda, och styrningskontroller som gör det resulterande certifikatsystemet granskningsbart, kompatibelt och operativt hanterbart.

Styrningskontroll 1: Certifikatprofiler

En certifikatprofil är den tekniska tillämpningen av certifikatpolicyn på CA-lagret. Varje certifikatbegäran refererar till en profil. CA:n validerar begäran mot profilens begränsningar innan den signeras. En begäran som bryter mot någon begränsning avvisas av CA:n innan ett certifikat utfärdas, oavsett om begäranden autentiserades korrekt.

En väl utformad profil för en specifik certifikatkategori specificerar:

• Tillåtna nyckelalgoritmer och minsta nyckelstorlekar. Till exempel ECDSA P-256 eller P-384, eller minst RSA-2048. Förfrågningar med RSA-1024-nycklar eller otillåtna algoritmer avvisas.
• OID:er för utökad nyckelanvändning. En TLS-profil för tjänsten tillåter serverautentisering (OID 1.3.6.1.5.5.7.3.1) och valfritt klientautentisering (OID 1.3.6.1.5.5.7.3.2). En kodsigneringsprofil tillåter kodsignering (OID 1.3.6.1.5.7.3.3). En inloggningsprofil för smartkort tillåter inloggning för smartkort (OID 1.3.6.1.4.1.311.20.2.2) och klientautentisering. Begäranden om en profil med EKU OID:er som skulle ge funktioner med hög behörighet (som kodsignering) via en registreringsväg med låg behörighet är omöjliga att konstruera eftersom profilen bara tillåter den avsedda EKU-uppsättningen.
• Regler för ämnesfält. Huruvida den som begär det gemensamma namnet kan ange det gemensamma namnet, om fälten O och OU är ifyllda med CA från organisationsposten och vilket format CN måste ha (till exempel måste vara ett fullständigt kvalificerat domännamn, måste matcha ett specifikt mönster, måste fyllas i från ett LDAP-attribut).
• Tillåtna SAN-typer. Om profilen endast tillåter DNS SAN, eller även IP SAN, URI SAN (för arbetsbelastningsidentitet i SPIFFE-stil), UPN SAN (för inloggning med smartkort) eller RFC 822 e-post SAN (för S/MIME). En profil som endast tillåter DNS SAN kan inte användas för att utfärda ett certifikat med ett IP SAN, även om begäraren inkluderar ett i CSR:n.
• Maximal certifikatgiltighet. CA vägrar att utfärda ett certifikat med en giltighetsperiod som överstiger profilens maximala giltighetstid, även om begäran anger en längre period i registreringsbegäran. Detta förhindrar långvariga certifikatackumulering via självbetjäningskanalen.

För PKIaaS-distributioner för företag bör profiluppsättningen mappas till organisationens certifikatkategorier: en intern TLS-profil för tjänster, en mTLS-klientautentiseringsprofil, en användarprofil för smartkort, en S/MIME-profil, en kodsigneringsprofil och en CI/CD-pipelineidentitetsprofil. Varje profil definieras av rollen CA-administratör och kan inte ändras av rollen Certifikatadministratör eller registreringsautomatiseringslagret. Profiländringar går igenom samma ändringshanteringsprocess som alla säkerhetsrelevanta konfigurationsändringar.

Prenumerantcertifikatprofiler i en väl utformad PKIaaS-implementering skiljer sig från auktoritetscertifikatprofiler (som styr själva CA-certifikaten) och kan anpassas per distribution för att tillämpa organisationsspecifika begränsningar som går utöver standardvärdena på protokollnivå för varje registreringstyp.

Styrningskontroll 2: SAN-tillåtelselistor

Tillåtelselistor för alternativa namn för ämnen är en kontroll på CA-nivå som begränsar vilka namn som kan visas i certifikat som utfärdats under en given CA eller profil. Tillåtelselistan hanteras av CA-administratören, inte av certifikatbegäraren. En certifikatbegäran som anger ett SAN som inte matchar tillåtelselistan avvisas innan något certifikat signeras.

SAN-godkännandelistor tjänar flera styrningsfunktioner samtidigt. De tillämpar namngivningskonventioner: om organisationens namngivningspolicy säger att interna servicecertifikat måste använda namn i *.internal.example.com domän, SAN-tillåtelselistan för den interna tjänstens TLS-profil begränsar DNS-SAN till det mönstret. En begäran om ett certifikat med ett SAN av api.external-partner.com avvisas, även om begäran är autentiserad och profilen i övrigt är giltig.

De förhindrar namnkonflikter mellan lag: om lag A äger payments.internal.example.com namn och deras teams SAN-tillåtenhetslista är begränsad till *.payments.internal.example.comTeam B kan inte begära ett certifikat för ett namn i Team A:s namnrymd via självbetjäningskanalen, även om båda teamen är behöriga att använda samma certifikatprofil.

De tillhandahåller en spårbar registrering av godkända namn: SAN-godkännandelistan är ett uttryckligt register över vilka namn organisationen har beslutat att utfärda certifikat för. Tillägg till godkännandelistan går igenom CA-administratörens ändringshanteringsprocess, vilket skapar ett dokumenterat godkännandespår för namnauktorisering.

För Kubernetes-baserade distributioner kompletterar SAN-tillåtelselistning på PKIaaS CA-lagret cert-managers CertificateRequestPolicy på Kubernetes-lagret. Kubernetes-lagret tillämpar namngivningsbegränsningen på namnrymdsnivå innan CSR:n når CA:n; SAN-tillåtelselistan på CA-nivå är en djupgående försvarskontroll som skulle fånga upp alla förfrågningar som på något sätt kringgår Kubernetes policylagret.

Styrningskontroll 3: Rollbaserad åtkomstkontroll

Rollseparation i PKIaaS-styrning är den administrativa motsvarigheten till principen om arbetsuppdelning som tillämpas på certifikatoperationer. Rollerna måste utformas så att ingen enskild person kan både definiera vad certifikatutfärdaren ska utfärda och utfärda certifikat utanför dessa definitioner, och ingen enskild person kan utfärda certifikat och sedan förhindra att dessa utfärdanden visas i granskningsloggen.

En produktions-PKIaaS-distribution bör ha minst följande rollkategorier, som innehas av olika namngivna individer med olika rapporteringskedjor:

CA-ägare / CA-administratör. Skapar och konfigurerar CA-hierarkin, definierar och modifierar certifikatprofiler, hanterar SAN-godkännandelistor, konfigurerar registreringsflöden och hanterar rolltilldelningar för andra användare. Denna roll får inte tilldelas någon som rutinmässigt utfärdar certifikat för operativa arbetsbelastningar. I praktiken innehas denna roll av PKI-arkitekten eller säkerhetsingenjören som ansvarar för PKI-programmet.

Certifikatadministratör. Utfärdar, förnyar och återkallar certifikat inom de profiler och SAN-godkännandelistor som CA-administratören har konfigurerat. Kan inte ändra profiler, SAN-godkännandelistor eller CA-konfiguration. För automatiserad registrering (ACME, SCEP, MDM) innehas denna roll funktionellt av de tjänstkonton eller API-autentiseringsuppgifter som används av registreringsautomationen. För manuell utfärdande (eForm TLS-godkännandearbetsflöden) innehas denna roll av medlemmar i PKI-driftsteamet som granskar och godkänner certifikatförfrågningar.

CA-revisor. Skrivskyddad åtkomst till alla certifikatutfärdandeposter, händelseloggar för registreringsarbetsflöden och revisionsloggar. Kan inte utfärda eller återkalla certifikat. Kan inte ändra någon konfiguration. Revisorrollen innehas av säkerhetsteamet, efterlevnadsteamet eller externa revisorer som behöver insyn i certifikataktivitet utan operativ åtkomst. Den viktigaste styrningsegenskapen för denna roll är oberoende: revisorn kan se allt som har utfärdats och kan inte blockeras från att se det av någon med operativ åtkomst.

Administratör för registreringsarbetsflöde. Konfigurerar de automatiserade registreringsarbetsflödena (skapande av ACME-slutpunkter, konfiguration av SCEP-profiler, installation av MDM-arbetsflöden, konfiguration av WSTEP-agenter) men har inte direkt behörighet för certifikatutfärdande. Denna roll innehas av plattformsteknikteamet som kopplar registreringsautomation till IDP:n. Att separera administrationen av registreringsarbetsflöden från CA-administration innebär att teamet som bygger automatiseringsintegrationen inte kan ändra profilerna eller tillåtelselistorna som styr vad automatiseringen kan begära.

Granskare av registreringsarbetsflöde. Skrivskyddad åtkomst till händelser i registreringsarbetsflödet och deras tillhörande utfärdandeloggar. Används av team som behöver insyn i registreringsautomationens beteende utan bredare åtkomst till CA-konfigurationen.

Rolltilldelningar bör hanteras via organisationens identitetsleverantör (Azure AD, Okta eller motsvarande), inte via lokala PKIaaS-användarkonton där det är möjligt. IdP-hanterade rolltilldelningar skapar en revisionslogg för rolltilldelningar i IdP:ns åtkomstlogg, styrs av organisationens process för att ansluta/flytta/lämna och är synliga för IAM-teamet tillsammans med alla andra åtkomsttilldelningar.

Styrningskontroll 4: Registreringsarbetsflöden och godkännandeportar

Registreringsarbetsflöden är det beslutslager som avgör hur en certifikatförfrågan behandlas: automatiskt godkänns och utfärdas, dirigeras till en mänsklig godkännare eller avvisas direkt. Utformningen av registreringsarbetsflödet för varje certifikattyp är ett av de viktigaste styrningsbesluten i en PKIaaS-distribution eftersom det avgör vilka förfrågningar som kringgår mänsklig granskning och vilka som är föremål för den.

För de flesta certifikattyper i en välkonfigurerad PKIaaS-distribution är arbetsflödet automatiserat: registreringsbegäran anländer (via ACME, SCEP, MDM eller WSTEP), CA validerar den mot profilen och SAN-godkännandelistan, och om den godkänns utfärdas certifikatet utan mänsklig granskning. Detta är rätt modell för TLS-tjänstcertifikat, mTLS-klientcertifikat, MDM-registrerade enhetscertifikat och Kubernetes-arbetsbelastningscertifikat. Profil- och godkännandelistbegränsningarna gör varje automatiserad utfärdande till en styrd utfärdande; mänsklig granskning av enskilda begäranden tillför inget ytterligare säkerhetsvärde när policyn redan tillämpas tekniskt.

Vissa certifikattyper bör gå igenom ett manuellt godkännandearbetsflöde. Ett webbformulärbaserat registreringsarbetsflöde (ibland kallat ett eForm-arbetsflöde i PKIaaS-implementeringar) presenterar begäran för en certifikatadministratör som granskar den innan den utfärdas. Granskaren kan inspektera det begärda ämnet, SAN:erna, den refererade profilen och den begärande partens identitet. De godkänner begäran om den är lämplig, avvisar den med en förklaring om den inte är det, eller eskalerar den till CA-administratören om den kräver ett policyundantag. Denna godkännandeväg är lämplig för: certifikat med förlängda giltighetsperioder utöver standardprofilens maximala giltighetstid; certifikat för namn som inte finns i SAN-godkännandelistan men som kan motivera ett policyundantag; kodsigneringscertifikat och inloggningscertifikat för smartkort, som har förhöjd behörighet och motiverar mänsklig granskning även när de tekniska parametrarna finns inom profilen; och certifikatförfrågningar från externa parter eller entreprenörer som inte har konfigurerad automatisk registrering.

Arkitekturen för registreringsarbetsflödet bör göra godkännandevägen tydlig och granskningsbar: varje begäran som går igenom det manuella godkännandeflödet bör ha ett loggat beslut (godkänd/avvisad/eskalerad), granskarens identitet och tidsstämpeln för beslutet. Detta skapar en mänsklig beslutslogg för icke-standardiserade certifikatförfrågningar som kompletterar den automatiserade utfärdandegranskningsloggen för standardförfrågningar.

Styrningskontroll 5: Revisionsloggar och kontinuerlig synlighet

Det är granskningsloggen som gör ett självbetjänande PKI-program granskningsbart snarare än bara bekvämt. Varje certifikatutfärdandehändelse, oavsett registreringskanal, måste registreras med: den utfärdande certifikatutfärdaren, den certifikatprofil som används, ämnet och SAN:erna för det utfärdade certifikatet, den begärande identiteten (ACME-klienttjänstkontot, MDM-registreringsuppgifterna, eForm-begäraren eller den API-uppgifter som används), tidsstämpeln och godkännandebeslutet om begäran gick igenom ett manuellt arbetsflöde.

En granskningslogg som endast täcker manuellt utfärdade certifikat och inte automatiserade ACME- eller MDM-utfärdanden är inte en granskningslogg; det är en ofullständig post. PKIaaS-distributioner bör granska alla registreringskanaler enhetligt. CA-revisorns roll bör ha åtkomst till den fullständiga utfärdandeposten över alla kanaler, inte bara posterna från de kanaler som revisorn redan känner till.

För att säkerställa efterlevnad måste revisionsloggen vara manipulationssäker och bevaras under relevant period. Många regelverk för efterlevnad specificerar krav på bevarande av revisionsloggar: SOC 2 kräver vanligtvis ett år; vissa reglerade branschramverk kräver längre tid. PKIaaS-revisionsloggen bör regelbundet exporteras till ett SIEM- eller säkert loggarkiv, så att loggen bevaras oberoende av PKIaaS-plattformen och överlever en PKIaaS-konfigurationsincident som skriver över eller korrumperar den aktuella revisionsloggen.

Utöver efterlevnad är granskningsloggen det operativa verktyget för certifikatstyrning: CLM-plattformen som är ansluten till PKIaaS CA kan varna för ovanliga utfärdandemönster (en ökning av certifikatförfrågningar från ett specifikt team, förfrågningar om namn utanför det förväntade mönstret, upprepade avslagshändelser som kan indikera att någon undersöker registrerings-API:et), och granskaren kan undersöka specifika utfärdandehändelser när en säkerhetsincident kräver spårning av vilket certifikat som användes i en specifik autentiseringshändelse.

Styrningskontroll 6: Utgångspolicy och livscykeltillämpning

Långlivade certifikat är den vanligaste orsaken till att certifikatspridning ackumuleras. Ett certifikat som utfärdats med en giltighetsperiod på 5 år och utan automatisk förnyelse kommer att finnas i miljön i 5 år. Efter de första 6 månaderna är det troligt att personen som begärde det har bytt roll eller lämnat organisationen, systemet det provisionerades för har uppdaterats eller ersatts, och teamet som äger det kommer inte ihåg att det existerar. Vid år 3 är certifikatet föräldralöst: ingen övervakar det, ingen förnyelse är planerad, och när det löper ut kommer det system som fortfarande använder det att sluta fungera utan förvarning.

Utgångspolicy som tillämpas på CA-profilnivå förhindrar denna ackumulering. En profil med en maximal giltighetsperiod på 90 dagar kan inte användas för att utfärda ett 2-årigt certifikat, oavsett vad begäraren anger. Profilens maximala giltighetstid är taket; begäraren kan begära en kortare giltighetstid men inte en längre. Genom att kombinera detta med automatisk förnyelse (cert-manager för Kubernetes-arbetsbelastningar, ACME-förnyelse för Linux-tjänster, MDM-utlöst förnyelse för enheter) innebär det att certifikat med korta giltighetsperioder och automatisk förnyelse är operativt hållbara: förnyelsen sker automatiskt innan certifikatet löper ut, och CLM-plattformen varnar om en förväntad förnyelse inte sker.

För certifikattyper som inte har automatisk förnyelse (manuellt utfärdade certifikat för äldre system eller externa partners) bör en CLM-plattform som är ansluten till PKIaaS CA meddela ägare med definierade intervall före utgångsdatum (90 dagar, 60 dagar, 30 dagar). Aviseringen bör skickas till den namngivna certifikatägaren, inte till en generisk PKI-teampostlåda som kanske inte vet vilket specifikt system certifikatet betjänar. Certifikatägande bör registreras vid utfärdandetillfället, antingen i PKIaaS-metadatafälten eller i CLM-plattformens inventering, så att utgångsaviseringar når rätt team.

Massåterkallelse är en nödåtgärd för att förhindra att certifikatet löper ut: när en certifikattyp som utfärdats av en specifik certifikatutfärdare eller en specifik profil behöver återkallas i hela certifikatparken (på grund av en kompromiss mellan certifikatutfärdarna, en utfasning av nyckelalgoritmer eller en felaktig profilkonfiguration), tillåter PKIaaS massåterkallningsfunktioner att alla matchande certifikat återkallas i en enda operation. De resulterande CRL- och OCSP-uppdateringarna sprids till alla förlitande parter inom det normala CRL-giltighetsfönstret, och CLM-plattformen visar återkallningshändelserna som en massåtgärd i granskningsloggen.

Policy-som-kod: Implementering av mogen styrning

De flesta PKIaaS-implementeringar börjar med styrningskontroller som konfigureras via hanteringskonsolen: en säkerhetsingenjör loggar in, skapar en certifikatprofil, ställer in SAN-godkännandelistan, tilldelar roller och sparar. Detta är fungerande men producerar en styrningsmodell som bara finns i PKIaaS-plattformens konfigurationsdatabas, inte i någon versionskontrollerad, granskningsbar, reproducerbar form. Om konfigurationen ändras (korrekt eller felaktigt) sparas inte den tidigare konfigurationen för granskning. Om en granskare frågar vilka profilbegränsningar som gällde ett specifikt datum kanske svaret inte är tillgängligt.

Policy-as-code mognar denna modell genom att hantera PKIaaS-konfigurationen genom samma infrastruktur-as-code-metoder som tillämpas på resten av plattformen: profildefinitioner, SAN-tillåtelselistor, rolltilldelningar och konfigurationer av registreringsarbetsflöden lagras som YAML eller JSON i ett versionskontrollerat arkiv, ändringar föreslås som pull requests som går igenom peer review innan de slås samman, och en CI/CD-pipeline distribuerar godkända ändringar till PKIaaS CA via REST API.

Denna metod ger flera styrningsfördelar samtidigt. Varje konfigurationsändring har en dokumenterad granskningslogg (pull request, granskarens godkännanden, tidsstämpeln för sammanslagningen). Varje tidigare konfigurationstillstånd kan hämtas från versionshistoriken (om en revisor frågar vilka profilbegränsningarna var under tredje kvartalet förra året visar arkivet profilkonfigurationen som den var vid varje tidpunkt). Konfigurationsavvikelser är detekterbara: den nuvarande PKIaaS-konfigurationen kan jämföras med arkivets förväntade konfiguration som en del av en kontinuerlig efterlevnadskontroll, och eventuella avvikelser (en profil som ändras utanför IaC-processen) visas som en varning.

För Kubernetes-distributioner är cert-managers CertificateRequestPolicy-resurser redan Kubernetes-manifest i GitOps-arkivet, så policy-as-code-mönstret gäller naturligt. För själva PKIaaS CA-konfigurationen tillhandahåller PKIaaS REST API det programmatiska gränssnitt som IaC-verktyg använder för att distribuera och uppdatera profiler, tillåtelselistor och arbetsflödeskonfigurationer från arkivet.

Flerhyresgäststyrning för plattformsteam

Plattformsteknikteam som betjänar flera interna kunder (applikationsutvecklingsteam, datateknikteam, säkerhetsdriftsteam, infrastrukturteam) står inför en ytterligare styrningsutmaning: olika team har olika certifikatkrav, olika riskprofiler och potentiellt olika efterlevnadsskyldigheter, men de delar alla samma PKIaaS CA-infrastruktur.

PKIaaS-partitionsbaserad multitenancy åtgärdar detta: varje hyresgästteam arbetar inom en PKIaaS-partition som har sin egen certifikatprofiluppsättning, sin egen SAN-tillåtelselista, sina egna rolltilldelningar och sin egen granskningslogg. CA-administratören för den övergripande plattformen kan se alla partitioner; certifikatadministratören för ett specifikt team kan bara se och utfärda certifikat inom det teamets partition. Detta skapar isolering av styrning per team utan att kräva separat CA-infrastruktur för varje team.

Plattformsteamets styrningsansvar i en PKIaaS-distribution med flera hyresgäster är att utforma partitionsstrukturen, definiera standardprofiluppsättningen som gäller för alla hyresgäster och skapa processen för hyresgästspecifika profilanpassningsförfrågningar (som går igenom CA-administratörens ändringshanteringsprocess). Enskilda hyresgästteam ansvarar för hanteringen av sin SAN-tillåtelselista (inom de begränsningar som plattformsteamet anger) och sina rolltilldelningar som certifikatadministratör (inom sin partition).

Denna styrningsmodell skalar till stora företagsdistributioner utan att skapa en flaskhals för PKI-teamet: varje klientteam har operativ autonomi inom sin partition, medan plattformsteamet upprätthåller policystyrning på CA- och profilnivå. CA-revisorns roll omfattar alla partitioner, vilket ger säkerhetsteamet fullständig insyn i organisationens certifikattillgångar oavsett vilken partition som utfärdat ett specifikt certifikat.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande förser den styrda CA-infrastrukturen med den fullständiga uppsättningen styrningskontroller som beskrivs i det här inlägget: certifikatprofiler med konfigurerbara begränsningar (nyckelalgoritmer, EKU OID:er, maximal giltighet, SAN-typer), SAN-godkännandelistning, rollbaserad åtkomstkontroll med rollseparation för ägare/CA-administratör/certifikatadministratör/CA-revisor/administratör för registreringsarbetsflöde/revisor för registreringsarbetsflöde, arbetsflöden för registreringsgodkännande för manuella utfärdandevägar och revisionsloggning per registreringskanal. Kontakta oss på Krypteringskonsulting för att diskutera era PKIaaS-styrningskrav.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare tillhandahåller det CLM-synlighetslager som styrningsmodellen kräver: enhetlig certifikatinventering över alla registreringskanaler och CA-partitioner, övervakning av utgångsdatum med aviseringar om namngiven ägare, rapportering om policyefterlevnad (visar certifikat som bryter mot de nuvarande profilbegränsningarna, indikerar profilkonfigurationsavvikelser eller äldre certifikat från innan styrningskontroller implementerades) och SIEM-integration för export av granskningsloggar och aviseringar om avvikande utfärdandemönster.
• PKI-bedömningstjänst: För organisationer som utformar en PKIaaS-styrningsmodell från grunden, eller utvärderar ett befintligt självbetjänande PKI-program för att upptäcka luckor i styrningen, kan Encryption Consultings PKI-bedömningstjänst utvärderar den nuvarande certifikatprofilens design, rolltilldelningsmodellen, konfigurationen av registreringsarbetsflödet och täckningen av granskningsloggen mot det styrningsramverk som beskrivs i det här inlägget, och tar fram en gapanalys och implementeringsplan.
• PKI-tjänster (CP/CPS-utveckling): Styrningskontrollerna i en PKIaaS-distribution måste dokumenteras i en certifikatpolicy och certifieringspraxis som revisorer, tillsynsmyndigheter och förlitande parter kan granska. Krypteringskonsultföretagets PKI-tjänster inkluderar CP/CPS-utveckling som dokumenterar profilbegränsningar, rollmodell, design av registreringsarbetsflöden och granskningsloggrutiner i det format som krävs av SOC 2, WebTrust, FedRAMP och andra efterlevnadsramverk.
• Rådgivningstjänster för efterlevnad: För organisationer som omfattas av efterlevnadskrav för DORA, NIS2, HIPAA, FedRAMP eller CMMC måste PKIaaS-styrningsmodellen uppfylla specifika krav kring dokumentation av certifikatpolicyer, lagring av granskningsloggar, bevis för rollseparation och ändringshantering för CA-konfiguration. Encryption Consulting's Rådgivning om efterlevnad kartlägga PKIaaS-styrningsdesignen mot varje tillämpligt regelverk för efterlevnad och ta fram det bevispaket som visar efterlevnad av styrningen för revisorer och tillsynsmyndigheter.

Slutsats

Självbetjäningscertifikatutgivning är möjlig utan certifikatspridning. De fem styrningskontroller som beskrivs i det här inlägget – certifikatprofiler, SAN-tillåtelselistor, RBAC-rollseparation, arbetsflöden för registreringsgodkännande och granskningsloggar – gör, när de implementeras tillsammans, självbetjäningskanalen till en styrd utfärdandekanal snarare än en okontrollerad. Certifikatspridning är ett styrningsmisslyckande, inte en konsekvens av självbetjäning. Organisationer som implementerar självbetjäning utan styrning får spridning. Organisationer som implementerar styrning tillsammans med självbetjäning får både bekvämlighet för utvecklare och en granskningsbar, policykompatibel certifikattillgång.

Mognadsprogressionen för PKIaaS-styrning sker vanligtvis genom: först profiler och tillåtelselistor (de tekniska kontrollerna som tillämpar policyramen), sedan rollseparation (de administrativa kontrollerna som förhindrar kringgående av policyer), sedan design av arbetsflöden för registrering (godkännandekontrollerna som hanterar icke-standardiserade förfrågningar), sedan policy-som-kod (ändringshanteringskontrollerna som gör policyn granskningsbar och granskbar via commit-historik) och slutligen design av partitioner för flera hyresgäster (de strukturella kontroller som skalar styrning över flera team utan centraliserade flaskhalsar). Organisationer styrs vid varje punkt i denna progression väsentligt bättre än organisationer utan några kontroller alls; mognadsprogressionen är en väg att följa, inte en förutsättning att uppnå innan man distribuerar självbetjäning.

Om din organisation utvärderar PKIaaS-styrningsdesign eller granskar kontrollerna i ett befintligt självbetjäningsprogram för certifikat, kontakta Encryption Consulting.

Det här inlägget granskas var sex månader och när CA/B Forum Baseline Requirements, SOC 2 Trust Service Criteria eller större efterlevnadsramverk publicerar uppdateringar som påverkar dokumentation av certifikatpolicyer eller krav på granskningsloggar.

Vanliga frågor om partihandel med mat och dryck

Vad är certifikatspridning och hur orsakar självbetjänings-PKI det?

Certifikatspridning är en ansamling av certifikat som inget team äger, inga systemspår och inga processer förnyas. Självbetjänings-PKI orsakar detta när det tillhandahåller en bekväm utfärdandekanal utan styrningskontroller: inga profilbegränsningar som definierar vad som kan utfärdas, inga SAN-godkännandelistor som definierar giltiga namn, ingen revisionslogg som visar vad som har utfärdats och ingen CLM-lagerövervakning av utgångsdatum. Lösningen är inte att eliminera självbetjäning utan att lägga till styrningskontroller som gör varje självbetjäningsutfärdande till en styrd utfärdande.

Vad är en certifikatprofil i PKIaaS och hur upprätthåller den policyn?

En certifikatprofil är en namngiven konfiguration som definierar de tillåtna parametrarna för en certifikatkategori: nyckelalgoritmer, minsta nyckelstorlekar, OID:er för utökad nyckelanvändning, SAN-typer, ämnesfältregler och maximal giltighetsperiod. Varje certifikatbegäran refererar till en profil. CA validerar varje begäran mot profilens begränsningar innan den signeras. En begäran som bryter mot någon begränsning avvisas av CA innan ett certifikat utfärdas, oavsett registreringskanal eller begärarens autentiseringsstatus.

Vilka RBAC-roller bör finnas i en PKIaaS-styrningsmodell?

Som minimum: CA-ägare/administratör (skapar profiler, hanterar SAN-godkännandelistor, konfigurerar arbetsflöden, kan inte rutinmässigt utfärda certifikat), Certifikatadministratör (problem inom konfigurerade profiler, kan inte ändra profiler), CA-revisor (skrivskyddad åtkomst till alla utfärdandeposter, kan inte utfärda eller konfigurera) och Administratör för registreringsarbetsflöde (konfigurerar automatiserad registrering, kan inte ändra profiler eller SAN-godkännandelistor). Genom att separera dessa roller säkerställs att ingen enskild person kan både definiera policy och problem utanför den, och ingen operativ användare kan undertrycka sin egen revisionslogg.

Vad är en SAN-tillåtenhetslista i PKIaaS och varför är det en styrningskontroll?

En SAN-godkännandelista anger vilka värden eller mönster för alternativa ämnesnamn som certifikatutfärdaren accepterar för en given profil eller certifikatutfärdare. Förfrågningar med SAN:er som inte matchar godkännandelistan avvisas innan ett certifikat signeras. Detta förhindrar brott mot namngivningskonventioner, konflikter om domänägarskap mellan team och utfärdande för namn som organisationen inte uttryckligen har godkänt. Ändringar av godkännandelistan går igenom certifikatutfärdaradministratörens ändringshanteringsprocess, vilket skapar ett dokumenterat godkännandespår för namnauktorisering.

Hur fungerar policy-som-kod för certifikatstyrning?

Policy-as-code lagrar certifikatprofildefinitioner, SAN-tillåtelselistor, RBAC-rolltilldelningar och konfigurationer av registreringsarbetsflöden som versionskontrollerade filer i ett arkiv. Ändringar föreslås som pull-requests med peer review, och en CI/CD-pipeline distribuerar godkända ändringar till PKIaaS CA via REST API. Detta genererar en granskningsbar ändringslogg (historik för pull-requests), hämtningsbar historisk konfiguration (versionshistorik för alla tidigare datum) och avvikelsedetektering (nuvarande CA-konfiguration jämfört med arkivets förväntade status som en kontinuerlig efterlevnadskontroll).