Privé-PKI voor machine-naar-machine-identificatie in hybride omgevingen

Elke aanroep tussen diensten in een moderne bedrijfsomgeving vormt een potentieel identiteitsprobleem. Wanneer een betaaldienst een API voor orderbeheer aanroept, wanneer een Kubernetes-pod gegevens opvraagt ​​uit een interne database, wanneer een edge-apparaat telemetriegegevens naar een cloudaggregatiedienst stuurt, heeft het ontvangende systeem geen inherente manier om te verifiëren dat de beller is wie hij beweert te zijn, tenzij de beller zijn identiteit kan bewijzen met een referentie die de ontvanger vertrouwt. In de meeste bedrijfsomgevingen is deze identiteitsverificatie ofwel afwezig (de interne netwerklocatie wordt beschouwd als impliciet vertrouwen) ofwel geïmplementeerd met gedeelde geheimen (API-sleutels en serviceaccounttokens die gestolen kunnen worden, inconsistent worden gewijzigd en moeilijk direct op grote schaal kunnen worden ingetrokken).

Private PKI lost het probleem van machine-identiteit op dezelfde manier op als het probleem van gebruikersidentiteit: elke machine-entiteit ontvangt een certificaat van een vertrouwde CA, presenteert dat certificaat bij het initiëren van verbindingen en wordt gevalideerd of geweigerd op basis van of het certificaat geldig, niet-ingetrokken en uitgegeven is door een vertrouwde autoriteit. PKI as a Service maakt dit mogelijk op hybride bedrijfsniveau: één beheerde CA-hiërarchie geeft certificaten uit voor services die on-premises, in cloudomgevingen, in Kubernetes-clusters en op edge-apparaten draaien, met consistent beleid, geautomatiseerde inschrijving en CLM-zichtbaarheid op CLM-niveau voor het gehele machinecertificatenportfolio.

Kort antwoord: Hoe maakt een private PKI machine-to-machine-identificatie mogelijk?

Een private PKI maakt M2M-identificatie mogelijk door een certificaat uit te geven aan elke machine-entiteit die authenticatie vereist: services, pods, VM's, containers, API's, netwerkapparaten en edge-apparaten. Wanneer een machine een verbinding met een andere machine initieert, presenteert deze zijn certificaat; de ontvangende machine valideert de certificaatketen aan de hand van de vertrouwde private CA en besluit of de verbinding wordt geaccepteerd. Dit is wederzijdse TLS (mTLS) en biedt cryptografische identiteitsverificatie voor elke service-naar-service-aanroep zonder gedeelde geheimen, zonder een centraal authenticatie-eindpunt waar alle aanroepen doorheen moeten lopen, en met intrekking die binnen enkele seconden na detectie van een inbreuk van kracht wordt.

Key Takeaways

• De wildgroei aan machine-identiteiten is het grootste risico in hybride infrastructuren. Interne certificaten hopen zich op bij verschillende teams, cloudaccounts, Kubernetes-clusters en edge-omgevingen, zonder centrale inventarisatie of beleidshandhaving. Een private PKIaaS CA met CLM-integratie biedt de zichtbaarheidslaag die het beheer van de machinecertificaten beheersbaar maakt: elk uitgegeven certificaat wordt geregistreerd, elke vervaldatum wordt bewaakt en elke intrekking wordt vastgelegd.
• mTLS (mutual TLS) is het juiste authenticatiemechanisme voor communicatie tussen services, omdat het zowel de server als de client op de TLS-laag authenticeert, voordat er een verzoek op applicatieniveau wordt verwerkt. Een service zonder een geldig certificaat van de vertrouwde CA kan geen mTLS-verbinding tot stand brengen met een beveiligde service, ongeacht of deze netwerktoegang heeft tot het eindpunt van die service.
• SPIFFE (Secure Production Identity Framework for Everyone) is de open standaard voor workloadidentiteit in cloud-native omgevingen. SPIFFE SVID's zijn X.509-certificaten met URI SAN's die de SPIFFE-ID van de workload coderen. PKIaaS kan fungeren als de upstream CA-autoriteit voor op SPIRE gebaseerde SPIFFE-implementaties, waarbij tijdelijke workloadcertificaten worden verankerd in de beheerde CA-vertrouwenshiërarchie van de organisatie.
• cert-manager is de Kubernetes-native controller voor certificaatvoorziening die Kubernetes-workloads verbindt met de PKIaaS CA. Het platformteam configureert een cert-manager ClusterIssuer die verwijst naar het PKIaaS ACME- of CA Gateway-eindpunt; services declareren certificaatbronnen in hun manifesten; cert-manager verzorgt de uitgifte, levering aan Kubernetes Secrets en automatische verlenging zonder menselijke tussenkomst.
• PKIaaS ondersteunt meerdere inschrijvingsprotocollen voor verschillende machineomgevingen: ACME voor cloud-native en Linux-services, EST voor bedrijfsservers en netwerkapparaten, CMP voor embedded en edge-apparaten en SCEP voor netwerkapparaten en MDM-geregistreerde machines. Eén centraal PKIaaS CA-beheerplatform regelt alle certificaatuitgifte, ongeacht welk inschrijvingsprotocol de machine gebruikt.

