Beheer van digitale certificaten en sleutels in DevOps

Certificaat- en sleutelbeheer in DevOps is het proces van het automatisch uitgeven, opslaan, vernieuwen en intrekken van digitale certificaten en cryptografische sleutels in CI/CD-pipelines, containers en cloudinfrastructuur. Goed uitgevoerd, geeft het elke workload een vertrouwde identiteit zonder de levering te vertragen.

Het beheren van digitale certificaten en sleutels in DevOps betekent het automatiseren van de uitgifte, opslag, rotatie en intrekking van TLS-certificaten, code-ondertekeningssleutels, SSH-sleutels en geheimen binnen CI/CD-pipelines en cloudworkloads. Automatisering via het ACME-protocol (Automatic Certificate Management Environment), platforms voor certificaatlevenscyclusbeheer en geheimbeheerders zorgt voor snelle levering en voorkomt verlopen certificaten en gelekte privésleutels.

Key Takeaways

• Certificaten en sleutels authenticeren elke machine in een pipeline: TLS voor clientverbindingen, wederzijdse TLS tussen services, codeondertekening voor build-artefacten en SSH voor toegang tot de repository en de server.
• CA/Browser Forum-stemming SC-081v3 verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. De verlenging wordt een maandelijkse gebeurtenis die alleen door automatisering kan worden bijgehouden.
• ACME, gestandaardiseerd als IETF RFC 8555 in maart 2019, automatiseert de validatie, uitgifte en verlenging van certificaten. cert-manager, waarvan de CNCF-certificering in november 2024 werd aangekondigd, past dezelfde automatisering toe binnen Kubernetes.
• Bij het datalek bij Equifax in 2017 werden gegevens van ongeveer 147 miljoen mensen openbaar gemaakt. De datadiefstal bleef 76 dagen onopgemerkt omdat een certificaat op een apparaat voor verkeersmonitoring was verlopen.
• Privésleutels horen thuis in een secrets manager of een hardware security module (HSM), nooit in broncode-repositories. Het datalek bij Uber in 2016, waarbij 57 miljoen gegevens werden blootgelegd, begon met inloggegevens die werden gevonden in een privé GitHub-repository.

Wat doen certificaten en sleutels in een DevOps-pipeline?

Certificaten en sleutels geven een betrouwbare identiteit aan elke machine, service en artefact waarmee een DevOps-pipeline in aanraking komt. Digitale certificaten beveiligen clientverkeer via HTTPS , en wederzijdse TLS-certificaten authenticeren microservices binnen het cluster. Codeondertekeningssleutels bewijzen dat een build-artefact of containerimage afkomstig is van uw pipeline en daarna niet is gewijzigd. SSH-sleutels regelen de toegang tot repositories en servers, en API-tokens authenticeren elke geautomatiseerde aanroep daartussen.

Het gevolg is dat het aantal machine-identiteiten in een pipeline veel groter is dan het aantal mensen dat de pipeline uitvoert. Elke buildserver, container en tijdelijke testomgeving heeft referenties nodig, en elke referentie heeft een levenscyclus: deze wordt aangemaakt, gebruikt, geroteerd en ingetrokken. Certificaat- en sleutelbeheer is de discipline die ervoor zorgt dat deze levenscyclus bewust wordt uitgevoerd in plaats van dat deze per ongeluk plaatsvindt.

Waarom DevOps handmatig certificaatbeheer onmogelijk maakt

Handmatige certificaatprocessen schieten tekort in DevOps omdat de infrastructuur nu sneller verandert dan een ticketwachtrij kan reageren. Een traditionele certificaataanvraag duurde dagen voor validatie en goedkeuring, wat acceptabel was toen servers jarenlang in gebruik bleven. Een container die slechts twintig minuten actief is, kan geen ticket aanmaken.

Wanneer de uitgifte traag verloopt, zoeken engineers naar alternatieve oplossingen. Ze genereren zelfondertekende certificaten, hergebruiken één wildcard-certificaat voor tientallen services of slaan sleutels op in een repository zodat de pipeline ze kan vinden. Elk van deze oplossingen creëert cryptografie die niet wordt bijgehouden door een inventaris en niet wordt gedekt door een vernieuwingsproces. Elk certificaat dat een pipeline buiten de inventaris aanmaakt, is een potentiële storing of inbreuk.

Hoe een mislukking eruitziet: Equifax en Uber

Twee goed gedocumenteerde incidenten laten zien wat er gebeurt als de hygiëne van certificaten en sleutels achterblijft bij de leveringssnelheid.

In 2017 werd Equifax gehackt via een niet-gepatchte kwetsbaarheid in Apache Struts (CVE-2017-5638), waardoor persoonsgegevens van ongeveer 147 miljoen mensen openbaar werden. De les die we hieruit kunnen trekken, is de mislukte detectie: het onderzoek van het Amerikaanse Government Accountability Office (GAO) wees uit dat een certificaat op het apparaat dat Equifax gebruikte om netwerkverkeer te inspecteren, was verlopen. Daardoor kon de datalek 76 dagen lang onopgemerkt blijven. Een verlopen certificaat was niet de oorzaak van het datalek, maar het verblindde wel de tools die het hadden moeten detecteren.

