Privat PKI för maskin-till-maskin-identitet i hybridmiljöer

Varje tjänst-till-tjänst-anrop i en modern företagsinfrastruktur är ett potentiellt identitetsproblem. När en betalningstjänst anropar ett orderhanterings-API, när en Kubernetes-pod begär data från en intern databas, när en edge-enhet skickar telemetri till en molnaggregeringstjänst, har det mottagande systemet inget inbyggt sätt att verifiera att den som ringer är den den utger sig för att vara, såvida inte den som ringer kan bevisa sin identitet med en autentiseringsuppgift som mottagaren litar på. I de flesta företagsmiljöer saknas denna identitetsverifiering antingen (intern nätverksplats behandlas som implicit förtroende) eller implementeras med delade hemligheter (API-nycklar och tjänstkontotokens som kan stjälas, roteras inkonsekvent och är svåra att återkalla direkt i stor skala).

Privat PKI löser problemet med maskinidentitet på samma sätt som det löser problemet med användaridentitet: varje maskinenhet får ett certifikat från en betrodd CA, presenterar det certifikatet när anslutningar initieras och valideras eller avvisas baserat på om certifikatet är giltigt, inte återkallat och utfärdat av en betrodd myndighet. PKI som en tjänst gör detta möjligt i hybridföretagsskala: en enda styrd CA-hierarki utfärdar certifikat för tjänster som körs lokalt, i molnmiljöer, i Kubernetes-kluster och på edge-enheter, med konsekvent policy, automatiserad registrering och synlighet på CLM-nivå över hela maskincertifikattillgången.

Snabbt svar: Hur möjliggör privat PKI maskin-till-maskin-identitet?

Privat PKI möjliggör M2M-identitet genom att utfärda ett certifikat till varje maskinenhet som behöver autentisera: tjänster, poddar, virtuella maskiner, containrar, API:er, nätverksapparater och edge-enheter. När en maskin initierar en anslutning till en annan presenterar den sitt certifikat; den mottagande maskinen validerar certifikatkedjan mot den betrodda privata certifikatutfärdaren och bestämmer sig för om anslutningen ska accepteras. Detta är ömsesidig TLS (mTLS), och det tillhandahåller kryptografisk identitetsverifiering för varje tjänst-till-tjänst-anrop utan delade hemligheter, utan en central autentiseringsslutpunkt som alla samtal måste dirigeras igenom, och med återkallelse som träder i kraft inom sekunder efter att en kompromiss har upptäckts.

Key Takeaways

• Spridning av maskinidentiteter är den primära risken i hybridinfrastruktur. Interna certifikat ackumuleras mellan team, molnkonton, Kubernetes-kluster och edge-miljöer utan central inventering eller policytillämpning. En privat PKIaaS CA med CLM-integration ger det synlighetslager som gör maskincertifikattillgångarna styrbara: varje utfärdat certifikat loggas, varje utgångsdatum övervakas och varje återkallelse registreras.
• mTLS (ömsesidig TLS) är den korrekta autentiseringsmekanismen för kommunikation mellan tjänster eftersom den autentiserar både servern och klienten på TLS-lagret, innan någon begäran på applikationsnivå behandlas. En tjänst utan ett giltigt certifikat från den betrodda certifikatutfärdaren kan inte upprätta en mTLS-anslutning till en skyddad tjänst, oavsett om den har nätverksåtkomst till den tjänstens slutpunkt.
• SPIFFE (Secure Production Identity Framework for Everyone) är den öppna standarden för arbetsbelastningsidentitet i molnbaserade miljöer. SPIFFE SVID:er är X.509-certifikat med URI SAN:er som kodar arbetsbelastningens SPIFFE-ID. PKIaaS kan fungera som uppströms CA-auktoritet för SPIRE-baserade SPIFFE-distributioner och förankra tillfälliga arbetsbelastningscertifikat i organisationens styrda CA-förtroendehierarki.
• cert-manager är den Kubernetes-nativa certifikatprovisioneringskontrollanten som ansluter Kubernetes-arbetsbelastningar till PKIaaS CA. Plattformsteamet konfigurerar en cert-manager ClusterIssuer som pekar mot PKIaaS ACME- eller CA Gateway-slutpunkten; tjänster deklarerar certifikatresurser i sina manifest; cert-manager hanterar utfärdande, leverans till Kubernetes Secrets och automatisk förnyelse utan mänsklig interaktion.
• PKIaaS stöder flera registreringsprotokoll för olika maskinmiljöer: ACME för molnbaserade och Linux-baserade tjänster, EST för företagsservrar och nätverksapparater, CMP för inbäddade enheter och edge-enheter, och SCEP för nätverksenheter och MDM-registrerade maskiner. Ett enda PKIaaS CA-hanteringsplan styr all certifikatutfärdande oavsett vilket registreringsprotokoll maskinen använder.

