Secrets Management: Schluss mit hartkodierten API-Keys

Jeder Post-Mortem-Bericht nach einem Sicherheitsvorfall enthält ein vertrautes Kapitel: Jemand hat Zugangsdaten gefunden. In einem Repository, in einem Docker-Layer, in einem CI-Log, in einem Screenshot, der in Slack gepostet wurde. Secrets Management ist kein Hygiene-Theater für das nächste Audit. Es ist der Unterschied zwischen einem eingedämmten Vorfall und einem Angreifer, der die Schlüssel zu Ihrer Produktionsdatenbank in der Hand hält. Und sobald dort personenbezogene Daten liegen, ist es zusätzlich ein Fall für Ihren Datenschutzbeauftragten.

Warum hartkodierte Secrets nie geheim bleiben

Ein Secret, das im Code committet wurde, ist kein Secret mehr. Es ist eine Zeitbombe mit öffentlichen Sichtbarkeitseinstellungen.

Hier leaken sie tatsächlich:

• Git-Historie. Den Key in einem neuen Commit zu löschen bringt nichts. Der alte Blob lebt im Objektspeicher weiter, in jedem Clone, in jedem Fork und in den Caches Ihrer CI-Runner. git log -p findet ihn in Sekunden.
• Docker-Image-Layer. COPY .env . gefolgt von RUN rm .env liefert das Secret trotzdem aus. Layer sind additiv. Jeder mit Pull-Zugriff kann docker history ausführen und es extrahieren.
• CI-Logs. Ein vergessenes env | sort in einem Debug-Schritt, ein Framework, das beim Start seine Konfiguration ausgibt, ein Test-Runner, der bei Fehlern die Umgebung dumpt. Logs werden aufbewahrt, weitergeleitet und indexiert.
• Client-Bundles. Frontend-Builds inlinen alles, was als öffentlich markiert ist. Wir sehen regelmäßig Server-Keys im Browser, weil jemand eine Variable umbenannt hat, damit der Build durchläuft.
• Synchronisation durch Dritte. Editor-Plugins, Backup-Tools und KI-Coding-Assistenten, die Ihren Workspace indexieren, indexieren .env gleich mit. Wo diese Daten anschließend liegen, weiß in der Regel niemand so genau.

Automatisierte Scanner überwachen den öffentlichen GitHub-Event-Stream rund um die Uhr. Nach unserer Erfahrung wird ein exponierter Cloud-Key in einem öffentlichen Repository innerhalb von Minuten angetestet, nicht innerhalb von Tagen. Kryptominer auf der AWS-Rechnung sind meist der Moment, in dem Teams es bemerken.

Das Bedrohungsmodell, nüchtern formuliert

Sie verteidigen sich gegen drei Dinge:

1. Exfiltration: Ein Angreifer liest das Secret dort aus, wo es notiert wurde.
2. Replay: Ein Angreifer, der das Secret besitzt, nutzt es, von überall, solange es gültig bleibt.
3. Schadensradius: Ein einziges geleaktes Credential öffnet weit mehr Türen, als es dürfte.

Jede Maßnahme in diesem Artikel greift genau eines dieser drei Probleme an. Verschlüsselung im Ruhezustand bekämpft Exfiltration. Kurze TTLs bekämpfen Replay. Eng zugeschnittene Zugangsdaten pro Service bekämpfen den Schadensradius. Wenn sich ein Werkzeug keinem der drei klar zuordnen lässt, ist es Dekoration. Diese Prüfung erspart Ihnen die meisten Anbieterpräsentationen.

Die Reifegrad-Leiter

Springen Sie nicht direkt zum eigenen Vault-Cluster. Steigen Sie die Leiter bewusst Stufe für Stufe.

Stufe 0: .env-Dateien in der .gitignore

Das Fundament, nicht das Ziel. Vertretbar für einen Solo-Prototyp. Die Secrets liegen im Klartext auf jedem Laptop, es gibt keinen Audit-Trail, keine Rotation, und beim Offboarding eines Engineers bleibt nur die Hoffnung, dass er die Datei löscht.

Stufe 1: Secret Stores der Plattform

