Worum es geht und warum es zur API-Sicherheit gehört

Ein Secret authentifiziert einen Aufrufer gegenüber einer API. Wer es kennt, gilt als legitimer Aufrufer - ein API-Key, ein Bearer-Token oder ein Datenbank-Connection-String ist also wie ein Passwort zu behandeln. Secrets-Management ist die organisierte Antwort auf das Risiko der Offenlegung (siehe Key-Leakage): das zentrale Erzeugen, Speichern, Bereitstellen, Auditieren und Rotieren dieser Geheimnisse, statt sie verstreut und hartkodiert zu halten.

Laut OWASP werden Secrets seit dem DevOps-Trend überall verwendet: API-Keys, Datenbank-Credentials, IAM-Berechtigungen, SSH-Keys und Zertifikate. Viele Organisationen kodieren sie im Klartext in den Quellcode oder verstreuen sie über Konfigurationsdateien. OWASP nennt daher ausdrücklich den wachsenden Bedarf, Speicherung, Provisionierung, Auditing, Rotation und Verwaltung zu zentralisieren, um Zugriff zu kontrollieren und Leaks zu verhindern.

Der Bezug zur API-Security ist direkt: Die OWASP API Security Top 10 zählen unter API2:2023 (Broken Authentication) unter anderem weak encryption keys und das Senden von Auth-Tokens in der URL zu den Schwachstellen, und API8:2023 (Security Misconfiguration) verlangt durchgängige TLS-Verschlüsselung und korrekt konfigurierte Berechtigungen auf Cloud-Diensten. Secrets-Management adressiert genau diese Punkte auf der Verteidigungsseite.

AspektStatisches Secret (z. B. fester API-Key)Dynamisches/kurzlebiges Secret
LebensdauerLang, oft unbegrenzt bis zur manuellen RotationKurz, an Session/Lease gebunden, läuft automatisch ab
Risiko bei DiebstahlGültig bis zur Rotation/zum WiderrufBeim nächsten Neustart bzw. Lease-Ende bereits abgelaufen
RotationSollte automatisiert erfolgen (z. B. AWS Secrets Manager, Lambda)Inhärent durch Neuerzeugung, z. B. Vault Secrets Engine
Typischer SpeicherortCloud-Secret-Manager oder Vault, nie im Code/GitVault/KMS erzeugt on demand, In-Memory-Bereitstellung
Empfehlung OWASPAkzeptabel mit Rotation und Least PrivilegeBevorzugt einsetzen, wo möglich

Statische vs. dynamische Secrets und Speicherorte

Zentralisieren und standardisieren: Vaults und Cloud-KMS

OWASP empfiehlt, die Secrets-Management-Lösung zu zentralisieren und zu standardisieren. In der Praxis heißt das: ein dediziertes System als Quelle der Wahrheit statt Secrets in .env-Dateien, CI-Variablen und Konfigurationsmanagement-Tools. Gängige Bausteine sind:

  • Dedizierte Vaults wie HashiCorp Vault oder CyberArk Conjur. In Vault stellen Secrets Engines Daten bereit; manche speichern nur, andere erzeugen dynamische Credentials on demand oder bieten Verschlüsselung als Dienst. Wird eine Secrets Engine deaktiviert, werden die zugehörigen Secrets - sofern unterstützt - widerrufen.
  • Cloud-KMS und Secret-Manager wie AWS Secrets Manager, Azure Key Vault und Google Secret Manager. OWASP rät, bei automatischer Rotation bevorzugt die Lösung des Cloud-Providers zu nutzen, da Einstiegshürde und Fehlkonfigurationsrisiko geringer sind.

Standardisierung kann mehrere Lösungen umfassen (Cloud-nativ plus eigenes System), solange die Interaktion einheitlich bleibt. Wichtig: Auch das Master-Secret der zentralen Lösung muss anderswo geschützt werden - etwa Root-Credentials des Cloud-Providers in einem zweiten System.

Kurzlebige und dynamische Credentials statt statischer Schlüssel

Der wirksamste Hebel ist, die menschliche Interaktion mit dem eigentlichen Secret zu reduzieren. OWASP nennt drei Wege:

  • Dynamische Secrets: Beim Start fordert eine Anwendung frische Credentials für ihre Session an. Werden gestohlene Datenbank-Credentials kompromittiert, sind sie laut OWASP beim nächsten Neustart bereits abgelaufen. Das verkleinert die Angriffsfläche der Credential-Wiederverwendung.
  • Automatisierte Rotation statischer Secrets: Manuelle Rotation ist fehleranfällig; sie sollte automatisiert werden. AWS Secrets Manager etwa bietet Managed Rotation oder Rotation per Lambda-Funktion in mehreren Schritten (neues Secret anlegen, setzen, testen, abschließen).
  • Secrets-Pipeline: Erzeugung und Rotation laufen über einen automatisierten Prozess, nicht über Hand.