Varför delade hemligheter misslyckas för maskinidentitet i stor skala

Standardmetoden för maskinidentitet i de flesta företagsmiljöer är delade hemligheter: API-nycklar tilldelade till tjänstkonton, långlivade tokens lagrade i miljövariabler eller konfigurationsfiler, databaslösenord inbäddade i anslutningssträngar och tjänstkontouppgifter som roterar långsamt eller inte alls. Dessa metoder har förvärrande problem i takt med att maskintillgången växer:

• Ingen kryptografisk bindning till maskinen: En API-nyckel eller tjänstkontotoken är en bäraruppgift: vem som helst som innehar den kan använda den, från vilken maskin som helst, på vilket nätverk som helst. Det finns inget kryptografiskt bevis på att anroparen som använder uppgiften är den specifika maskin eller tjänst den påstår sig vara. En läckt API-nyckel från en komprometterad miljöfil ger angriparen samma åtkomst som den legitima tjänsten;
• Rotationskomplexitet i skala: Att rotera en delad hemlighet kräver att den uppdateras på varje plats där den är konfigurerad: varje miljövariabel, varje Kubernetes-hemlighet, varje CI/CD-pipelinekonfiguration, varje infrastruktur-som-kod-modul som refererar till den. I stor skala blir rotationshändelser operativa incidenter som hoppas över eller utförs ofullständigt, vilket lämnar långlivade autentiseringsuppgifter i produktion på obestämd tid;
• Ingen omedelbar återkallningsväg: När en maskin komprometteras kräver återkallelse av åtkomst att man känner till alla autentiseringsuppgifter som maskinen innehöll och ogiltigförklarar var och en vid varje tjänst som accepterade dem. Med PKI-certifikat återkallar återkallelse av certifikatet åtkomst till varje tjänst som validerar mot PKIaaS CA:s OCSP-responder i en enda operation;
• Inget enhetligt lager: Delade hemligheter ackumuleras i olika autentiseringsuppgifter, konfigurationshanteringssystem och molnhemlighetshanterare utan en enhetlig vy över vilken tjänst som har vilken autentiseringsuppgift och när den senast roterades. Maskincertifikatinventering i en CLM-plattform ansluten till PKIaaS CA ger en enhetlig vy över varje certifikat i alla maskinmiljöer.

Ömsesidig TLS: Autentiseringslagret för M2M-kommunikation

Ömsesidig TLS (mTLS) utökar standard TLS genom att kräva att både servern och klienten presenterar certifikat under TLS-handskakningen. I ett service mesh eller en intern API-arkitektur som använder mTLS:

• Tjänst A initierar en anslutning till tjänst B:s HTTPS-slutpunkt;
• Tjänst B presenterar sitt servercertifikat; Tjänst A validerar det mot den betrodda CA-kedjan;
• Tjänst B begär ett klientcertifikat från Tjänst A; Tjänst A presenterar sitt klientcertifikat;
• Tjänst B validerar Tjänst A:s certifikat mot den betrodda CA-kedjan och kontrollerar återkallelse via OCSP;
• Om båda certifikaten är giltiga upprättas mTLS-sessionen och applikationsdata flödar;
• Om något av certifikaten är ogiltigt eller återkallat misslyckas TLS-handskakningen och inga programdata utbyts.

Den kritiska egenskapen hos mTLS för maskinidentitet är att autentisering sker före någon bearbetning på applikationsnivå. En komprometterad intern maskin som försöker anropa en skyddad tjänst kan inte skapa ett giltigt certifikat från organisationens privata certifikatutfärdare. En angripare på nätverksnivå i det interna nätverket som avlyssnar trafik kan inte injicera begäranden i ett mTLS-skyddat tjänsteanrop eftersom de inte kan producera ett giltigt klientcertifikat. Den privata certifikatutfärdarens förtroendehierarki definierar gränsen för vad som är betrott; alla maskiner som inte har utfärdat ett certifikat av den certifikatutfärdaren befinner sig utanför förtroendegränsen oavsett dess nätverksplats.

