Ein praxisnaher Plan für das Secrets Management selbst gehosteter Anwendungen

Warum Secrets Management eine betriebliche und nicht nur eine Sicherheitsanforderung ist

Eine selbst gehostete Anwendung läuft selten mit nur einer Zugangsinformation. Sie kann ein Datenbankkonto, ein SMTP-Passwort, API-Token von Drittanbietern, Webhooks, Signaturmaterial und einen oder mehrere Verschlüsselungsschlüssel benötigen. Sind diese Werte nicht verwaltet, wird die Routinearbeit riskant: Eine Bereitstellung lässt sich schwerer reproduzieren, nach dem Ausscheiden von Mitarbeitenden bleiben Zugriffsrechte unklar, und ein vermuteter Sicherheitsvorfall kann zu einer dringenden Störung werden.

Ein hilfreicher Prozess für das Secrets Management macht autorisierte Arbeit vorhersehbar. Das Team weiß, wofür jedes Secret dient, wer dafür verantwortlich ist, wo es bereitgestellt wird, welche Anwendung davon abhängt und wie es ersetzt werden kann. Dies steht im Einklang mit dem NIST Cybersecurity Framework 2.0, das verlangt, Rollen, Verantwortlichkeiten und Befugnisse für das Cybersicherheitsrisikomanagement festzulegen, zu kommunizieren, zu verstehen und durchzusetzen.

Verwaltete Infrastruktur kann den betrieblichen Aufwand rund um eine Anwendung reduzieren, regelt aber nicht die Governance von Zugangsdaten. Airbip stellt beispielsweise Kataloganwendungen als Docker-Workloads auf seinen Cloud-Servern bereit und automatisiert Routing sowie TLS-Zertifikate über Traefik und Let's Encrypt. Kunden müssen weiterhin entscheiden, wer die Anwendungszugangsdaten erstellen, genehmigen, einsehen und rotieren darf, die diese Workloads mit Datenbanken und externen Diensten verbinden.

• Behandeln Sie jedes Produktions-Secret als betriebliche Abhängigkeit mit einer verantwortlichen Person.
• Entwerfen Sie Ersatzverfahren, bevor bei einem Secret dringend ein Sicherheitsvorfall vermutet oder bestätigt wird.
• Trennen Sie nach Möglichkeit die Verantwortung für die Infrastrukturadministration von der geschäftlichen Genehmigung sensibler Drittanbieterkonten.

Was als Secret gilt

Ein Secret ist eine Information, deren Offenlegung unbefugten Zugriff, Identitätsvortäuschung, Entschlüsselung oder privilegierte Aktionen ermöglichen könnte. Ein geheimer Schlüssel ist beispielsweise ein kryptografischer Schlüssel, der nicht öffentlich ist; seine Vertraulichkeit ist für seinen Zweck grundlegend.

Beschränken Sie das Register nicht auf Werte, die wörtlich PASSWORD heißen. Eine Verbindungszeichenfolge kann einen Benutzernamen und ein Passwort enthalten. Ein Konfigurationsexport kann ein Integrations-Token enthalten. Ein privater Schlüssel, ein Wert zur Cookie-Signierung, ein OAuth-Client-Secret oder ein Wiederherstellungscode kann folgenreicher sein als ein herkömmliches Passwort.

Im Gegensatz dazu ermöglicht gewöhnliche Konfiguration bei Offenlegung in der Regel keinen Zugriff. Beispiele sind die öffentliche URL einer Anwendung, eine nicht sensible Funktionseinstellung, ein Gebietsschema oder die Wahl der Protokollierungsstufe. Die Klassifizierung sollte darauf beruhen, was eine Offenlegung ermöglicht, und nicht auf dem Namen einer Umgebungsvariable.

• Datenbank-Benutzernamen und -Passwörter, einschließlich Zugangsdaten in Verbindungszeichenfolgen.
• API-Token, Webhook-Secrets und OAuth-Client-Secrets, die von Integrationen verwendet werden.
• SMTP-Benutzernamen und -Passwörter zum Versand von Anwendungs-E-Mails.
• Werte zur Sitzungssignierung, private Schlüssel und andere Signaturschlüssel.
• Verschlüsselungsschlüssel, Schlüsselverschlüsselungsmaterial und Wiederherstellungscodes.
• Administratorpasswörter und Zugriffstoken für Anwendungs-, Server- oder Drittanbieterdienstkonten.

Secrets vor der Bereitstellung von nicht sensibler Konfiguration trennen

Erstellen Sie vor der Bereitstellung zwei Listen: Konfiguration, die in gewöhnlicher Bereitstellungsdokumentation enthalten sein kann, und Werte, die eingeschränkt behandelt werden müssen. Dieser kleine Schritt verhindert einen häufigen Fehler, bei dem eine bequeme .env-Datei zur informellen Quelle der Wahrheit für alles wird, einschließlich Produktionszugangsdaten.

