Geheimenbeheer in defensie-CI/CD-pijplijnen: Vault, HSM en sleutelrotatie

Elk defensiesoftwaresysteem is afhankelijk van geheimen: TLS-certificaten die service-identiteiten authenticeren, API-sleutels die toegang autoriseren tot externe diensten, databasewachtwoorden die operationele gegevens beschermen, encryptiesleutels die geclassificeerde informatie beschermen en code-ondertekeningssleutels die firmware- en softwareintegriteit verifiëren. Als deze geheimen onzorgvuldig worden behandeld — opgeslagen in configuratiebestanden, ingecheckt in broncode-repositories, als omgevingsvariabelen in platte tekst doorgegeven of voor onbepaalde tijd ongewijzigd gelaten — worden ze aanvalsvectoren die alle andere beveiligingscontroles omzeilen.

Geheimenbeheer in defensie-CI/CD-pijplijnen gaat niet primair over het voorkomen van fouten door ontwikkelaars (hoewel het dat ook doet). Het gaat over het implementeren van een beveiligingsarchitectuur waarbij geheimen nooit in platte tekst zijn buiten hun geautoriseerde gebruikscontext, waarbij elk geheimgebruik wordt gecontroleerd, waarbij geheimen gedefinieerde levensduren hebben en automatisch worden geroteerd, en waarbij de compromittering van een individueel geheim een beperkte straal heeft vanwege korte vervaltijden en beperkte toegang.

Soorten geheimen in defensiepijplijnen

Defensie-CI/CD-pijplijnen komen een grotere verscheidenheid aan geheimtypen tegen dan commerciële tegenhangers, omdat de systemen die ze implementeren strengere toegangscontrole- en authenticatievereisten hebben:

TLS-certificaten authenticeren service-identiteiten in mTLS-implementaties en beschermen netwerkcommunicatie. In een defensie-Kubernetes-cluster met een service mesh heeft elke microservice zijn eigen certificaat, mogelijk duizenden certificaten in totaal, die allemaal rotatie vereisen vóór vervaling. De certificaten voor extern gerichte diensten moeten koppelen aan een geautoriseerde CA; interne servicecertificaten kunnen koppelen aan een interne CA die wordt beheerd door Vault of het service mesh-besturingsvlak.

API-sleutels en toegangstokens autoriseren service-naar-service-aanroepen, toegang tot externe dreigingsinformatiefeed, SIEM API-toegang en integratie met geclassificeerde systeembacks. Dit zijn doorgaans statische geheimen (niet dynamisch gegenereerd) en zijn het meest waarschijnlijk in broncode-repositories te verschijnen door ontwikkelaarsfouten.

Databasereferenties beschermen toegang tot operationele en geclassificeerde databases. Statische databasereferenties — een gebruikersnaam en wachtwoordpaar dat nooit verandert — zijn een significant beveiligingsrisico: als de referentie is gecompromitteerd, blijft de toegang bestaan totdat de referentie handmatig wordt geroteerd, wat maanden of jaren kan duren. Dynamische referenties met korte levensduren zijn aanzienlijk veiliger.

Code-ondertekeningssleutels worden gebruikt om software-releases, containerimages, firmwarepakketten en configuratiebundels te ondertekenen. Deze sleutels zijn extreem gevoelig — een gecompromitteerde code-ondertekeningssleutel stelt een aanvaller in staat kwaadaardige code te ondertekenen die wordt vertrouwd door alle systemen die de sleutel vertrouwen. Code-ondertekeningssleutels moeten worden beschermd door HSM-hardware en moeten meervoudige autorisatie vereisen voor gebruik.

HashiCorp Vault: dynamische geheimen en auditlog

HashiCorp Vault is het standaard geheimensbeheerplatform voor defensie-DevSecOps-omgevingen. Vault biedt een gecentraliseerde, gecontroleerde opslag voor geheimen, een uniforme API voor geheimopvraging en een dynamische geheimensmotor die tijdgebonden, doelspecifieke referenties genereert in plaats van applicaties te vereisen langlevende statische geheimen op te slaan.