Waarom gedeelde geheimen niet geschikt zijn voor machine-identificatie op grote schaal

De standaardaanpak voor machine-identiteit in de meeste bedrijfsomgevingen is het gebruik van gedeelde geheimen: API-sleutels toegewezen aan serviceaccounts, langdurige tokens opgeslagen in omgevingsvariabelen of configuratiebestanden, databasewachtwoorden ingebed in verbindingsreeksen en serviceaccountreferenties die slechts in een beperkt tijdsbestek of helemaal niet worden vernieuwd. Deze aanpak leidt tot steeds grotere problemen naarmate het aantal machines toeneemt:

• Geen cryptografische koppeling met de machine: Een API-sleutel of serviceaccounttoken is een token met een geldige toegangscode: iedereen die deze bezit, kan deze gebruiken, vanaf elke machine, op elk netwerk. Er is geen cryptografisch bewijs dat de gebruiker van de token daadwerkelijk de machine of service is die de token claimt te zijn. Een gelekte API-sleutel uit een gecompromitteerd omgevingsbestand geeft de aanvaller dezelfde toegang als de legitieme service.
• Complexiteit van rotatie op grote schaal: Het roteren van een gedeeld geheim vereist dat het op elke locatie waar het geconfigureerd is, wordt bijgewerkt: elke omgevingsvariabele, elk Kubernetes Secret, elke CI/CD-pipelineconfiguratie en elke infrastructure-as-code-module die ernaar verwijst. Op grote schaal worden rotatiegebeurtenissen operationele incidenten die worden overgeslagen of onvolledig worden uitgevoerd, waardoor lang bestaande referenties voor onbepaalde tijd in productie blijven.
• Geen mogelijkheid tot onmiddellijke intrekking: Wanneer een machine is gecompromitteerd, vereist het intrekken van de toegang dat alle inloggegevens van die machine bekend zijn en dat elk van deze gegevens ongeldig wordt verklaard bij elke service die ze accepteerde. Met PKI-certificaten trekt het intrekken van het certificaat in één enkele bewerking de toegang in tot elke service die valideert via de OCSP-responder van de PKIaaS CA;
• Geen uniforme inventaris: Gedeelde geheimen hopen zich op in verschillende referentiearchieven, configuratiebeheersystemen en cloudgeheimbeheerders, zonder een uniform overzicht van welke service welke referentie heeft en wanneer deze voor het laatst is geroteerd. Een certificaatinventaris van machines in een CLM-platform dat is verbonden met de PKIaaS CA biedt een uniform overzicht van elk certificaat in alle machineomgevingen.

Mutual TLS: De authenticatielaag voor M2M-communicatie

Mutual TLS (mTLS) is een uitbreiding van standaard TLS, waarbij zowel de server als de client certificaten moeten presenteren tijdens de TLS-handshake. In een service mesh of interne API-architectuur die gebruikmaakt van mTLS:

• Service A initieert een verbinding met het HTTPS-eindpunt van Service B;
• Service B presenteert zijn servercertificaat; Service A valideert dit aan de hand van de vertrouwde CA-keten;
• Dienst B vraagt ​​een clientcertificaat aan bij Dienst A; Dienst A presenteert zijn clientcertificaat;
• Service B valideert het certificaat van Service A aan de hand van de vertrouwde CA-keten en controleert de intrekking via OCSP;
• Als beide certificaten geldig zijn, wordt de mTLS-sessie tot stand gebracht en stroomt de applicatiedata;
• Als een van beide certificaten ongeldig of ingetrokken is, mislukt de TLS-handshake en worden er geen applicatiegegevens uitgewisseld.

De cruciale eigenschap van mTLS voor machine-identificatie is dat authenticatie plaatsvindt vóórdat er verwerking op applicatieniveau plaatsvindt. Een gecompromitteerde interne machine die een beveiligde service probeert aan te roepen, kan geen geldig certificaat genereren bij de private CA van de organisatie. Een aanvaller op netwerkniveau die verkeer onderschept, kan geen verzoeken injecteren in een mTLS-beveiligde serviceaanroep, omdat hij geen geldig clientcertificaat kan produceren. De vertrouwenshiërarchie van de private CA definieert de grens van wat vertrouwd is; elke machine die geen certificaat van die CA heeft ontvangen, valt buiten de vertrouwensgrens, ongeacht de locatie in het netwerk.

