Skip to content

Wie sollten Secrets wie API-Schlüssel und Datenbankpasswörter in einer Anwendung verwaltet werden?

Kurzantwort

Secrets niemals fest im Quellcode codieren oder in Git committen. In einem dedizierten Secrets Manager oder Vault speichern, zur Laufzeit injizieren, den Zugriff mit geringsten Rechten begrenzen, regelmäßig rotieren und kurzlebige dynamische Anmeldeinformationen langlebigen statischen vorziehen. Jeden Zugriff auditieren.

Secrets – API-Schlüssel, DB-Passwörter, Signaturschlüssel, Tokens – sind hochwertige Ziele, weil ein einziges geleaktes Secret ganze Systeme aufschließen kann. Sie gut zu verwalten bedeutet vor allem, sie aus den Orten herauszuhalten, an denen sie üblicherweise lecken, und den Schaden zu begrenzen, falls eines doch leckt.

Die oberste Regel: nicht im Code

Secrets dürfen niemals im Quellcode, in versionierten Konfigurationsdateien, in Container-Images oder in clientseitigen Bundles liegen. Die Git-Historie ist für immer – ein einmal committetes Secret ist selbst nach dem Löschen kompromittiert, es muss also rotiert, nicht nur entfernt werden. Secrets in eine kompilierte Binärdatei einzubetten hilft ebenfalls nicht; sie lassen sich trivial extrahieren.

Zentralisieren und injizieren

Speichere Secrets in einem zweckgebauten Secrets Manager oder Vault (HashiCorp Vault, AWS Secrets Manager, KMS-gestützte Cloud-Speicher). Die Anwendung holt sie zur Laufzeit über eine authentifizierte Identität, oder sie werden von der Plattform als Umgebungsvariablen/eingehängte Dateien injiziert. Das zentralisiert Kontrolle, Verschlüsselung und Auditing.

Den Wirkungsradius begrenzen

  • Geringste Rechte: Jeder Dienst kann nur die spezifischen Secrets lesen, die er benötigt.
  • Rotation: Rotiere Secrets nach Zeitplan und sofort bei vermuteter Offenlegung.
  • Kurzlebige dynamische Anmeldeinformationen: das beste Muster – der Vault erzeugt bei Bedarf eine Anmeldeinformation, die in Minuten abläuft, sodass ein geleaktes Secret fast sofort nutzlos ist und es nichts Langlebiges zu stehlen gibt.
  • Audit-Logging: Protokolliere jeden Secret-Zugriff, um Missbrauch zu erkennen.

Das Bootstrapping-Problem

Es gibt immer ein »Secret Zero« – die initiale Anmeldeinformation, mit der sich eine App beim Vault authentifiziert. Löse es mit plattformseitiger Workload Identity (Instanzrollen, OIDC-Föderation, mTLS) statt mit noch einem weiteren statischen Secret.

Worauf Interviewer achten

Die Grundlage lautet »niemals fest codieren, einen Vault verwenden«. Das Signal auf mittlerem Niveau sind Rotation, Begrenzung auf geringste Rechte und vor allem das Bevorzugen kurzlebiger dynamischer Anmeldeinformationen, ergänzt um das Bewusstsein für die Secret-Zero-Bootstrapping-Herausforderung.

Wahrscheinliche Anschlussfragen

  • Warum sind kurzlebige dynamische Anmeldeinformationen besser als statische?
  • Ein Secret ist in die Git-Historie gelangt – was tust du?
  • Wie löst du das Bootstrapping-Problem des »Secret Zero«?

Quellen

Zertifizierungen

Erhalte 100 Cybersecurity-Interviewfragen + Antworten

Gib deine E-Mail-Adresse ein und wir senden dir das kostenlose PDF-Paket und das Flashcard-Deck.

Kein Spam. Jederzeit abbestellbar.