In 2016 bemachtigden aanvallers Uber-inloggegevens via een privé GitHub-repository en gebruikten deze om toegang te krijgen tot cloudopslag met gegevens van 57 miljoen passagiers en chauffeurs. Uber maakte dit datalek in 2017 bekend. Sleutels en inloggegevens die onder versiebeheer vallen, zijn geheimen op de eerste plek waar elke aanvaller kijkt. Uber reageerde hierop met strengere toegangscontroles en multifactorauthenticatie voor toegang tot de code; de ​​goedkopere oplossing is echter om sleutelmateriaal helemaal niet in een repository op te slaan.

De geldigheidsduur van 47 dagen verhoogt de inzet.

De geldigheidsduur van openbare TLS-certificaten wordt vanaf maart 2029 teruggebracht tot 47 dagen, volgens het voorstel SC-081v3 van het CA/Browser Forum , dat in april 2025 is goedgekeurd. Deze verkorting vindt gefaseerd plaats:

Ingangsdatum	Maximale geldigheidsduur van het TLS-certificaat
Tot 14 maart 2026	398 dagen
15 maart 2026	200 dagen
15 maart 2027	100 dagen
15 maart 2029	47 dagen

Na 47 dagen vernieuwt elke publiek toegankelijke service zijn certificaat ongeveer maandelijks. Elk team dat dit nog handmatig doet, besteedt meer tijd aan vernieuwingen dan de vernieuwingen waard zijn. Voor DevOps-teams is hiermee de automatiseringsvraag beantwoord: de pipeline die de service implementeert, moet ook in staat zijn om het certificaat te vernieuwen. Organisaties kunnen hun risico nu al inschatten door middel van een certificaatgereedheidsbeoordeling na 47 dagen, in plaats van te wachten tot de fase van 100 dagen in maart 2027 om de kwestie af te dwingen.

Zes werkwijzen voor het beheren van certificaten en sleutels in DevOps

Zes werkwijzen dekken het grootste deel van de risico's bij het beheer van certificaten en sleutels in DevOps, en elk ervan kan worden ingevoerd zonder de levering te onderbreken.

1. Stel een inventaris van certificaten en sleutels samen en houd deze bij: Registreer elk certificaat en elke sleutel in de omgeving: type, eigenaar, vervaldatum, locatie en uitgevende instantie. De inventaris vormt de basis voor al het andere, omdat u niet kunt vernieuwen, roteren of intrekken wat u niet kunt zien. Ontdekking moet continu zijn; een eenmalige audit is verouderd zodra de volgende pipeline wordt uitgevoerd.
2. Automatiseer uitgifte en verlenging: Gebruik het ACME-protocol (IETF RFC 8555, maart 2019) of een platform voor certificaatlevenscyclusbeheer, zodat certificaten zonder tickets kunnen worden uitgegeven en verlengd. In Kubernetes, certificaat-manager Het automatiseert de uitgifte en verlenging van TLS en wederzijdse TLS, en de CNCF-certificering, die in november 2024 werd aangekondigd, weerspiegelt hoe standaard deze automatisering is geworden.
3. Bescherm privésleutels in een HSM of geheimenbeheerder: Sleutels horen nooit thuis in broncode-repositories, containerimages of gewone pipelinevariabelen. Bewaar ze in een hardwarebeveiligingsmodule of een geheimenbeheerder en laat workloads ze tijdens de uitvoering ophalen via kortstondige, gecontroleerde toegang.
4. Handhaaf het principe van minimale privileges: Beperk wie en wat certificaten kan aanvragen, sleutels kan lezen of het uitgiftebeleid kan wijzigen, en registreer elke toegang. Op rollen gebaseerde controles op de certificeringsinstantie en de geheimenopslag beperken de impact wanneer één enkele referentie uitlekt.
5. Houd de vervaldatum in de gaten en waarschuw tijdig; Houd elk certificaat bij aan de hand van de vervaldatum en ontvang ruim voor de verlenging een waarschuwing, ook voor certificaten op de beveiligingssoftware zelf. Equifax laat zien waarom: monitoring die je niet kunt decoderen, is in feite geen effectieve monitoring.
6. Geef de voorkeur aan kortstondige kwalificaties: Certificaten en tokens met een korte geldigheidsduur verkleinen de periode waarin een aanvaller gestolen inloggegevens kan gebruiken en verminderen de afhankelijkheid van intrekking. De sector beweegt zich sowieso al in deze richting; door vroegtijdig korte geldigheidsduur in te voeren, wordt de termijn van 47 dagen irrelevant.