För PKIaaS CA använder mTLS-maskincertifikat TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) och, för tjänster som även accepterar inkommande anslutningar, TLS Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). Certifikatets Subject CN eller URI SAN identifierar tjänsten enligt organisationens namngivningskonvention (vanligtvis tjänstens DNS-namn, SPIFFE ID eller Kubernetes-tjänstens FQDN). Certifikatgiltigheten för maskin-mTLS-certifikat är vanligtvis kort: 24 timmar till 90 dagar, med automatisk förnyelse som hanteras av tjänstens certifikathanteringsagent före utgångsdatum.

SPIFFE-arbetsbelastningsidentitet och PKIaaS

SPIFFE (Secure Production Identity Framework for Everyone) är en öppen standard som underhålls av Cloud Native Computing Foundation (CNCF) och som definierar ett enhetligt identitetsramverk för arbetsbelastningar över heterogen infrastruktur. SPIFFE definierar:

• SPIFFE-ID:t: En URI-formatidentitet i formuläret spiffe://trust-domain/path/to/workload, där trust-domain motsvarar organisationens administrativa domän och sökvägen identifierar den specifika arbetsbelastningen. Till exempel, spiffe://example.com/env/production/service/payment-api identifierar betalnings-API-tjänsten i produktionsmiljön;
• SVID (SPIFFE-verifierbart identitetsdokument): Ett X.509-certifikat med SPIFFE-ID kodat som ett URI SAN. SVID är vilka arbetsbelastningar som finns i mTLS-anslutningar; den mottagande tjänsten validerar SVID:s SPIFFE-ID mot sin auktoriseringspolicy för att avgöra om den anropande arbetsbelastningen har tillstånd att göra begäran;
• Arbetsbelastnings-API:et: Ett lokalt Unix-domänsocket-API genom vilket arbetsbelastningar hämtar sina SVID:er utan att behöva hantera certifikatlagring själva. SPIFFE-körningen (SPIRE) levererar nya SVID:er till arbetsbelastningar innan deras nuvarande SVID:er löper ut, vilket hanterar certifikatrotation transparent.

SPIRE är referensimplementeringen av SPIFFE-standarden. I en PKIaaS-integration konfigureras SPIRE med ett uppströms CA-plugin som begär mellanliggande CA-certifikat från PKIaaS CA. SPIRE använder dessa mellanliggande CA-certifikat för att signera SVID:er för de arbetsbelastningar den hanterar. SVID:erna är kedjade till organisationens PKIaaS-rot-CA, vilket tillhandahåller ett enda enhetligt förtroendeankare för SPIFFE-identifierade arbetsbelastningar tillsammans med icke-SPIFFE-maskincertifikat som utfärdats direkt av PKIaaS CA. CLM-plattformen som är ansluten till PKIaaS kan inventera de mellanliggande CA-certifikat som utfärdats till SPIRE, även om de individuella kortlivade SVID:erna som utfärdats av SPIRE från dessa mellanliggande CA:er är för kortlivade för att traditionell CLM-inventering ska kunna spåras direkt.

Maskinidentitet i Kubernetes med cert-manager och PKIaaS

Kubernetes är den vanligaste miljön för maskin-till-maskin-kommunikation i molnbaserade hybridarkitekturer. Tjänster i ett Kubernetes-kluster kommunicerar via klustrets DNS- och tjänstelager; när mTLS tillämpas behöver varje tjänst ett certifikat som identifierar den för de andra tjänsterna den kommunicerar med.

cert-manager för tillhandahållande av tjänstecertifikat

cert-manager tillhandahåller maskinidentitetscertifikat för Kubernetes-tjänster genom att ansluta klustret till PKIaaS CA. Plattformsteamet konfigurerar en ClusterIssuer (eller namnrymdsbaserade Issuers för kluster med flera hyresgäster) som pekar mot PKIaaS ACME-slutpunkten eller CA Gateway API. Tjänster deklarerar certifikatresurser och anger önskat ämne, SAN:er (DNS SAN:er för tjänstens Kubernetes-tjänstens FQDN och eventuellt ett URI SAN med tjänstens SPIFFE-ID), giltighetsperiod och förnyelsetröskelvärde. cert-manager skickar certifikatbegäran till PKIaaS CA, lagrar det utfärdade certifikatet som en Kubernetes-hemlighet och monterar det i tjänstens poddar via en volymmontering eller projicerad hemlighet. Tjänsten läser sitt certifikat och sin privata nyckel från den monterade sökvägen och presenterar dem i mTLS-anslutningar till andra tjänster.

