Secrets-Management in Defense-CI/CD-Pipelines: Vault, HSM und Schlüsselrotation

Jedes Defense-Softwaresystem ist auf Secrets angewiesen: TLS-Zertifikate, die Service-Identitäten authentifizieren, API-Schlüssel, die den Zugriff auf externe Dienste autorisieren, Datenbankpasswörter, die operative Daten schützen, Verschlüsselungsschlüssel, die klassifizierte Informationen schützen, und Code-Signing-Schlüssel, die die Integrität von Firmware und Software überprüfen. Wenn diese Secrets nachlässig behandelt werden — in Konfigurationsdateien gespeichert, in Quellcode-Repositories eingecheckt, als Umgebungsvariablen im Klartext übergeben oder auf unbestimmte Zeit unverändert gelassen — werden sie zu Angriffsvektoren, die alle anderen Sicherheitskontrollen umgehen.

Secrets-Management in Defense-CI/CD-Pipelines dreht sich nicht in erster Linie darum, Entwicklerfehler zu verhindern (obwohl es das auch tut). Es geht darum, eine Sicherheitsarchitektur zu implementieren, bei der Secrets außerhalb ihres autorisierten Nutzungskontexts niemals im Klartext vorliegen, jede Secret-Nutzung auditiert wird, Secrets definierte Lebenszeiten haben und automatisch rotiert werden, und die Kompromittierung eines einzelnen Secrets aufgrund kurzer Ablaufzeiten und begrenztem Zugriff einen begrenzten Strahlungsradius hat.

Secret-Typen in Defense-Pipelines

Defense-CI/CD-Pipelines begegnen einem breiteren Spektrum an Secret-Typen als kommerzielle Entsprechungen, da die Systeme, die sie deployen, strengere Anforderungen an Zugriffskontrolle und Authentifizierung haben:

TLS-Zertifikate authentifizieren Service-Identitäten in mTLS-Deployments und schützen Netzwerkkommunikation. In einem Defense-Kubernetes-Cluster mit Service-Mesh hat jeder Microservice sein eigenes Zertifikat — potenziell Tausende Zertifikate insgesamt, alle mit erforderlicher Rotation vor Ablauf. Zertifikate für externe Dienste müssen zu einer autorisierten CA verketten; interne Service-Zertifikate können zu einer von Vault oder der Service-Mesh-Steuerungsebene verwalteten internen CA verketten.

API-Schlüssel und Access-Token autorisieren Service-zu-Service-Aufrufe, den Zugriff auf externe Threat-Intelligence-Feeds, SIEM-API-Zugriff und die Integration mit klassifizierten System-Backends. Diese sind typischerweise statische Secrets (nicht dynamisch generiert) und am wahrscheinlichsten durch Entwicklerfehler in Quellcode-Repositories zu finden.

Datenbankzugangsdaten schützen den Zugriff auf operative und klassifizierte Datenbanken. Statische Datenbankzugangsdaten — ein Benutzername-Passwort-Paar, das sich nie ändert — sind ein erhebliches Sicherheitsrisiko: Wenn die Zugangsdaten kompromittiert werden, bleibt der Zugriff bestehen, bis die Zugangsdaten manuell rotiert werden, was Monate oder Jahre dauern kann. Dynamische Zugangsdaten mit kurzen Lebenszeiten sind deutlich sicherer.

Code-Signing-Schlüssel werden verwendet, um Software-Releases, Container-Images, Firmware-Pakete und Konfigurations-Bundles zu signieren. Diese Schlüssel sind äußerst sensibel — ein kompromittierter Code-Signing-Schlüssel ermöglicht es einem Angreifer, bösartigen Code zu signieren, dem alle Systeme vertrauen werden, die dem Schlüssel vertrauen. Code-Signing-Schlüssel sollten durch HSM-Hardware geschützt werden und für die Verwendung eine Multi-Party-Autorisierung erfordern.

HashiCorp Vault: dynamische Secrets und Audit-Log

HashiCorp Vault ist die Standard-Secrets-Management-Plattform für Defense-DevSecOps-Umgebungen. Vault bietet einen zentralisierten, auditierten Speicher für Secrets, eine einheitliche API zum Secret-Abruf und eine Dynamic-Secrets-Engine, die zeitlich begrenzte, zweckspezifische Zugangsdaten generiert, anstatt Anwendungen dazu zu zwingen, langlebige statische Secrets zu speichern.