Certificaatbeveiliging integreren in CI/CD

Certificaatbeveiliging blijft in DevOps effectief wanneer deze op dezelfde manier wordt geïmplementeerd als de rest van de infrastructuur: als code. Uitgiftebeleid, certificaatprofielen en vertrouwensconfiguraties horen thuis in versiebeheer, waar ze net als applicatiecode worden gecontroleerd en teruggedraaid. Het scannen op geheimen in de pipeline moet elke build die een privésleutel of hardgecodeerde referentie bevat, laten mislukken. Dit verandert de Uber-foutmodus in een geblokkeerde samenvoeging in plaats van een inbreuk. Continue monitoring sluit vervolgens de cirkel door gebeurtenissen met betrekking tot verlopen certificaten en afwijkende uitgifte door te geven aan hetzelfde waarschuwingssysteem dat de applicatie bewaakt.

Hoe encryptieconsultancy kan helpen

CertSecure Manager is het platform van Encryption Consulting voor certificaatlevenscyclusbeheer. Het detecteert en inventariseert certificaten in uw omgeving en automatiseert de uitgifte, verlenging en intrekking, zodat pipelinecertificaten volgens schema worden verlengd in plaats van per ticket. Voor teams die hun pipelinebeveiliging breder willen uitbouwen, biedt de Securing DevOps- praktijk ondersteuning voor het bijbehorende sleutelbeheer en de PKI- architectuur. Ondersteund door ISO/IEC 27001:2022 en SOC 2-gecertificeerde praktijken.

Veelgestelde Vragen / FAQ

Waarom is certificaatbeheer in DevOps lastiger dan in traditionele IT?

DevOps-infrastructuur is vluchtig. Containers en cloud-instances worden binnen enkele minuten aangemaakt en verwijderd, en elk ervan heeft een vertrouwde identiteit nodig. Daardoor groeit het aantal certificaten veel te snel voor een ticketgebaseerd uitgifteproces. Traditionele IT-systemen vernieuwden eens per jaar een vaste set certificaten; een pipeline kan honderden certificaten per dag aanvragen en kan niet dagen wachten op elk certificaat.

Wat is ACME en hoe helpt het DevOps-teams?

ACME (Automatic Certificate Management Environment) is het protocol dat in maart 2019 is gestandaardiseerd in IETF RFC 8555. Het automatiseert domeinvalidatie, certificaatuitgifte en -vernieuwing tussen een client en een certificeringsinstantie, zonder menselijke tussenkomst. Tools zoals cert-manager gebruiken ACME om automatisch certificaten uit te geven en te vernieuwen voor Kubernetes-workloads, wat vergelijkbaar is met de manier waarop openbare certificeringsinstanties zoals Let's Encrypt op grote schaal werken.

Welke invloed heeft de regel dat certificaten 47 dagen geldig moeten zijn op DevOps-pipelines?

CA/Browser Forum-stemming SC-081v3 verkort de maximale geldigheidsduur van openbare TLS-certificaten in stappen: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Na 47 dagen vernieuwt elke publiek toegankelijke dienst de certificaten ongeveer maandelijks. Handmatige vernieuwing kan dit tempo niet bijhouden, waardoor geautomatiseerde uitgifte en vernieuwing binnen het proces een vereiste wordt in plaats van een optimalisatie.

Waar moeten privésleutels worden opgeslagen in een CI/CD-pipeline?

Privésleutels horen thuis in een secrets manager of een hardware security module (HSM), nooit in broncode repositories, containerimages of gewone pipelinevariabelen. De datalek bij Uber in 2016 begon met inloggegevens die werden gevonden in een privé GitHub-repository. Pipelines zouden sleutels tijdens runtime moeten ophalen via kortstondige, gecontroleerde toegang, en het scannen op geheimen zou elke build moeten laten mislukken die sleutelmateriaal in de code insluit.

Wat is het verschil tussen een secrets manager en een certificate lifecycle management platform?

Een secrets manager slaat gevoelige waarden zoals privésleutels, API-tokens en wachtwoorden op, roteert deze en stelt ze beschikbaar aan workloads tijdens de uitvoering. Een certificate lifecycle management (CLM) platform beheert het certificaat zelf: ontdekking, inventarisatie, uitgifte via een certificeringsinstantie, verlenging en intrekking. De twee zijn complementair. Het CLM-platform bepaalt wanneer en hoe een certificaat bestaat; de secrets manager beschermt het sleutelmateriaal waarop het certificaat is gebaseerd.

Automatiseer de levenscyclus van certificaten voordat de tijd dringt.

De limiet van 200 dagen is ingegaan op 15 maart 2026 en het tempo zal vanaf nu alleen maar toenemen. Bekijk CertSecure Manager in actie om de ontdekking, uitgifte en verlenging van certificaten in uw pipelines te automatiseren, of genereer een testverzoek met de gratis CSR Generator om uw huidige uitgifteproces te controleren.