cert-managers automatiska förnyelse innebär att maskincertifikat i Kubernetes alltid är nya. Om PKIaaS CA:s certifikatprofil uppdateras (till exempel för att tillämpa en kortare giltighetsperiod som en del av en säkerhetsförbättring) producerar nästa förnyelsebegäran under den uppdaterade profilen ett certifikat med de nya parametrarna. Tjänsten behöver inte distribueras om; cert-manager utlöser förnyelsen och uppdaterar Kubernetes-hemligheten, och tjänsten hämtar det nya certifikatet vid nästa filsystemsynkronisering.

Integrering av servicenätcertifikat

Tjänstenät (Istio, Linkerd och andra) tillhandahåller automatisk mTLS mellan alla tjänster i ett nät utan att enskilda tjänster själva behöver implementera TLS. Tjänstenätets dataplan (Envoy proxy sidecars i fallet med Istio) hanterar mTLS-handskakningen för applikationens räkning; applikationen kommunicerar med sin sidecar via en lokal klartextanslutning och sidecaren hanterar alla mTLS-anslutningar till andra tjänster.

Som standard använder service meshes en intern, självsignerad CA för att utfärda certifikat till dataplansproxyer. Denna interna CA är inte integrerad med organisationens PKIaaS CA-hierarki, vilket innebär att service mesh-certifikat är osynliga för CLM-plattformen, inte styrs av samma profiler och policyer som andra maskincertifikat, och inte kan återkallas via PKIaaS återkallningsmekanism. Integrering av service mesh med PKIaaS löser detta:

• Istio-integration: Istiods certifikatutfärdare (istiod) kan konfigureras för att använda ett externt CA-plugin. cert-managers istio-csr-komponent fungerar som en brygga mellan Istios mekanism för certifikatsigneringsförfrågningar och PKIaaS CA: istiod skickar CSR:er till istio-csr, som vidarebefordrar dem till PKIaaS CA via cert-manager, och de signerade certifikaten returneras till istiod för distribution till Envoy-sidecars. Alla service mesh-certifikat utfärdas nu av PKIaaS CA och är synliga i CLM-inventeringen;
• Linkerd-integration: Linkerds kontrollplan använder ett förtroendeankarcertifikat och ett utfärdarcertifikat för utfärdande av proxycertifikat. cert-manager kan tillhandahålla och automatiskt förnya både förtroendeankarcertifikatet och utfärdarcertifikatet från PKIaaS-certifikatutfärdaren, vilket säkerställer att Linkerds proxycertifikat kedjas till organisationens privata certifikatutfärdare snarare än till en självsignerad Linkerd-intern certifikatutfärdare.

Registrering av maskincertifikat för lokala miljöer

Inte alla maskiner i en hybridmiljö körs i Kubernetes eller molnbaserade runtimes. Lokala servrar, nätverksapparater och äldre applikationsservrar behöver också maskincertifikat för mTLS och intern API-autentisering. PKIaaS stöder registrering för dessa miljöer via EST och SCEP.

EST (Registrering via säker transport)

EST (RFC 7030) är IETF-standarden för certifikatregistrering via HTTPS. EST är att föredra framför SCEP för nya distributioner eftersom den använder standard HTTPS-transport (ingen speciell port eller protokoll krävs), stöder ömsesidig TLS för klientautentisering före certifikatutfärdande (förhindrar oautentiserad registrering), tillhandahåller explicit certifikatåterregistrering och hämtning av CA-certifikat, och stöds av moderna företagsnätverksenheter och Linux-baserade system.

För lokala maskiner fungerar EST-registrering via PKIaaS EST-slutpunkten enligt följande: maskinen genererar ett nyckelpar lokalt, konstruerar en PKCS#10 CSR, autentiserar sig mot PKIaaS EST-slutpunkten med hjälp av en initial delad hemlighet eller ett tidigare utfärdat certifikat (för återregistrering), skickar in CSR:n och tar emot det signerade certifikatet. Förnyelse hanteras genom att EST-klienten återregistrerar sig innan det aktuella certifikatet löper ut. EST-klienter är tillgängliga för Linux (est-klient, OpenSSL-baserade implementeringar), nätverksapparater och inbyggda system som stöder RFC 7030.

CMP för inbyggda enheter och Edge-enheter