Dynamische Secrets sind Vaults leistungsstärkstes Sicherheitsmerkmal. Anstatt ein statisches Datenbankpasswort zu speichern, das Anwendungen abrufen, generiert Vault dynamisch einen neuen Datenbankbenutzer mit zeitlich begrenzten Zugangsdaten, jedes Mal wenn eine Anwendung Zugriff anfordert. Die Zugangsdaten laufen automatisch ab und der Datenbankbenutzer wird nach der Lease-Periode widerrufen (typischerweise 1–24 Stunden). Ein Angreifer, der dynamische Datenbankzugangsdaten abgreift, hat ein enges Fenster für die Ausnutzung, bevor sie ablaufen; ein Angreifer mit statischen Zugangsdaten hat unbegrenzten Zugriff bis zur manuellen Rotation.

Vaults Dynamic-Secrets-Engines decken PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (für Log-Management), PKI (Zertifikatsausstellung), AWS IAM (Cloud-Zugangsdaten) und mehr ab. Für Defense-Umgebungen ist die PKI-Secrets-Engine — die es Vault ermöglicht, als intermediäre CA zu fungieren und kurzlebige TLS-Zertifikate auf Abruf auszustellen — besonders wertvoll: Zertifikate mit 24-Stunden-TTLs eliminieren das Fenster für Zertifikatsmissbrauch, wenn ein Zertifikat kompromittiert wird.

Vaults Audit-Log zeichnet jeden API-Aufruf an Vault auf: jede Secret-Anfrage, jeden Authentifizierungsversuch, jede Policy-Abfrage. Das Audit-Log ist append-only und kann von Vault-Administratoren nicht modifiziert werden. Für Defense-Umgebungen liefert das Audit-Log die für die Akkreditierung erforderliche Beweisspur: Wer hat auf welches Secret zugegriffen, wann und von welchem System. Vault-Audit-Logs sollten an das SIEM weitergeleitet werden, um sie mit Anwendungs- und Netzwerkereignissen zu korrelieren.

Hardware-Sicherheitsmodule: Wenn Software-Vault nicht ausreicht

HashiCorp Vault sichert seine eigenen Verschlüsselungsschlüssel (der Master-Schlüssel, der zum Entsiegeln von Vault und zur Verschlüsselung seines Secret-Speichers verwendet wird) mithilfe eines softwarebasierten Schlüsselverschlüsselungsansatzes. Für die meisten Umgebungen ist dies eine ausreichende Sicherheit. Für Defense-Umgebungen mit FIPS 140-2 Level 3-Anforderungen — die für National Security Systems und Systeme gelten, die klassifiziertes kryptografisches Schlüsselmaterial verarbeiten — müssen die Root-Schlüssel durch Hardware und nicht durch Software geschützt werden.

FIPS 140-2 Level 3 erfordert manipulationssichere physische Sicherheit, identitätsbasierte Authentifizierung für Operatoren und kritische Sicherheitsparameter (private Schlüssel), die zu keinem Zeitpunkt im Klartext exportiert werden. Softwarebasierte Schlüsselspeicher erfüllen diese Anforderung nicht, egal wie gut sie verschlüsselt sind, da der Verschlüsselungsschlüssel selbst im Software-Speicher existiert, wo er für einen privilegierten Software-Angreifer potenziell zugänglich ist.

HSM-Auto-Unseal für Vault ist die Standardarchitektur: Vaults Master-Schlüssel wird durch einen HSM-Schlüssel eingehüllt, und Vault entsiegelt sich automatisch, indem es seinen eingehüllten Master-Schlüssel beim Start zum Auspacken an das HSM sendet. Das HSM führt die Entschlüsselung innerhalb seiner manipulationssicheren Grenze durch — der Master-Schlüssel existiert außerhalb des HSM niemals im Klartext. Diese Architektur erfüllt die FIPS 140-2 Level 3-Anforderungen für die Root-Schlüsselschutzschicht.