Voor de PKIaaS CA gebruiken mTLS-machinecertificaten de TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) en, voor services die ook inkomende verbindingen accepteren, de TLS Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). De Subject CN of URI SAN van het certificaat identificeert de service, volgens de naamgevingsconventie van de organisatie (doorgaans de DNS-naam van de service, de SPIFFE ID of de FQDN van de Kubernetes-service). De geldigheidsduur van mTLS-machinecertificaten is doorgaans kort: 24 uur tot 90 dagen, waarbij de certificaatbeheerder van de service de certificaten automatisch vernieuwt vóór de vervaldatum.

SPIFFE Workload Identity en PKIaaS

SPIFFE (Secure Production Identity Framework for Everyone) is een open standaard, beheerd door de Cloud Native Computing Foundation (CNCF), die een uniform identiteitsraamwerk definieert voor workloads in heterogene infrastructuren. SPIFFE definieert:

• De SPIFFE ID: Een URI-identificatie in de vorm van een URI-bestand spiffe://trust-domain/path/to/workloadwaarbij het vertrouwensdomein overeenkomt met het administratieve domein van de organisatie en het pad de specifieke workload identificeert. Bijvoorbeeld: spiffe://example.com/env/production/service/payment-api identificeert de betalings-API-service in de productieomgeving;
• Het SVID (SPIFFE Verifieerbaar Identiteitsdocument): Een X.509-certificaat met de SPIFFE ID gecodeerd als een URI SAN. De SVID is wat workloads aanwezig zijn in mTLS-verbindingen; de ontvangende service valideert de SPIFFE ID van de SVID aan de hand van zijn autorisatiebeleid om te bepalen of de aanroepende workload gemachtigd is om het verzoek te doen;
• De Workload API: Een lokale Unix-domeinsocket-API waarmee workloads hun SVID's kunnen ophalen zonder zelf certificaatopslag te hoeven beheren. De SPIFFE-runtime (SPIRE) levert nieuwe SVID's aan workloads voordat hun huidige SVID's verlopen, waardoor certificaatrotatie transparant wordt afgehandeld.

SPIRE is de referentie-implementatie van de SPIFFE-standaard. In een PKIaaS-integratie wordt SPIRE geconfigureerd met een upstream CA-plugin die intermediaire CA-certificaten aanvraagt ​​bij de PKIaaS CA. SPIRE gebruikt deze intermediaire CA-certificaten om SVID's te ondertekenen voor de workloads die het bedient. De SVID's leiden naar de PKIaaS root CA van de organisatie, waardoor een enkel, uniform vertrouwensanker ontstaat voor SPIFFE-geïdentificeerde workloads, naast niet-SPIFFE-machinecertificaten die rechtstreeks door de PKIaaS CA zijn uitgegeven. Het CLM-platform dat is gekoppeld aan PKIaaS kan de aan SPIRE uitgegeven intermediaire CA-certificaten inventariseren, ook al zijn de individuele, kortstondige SVID's die SPIRE van die intermediaire CA's uitgeeft te kortstondig om direct te kunnen worden bijgehouden met traditionele CLM-inventarisatie.

Machine-identificatie in Kubernetes met cert-manager en PKIaaS

Kubernetes is de meest gebruikte omgeving voor machine-naar-machine-communicatie in cloud-native hybride architecturen. Services in een Kubernetes-cluster communiceren via de DNS- en servicelaag van het cluster; wanneer mTLS wordt toegepast, heeft elke service een certificaat nodig dat deze identificeert bij de andere services waarmee deze communiceert.

cert-manager voor het verstrekken van servicecertificaten

Cert-manager voorziet Kubernetes-services van machine-identiteitscertificaten door het cluster te verbinden met de PKIaaS CA. Het platformteam configureert een ClusterIssuer (of namespace-scoped Issuers voor multi-tenant clusters) die verwijst naar het PKIaaS ACME-eindpunt of de CA Gateway API. Services declareren certificaatbronnen met de gewenste subject, SAN's (DNS SAN's voor de FQDN van de Kubernetes-service en optioneel een URI SAN met de SPIFFE ID van de service), geldigheidsperiode en verlengingsdrempel. Cert-manager dient het certificaatverzoek in bij de PKIaaS CA, slaat het uitgegeven certificaat op als een Kubernetes Secret en koppelt het aan de pods van de service via een volume mount of geprojecteerd secret. De service leest zijn certificaat en privésleutel van het gekoppelde pad en presenteert deze in mTLS-verbindingen aan andere services.