Nutzen Sie für Docker-basierte Bereitstellungen eine getrennte Methode zur Bereitstellung von Secrets, sofern die Anwendung dies unterstützt. Docker empfiehlt, in Compose-Bereitstellungen für sensible Werte Secrets statt Umgebungsvariablen zu verwenden. Compose-Secrets werden auf oberster Ebene deklariert und anschließend einzelnen Diensten ausdrücklich zugewiesen; ein Dienst kann nicht auf ein deklariertes Secret zugreifen, sofern seine eigene Definition diese Zuweisung nicht enthält.

Docker-Secrets werden als Dateien eingebunden, statt direkt als Umgebungsvariablen gesetzt zu werden, normalerweise unter /run/secrets. Dieser Ansatz kann einschränken, welcher Dienst einen Wert erhält. Er ersetzt nicht die Notwendigkeit, den Host, die Bereitstellungskonfiguration oder Personen mit administrativem Zugriff abzusichern, und die Anwendung muss das Secret in der bereitgestellten Form lesen können.

Vermeiden Sie es, Build-Zugangsdaten in Docker-Build-Argumente oder Umgebungsvariablen aufzunehmen. Docker weist darauf hin, dass diese im finalen Image erhalten bleiben können. Verwenden Sie Secret-Mounts oder SSH-Mounts für Zugangsdaten, die nur während eines Builds benötigt werden. Schließen Sie außerdem .env-Dateien über .dockerignore aus dem Build-Kontext aus, wenn sie Secrets enthalten könnten; andernfalls können sie in eine Image-Schicht aufgenommen werden.

• Klassifizieren Sie jeden Bereitstellungswert, bevor Sie ihn zu einer Compose-Datei, einem CI-Job oder einem Administrationspanel hinzufügen.
• Weisen Sie ein Docker-Compose-Secret nur dem Dienst zu, der es benötigt.
• Prüfen Sie die Konfigurationsdokumentation der Anwendung, um festzustellen, ob sie ein Secret aus einer Datei, einer Umgebungsvariable oder über einen anderen Mechanismus annimmt.
• Überprüfen Sie Dockerfiles, Build-Kontexte und die Image-Historie, wenn jemals Zugangsdaten zur Build-Zeit verwendet wurden.

Jeden Ort erfassen, an dem ein Secret offengelegt werden kann

Ein Secret ist nur so gut geschützt wie jede einzelne Kopie davon. Die Bereitstellungsdatei ist nur ein Ort, der überprüft werden muss. Build-Artefakte, ein Entwickler-Laptop, eine archivierte Supportanfrage oder eine exportierte Konfiguration können unbemerkt zu weiteren Kopien werden, die länger als die vorgesehenen Zugangsdaten bestehen bleiben.

Erstellen Sie für jedes hochwertige Secret eine Karte der Offenlegungsorte. Erfassen Sie sowohl beabsichtigte Ablageorte wie einen eingeschränkten Secret-Speicher als auch mögliche unbeabsichtigte Orte wie Shell-Verlauf, Screenshots oder Fehlerberichte. Die Karte ist insbesondere bei der Reaktion auf Sicherheitsvorfälle wertvoll, weil sie dem Team zeigt, was nach einer Rotation überprüft werden muss.

Protokolle verdienen besondere Aufmerksamkeit. OWASP ASVS weist darauf hin, dass Zugangsdaten und Zahlungsdetails in Protokollen möglicherweise verboten sind, während Sitzungstoken unter Umständen gehasht oder maskiert werden müssen. Zudem fordert es ein Inventar der Dateien und Dienste, in denen Protokolle gespeichert oder an die sie übertragen werden. Behandeln Sie Protokollziele, Fehlertracker und Supportkanäle als Teil der Secret-Grenze.

• Quellcode-Repositories, einschließlich eingecheckter .env-Dateien, Beispiele und historischer Commits.
• Compose-Dateien, CI/CD-Variablen, Shell-Verlauf und Befehlszeilenausgaben.
• Container-Protokolle, Reverse-Proxy-Protokolle, Anwendungsfehlerberichte und externe Protokolldienste.
• Supporttickets, Chatnachrichten, E-Mails, Screenshots und kopierte Terminalausgaben.
• Backups, Datenbank-Dumps, Konfigurationsexporte und alte Server-Snapshots.
• Administratorcomputer, Tresore von Passwortmanagern, Browsersitzungen und Wechselmedien.

Ein Verantwortungsmodell wählen, bevor Zugriffe erteilt werden