Nutzen Sie den Store, den Ihre Plattform ohnehin mitbringt: AWS Secrets Manager oder SSM Parameter Store, GCP Secret Manager, Azure Key Vault oder die verschlüsselten Secrets in Vercel, Fly.io oder GitHub Actions. Secrets sind im Ruhezustand verschlüsselt, werden zur Laufzeit injiziert, und der Zugriff läuft über IAM. Für die meisten Teams unter 20 Engineers schlägt diese Stufe, sauber umgesetzt, jedes schlecht betriebene Vault.

Zwei Disziplinen gehören auf diese Stufe. Erstens: Die Anwendung liest Secrets beim Start aus der Umgebung oder über das SDK, niemals aus einer Datei im Repository. Zweitens, und in der DACH-Region kein Randthema: Der Speicherort ist eine Datenschutzfrage. Wählen Sie bewusst EU-Regionen wie Frankfurt oder Zürich und dokumentieren Sie im Rahmen der Auftragsverarbeitung, welcher Anbieter theoretisch Zugriff hätte.

Stufe 2: zentrale Secrets mit Zugriffskontrolle und Audit

Ein System of Record für jedes Secret in jeder Umgebung. HashiCorp Vault, OpenBao (der Open-Source-Fork), Infisical oder Doppler. Was Sie gegenüber Stufe 1 gewinnen:

• Einheitlichkeit: eine API und eine Policy-Sprache über AWS, GCP, On-Premises und CI hinweg.
• Audit: Jeder Lesezugriff wird mit Identität, Pfad und Zeitstempel protokolliert. Wenn ein Key leakt, ist das Audit-Log das Werkzeug, mit dem Sie den Vorfall eingrenzen.
• Policy: Der Billing-Service darf billing/* lesen und sonst nichts, zentral durchgesetzt.

Vault und OpenBao lassen sich zudem vollständig selbst betreiben. Für Organisationen mit harten Anforderungen an Datenhoheit und Hosting-Standort, ob aus DSGVO-Gründen, wegen des Schweizer revDSG oder aus Prinzip, ist genau das oft der Ausschlag.

Stufe 3: dynamische, kurzlebige Zugangsdaten

Das Endspiel. Statische Secrets existieren gar nicht mehr. Zugangsdaten werden auf Anfrage ausgestellt, sind an genau eine Identität gebunden und verfallen nach Minuten oder Stunden. Ein geleaktes Credential ist auf dieser Stufe ein Ärgernis, kein Sicherheitsvorfall.

Dynamische Secrets: das Ende des statischen Credentials

Die Database Secrets Engine von Vault zeigt das Muster am klarsten. Statt eines gemeinsamen DB_PASSWORD, das an zwölf Stellen liegt, fordert jede Service-Instanz beim Start ihren eigenen Benutzer an:

vault write database/roles/app-readonly \
  db_name=postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
    VALID UNTIL '{{expiration}}'; \
    GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" max_ttl="24h"

Jeder Lesezugriff auf database/creds/app-readonly erzeugt eine frische Postgres-Rolle, die sich nach einer Stunde selbst zerstört. Die Eigenschaften, die Sie dabei geschenkt bekommen:

• Zuordenbarkeit. Langsame Query von v-k8s-app-readonly-x7Hf? Sie wissen exakt, welcher Pod sie abgesetzt hat.
• Sofortiger Widerruf. Lease widerrufen, und das Credential stirbt jetzt, nicht erst beim nächsten Deploy.
• Wertlose Leaks. Ein Credential auf einem Screenshot aus einer Debug-Session ist abgelaufen, bevor es jemand verwenden kann.

Dasselbe Muster existiert für AWS-STS-Credentials, GCP-Service-Account-Keys, SSH-Zertifikate und PKI. Der Preis ist real: Ihre Datenbank muss den Rollen-Churn vertragen, Connection Pooler brauchen Re-Authentifizierungslogik, und Vault wird zu Tier-Zero-Infrastruktur. Womit wir bei den Fallstricken wären.

Das Secret-Zero-Problem und andere Fallstricke

Teams führen einen Vault ein und stolpern dann über dieselben vier Dinge:

• Secret Zero. Die Anwendung braucht ein Credential, um mit dem Vault zu sprechen. Ist dieses Credential ein statisches Token in einer Umgebungsvariablen, haben Sie das Problem verschoben, nicht gelöst. Die Lösung ist Plattform-Identität: Kubernetes-Service-Account-Tokens, AWS-IAM-Auth, GCP Instance Identity. Der Workload beweist seine Identität mit etwas, das die Plattform attestiert, nicht mit etwas, das ein Mensch irgendwo hineinkopiert hat.
• Der Vault als Single Point of Failure. Wenn Vault ausfällt und Ihre Pods nicht mehr starten, haben Sie ein Sicherheitswerkzeug in einen Verfügbarkeitsvorfall verwandelt. Betreiben Sie es mit echter Hochverfügbarkeit, cachen Sie Leases clientseitig und setzen Sie TTLs lang genug, um einen kurzen Ausfall zu überstehen.
• Der Rückfall in den Wildwuchs. Engineers unter Termindruck kopieren Secrets aus dem Vault zurück in .env-Dateien, "nur vorübergehend". Machen Sie den sanktionierten Weg zum einfachsten Weg: SDK-Integration, Sidecar-Injection oder templatierte Dateien zum Deploy-Zeitpunkt.
• Audit-Logs, die niemand liest. Ein Audit-Log ohne Alarme ist ein Compliance-Artefakt, mehr nicht. Alarmieren Sie bei Lesezugriffen von ungewöhnlichen Identitäten, bei Massenzugriffen und bei jeder Nutzung des Root-Tokens.

CI/CD: keine Cloud-Keys mehr in der Pipeline

CI ist der Ort, an dem statische Credentials gestohlen werden. Ein langlebiger AWS_SECRET_ACCESS_KEY in den Pipeline-Einstellungen ist lesbar für jeden Maintainer, jede kompromittierte Action und jede Abhängigkeit mit einem Postinstall-Skript.

Die zeitgemäße Antwort heißt OIDC-Föderation. Der CI-Anbieter stellt pro Job ein signiertes, kurzlebiges Identitätstoken aus, und Ihre Cloud vertraut diesem Token direkt. Es existiert kein gespeicherter Key mehr, den man stehlen könnte:

permissions:
  id-token: write
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/deploy-prod
      aws-region: eu-west-1

Schränken Sie die IAM-Trust-Policy auf Ihre exakte Organisation, Ihr Repository und Ihren Branch ein. Ein Job auf main in Ihrem Repository darf deployen; ein Job auf einem Fork darf es nicht, kryptografisch abgesichert. GitHub Actions, GitLab CI und CircleCI unterstützen das gegen AWS, GCP und Azure. Wenn Sie die Sicherheit Ihrer Pipeline breiter aufstellen wollen, ordnet unser DevSecOps-Pipeline-Leitfaden ein, wo der Umgang mit Secrets in der Gesamtkette sitzt.

Leaks abfangen, bevor sie ausgeliefert werden

Prävention schlägt Reaktion, und die Werkzeuge kosten nichts. Spannen Sie drei Netze übereinander:

1. Pre-Commit-Scanning. Gitleaks läuft auf einem gestagten Diff in unter einer Sekunde:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.0
    hooks:
      - id: gitleaks

2. Push Protection. GitHub Secret Scanning mit Push Protection blockiert den Push serverseitig, sobald ein bekanntes Credential-Muster erkannt wird. Aktivieren Sie es für jedes Repository, private eingeschlossen. GitLab bietet ein Äquivalent.

3. Historien- und Artefakt-Scans. Lassen Sie TruffleHog oder Gitleaks regelmäßig über die vollständige Git-Historie, Container-Images und Build-Artefakte laufen. Verifizierte Treffer (der Scanner prüft beim Anbieter, ob der Key tatsächlich aktiv ist) reduzieren das False-Positive-Rauschen drastisch.

Nichts davon ersetzt ein Design, bei dem Secrets von vornherein eng zugeschnitten sind. Unser Beitrag zu Best Practices der API-Sicherheit geht auf Key-Scoping und Rotation an der API-Grenze tiefer ein.

Wenn ein Key trotzdem leakt: die erste Stunde

Gehen Sie davon aus, dass es passieren wird. Das Playbook, in dieser Reihenfolge:

1. Erst widerrufen, dann untersuchen. In dem Moment, in dem die Exposition bestätigt ist, wird das Credential deaktiviert. Warten Sie nicht auf ein Wartungsfenster. Verfügbarkeitsschmerzen sind reparabel, exfiltrierte Daten nicht.
2. Ersatz ausstellen. Das neue Credential kommt aus dem Secret Manager und ist enger zugeschnitten als das alte. Das ist der Moment, die überbreiten Berechtigungen zu korrigieren, die Sie ohnehin längst korrigieren wollten.
3. Schaden eingrenzen. Ziehen Sie die Audit-Logs für das gesamte Expositionsfenster des Credentials, nicht erst ab der Entdeckung. In AWS heißt das: CloudTrail-Abfragen auf die Access-Key-ID. Suchen Sie nach unbekannten IPs, Regionen und API-Aufrufen. Das Ergebnis entscheidet auch über Ihre Meldepflichten: Sind personenbezogene Daten abgeflossen, läuft nach Art. 33 DSGVO die 72-Stunden-Frist für die Meldung an die Aufsichtsbehörde.
4. Bereinigen, aber als verbrannt behandeln. Schreiben Sie die Historie mit git filter-repo um und pushen Sie mit Force, aber verstehen Sie das als Aufräumen, nicht als Behebung. Clones und Forks haben den Key weiterhin. Das Credential ist ohnehin tot, genau dafür war Schritt 1 da.
5. Den Weg reparieren, nicht die Person. Das Secret wurde committet, weil der sichere Weg mühsamer war als der unsichere. Ergänzen Sie den Pre-Commit-Hook, binden Sie den Secret Manager an, schließen Sie die Lücke. Eine Schuldzuweisung produziert nur das nächste vertuschte Leak.

Wenn dieses Vorgehen bei Ihnen nicht schriftlich vorliegt und geprobt ist, bevor Sie es brauchen, beginnen Sie mit unserem Incident-Response-Playbook.

Ein Entscheidungsrahmen

Wählen Sie das Werkzeug passend zum Team, nicht passend zum Konferenzvortrag:

• Solo oder Kleinstteam, eine Cloud: der Secret Manager Ihrer Cloud plus OIDC in der CI. Ein Nachmittag Arbeit, der Großteil des Nutzens.
• Wachsendes Team, ein bis zwei Clouds, Kubernetes: Cloud Secret Manager als Backend, External Secrets Operator synchronisiert in den Cluster, Push Protection auf jedem Repository.
• Multi-Cloud, Compliance-Anforderungen, 24/7-Workloads: Vault oder OpenBao mit Plattform-Identität als Auth, dynamische Credentials für Datenbanken und Cloud-Zugriff, Alarme auf dem Audit-Log.
• Regulierte Branchen oder lohnende Ziele (NIS2, DORA, ISO 27001, BSI-Grundschutz): alles Vorgenannte, plus kurze TTLs als Policy, vierteljährliche Leak-Übungen und eine Rotation, die durch Automatisierung verifiziert wird statt durch einen Kalendereintrag.

Welche Stufe Sie auch wählen, drei Regeln gelten universell. Kein Secret in Git, niemals. Kein Secret, das zwei Services teilen. Jedes Secret hat einen Verantwortlichen, einen Geltungsbereich und ein Ablaufdatum, das jemand aus dem Stegreif nennen kann.

Wie Innovation T unterstützen kann

Innovation T konzipiert und betreibt Secrets-Infrastruktur für Teams in ganz Europa und Nordafrika: Vault- und OpenBao-Deployments mit echter Hochverfügbarkeit, OIDC-Föderation für CI/CD, dynamische Datenbank-Credentials und Leak-Erkennung, die in die Pipeline eingebaut ist statt nach einem Vorfall angeschraubt. Wir haben Teams ohne einen einzigen Produktionsausfall von hartkodierten Keys wegmigriert, und wir hinterlassen Runbooks, mit denen Ihre Engineers tatsächlich arbeiten.

Wenn Ihre .env-Dateien nur einen gestohlenen Laptop von einem meldepflichtigen Vorfall entfernt sind, sprechen Sie mit uns. Werfen Sie einen Blick auf unsere Leistungen oder nehmen Sie Kontakt auf für ein Review Ihrer Secrets-Posture.