Dynamische geheimen zijn de krachtigste beveiligingsfunctie van Vault. In plaats van een statisch databasewachtwoord op te slaan dat applicaties ophalen, genereert Vault dynamisch een nieuwe databasegebruiker met een tijdgebonden referentie elke keer dat een applicatie toegang aanvraagt. De referentie verloopt automatisch en de databasegebruiker wordt ingetrokken na de leaseperiode (doorgaans 1-24 uur). Een aanvaller die een dynamische databasereferentie bemachtigt, heeft een smal venster om het te exploiteren voordat het verloopt; een aanvaller die een statische referentie bemachtigt, heeft onbeperkte toegang totdat de referentie handmatig wordt geroteerd.

De dynamische geheimensmotoren van Vault omvatten PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (voor logbeheer), PKI (certificaatuitgifte), AWS IAM (cloudreferenties) en meer. Voor defensieomgevingen is de PKI-geheimensmotor — die Vault in staat stelt te fungeren als een tussenliggende CA die kort levende TLS-certificaten op aanvraag uitgeeft — bijzonder waardevol: certificaten uitgegeven met 24-uur TTL's elimineren het venster voor certificaatmisbruik als een certificaat wordt gecompromitteerd.

Het auditlog van Vault registreert elke API-aanroep naar Vault: elk geheimverzoek, elke authenticatiepoging, elke beleidsopzoeking. Het auditlog is uitsluitend toevoegbaar en kan niet worden gewijzigd door Vault-beheerders. Voor defensieomgevingen biedt het auditlog het bewijsspoor dat vereist is door accreditatie: wie heeft welk geheim geopend, wanneer en van welk systeem. Vault-auditlogs moeten worden doorgestuurd naar de SIEM voor correlatie met applicatie- en netwerkgebeurtenissen.

Hardware Security Modules: wanneer softwaregebaseerde Vault onvoldoende is

HashiCorp Vault beveiligt zijn eigen encryptiesleutels (de hoofdsleutel die wordt gebruikt om Vault te ontzegelen en zijn geheimensopslag te versleutelen) met een softwaregebaseerde sleutelencryptieaanpak. Voor de meeste omgevingen is dit adequate beveiliging. Voor defensieomgevingen met FIPS 140-2 Niveau 3-vereisten — die van toepassing zijn op nationale veiligheidssystemen en systemen die geclassificeerd cryptografisch sleutelmateriaal verwerken — moeten de rootsleutels worden beschermd door hardware, niet software.

FIPS 140-2 Niveau 3 vereist manipulatiebestendige fysieke beveiliging, identiteitsgebaseerde authenticatie voor operators en kritieke beveiligingsparameters (privésleutels) die op geen enkel moment in platte tekst worden geëxporteerd. Softwaregebaseerde sleutelopslag, hoe goed versleuteld ook, voldoet niet aan deze vereiste omdat de encryptiesleutel zelf bestaat in softwaregeheugen waar het potentieel toegankelijk is voor een bevoorrechte software-aanvaller.

HSM auto-unseal voor Vault is de standaardarchitectuur: de hoofdsleutel van Vault wordt omhuld door een HSM-sleutel, en Vault wordt automatisch ontzegeld door zijn omhulde hoofdsleutel naar de HSM te sturen voor onthulling bij opstarten. De HSM voert de ontcijfering uit binnen zijn manipulatiebestendige grens — de hoofdsleutel bestaat nooit in platte tekst buiten de HSM. Deze architectuur voldoet aan FIPS 140-2 Niveau 3-vereisten voor de rootsleutelbeschermingslaag.