Kleine Teams bündeln Verantwortlichkeiten oft in einem einzigen Administratorkonto. Das kann zweckmäßig sein, erschwert aber Genehmigungen, Wiederherstellung und Offboarding. Weisen Sie stattdessen für jedes wesentliche Secret namentlich definierte Rollen zu, auch wenn eine Person vorübergehend mehr als eine Rolle innehat.

Ein praktisches Modell trennt Anwendungsverantwortliche, Infrastrukturadministration und Verantwortliche für Drittanbieterdienste. Die anwendungsverantwortliche Person entscheidet, ob eine Integration benötigt wird, und akzeptiert deren geschäftliches Risiko. Die Infrastrukturadministration stellt dem laufenden Dienst genehmigte Konfiguration bereit und verwaltet den Zugriff auf die Bereitstellung. Die für Drittanbieterdienste verantwortliche Person verwaltet das Konto beim externen Anbieter, das die Zugangsdaten ausgestellt hat, etwa bei einem E-Mail-Anbieter oder einer API-Plattform.

NIST-Leitlinien unterstützen die Definition von Rollen und die Beschränkung privilegierter Konten auf festgelegte Personen oder Rollen. Soweit möglich, sollten Administratoren für ihre gewöhnliche Arbeit nicht privilegierte Konten verwenden und privilegierten Zugriff Aufgaben vorbehalten, die ihn erfordern.

• Anwendungsverantwortliche Person: genehmigt Zweck, Datennutzung und geschäftliche Notwendigkeit.
• Infrastrukturadministration: stellt genehmigte Werte bereit und kontrolliert den Zugriff auf Plattformebene.
• Verantwortliche Person für Drittanbieterdienste: verwaltet das Konto beim externen Anbieter, die Abrechnungsbeziehung und die Ausstellung von Zugangsdaten.
• Sicherheits- oder Betriebsrevision: bestätigt regelmäßig Zugriff, Ablauf, Rotationsstatus und Wiederherstellungsbereitschaft.

Secrets sicher speichern und bereitstellen

Wählen Sie den schlanksten Prozess, der Offenlegung zuverlässig begrenzt und Wiederherstellung unterstützt. Die beste Option hängt von Teamgröße, Anzahl der Anwendungen, Personalwechseln, Compliance-Anforderungen und der Häufigkeit von Änderungen an Zugangsdaten ab. Ein ausgereiftes Secret-System ist nicht automatisch der richtige erste Schritt, wenn das Team es nicht konsistent betreiben kann.

Ein verschlüsselter Secret-Speicher mit individuellen Benutzerzugängen ist im Allgemeinen eine gute Wahl, wenn mehrere Personen kontrollierten Zugriff auf ein wachsendes Inventar benötigen. Eingeschränkte Bereitstellungskonfiguration ist nützlich, wenn der Bereitstellungsmechanismus begrenzen kann, wer einen Wert lesen oder ändern darf. Ein manueller Eingabeprozess kann für eine kleine Zahl seltener Änderungen geeignet sein, sofern der Prozess erfasst, wer das Secret eingegeben hat, wo es eingegeben wurde und wie der Wert wiederhergestellt wird.

Vermeiden Sie es, ein gemeinsam genutztes Klartextdokument, einen uneingeschränkten Teamchat oder ein Repository als primären Speicher für Produktions-Secrets zu behandeln. Gehen Sie außerdem nicht davon aus, dass ein Compose-Secret ein vollständiger Tresor ist: Compose kann Secret-Inhalte aus einer Host-Datei oder in Docker Compose aus einer Host-Umgebungsvariable beziehen. Diese Quellorte benötigen eigene Zugriffskontrollen. Auf Umgebungsvariablen basierende Compose-Secrets werden von docker stack deploy nicht unterstützt.

• Verwenden Sie einen verschlüsselten Secret-Speicher mit individuellen Konten, wenn mehrere Personen Zugriff benötigen oder Nachvollziehbarkeit wichtig ist.
• Nutzen Sie eingeschränkte Bereitstellungseinstellungen, wenn nur eine kleine administrative Gruppe Werte an Workloads liefern soll.
• Nutzen Sie einen dokumentierten manuellen Prozess nur für Änderungen mit geringem Volumen und klarer Genehmigung, sicherer Übertragung und Wiederherstellungsschritten.
• Hinterlegen Sie in der Bereitstellungsdokumentation einen Verweis auf die Register-ID des Secrets, nicht seinen tatsächlichen Wert.

Least Privilege auf Datenbanken, E-Mail-Dienste, APIs und Integrationen anwenden

Least Privilege bedeutet, Nutzern und Prozessen nur die Berechtigungen zu geben, die für ihre zugewiesenen Aufgaben erforderlich sind. NIST fordert außerdem, Berechtigungen regelmäßig zu überprüfen und nicht benötigten Zugriff zu entfernen oder neu zuzuweisen. Wenden Sie dies auf Zugangsdaten an, nicht nur auf menschliche Nutzer.