CMP (Certificate Management Protocol, RFC 4210) används i miljöer där EST och ACME inte är lämpliga: industriella styrsystem, programmerbara logikstyrenheter, inbyggda enheter med begränsade nätverksstackar, tillverkningsutrustning och telekominfrastruktur. CMP är mer komplext än EST men tillhandahåller omfattande certifikathanteringsåtgärder inklusive initial registrering, certifikatförnyelse, certifikatåterkallelse och meddelande om uppdatering av CA-nyckel, i ett protokoll utformat för miljöer där den registrerande enheten kan ha begränsade beräkningsresurser eller fungera över begränsade nätverkslänkar.

För hybridmiljöer med lokal OT (operativ teknik) eller edge-infrastruktur tillsammans med molnbaserade arbetsbelastningar innebär PKIaaS CMP-stöd att samma CA-hierarki kan utfärda certifikat för både en Kubernetes-mikrotjänst som körs i molnet och en industriell styrenhet på fabriksgolvet. CLM-lagret ger enhetlig insyn över båda, och visar varningar om certifikatutgång för edge-enhetscertifikat som annars inte skulle ha någon övervakning.

Säkra interna API:er med PKIaaS-maskincertifikat

Interna API:er är bland de mest värdefulla målen i en hybridföretagsmiljö. Ett internt API som accepterar förfrågningar från alla anropare på det interna nätverket (utan verifiering av maskinidentitet) är tillgängligt för alla komprometterade maskiner som har nätverksåtkomst, alla utvecklararbetsstationer på ett platt nätverkssegment och alla laterala rörelsevägar som en angripare har etablerat. mTLS på interna API:er eliminerar nätverksplatsbaserat förtroende för API-åtkomst.

För REST API:er och gRPC-tjänster i hybridmiljöer möjliggör PKIaaS-maskincertifikat följande API-säkerhetsarkitektur:

• Klientcertifikat per tjänst: Varje tjänst som anropar det interna API:et utfärdas ett klientcertifikat från PKIaaS CA. API-serverns TLS-konfiguration kräver presentation av klientcertifikat och validerar certifikatkedjan mot PKIaaS CA. API-servern kan läsa klientcertifikatets ämnes-CN eller URI SAN för att identifiera den anropande tjänsten och tillämpa auktoriseringsprinciper på tjänstenivå (tjänst A har tillåtelse att anropa /orders read-slutpunkten; tjänst B har inte det).
• Tillämpning av API-gatewaycertifikat: Interna API-gateways (Kong, Apigee eller molnbaserade API-gateways) kan konfigureras för att framtvinga klientcertifikatvalidering innan begäranden dirigeras till uppströmstjänster. Gatewayen läser klientcertifikatet, validerar det mot PKIaaS CA-förtroendekedjan och skickar den verifierade anroparidentiteten till uppströmstjänsten som ett header- eller kontextattribut.
• Kortlivade API-anropscertifikat för känsliga operationer: För API-anrop med hög behörighet (administrativa åtgärder, massdataåtkomst, konfigurationsändringar) kan PKIaaS utfärda certifikat som endast är giltiga under den specifika åtgärdens varaktighet (minuter till timmar) snarare än för en standardgiltighetsperiod för tjänstecertifikatet. API-servern kontrollerar både att certifikatet är giltigt och att det utfärdades inom det förväntade tidsfönstret för åtgärdstypen.

Design av betrodda domäner för hybridmiljöer

Hybridmiljöer sträcker sig över flera administrativa domäner: organisationens lokala datacenter, ett eller flera publika molnkonton, Kubernetes-kluster i olika regioner, distributionszoner på gränsen och partner- eller förvärvade organisationsnätverk. PKIaaS CA-hierarkin måste ta hänsyn till denna topologi för att ge meningsfull förtroendeisolering mellan miljöer.

Den rekommenderade designen använder en enda PKIaaS-rot-CA med miljöspecifika utfärdande CA:er, vilket speglar den styrningsmodell för flera kluster som beskrivs för plattformsteknik men tillämpas på hela hybridområdet:

• Miljöspecifika utfärdande CA:er: En produktionsutfärdande CA för produktionsarbetsbelastningar, en icke-produktionsutfärdande CA för utveckling och mellanlagring, och separata utfärdande CA:er för reglerade miljöer (de som omfattas av krav på datalagring eller efterlevnadsisolering). Certifikat som utfärdas av den produktionsutfärdande CA:n kan inte autentiseras mot icke-produktionstjänster vars förtroendelager endast innehåller den icke-produktionsutfärdande CA:n, vilket ger isolering av kryptografisk miljö.
• Molnspecifika utfärdande CA:er: För organisationer med distributioner i flera moln där arbetsbelastningar hos en molnleverantör inte ska kunna autentisera mot tjänster hos en annan molnleverantör utan explicit konfiguration av förtroende mellan olika CA:er, tillhandahåller molnspecifika utfärdande CA:er isoleringsgränsen. Förtroende mellan molnmiljöer upprättas genom explicit distribution av förtroendeankare, inte som standard;
• Edge-utfärdande CA:er med offlinefunktion: Kantmiljöer med intermittent anslutning till PKIaaS-hanteringsplanet kan kräva en kantutfärdande certifikatutfärdare som kan utfärda certifikat lokalt när anslutningen till den centrala PKIaaS-certifikatutfärdaren inte är tillgänglig. Den kantutfärdande certifikatutfärdaren utfärdas av PKIaaS-rot-certifikatutfärdaren; dess certifikat är betrodda av samma rot-certifikatutfärdarens förtroendearkiv. Certifikatutfärdandet vid kanten fortsätter under anslutningsgap; återkallelsen synkroniseras när anslutningen återställs.
• Integrering av partners och förvärv: För förvärvade organisationer eller partnernätverk som behöver delta i maskinidentitetsförtroendedomänen kan PKIaaS-utfärdaren utfärda ett korscertifieringscertifikat till partnerns befintliga utfärdare (eller utfärda en ny utfärdande utfärdare under PKIaaS-roten) utan att partnern behöver ersätta sin befintliga certifikatinfrastruktur omedelbart.

Livscykelhantering för maskincertifikat i stor skala

Maskincertifikat har ett annat felläge än användarcertifikat. När ett användares certifikat går ut förlorar en användare åtkomst och rapporterar det till helpdesk. När ett maskincertifikat går ut i en service mesh- eller mTLS-skyddad mikrotjänstarkitektur misslyckas tjänst-till-tjänst-anrop. Beroende på hur felhanteringen implementeras kan detta kaskadföra: Tjänst A kan inte anropa tjänst B, så tjänst A returnerar fel till tjänst C, som misslyckas med sina egna operationer, vilket ger symptom som ser ut som ett nätverksavbrott eller en applikationsbugg snarare än ett certifikatutgångsdatum. Att diagnostisera ett certifikatutgångsdatum i ett kaskadfelscenario är tidskrävande och störande.

CLM för maskincertifikat förhindrar detta felläge genom att tillhandahålla:

• Enhetlig maskincertifikatinventering: CLM-plattformen som är ansluten till PKIaaS-certifikatutfärdaren upprätthåller en inventering av alla maskincertifikat som utfärdats i alla miljöer: Kubernetes-klustercertifikat, lokala servercertifikat, certifikat för edge-enheter, certifikat för nätverksapparater och API-gatewaycertifikat. Varje certifikatpost registrerar den utfärdande certifikatutfärdaren, ämnet och SAN:erna, giltighetsperioden, det använda registreringsprotokollet och den tillhörande tjänsten eller maskinidentiteten.
• Utgångsövervakning med miljömedvetna varningar: För produktionsmaskincertifikat skickas utgångsdatumaviseringar till serviceteamet och infrastrukturteamet som ansvarar för tjänstens certifikathantering. För gränsenhetscertifikat skickas aviseringar till gränsdriftsteamet. Aviseringströsklar för maskincertifikat bör ställas in tidigare än för användarcertifikat (30 dagar, 14 dagar, 7 dagar) eftersom misslyckade förnyelser av maskincertifikat i produktionsmiljöer har större omedelbar effekt än misslyckade förnyelser av användarcertifikat.
• Automatisk bekräftelse av förnyelse: CLM-plattformen övervakar om certifikat förnyas före utgångsdatum genom att jämföra det förväntade förnyelsedatumet (baserat på certifikatets giltighetsperiod och den konfigurerade förnyelsetröskeln) med utfärdandetidsstämpeln för det senast utfärdade certifikatet för varje maskinidentitet. Om inget nytt certifikat har utfärdats inom det förväntade förnyelsefönstret flaggar CLM certifikatet som i fara och initierar varningssökvägen;
• Spårning av avveckling: När en tjänst tas ur drift bör dess certifikat återkallas. CLM-plattformen bör flagga aktiva certifikat för tjänster som har tagits bort från tjänstregistret, vilket varnar PKI-administrationsteamet om att återkalla certifikat för överblivna maskinenheter. Ett överblivna certifikat för en överblivna tjänst är en säkerhetsrisk: om tjänstens privata nyckel inte förstördes vid avstängningen kan certifikatet missbrukas för att autentisera som den tjänsten för andra tjänster som fortfarande litar på det.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande tillhandahåller den styrda CA-infrastrukturen för maskin-till-maskin-identitet i hybridmiljöer: mTLS-maskincertifikatprofiler (TLS Client Auth EKU, TLS Server Auth EKU, SPIFFE URI SAN-stöd), hierarkidesign för CA i flera miljöer (produktions-/icke-produktions-/edge-/molnspecifika utfärdande CA:er), ACME-slutpunkt för molnbaserad maskinregistrering, EST-slutpunkt för registrering av Linux-servrar och nätverksapparater, CMP för inbäddade enheter och edge-enheter, och CA Gateway API för programmatisk certifikatutfärdande från DevOps-verktygskedjor och infrastruktur-som-kod-pipelines. Kontakta oss på Krypteringskonsulting för att designa din hybridmaskinidentitetsarkitektur.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare tillhandahåller CLM-lagret för hantering av maskincertifikats livscykel: enhetlig maskincertifikatinventering i lokala, moln-, Kubernetes- och edge-miljöer, övervakning av utgångsdatum med miljömedveten och serviceteamspecifik aviseringsrouting, automatiserad övervakning av förnyelsebekräftelse, spårning av avveckling av överblivna maskincertifikat och SIEM-integration för livscykelhändelser för maskincertifikat tillsammans med säkerhetshändelser för infrastrukturen.
• PKI-tjänster (maskinidentitetsarkitektur): Krypteringskonsulttjänster PKI-tjänster inkluderar design av maskinidentitetsarkitektur för hybridmiljöer: CA-hierarkidesign för förtroendeisolering i flera miljöer, cert-manager ClusterIssuer-konfiguration för Kubernetes-maskincertifikat, SPIRE uppströms CA-integration med PKIaaS, integration av service mesh-certifikat (Istio istio-csr och Linkerd trust anchor provisioning), EST- och CMP-registreringskonfiguration för lokala och edge-enheter, och mTLS-tillämpningsdesign för interna API-gateway- och service mesh-arkitekturer.
• CBOM-säker: För organisationer som inte har en komplett inventering av maskincertifikat i sin hybridmiljö, Encryption Consultings CBOM-säkerhet tillhandahåller automatiserad kryptografisk identifiering över nätverket och infrastrukturen, och identifierar varje certifikat som används på servrar, containrar, nätverksenheter och molnarbetsbelastningar. CBOM-utdata tillhandahåller baslinjen för maskincertifikatinventeringen från vilken CLM-övervakningsprogrammet börjar, och identifierar certifikat från okända eller självsignerade certifikatutfärdare som indikerar ostyrd maskinidentitet i miljön.
• PKI-bedömningstjänst: För organisationer som utvärderar en övergång från delad M2M-autentisering till certifikatbaserad mTLS, Encryption Consultings PKI-bedömningstjänst utvärderar den nuvarande maskinidentitetsarkitekturen, mappar varje tjänst-till-tjänst-autentiseringsmönster till lämplig certifikattyp och registreringsmekanism, identifierar de ostyrda maskinidentitetsluckorna med högst risk och tar fram en implementeringsplan för M2M-certifikatprogrammet.

Slutsats

Maskin-till-maskin-identitet är det autentiseringsproblem som de flesta hybridföretag inte helt har löst. Delade hemligheter ackumuleras, roterar inkonsekvent och ger ingen kryptografisk bindning mellan autentiseringsuppgifterna och den specifika maskin som innehåller dem. mTLS med PKIaaS-utfärdade certifikat är rätt lösning: kryptografisk identitet för varje maskinenhet, automatisk autentisering på TLS-lagret innan någon applikationsbearbetning, omedelbar återkallelse när en maskin komprometteras eller tas ur bruk, och synlighet på CLM-nivå över hela maskincertifikattillgången.

Den hybrida karaktären hos modern infrastruktur (molnarbetsbelastningar, lokala servrar, Kubernetes-kluster, edge-enheter) gör inte detta svårare; det gör det mer brådskande. En maskin som inte finns i PKIaaS-förtroendedomänen kan anropa vilken tjänst som helst som litar på nätverksplatsen istället för ett certifikat. Varje tjänst som går över till mTLS-tillämpning begränsar attackytan som är tillgänglig för en komprometterad maskin med exakt den uppsättning tjänster som maskinens certifikat inte ger den åtkomst till.