De automatische vernieuwing van cert-manager zorgt ervoor dat machinecertificaten in Kubernetes altijd actueel zijn. Als het certificaatprofiel van de PKIaaS CA wordt bijgewerkt (bijvoorbeeld om een ​​kortere geldigheidsperiode af te dwingen als onderdeel van een beveiligingsverbetering), genereert het volgende vernieuwingsverzoek onder het bijgewerkte profiel een certificaat met de nieuwe parameters. De service hoeft niet opnieuw te worden geïmplementeerd; cert-manager activeert de vernieuwing en werkt het Kubernetes Secret bij, waarna de service het nieuwe certificaat ophaalt bij de volgende bestandssysteemsynchronisatie.

Integratie van Service Mesh-certificaten

Service meshes (zoals Istio, Linkerd en andere) bieden automatische mTLS-communicatie tussen alle services in een mesh, zonder dat individuele services zelf TLS hoeven te implementeren. Het dataplane van de service mesh (in het geval van Istio Envoy proxy sidecars) verzorgt de mTLS-handshake namens de applicatie; de ​​applicatie communiceert met de sidecar via een lokale plaintext-verbinding en de sidecar beheert alle mTLS-verbindingen met andere services.

Standaard gebruiken service meshes een interne, zelfondertekende CA om certificaten uit te geven aan dataplane-proxy's. Deze interne CA is niet geïntegreerd met de PKIaaS CA-hiërarchie van de organisatie, wat betekent dat service mesh-certificaten onzichtbaar zijn voor het CLM-platform, niet onderworpen zijn aan dezelfde profielen en beleidsregels als andere machinecertificaten en niet intrekbaar zijn via het PKIaaS-intrekkingsmechanisme. Integratie van de service mesh met PKIaaS lost dit op:

• Istio-integratie: De certificeringsinstantie van Istio (istiod) kan worden geconfigureerd om een ​​externe CA-plugin te gebruiken. De istio-csr-component van cert-manager fungeert als een brug tussen het certificaatondertekeningsmechanisme van Istio en de PKIaaS CA: istiod stuurt CSR's naar istio-csr, die ze via cert-manager doorstuurt naar de PKIaaS CA, waarna de ondertekende certificaten worden teruggestuurd naar istiod voor distributie naar Envoy-sidecars. Alle service mesh-certificaten worden nu uitgegeven door de PKIaaS CA en zijn zichtbaar in de CLM-inventaris.
• LinkedIn-integratie: Het controlepaneel van Linkerd maakt gebruik van een vertrouwensankercertificaat en een uitgevercertificaat voor de uitgifte van proxycertificaten. Cert-manager kan zowel het vertrouwensankercertificaat als het uitgevercertificaat van de PKIaaS CA aanvragen en automatisch vernieuwen, waardoor de certificaatketen van Linkerd naar de private CA van de organisatie loopt in plaats van naar een zelfondertekende interne Linkerd CA.

Certificaatregistratie voor machines in on-premises omgevingen

Niet alle machines in een hybride omgeving draaien in Kubernetes of cloud-native runtimes. On-premises servers, netwerkapparaten en legacy applicatieservers hebben ook machinecertificaten nodig voor mTLS en interne API-authenticatie. PKIaaS ondersteunt de registratie voor deze omgevingen via EST en SCEP.

EST (Inschrijving via beveiligd transport)

EST (RFC 7030) is de IETF-standaard voor certificaatinschrijving via HTTPS. EST heeft de voorkeur boven SCEP voor nieuwe implementaties omdat het gebruikmaakt van standaard HTTPS-transport (geen speciale poort of protocol vereist), wederzijdse TLS ondersteunt voor clientauthenticatie vóór certificaatuitgifte (waardoor niet-geauthenticeerde inschrijving wordt voorkomen), expliciete herinschrijving van certificaten en het ophalen van CA-certificaten mogelijk maakt, en wordt ondersteund door moderne bedrijfsnetwerkapparaten en Linux-gebaseerde systemen.

Voor machines op locatie werkt EST-registratie via het PKIaaS EST-eindpunt als volgt: de machine genereert lokaal een sleutelpaar, construeert een PKCS#10 CSR, authenticeert zich bij het PKIaaS EST-eindpunt met behulp van een initieel gedeeld geheim of een eerder uitgegeven certificaat (voor herregistratie), dient de CSR in en ontvangt het ondertekende certificaat. Vernieuwing wordt afgehandeld doordat de EST-client zich opnieuw registreert voordat het huidige certificaat verloopt. EST-clients zijn beschikbaar voor Linux (est-client, OpenSSL-gebaseerde implementaties), netwerkapparaten en embedded systemen die RFC 7030 ondersteunen.

CMP voor embedded en edge-apparaten