Bevorzugen Sie für eine Datenbank ein anwendungsspezifisches Konto statt eines gemeinsam verwendeten Administratorkontos. Verwenden Sie für E-Mails Zugangsdaten, die für die Versandfunktion der Anwendung bestimmt sind, statt des Passworts eines persönlichen Postfachs. Wählen Sie für APIs die engsten verfügbaren Berechtigungen und trennen Sie Zugangsdaten für Entwicklung, Test und Produktion. Ermitteln Sie bei Integrationen, ob das Token Daten lesen, Daten schreiben, Daten löschen, Nutzer administrieren oder weitere Zugangsdaten erstellen kann.

Ein hilfreicher Test ist der Schadensradius: Was kann ein Angreifer tatsächlich tun, wenn dieser Wert offengelegt wird? Ein eng begrenztes Token, das an eine Anwendung gebunden ist, lässt sich leichter widerrufen und richtet weniger Schaden an als ein weitreichend berechtigtes Token, das über mehrere Systeme hinweg wiederverwendet wird.

• Erstellen Sie getrennte Datenbankzugangsdaten für jede Anwendung und Umgebung, sofern der Dienst dies zulässt.
• Vermeiden Sie für den üblichen Anwendungszugriff die Verwendung eines Datenbank-Superusers oder einer weitreichenden Administratorberechtigung.
• Verwenden Sie getrennte API-Token für getrennte Anwendungen oder Integrationen, statt ein allgemeines Token wiederzuverwenden.
• Beschränken Sie Berechtigungen, zugängliche Daten und administrative Fähigkeiten auf den tatsächlichen Bedarf der Anwendung.
• Überprüfen Sie Zugangsdaten nach Änderungen an Rolle, Anbieter, Integration oder Architektur.

Ein Rotationsverfahren entwickeln, das keine Integrationen unterbricht

Rotation ist ein kontrollierter Austausch und nicht lediglich ein Zurücksetzen eines Passworts. Eine ungeplante Änderung kann die Datenbankverbindung, den E-Mail-Versand, Webhooks oder essenzielle Automatisierung unterbrechen. Die sicherere Reihenfolge lautet: Ersatz vorbereiten, den nutzenden Dienst aktualisieren, validieren, den alten Wert widerrufen und das Ergebnis dokumentieren.

Beginnen Sie mit einem Inventareintrag, der festhält, ob parallele Zugangsdaten möglich sind. Manche Anbieter erlauben, dass ein neues Token kurzzeitig neben dem alten Token besteht; das erleichtert eine schrittweise Umstellung. Wenn keine Überschneidung möglich ist, planen Sie ein Wartungsfenster, definieren Sie einen Rückfallweg und stellen Sie sicher, dass die richtigen Verantwortlichen verfügbar sind.

Prüfen Sie nach der Änderung die tatsächliche Funktion, statt nur zu kontrollieren, ob der Dienst startet. Testen Sie einen für die Anwendung geeigneten Datenbank-Lese- und Schreibvorgang, senden Sie eine kontrollierte E-Mail, führen Sie einen autorisierten API-Aufruf aus oder starten Sie den kritischen Workflow. Entfernen Sie danach die alten Zugangsdaten.

Bei einem vermuteten Leak sind Rotation und Widerruf Maßnahmen zur Eindämmung, aber keine vollständige Untersuchung. Bereits kopierte Werte, Protokolle, Backups oder andere Folgen des Vorfalls bleiben möglich. Prüfen Sie deshalb die bekannten Offenlegungsorte, dokumentieren Sie die Ergebnisse und behandeln Sie die weitere Untersuchung getrennt von der technischen Umstellung auf neue Zugangsdaten.

• 1. Inventarisieren: Zugangsdaten, verantwortliche Person, nutzende Systeme, Abhängigkeiten und Offenlegungsorte identifizieren.
• 2. Ersetzen: Einen neuen Wert über den genehmigten Prozess der für den Drittanbieter verantwortlichen Person erzeugen oder beziehen.
• 3. Aktualisieren: Den Ersatzwert nur über den autorisierten Anwendungs- oder Bereitstellungspfad bereitstellen.
• 4. Validieren: Die konkrete Integration oder Funktion testen, die von den Zugangsdaten abhängt.
• 5. Widerrufen: Den vorherigen Wert deaktivieren, löschen oder auf andere Weise ungültig machen, sobald dies sicher möglich ist.
• 6. Dokumentieren: Datum, ausführende Person, Validierungsergebnis, nächstes Prüfdatum und jede Ausnahme erfassen.