Den praktiska vägen är stegvis: börja med den tjänst-till-tjänst-kommunikation som har högst risk (interna API:er som hanterar känsliga data, tjänster med privilegierad åtkomst till databaser eller nyckelhanteringssystem), utfärda certifikat till dessa tjänster från PKIaaS CA, tillämpa mTLS och utöka den certifikatkrävda förtroendedomänen utåt allt eftersom automatiserings- och övervakningsstacken mognar. CLM-insyn i maskinens certifikattillgångar gör varje ökning av täckningen mätbar.

Om din organisation utformar maskinidentiteter för en hybridmiljö eller utvärderar det aktuella läget för M2M-autentisering, kontakta Encryption Consulting.

Det här inlägget granskas med sex månaders mellanrum och när CNCF SPIFFE/SPIRE, cert-manager, Istio eller större molnleverantörers mesh-integrationer publicerar uppdateringar som påverkar PKIaaS-maskinidentitetsarkitekturmönster.

Vanliga frågor om partihandel med mat och dryck

Vad är maskin-till-maskin-identitet och varför kräver det PKI?

Maskin-till-maskin-identitet är den process genom vilken en tjänst, applikation eller enhet bevisar sin identitet för en annan utan mänsklig interaktion. PKI tillhandahåller detta genom certifikat: varje maskin tar emot ett certifikat från den privata PKIaaS-CA:n, presenterar det när anslutningar initieras och valideras eller avvisas baserat på om certifikatet är giltigt, inte återkallat och utfärdat av en betrodd myndighet. Till skillnad från delade hemligheter lämnar den privata nyckeln aldrig maskinen och det finns ingen delad autentiseringsuppgift som en angripare kan stjäla och återanvända från en annan maskin.

Vad är mTLS och hur skiljer det sig från vanlig TLS?

Standard TLS autentiserar endast servern gentemot klienten. mTLS (ömsesidig TLS) kräver att både servern och klienten presenterar certifikat, vilket autentiserar båda parter innan någon applikationsdata utbyts. För M2M-kommunikation innebär mTLS att en tjänst inte kan ta emot förfrågningar från någon anropare som saknar ett giltigt certifikat från den betrodda PKIaaS CA, oavsett anroparens nätverksplats. Autentisering sker på TLS-lagret före bearbetning på applikationsnivå, vilket eliminerar nätverksplatsbaserad implicit förtroende.

Vad är SPIFFE och hur relaterar det till PKIaaS-maskinidentitet?

SPIFFE (Secure Production Identity Framework for Everyone) är en öppen CNCF-standard för molnbaserade arbetsbelastningsidentiteter. SPIFFE SVID:er är X.509-certifikat där arbetsbelastningens SPIFFE-ID är kodat som ett URI SAN. SPIRE (referensimplementeringen) kan konfigureras för att använda PKIaaS CA som sin uppströmsauktoritet, så SPIFFE-identifierade arbetsbelastningar får SVID:er som länkas till organisationens privata CA-förtroendehierarki snarare än en SPIRE-intern självsignerad CA.

Hur integreras cert-manager med PKIaaS för Kubernetes maskinidentitet?

cert-manager är Kubernetes certifikathanteringskontrollant. Plattformsteamet konfigurerar en cert-manager ClusterIssuer som pekar mot PKIaaS ACME-slutpunkten eller CA Gateway API:et. Tjänster deklarerar certifikatresurser och specificerar ämne och SAN:er; cert-manager hanterar utfärdandet, lagrar certifikatet som en Kubernetes-hemlighet och förnyar det automatiskt innan det löper ut. För servicenät överbryggar cert-managers istio-csr-komponent Istio-certifikatsigneringsförfrågningar till PKIaaS CA, vilket gör servicenätcertifikat synliga i CLM-inventeringen.

Vilka registreringsprotokoll stöder PKIaaS för registrering av maskincertifikat i hybridmiljöer?

PKIaaS stöder ACME (RFC 8555) för molnbaserade och Linux-baserade maskiner, EST (RFC 7030) för företagsservrar och nätverksapparater, CMP (RFC 4210) för inbäddade och edge-enheter, och SCEP för nätverksenheter och MDM-registrerade maskiner. Ett enda PKIaaS CA-hanteringsplan styr all certifikatutfärdande oavsett vilket registreringsprotokoll maskinen använder, vilket ger enhetlig policytillämpning och CLM-inventering över hela hybridmaskintillgången.