CMP (Certificate Management Protocol, RFC 4210) wordt gebruikt in omgevingen waar EST en ACME niet geschikt zijn: industriële besturingssystemen, programmeerbare logische controllers, embedded systemen met beperkte netwerkcapaciteit, productieapparatuur en telecommunicatie-infrastructuur. CMP is complexer dan EST, maar biedt uitgebreide mogelijkheden voor certificaatbeheer, waaronder initiële registratie, certificaatvernieuwing, certificaatintrekking en meldingen over CA-sleutelupdates, in een protocol dat is ontworpen voor omgevingen waar het registrerende apparaat mogelijk beperkte rekenkracht heeft of werkt via beperkte netwerkverbindingen.

Voor hybride omgevingen met on-premises OT (operationele technologie) of edge-infrastructuur naast cloud-native workloads, betekent PKIaaS CMP-ondersteuning dat dezelfde CA-hiërarchie certificaten kan uitgeven voor zowel een Kubernetes-microservice die in de cloud draait als een industriële controller op de fabrieksvloer. De CLM-laag biedt uniforme zichtbaarheid over beide, met waarschuwingen voor verlopen certificaten van edge-apparaten die anders niet gemonitord zouden worden.

Interne API's beveiligen met PKIaaS-machinecertificaten

Interne API's behoren tot de meest waardevolle doelwitten in een hybride bedrijfsomgeving. Een interne API die verzoeken accepteert van elke aanroeper op het interne netwerk (zonder verificatie van de machine-identiteit) is toegankelijk voor elke gecompromitteerde machine met netwerktoegang, elk ontwikkelaarswerkstation op een vlak netwerksegment en elk lateraal bewegingspad dat een aanvaller heeft gecreëerd. mTLS op interne API's elimineert op netwerklocatie gebaseerd vertrouwen voor API-toegang.

Voor REST API's en gRPC-services in hybride omgevingen maken PKIaaS-machinecertificaten de volgende API-beveiligingsarchitectuur mogelijk:

• Per-service klantcertificaten: Elke service die de interne API aanroept, ontvangt een clientcertificaat van de PKIaaS CA. De TLS-configuratie van de API-server vereist de presentatie van het clientcertificaat en valideert de certificaatketen aan de hand van de PKIaaS CA. De API-server kan de Subject CN of URI SAN van het clientcertificaat lezen om de aanroepende service te identificeren en autorisatiebeleid op serviceniveau toe te passen (Service A mag het /orders read-eindpunt aanroepen; Service B niet).
• Handhaving van API-gatewaycertificaten: Interne API-gateways (Kong, Apigee of cloud-native API-gateways) kunnen worden geconfigureerd om de validatie van clientcertificaten af ​​te dwingen voordat verzoeken naar upstream-services worden doorgestuurd. De gateway leest het clientcertificaat, valideert het aan de hand van de PKIaaS CA-vertrouwensketen en geeft de geverifieerde belleridentiteit door aan de upstream-service als een header- of contextattribuut.
• Certificaten voor API-aanroepen met een korte geldigheidsduur voor gevoelige bewerkingen: Voor API-aanroepen met hoge privileges (administratieve bewerkingen, bulktoegang tot gegevens, configuratiewijzigingen) kan PKIaaS certificaten uitgeven die alleen geldig zijn voor de duur van de specifieke bewerking (minuten tot uren), in plaats van voor de standaard geldigheidsperiode van een servicecertificaat. De API-server controleert zowel of het certificaat geldig is als of het binnen het verwachte tijdsvenster voor het betreffende bewerkingstype is uitgegeven.

Ontwerp van vertrouwensdomeinen voor hybride omgevingen

Hybride omgevingen omvatten meerdere administratieve domeinen: het eigen datacenter van de organisatie, een of meer publieke cloudaccounts, Kubernetes-clusters in verschillende regio's, edge-implementatiezones en netwerken van partners of overgenomen organisaties. Het ontwerp van de PKIaaS CA-hiërarchie moet rekening houden met deze topologie om een ​​zinvolle vertrouwensisolatie tussen omgevingen te garanderen.

Het aanbevolen ontwerp maakt gebruik van één enkele PKIaaS-root-CA met omgevingsspecifieke uitgevende CA's, waarmee het multi-cluster-governancemodel dat is beschreven voor platformengineering wordt weerspiegeld, maar dan toegepast op de volledige hybride omgeving:

• Omgevingsspecifieke uitgevende CA's: Een productie-CA voor productieworkloads, een niet-productie-CA voor ontwikkeling en staging, en aparte CA's voor gereguleerde omgevingen (die onderworpen zijn aan vereisten voor gegevensresidentie of compliance-isolatie). Certificaten uitgegeven door de productie-CA kunnen geen authenticatie uitvoeren bij niet-productieservices waarvan de vertrouwensarchieven alleen de niet-productie-CA bevatten, wat zorgt voor cryptografische omgevingsisolatie;
• Cloudspecifieke uitgevende CA's: Voor organisaties met multi-cloudimplementaties, waarbij workloads in de ene cloudprovider geen toegang mogen hebben tot services in een andere cloudprovider zonder expliciete configuratie van het vertrouwen tussen CA's, bieden cloudspecifieke uitgevende CA's de isolatiegrens. Vertrouwen tussen cloudomgevingen wordt tot stand gebracht door expliciete distributie van vertrouwensankers, niet door standaardinstellingen.
• Edge-uitgevende CA's met offline-functionaliteit: Edge-omgevingen met een intermitterende verbinding met het PKIaaS-beheerplatform hebben mogelijk een edge-CA nodig die lokaal certificaten kan uitgeven wanneer de verbinding met de centrale PKIaaS-CA niet beschikbaar is.
• Integratie van partners en overnames: Voor overgenomen organisaties of partnernetwerken die moeten deelnemen aan het vertrouwensdomein voor machine-identiteit, kan de PKIaaS CA een kruiscertificeringscertificaat uitgeven aan de bestaande CA van de partner (of een nieuwe uitgevende CA onder de PKIaaS-root uitgeven) zonder dat de partner zijn bestaande certificaatinfrastructuur onmiddellijk hoeft te vervangen.

Levenscyclusbeheer van machinecertificaten op grote schaal

Machinecertificaten hebben een andere faalmodus dan gebruikerscertificaten. Wanneer een gebruikerscertificaat verloopt, verliest één gebruiker de toegang en meldt dit aan de helpdesk. Wanneer een machinecertificaat verloopt in een service mesh of een met mTLS beveiligde microservices-architectuur, mislukken service-naar-service-aanroepen. Afhankelijk van hoe foutafhandeling is geïmplementeerd, kan dit een kettingreactie veroorzaken: Service A kan Service B niet aanroepen, waardoor Service A fouten doorgeeft aan Service C. Service C faalt vervolgens zelf ook, wat symptomen oplevert die lijken op een netwerkstoring of een applicatiefout in plaats van een verlopen certificaat. Het diagnosticeren van een verlopen certificaat in een dergelijk kettingreactiescenario is tijdrovend en verstorend.

CLM voor machinecertificaten voorkomt deze foutmodus door het volgende te bieden:

• Uniforme inventaris van machinecertificaten: Het CLM-platform, gekoppeld aan de PKIaaS CA, houdt een inventaris bij van elk machinecertificaat dat in alle omgevingen is uitgegeven: Kubernetes-clustercertificaten, on-premises servercertificaten, edge-apparaatcertificaten, netwerkapparaatcertificaten en API-gatewaycertificaten. Elk certificaat bevat de uitgevende CA, het onderwerp en de SAN's, de geldigheidsperiode, het gebruikte inschrijvingsprotocol en de bijbehorende service- of machine-identiteit.
• Vervaldatumbewaking met omgevingsafhankelijke waarschuwingen: Voor machinecertificaten in productieomgevingen worden waarschuwingen voor verlopen certificaten doorgestuurd naar het serviceteam en het infrastructuurteam dat verantwoordelijk is voor het certificaatbeheer van die service. Voor edge-apparaten worden waarschuwingen doorgestuurd naar het edge-operationsteam. De waarschuwingsdrempels voor machinecertificaten moeten eerder worden ingesteld dan voor gebruikerscertificaten (30 dagen, 14 dagen, 7 dagen), omdat mislukte verlengingen van machinecertificaten in productieomgevingen een grotere directe impact hebben dan mislukte verlengingen van gebruikerscertificaten.
• Automatische verlengingsbevestiging: Het CLM-platform controleert of certificaten vóór de vervaldatum worden verlengd door de verwachte verlengingsdatum (gebaseerd op de geldigheidsperiode van het certificaat en de geconfigureerde verlengingsdrempel) te vergelijken met de uitgiftedatum van het meest recent uitgegeven certificaat voor elke machine-identiteit. Als er binnen de verwachte verlengingsperiode geen nieuw certificaat is uitgegeven, markeert het CLM-platform het certificaat als risicovol en start het de waarschuwingsprocedure.
• Registratie van buitenbedrijfstelling: Wanneer een service wordt buiten gebruik gesteld, moet het bijbehorende certificaat worden ingetrokken. Het CLM-platform moet actieve certificaten markeren voor services die uit het serviceregister zijn verwijderd, zodat het PKI-beheerteam wordt gealarmeerd om achtergebleven machinecertificaten in te trekken. Een achtergebleven certificaat voor een buiten gebruik gestelde service vormt een beveiligingsrisico: als de privésleutel van de service niet is vernietigd bij de buitenbedrijfstelling, kan het certificaat worden misbruikt om zich namens die service te authenticeren bij andere services die er nog steeds op vertrouwen.

Hoe encryptieconsultancy kan helpen