Unterstützte HSM-Integration für HashiCorp Vault Enterprise umfasst Thales (ehemals SafeNet) Luna, nCipher nShield, AWS CloudHSM und Azure Dedicated HSM. Für air-gapped Defense-Umgebungen sind die On-Premises-HSM-Optionen (Thales Luna, nCipher nShield) erforderlich — Cloud-basierte HSM-Dienste sind von air-gapped Netzwerken nicht erreichbar.

Schlüsselrotation ohne Ausfallzeit

Schlüsselrotation — das Ersetzen eines bestehenden kryptografischen Schlüssels durch einen neuen — ist für die Sicherheitshygiene unerlässlich: Sie begrenzt das Expositionsfenster, wenn ein Schlüssel kompromittiert wird, und erfüllt regulatorische Anforderungen für Schlüssellebensdauerlimits. Aber Schlüsselrotation, die Anwendungsausfallzeiten oder komplexe manuelle Koordination erfordert, wird oft unbegrenzt aufgeschoben, was ihren Sicherheitswert zunichte macht.

Vaults Schlüssel-Versionierung ermöglicht eine ausfallzeitfreie Rotation für Secrets und Verschlüsselungsschlüssel. Wenn Vaults Transit-Verschlüsselungs-Engine (die Anwendungen Verschlüsselung als Dienst bereitstellt) einen Schlüssel rotiert, erstellt sie eine neue Schlüsselversion und behält ältere Versionen für die Entschlüsselung von Daten bei, die mit früheren Versionen verschlüsselt wurden. Anwendungen, die neue Daten verschlüsseln, verwenden die aktuelle Schlüsselversion; bestehender Chiffretext kann weiterhin mit der alten Version entschlüsselt werden, bis die Anwendung aktualisiert wird, um ihn neu zu verschlüsseln. Die Rotation ist für die Anwendung transparent — sie muss nicht offline genommen werden.

Toleranzperioden für die Zertifikatsrotation ermöglichen ein schrittweises Rollout neuer Zertifikate: Das neue Zertifikat wird verteilt und vertrauenswürdig gemacht, bevor das alte widerrufen wird, sodass es kein Fenster gibt, in dem einige Dienste das neue Zertifikat haben und andere es noch nicht erhalten haben. Vaults PKI-Secrets-Engine unterstützt die Konfiguration von Zertifikats-TTLs und Erneuerungszeiträumen zur Automatisierung dieses Toleranzzeitraum-Managements.

CI/CD-Integration: Secret-Injektionsmuster

Secrets müssen die Anwendungen und Infrastrukturkomponenten, die sie benötigen, erreichen, ohne in CI/CD-Pipeline-Logs, Umgebungsvariablen-Dumps oder Container-Image-Ebenen offengelegt zu werden. Drei Integrationsmuster dominieren Defense-CI/CD-Umgebungen:

Vault-Agent-Sidecar (in Kubernetes) deployt einen Vault-Agent-Container neben dem Anwendungscontainer. Der Vault-Agent authentifiziert sich bei Vault mit der Kubernetes-Service-Account-Identität des Pods, ruft die konfigurierten Secrets ab und schreibt sie in ein gemeinsames In-Memory-Volume oder injiziert sie in die Umgebung des Anwendungscontainers. Die Secrets erscheinen niemals in der Pod-Spezifikation oder im Container-Image — sie werden zur Laufzeit aus Vault injiziert.

External Secrets Operator ist ein Kubernetes-Operator, der Secrets aus externen Secret-Stores (Vault, AWS Secrets Manager, Azure Key Vault) in Kubernetes Secrets synchronisiert. Er bietet einen deklarativen, GitOps-kompatiblen Ansatz: Die ExternalSecret-Custom-Resource in der GitLab/Kubernetes-Konfiguration deklariert, welche Secrets benötigt werden und woher sie kommen; der Operator übernimmt den Abruf und die Synchronisierung. Die vom Operator erstellten Kubernetes Secrets können normal in Pods gemountet werden.

Für GitLab-CI-Pipelines ermöglicht die GitLab-Vault-Integration (GitLab CI/CD Vault-Integration mit JWT-Authentifizierung) Pipeline-Jobs, sich bei Vault mit ihrer GitLab-JWT-Identität zu authentifizieren und Secrets für die Dauer des Pipeline-Jobs abzurufen. Secrets sind als Umgebungsvariablen innerhalb des Jobs verfügbar und werden nie in der GitLab-CI-Konfiguration oder im Repository gespeichert.