Was ist Secrets Management?

Secrets Management umfasst das sichere Erzeugen, Speichern, Verteilen, Verwenden, Rotieren und Widerrufen vertraulicher Maschinenzugänge. Dazu gehören API-Schlüssel, Datenbankpasswörter, private Schlüssel, Tokens, Zertifikate und Signing Keys. Ein Secret im privaten Git-Repository oder Container-Image ist nicht sicher: Kopien entstehen in Historie, CI-Logs, Caches, Backups und Entwicklergeräten.

Unsicheres und besseres Beispiel

// Unsicher: Secret ist Teil von Quellcode und Buildartefakt
const client = new ApiClient({
  token: 'prod_live_abc123...'
});

// Besser: kurzlebige Identität oder Laufzeit-Injection
const token = await workloadIdentity.getAccessToken({
  audience: 'payments-api',
  ttl: '10m'
});
const client = new ApiClient({ token });

Eine Umgebungsvariable ist besser als fest codierter Quellcode, aber noch kein vollständiges Secrets Management. Sie kann in Prozess-Dumps, Diagnoseausgaben oder Fehlkonfigurationen erscheinen. Wo möglich, sollten Workload Identities kurzlebige Zugangsdaten ohne statisches Secret ausstellen.

Lebenszyklus eines Secrets

1. Erzeugen:
   Kryptografisch zufällig, zweckgebunden und mit minimalen Rechten.
2. Speichern:
   Verschlüsselt in einem zentralen Secret Store oder Hardwaremodul; kein Klartext in Repositories.
3. Ausliefern:
   Erst zur Laufzeit an authentifizierte Workloads, über geschützte Kanäle und ohne unnötige Kopien.
4. Überwachen:
   Zugriffe, Fehler und ungewöhnliche Nutzung protokollieren, ohne den Secretwert selbst zu loggen.
5. Rotieren/Widerrufen:
   Regelmäßig und sofort bei Verdacht; Anwendungen müssen überlappende Schlüssel sicher unterstützen.

Was tun bei einem veröffentlichten Secret?

Zuerst widerrufen oder rotieren – das Löschen des Commits reicht nicht. Danach Nutzung und Logs prüfen, abhängige Systeme identifizieren und mögliche Persistenz untersuchen. Erst anschließend kann die Historie bereinigt werden. Der alte Wert muss dauerhaft als kompromittiert gelten, auch wenn das Repository privat war oder nur kurz öffentlich zugänglich wurde.

Nützliche Open-Source-Werkzeuge

Gitleaks und TruffleHog suchen in Dateien und Git-Historie nach Secrets; TruffleHog kann viele Fundtypen zusätzlich verifizieren. detect-secrets eignet sich als Pre-Commit-Baseline. Für den Betrieb stehen unter anderem HashiCorp Vault und Plattformlösungen zur Verfügung. Scanner erzeugen Fehlalarme und finden keine selbst entwickelten Formate ohne passende Regeln; sie sollten in Commit, CI und periodischen Scans kombiniert werden.