• PKI als een service: Encryptie Consulting's PKIaaS-aanbod Biedt de beheerde CA-infrastructuur voor machine-to-machine-identificatie in hybride omgevingen: mTLS-machinecertificaatprofielen (TLS Client Auth EKU, TLS Server Auth EKU, SPIFFE URI SAN-ondersteuning), ontwerp van de CA-hiërarchie voor meerdere omgevingen (productie-/niet-productie-/edge-/cloudspecifieke uitgevende CA's), ACME-eindpunt voor cloud-native machine-inschrijving, EST-eindpunt voor inschrijving van Linux-servers en netwerkapparaten, CMP voor embedded en edge-apparaten en CA Gateway API voor programmatische certificaatuitgifte vanuit DevOps-toolchains en infrastructure-as-code-pipelines. Neem contact met ons op via Encryptie Consulting om uw hybride machine-identiteitsarchitectuur te ontwerpen.
• CertSecure Manager: Encryptie Consulting's CertSecure Manager Biedt de CLM-laag voor het beheer van de levenscyclus van machinecertificaten: een uniforme inventaris van machinecertificaten voor on-premises, cloud-, Kubernetes- en edge-omgevingen, vervalbewaking met omgevingsbewuste en serviceteamspecifieke waarschuwingsroutering, geautomatiseerde bewaking van verlengingsbevestigingen, tracking van de buitenbedrijfstelling van niet-bestaande machinecertificaten en SIEM-integratie voor gebeurtenissen in de levenscyclus van machinecertificaten naast gebeurtenissen op het gebied van infrastructuurbeveiliging.
• PKI-services (Machine Identity Architecture): Encryptie Consulting's PKI-diensten Dit omvat het ontwerp van de machine-identiteitsarchitectuur voor hybride omgevingen: het ontwerp van de CA-hiërarchie voor vertrouwensisolatie tussen meerdere omgevingen, de configuratie van cert-manager ClusterIssuer voor Kubernetes-machinecertificaten, de integratie van SPIRE upstream CA met PKIaaS, de integratie van service mesh-certificaten (Istio istio-csr en Linkerd trust anchor provisioning), de configuratie van EST- en CMP-inschrijvingen voor on-premises en edge-apparaten, en het ontwerp van mTLS-handhaving voor interne API gateway- en service mesh-architecturen.
• CBOM Secure: Voor organisaties die geen volledig overzicht hebben van alle machinecertificaten in hun hybride omgeving, biedt Encryption Consulting een oplossing. CBOM Secure Het systeem biedt geautomatiseerde cryptografische detectie in het netwerk en de infrastructuur, waarbij elk certificaat dat in gebruik is op servers, containers, netwerkapparaten en cloudworkloads wordt geïdentificeerd. De CBOM-output levert de basisinventaris van machinecertificaten van waaruit het CLM-monitoringprogramma start, en identificeert certificaten van onbekende of zelfondertekende CA's die wijzen op een ongecontroleerde machine-identiteit in de omgeving.
• PKI-beoordelingsservice: Voor organisaties die een overstap van M2M-authenticatie met gedeelde geheimen naar certificaatgebaseerde mTLS overwegen, biedt Encryption Consulting de volgende oplossingen: PKI-beoordelingsservice Het evalueert de huidige architectuur voor machine-identiteit, koppelt elk authenticatiepatroon tussen services aan het juiste certificaattype en inschrijvingsmechanisme, identificeert de grootste risico's op het gebied van ongereguleerde machine-identiteit en stelt een implementatieplan op voor het M2M-certificaatprogramma.

Conclusie

Machine-to-machine-identificatie is het authenticatieprobleem dat de meeste hybride ondernemingen nog niet volledig hebben opgelost. Gedeelde geheimen hopen zich op, worden inconsistent geroteerd en bieden geen cryptografische koppeling tussen de authenticatiegegevens en de specifieke machine waarop deze zich bevindt. mTLS met PKIaaS-certificaten is de juiste oplossing: cryptografische identiteit voor elke machine-entiteit, automatische authenticatie op de TLS-laag vóórdat een applicatie wordt verwerkt, onmiddellijke intrekking wanneer een machine wordt gecompromitteerd of buiten gebruik wordt gesteld, en CLM-niveau inzicht in het gehele certificaatportfolio van de machines.

Het hybride karakter van moderne infrastructuren (cloudworkloads, on-premises servers, Kubernetes-clusters, edge-apparaten) maakt dit niet moeilijker, maar juist urgenter. Een machine die zich niet in het PKIaaS-vertrouwensdomein bevindt, kan elke service aanroepen die de netwerklocatie vertrouwt in plaats van een certificaat. Elke service die overstapt op mTLS-handhaving verkleint het aanvalsoppervlak voor een gecompromitteerde machine tot precies die services waartoe het certificaat van die machine geen toegang verleent.