Ergänzend gilt: Passwordless-Mechanismen wie OpenID Connect ersetzen nicht alle Secret-Typen (API-Keys, DB-Credentials bleiben), reduzieren aber die Angriffsfläche, da OIDC-Tokens typischerweise kurzlebig sind. Bearer-Tokens müssen dennoch geschützt werden: nur über TLS übertragen, nicht im Browser-LocalStorage ablegen, Signatur, Issuer und Audience validieren, kurze Laufzeiten und Refresh-Token-Rotation.

Lebenszyklus: Erzeugung, Rotation, Widerruf, Ablauf

OWASP beschreibt einen klaren Secret-Lebenszyklus, der durch Policies der zentralen Lösung durchgesetzt wird:

  • Erzeugung: kryptografisch robust und mit minimalen Rechten für den vorgesehenen Zweck; sichere Übertragung über einen authentifizierten Kanal.
  • Rotation: regelmäßig, damit gestohlene Credentials nur kurz gültig sind. Die Lebensdauer reicht je nach Funktion von Minuten bis Jahren. Maschinelle Secrets sollten regelmäßig rotieren; reine Benutzer-Credentials rotiert man laut NIST nur bei Verdacht auf Kompromittierung. Für kryptografisches Schlüsselmaterial liefert NIST SP 800-57 Part 1 die Grundlagen zu Kryptoperioden und Rotation.
  • Widerruf: nicht mehr benötigte oder potenziell kompromittierte Secrets sicher revozieren; bei TLS-Zertifikaten gehört Certificate Revocation dazu.
  • Ablauf: Secrets möglichst mit Ablaufdatum versehen; Anwendungen sollten vor dem Vertrauen prüfen, ob das Secret noch aktiv ist.

Querschnittlich gilt TLS überall - Secrets niemals im Klartext übertragen - sowie manipulationssicheres Auditing: Wer hat wann welches Secret für welches System/welche Rolle angefordert, wurde es genehmigt, wann benutzt, wann ist es abgelaufen, gab es Versuche, abgelaufene Secrets erneut zu nutzen.

Kein Hardcoding: Secrets aus Code, Git und Logs heraushalten

Secrets gehören weder in den ausgelieferten Client-/Mobile-Code noch in die Versionskontrolle noch in Logs. Konkret:

  • Nicht in Git einchecken: Auch nach dem Löschen bleibt ein Secret über die Git-Historie auffindbar. CI/CD-Werkzeuge sollten Secrets aus einem Secret-Manager beziehen; OWASP betont, dass das Speichern in der CI/CD-Tooling-Konfiguration (z. B. GitHub/GitLab Secrets) nicht dasselbe ist wie das Einchecken in Code, aber dennoch Härtung, Least Privilege, Logging und Rotation erfordert.
  • Nicht in URLs oder Query-Parametern: Sie landen in Server-, Proxy- und Browser-Logs. OWASP API2:2023 listet das Senden von Auth-Tokens in der URL ausdrücklich als Schwachstelle.
  • Nicht im Klartext loggen: Tokens, Passwörter, Connection-Strings und Encryption-Keys vor dem Logging maskieren oder entfernen.
  • CI/CD-Pipeline härten: wie ein Produktionssystem behandeln, Least-Privilege-Zugriff, sicherstellen, dass Pipeline-Output keine Secrets leakt und Forks keine Secrets kopieren.

Idealerweise berührt CI/CD das Secret gar nicht selbst, sondern weist nur die Orchestrierung (etwa Kubernetes) an, einen Dienst mit einem Service-Account zu starten, mit dem der Konsument das Secret selbst abruft - ein Muster, das auch dem Sidecar-Ansatz (z. B. Vault Agent, der Secrets in ein In-Memory-Volume schreibt) zugrunde liegt.

Least Privilege, Secret Scanning und Incident Response

Drei flankierende Disziplinen runden Secrets-Management ab:

Least Privilege und Access Control

Sobald ein Mensch ein Secret lesen oder ändern kann, kann es über diese Person leaken. OWASP fordert daher feingranulare Zugriffskontrollen pro Objekt: Engineers dürfen nicht auf alle Secrets zugreifen, und Erzeugung kann minimale Rechte direkt mitgeben. In der Cloud verkleinert striktes IAM den Blast Radius.

Secret Scanning (Detection)

Secret-Detection findet eingecheckte oder offengelegte Secrets, bevor oder nachdem sie ins Repository gelangen. GitHub Secret Scanning erkennt bekannte Secret-Typen in Repositories; Push Protection blockiert das Einbringen erkannter Secrets bereits beim Push. Quelloffene Scanner wie Gitleaks oder TruffleHog lassen sich in Pre-Commit-Hooks und Pipelines einbinden.

Incident Response

Für den Fund eines geleakten Secrets braucht es einen dokumentierten Prozess: sofortige Rotation oder Widerruf, Prüfung auf Missbrauch über die Audit-Logs und Behebung der Ursache. Kurze Rotationsintervalle und dynamische Secrets begrenzen das Zeitfenster, in dem ein gestohlenes Secret überhaupt nutzbar ist.

Quellen

Weiterlesen
AngriffAPI-Secrets & Key-Leakage GrundlagenAPI-Authentifizierung OWASP API8Security Misconfiguration