Ondersteunde HSM-integratie voor HashiCorp Vault Enterprise omvat Thales (voorheen SafeNet) Luna, nCipher nShield, AWS CloudHSM en Azure Dedicated HSM. Voor air-gapped defensieomgevingen zijn de on-premises HSM-opties (Thales Luna, nCipher nShield) vereist — cloudgebaseerde HSM-diensten zijn niet toegankelijk vanuit air-gapped netwerken.

Sleutelrotatie zonder downtime

Sleutelrotatie — een bestaande cryptografische sleutel vervangen door een nieuwe — is essentieel voor beveiligingshygiëne: het beperkt het blootstellingsvenster als een sleutel is gecompromitteerd en voldoet aan regelgevingsvereisten voor sleutellevensduurlimieten. Maar sleutelrotatie die applicatiedowntime of complexe handmatige coördinatie vereist, wordt vaak voor onbepaalde tijd uitgesteld, wat de beveiligingswaarde tenietdoet.

Sleutelversioning van Vault maakt nul-downtime rotatie mogelijk voor geheimen en encryptiesleutels. Wanneer de transit-encryptiemdotor van Vault (die encryptie-als-dienst biedt voor applicaties) een sleutel roteert, maakt het een nieuwe sleutelversie aan terwijl oudere versies worden bewaard voor ontcijfering van gegevens die zijn versleuteld met vorige versies. Applicaties die nieuwe gegevens versleutelen, gebruiken de huidige sleutelversie; bestaande versleutelde tekst kan nog steeds worden ontcijferd met de oude versie totdat de applicatie wordt bijgewerkt om het opnieuw te versleutelen. De rotatie is transparant voor de applicatie — het hoeft niet offline te gaan.

Respijtperioden voor certificaatrotatie maken geleidelijke uitrol van nieuwe certificaten mogelijk: het nieuwe certificaat wordt gedistribueerd en vertrouwd voordat het oude certificaat wordt ingetrokken, zodat er geen venster is waarbij sommige diensten het nieuwe certificaat hebben en anderen het nog niet hebben ontvangen. De PKI-geheimensmotor van Vault ondersteunt het configureren van certificaat-TTL's en vernieuwingsperioden om dit respijtperiodbeheer te automatiseren.

CI/CD-integratie: patronen voor geheimsinjectie

Geheimen moeten de applicaties en infrastructuurcomponenten bereiken die ze nodig hebben zonder blootgesteld te worden in CI/CD-pijplijnlogs, omgevingsvariabele-dumps of containerimage-lagen. Drie integratiepatronen domineren defensie-CI/CD-omgevingen:

Vault Agent sidecar (in Kubernetes) implementeert een Vault Agent-container naast de applicatiecontainer. De Vault Agent authenticeert bij Vault met de Kubernetes-serviceaccount-identiteit van de pod, haalt de geconfigureerde geheimen op en schrijft ze naar een gedeeld geheugenvolume of injecteert ze in de omgeving van de applicatiecontainer. De geheimen verschijnen nooit in de podspecificatie of containerimage — ze worden bij runtime geïnjecteerd vanuit Vault.

External Secrets Operator is een Kubernetes-operator die geheimen synchroniseert van externe geheimensopslag (Vault, AWS Secrets Manager, Azure Key Vault) naar Kubernetes Secrets. Het biedt een declaratieve, GitOps-compatibele aanpak: de ExternalSecret-aangepaste resource in de GitLab/Kubernetes-configuratie verklaart welke geheimen nodig zijn en waar ze vandaan komen; de operator handelt ophaling en synchronisatie af. De Kubernetes Secrets die door de operator worden aangemaakt, kunnen normaal worden gemount in pods.

Voor GitLab CI-pijplijnen stelt de GitLab-Vault-integratie (GitLab CI/CD Vault-integratie, met JWT-authenticatie) pijplijntaken in staat te authenticeren bij Vault met hun GitLab JWT-identiteit en geheimen op te halen voor de duur van de pijplijntaak. Geheimen zijn beschikbaar als omgevingsvariabelen binnen de taak en worden nooit opgeslagen in de GitLab CI-configuratie of repository.