De praktische aanpak is stapsgewijs: begin met de meest risicovolle service-to-service-communicatie (interne API's die gevoelige gegevens verwerken, services met bevoorrechte toegang tot databases of sleutelbeheersystemen), geef certificaten uit aan deze services via de PKIaaS CA, handhaaf mTLS en breid het certificaatvereiste vertrouwensdomein uit naarmate de automatiserings- en monitoringstack volwassener wordt. Dankzij de CLM-inzichten in het certificaatportfolio van de machines is elke uitbreiding van de dekking meetbaar.

Als uw organisatie machine-identificatie ontwerpt voor een hybride omgeving of de huidige stand van M2M-authenticatie evalueert, neem dan contact op met Encryption Consulting.

Dit bericht wordt elke zes maanden herzien en wanneer CNCF SPIFFE/SPIRE, cert-manager, Istio of belangrijke cloudprovider-service mesh-integraties updates publiceren die van invloed zijn op de architectuurpatronen voor machine-identiteit van PKIaaS.

Veelgestelde Vragen / FAQ

Wat is machine-to-machine-identificatie en waarom is PKI hiervoor nodig?

Machine-to-machine-identificatie is het proces waarbij een service, applicatie of apparaat zijn identiteit aan een ander bewijst zonder menselijke tussenkomst. PKI biedt dit via certificaten: elke machine ontvangt een certificaat van de private PKIaaS-CA, presenteert dit bij het initiëren van verbindingen en wordt gevalideerd of afgewezen op basis van de vraag of het certificaat geldig, niet ingetrokken en uitgegeven is door een vertrouwde autoriteit. In tegenstelling tot gedeelde geheimen verlaat de privésleutel de machine nooit en is er geen gedeelde authenticatie die een aanvaller kan stelen en hergebruiken op een andere machine.

Wat is mTLS en waarin verschilt het van standaard TLS?

Standaard TLS authenticeert alleen de server bij de client. mTLS (mutual TLS) vereist dat zowel de server als de client certificaten presenteren, waardoor beide partijen worden geauthenticeerd voordat er applicatiegegevens worden uitgewisseld. Voor M2M-communicatie betekent mTLS dat een service geen verzoeken kan ontvangen van een beller die geen geldig certificaat heeft van de vertrouwde PKIaaS-CA, ongeacht de netwerklocatie van de beller. Authenticatie vindt plaats op de TLS-laag vóór de verwerking op applicatieniveau, waardoor impliciet vertrouwen op basis van netwerklocatie wordt geëlimineerd.

Wat is SPIFFE en hoe verhoudt het zich tot de machine-identiteit van PKIaaS?

SPIFFE (Secure Production Identity Framework for Everyone) is een open CNCF-standaard voor cloud-native workload-identificatie. SPIFFE SVID's zijn X.509-certificaten waarbij de SPIFFE-ID van de workload is gecodeerd als een URI SAN. SPIRE (de referentie-implementatie) kan worden geconfigureerd om de PKIaaS CA als upstream-autoriteit te gebruiken, zodat SPIFFE-geïdentificeerde workloads SVID's ontvangen die verwijzen naar de private CA-vertrouwenshiërarchie van de organisatie in plaats van een interne, zelfondertekende CA van SPIRE.

Hoe integreert cert-manager met PKIaaS voor Kubernetes-machine-identificatie?

Cert-manager is de controller voor certificaatbeheer in Kubernetes. Het platformteam configureert een cert-manager ClusterIssuer die verwijst naar het PKIaaS ACME-eindpunt of de CA Gateway API. Services declareren certificaatbronnen met specificatie van onderwerp en SAN's; cert-manager verzorgt de uitgifte, slaat het certificaat op als een Kubernetes Secret en vernieuwt het automatisch vóór de vervaldatum. Voor service meshes zorgt de istio-csr-component van cert-manager ervoor dat Istio-certificaatondertekeningsverzoeken worden doorgestuurd naar de PKIaaS CA, waardoor service mesh-certificaten zichtbaar worden in de CLM-inventaris.

Welke inschrijvingsprotocollen ondersteunt PKIaaS voor het inschrijven van machinecertificaten in hybride omgevingen?

PKIaaS ondersteunt ACME (RFC 8555) voor cloud-native en Linux-machines, EST (RFC 7030) voor enterprise-servers en netwerkapparaten, CMP (RFC 4210) voor embedded en edge-apparaten, en SCEP voor netwerkapparaten en MDM-geregistreerde machines. Eén centraal PKIaaS CA-beheerplatform regelt alle certificaatuitgifte, ongeacht welk registratieprotocol de machine gebruikt, en biedt uniforme beleidshandhaving en CLM-inventarisatie voor het volledige hybride machinepark.