Datenbank-Zugangsdaten gehören zu den wertvollsten Geheimnissen in einem geschäftlichen Umfeld. Ein offengelegter Benutzername mit Passwort kann Kundendaten, Finanzinformationen, Anwendungsdaten oder ein vollständiges Produktionssystem zugänglich machen. Connection Strings können Host, Port, Datenbankname und Authentifizierungsmethode der Datenbank verraten, selbst wenn das Passwort nicht sofort erkennbar ist.
Das Risiko beschränkt sich nicht auf den Quellcode der Anwendung. Zugangsdaten können in Konfigurationsdateien, Support-Tickets, Deployment-Protokollen, Container-Images, Monitoring-Tools, Server-Backups und Chatnachrichten auftauchen. Agenturen stehen außerdem vor einer zusätzlichen Herausforderung: Mehrere Kundenumgebungen werden möglicherweise vom selben Team verwaltet, doch jeder Kunde benötigt eine klare Trennung von Zugriffen, Verantwortlichkeiten und Nachweisen.
Die sichere Verwaltung von Datenbank-Zugangsdaten ist daher ein Prozess und kein einzelnes Produkt. Sie kombiniert Secret-Management, die Trennung von Umgebungen, Konten mit geringstmöglichen Rechten, Verschlüsselung, Protokollierung, Rotation und sorgfältig geplanten Notfallzugriff.
Ermitteln, wo Datenbank-Zugangsdaten durchsickern können
Bevor Sie sich für Tools entscheiden, sollten Sie jeden Ort identifizieren, an dem Zugangsdaten erstellt, kopiert, verarbeitet oder gespeichert werden können. Diese Prüfung deckt häufig mehr Risiken auf als erwartet, weil Zugangsdaten dem Workflow eines Systems folgen und nicht nur der Anwendung.
- Quellcode: Entwickler hinterlegen während des Testens möglicherweise Passwörter, API-Schlüssel oder vollständige Connection Strings direkt im Code und vergessen, sie vor dem Commit zu entfernen.
- Konfigurationsdateien: Anwendungseinstellungen, Webserver-Konfigurationen und Deployment-Manifeste können Geheimnisse im Klartext enthalten.
- Tickets und Chats: Ein Entwickler kann ein Passwort oder einen Connection String zur schnelleren Fehlerbehebung einfügen, sodass dieser in einem durchsuchbaren Gesprächsverlauf erhalten bleibt.
- Protokolle: Fehlermeldungen bei Verbindungen, Debug-Ausgaben, SQL-Anweisungen und Exception-Tracebacks können Benutzernamen, Hosts oder Verbindungsparameter enthalten.
- Backups: Ein Server-Backup kann Konfigurationsdateien, Anwendungsverzeichnisse, Skripte, Datenbanken, Zugangsspeicher und Protokolle gemeinsam enthalten.
- Container-Images: In ein Dockerfile, eine Image-Schicht oder ein Build-Artefakt kopierte Geheimnisse können weiterhin verfügbar sein, selbst nachdem die sichtbare Datei gelöscht wurde.
- CI/CD-Systeme: Pipeline-Variablen, Job-Ausgaben, zwischengespeicherte Arbeitsbereiche und Build-Artefakte können Zugangsdaten für Benutzer oder Dienste offenlegen, die sie nicht benötigen.
Erstellen Sie für jede Anwendung und Datenbank ein Inventar. Dokumentieren Sie, wofür das Geheimnis verwendet wird, zu welcher Umgebung es gehört, wer darauf zugreifen kann, wo es gespeichert ist, wie es rotiert wird und wie es widerrufen werden kann. Behandeln Sie dieses Inventar als vertrauliche Dokumentation: Es sollte das Geheimnis beschreiben, ohne das Geheimnis selbst zu reproduzieren.
Secret-Management statt verstreuter Konfigurationen verwenden
Passwörter und Schlüssel sollten in einem speziell für Geheimnisse entwickelten System gespeichert werden und nicht in einem Repository, einer Tabelle oder einem allgemein genutzten Netzlaufwerk. Ein Secret-Manager kann kontrollierten Zugriff, Verschlüsselung, Audit-Protokolle, Versionierung und automatisches Abrufen beim Deployment oder zur Laufzeit ermöglichen. Die Anwendung erhält den benötigten Wert, ohne dass Entwickler ihn in den Quellcode kopieren müssen.
Ansätze für das Secret-Management unterscheiden sich. Einige Organisationen verwenden einen dedizierten Vault, andere den Managed Service eines Cloud-Anbieters, während wieder andere einen verschlüsselten Konfigurationsmechanismus einsetzen, der in ihre Deployment-Plattform integriert ist. Vergleichen Sie bei der Auswahl Tools für das Secret-Management von Datenbank-Zugangsdaten und deren Modelle für Zugriff, Auditing und Rotation mit Ihren tatsächlichen betrieblichen Anforderungen.
Ein geeignetes Design sollte praktische Fragen beantworten:
- Kann der Zugriff einer Workload-Identität statt einem langlebigen gemeinsamen Passwort gewährt werden?
- Können Berechtigungen nach Anwendung, Kunde, Umgebung und Datenbank eingeschränkt werden?
- Werden Abrufe und Änderungen in einem Audit-Trail protokolliert?
- Kann ein Geheimnis versioniert und widerrufen werden, ohne jedes System neu zu erstellen?
- Kann der Zugriff automatisch verweigert werden, wenn eine Person ein Projekt verlässt oder eine Integration eingestellt wird?
- Können Entwickler mit sicheren Test-Zugangsdaten arbeiten, ohne Produktionswerte zu sehen?
Secret-Management ist nicht automatisch sicher, nur weil es eine Vault-Oberfläche besitzt. Auch das Administratorkonto des Vaults, Wiederherstellungsschlüssel, Integrationstoken und Zugriffsrichtlinien müssen geschützt werden. Halten Sie die Zahl der Personen mit umfassenden Leserechten für Geheimnisse klein, verwenden Sie eine starke Authentifizierung, prüfen Sie Zugriffsrechte regelmäßig und vermeiden Sie, dass eine einzelne Pipeline oder ein Administrator alle Kundenzugangsdaten abrufen kann.
Umgebungen, Kunden und Verantwortlichkeiten trennen
Entwicklung, Staging und Produktion sollten keine gemeinsamen Datenbank-Zugangsdaten verwenden. Eine Testanwendung sollte nicht allein deshalb eine Verbindung zu einer Produktionsdatenbank herstellen können, weil sie dieselbe Konfigurationsvorlage nutzt. Verwenden Sie separate Datenbankkonten, separate Geheimnisse und, soweit praktikabel, separate Datenbankinstanzen oder Server.
Dasselbe Prinzip gilt für verschiedene Kunden. Eine Agentur sollte kein Datenbankkonto für mehrere Kunden verwenden, selbst wenn dieses für den Support bequem ist. Jede Kundenumgebung sollte eigene Zugangsdaten, eine eigene Zugriffsrichtlinie und einen eigenen Audit-Trail besitzen. Das begrenzt die Auswirkungen eines Lecks und macht es möglich, das tatsächlich aufgerufene System zu identifizieren.
Dokumentieren Sie die Aufteilung der Verantwortlichkeiten. Ein Kunde kann Eigentümer der Datenbank sein und privilegierte Zugriffe genehmigen, während die Agentur die Anwendung betreibt und Wartungsarbeiten durchführt. Alternativ kann die Agentur den Server administrieren, aber vor Änderungen an Zugangsdaten die Zustimmung des Kunden benötigen. Beide Modelle können funktionieren, sofern sie eindeutig geregelt sind.
Definieren Sie:
- Wem die Datenbank und ihre Daten gehören
- Wer Zugangsdaten erstellen, lesen, rotieren und widerrufen darf
- Wer den Produktionszugriff genehmigt
- Welche Support-Mitarbeiter auf welche Kundenumgebung zugreifen können
- Wie Zugriffe entfernt werden, wenn ein Vertrag oder Projekt endet
- Wie Notfallzugriffe beantragt, dokumentiert und geprüft werden
Verwechseln Sie die betriebliche Verantwortung nicht mit uneingeschränktem Zugriff. Eine Hosting-, Entwicklungs- oder Supportrolle muss möglicherweise eine Anwendung warten können, ohne jede Datenbanktabelle lesen oder alle Daten exportieren zu dürfen.
Prinzip der geringsten Rechte auf Datenbankkonten anwenden
Die Zugriffskontrolle für Datenbanken sollte mit getrennten Konten für verschiedene Funktionen beginnen. Ein Anwendungskonto benötigt normalerweise nur die Berechtigungen, die diese Anwendung erfordert. Ein Reporting-Dienst benötigt möglicherweise Lesezugriff auf ausgewählte Views, während ein Migrationsprozess vorübergehend Berechtigungen zur Änderung des Schemas braucht. Keines dieser Konten sollte für Routinearbeiten das Datenbankbesitzerkonto verwenden.
Sinnvolle Grenzen für Konten
- Anwendungskonto: Beschränkt auf die erforderliche Datenbank, das Schema, Tabellen, Prozeduren oder Views.
- Migrationskonto: Nur während genehmigter Deployment-Arbeiten aktiviert und anschließend eingeschränkt oder deaktiviert.
- Reporting-Konto: Schreibgeschützt, vorzugsweise für kontrollierte Views oder ein Reporting-Replikat.
- Supportkonto: Individueller Zugriff mit zeitlicher Begrenzung und Audit-Trail statt eines dauerhaft gemeinsam genutzten Administratorpassworts.
- Backup-Konto: Auf den Backup-Vorgang beschränkt und, sofern die Plattform dies erlaubt, nicht in der Lage, Anwendungsdaten zu verändern.
Prüfen Sie Berechtigungen, wenn sich die Anwendung ändert. Alte Freigaben bleiben häufig lange bestehen, nachdem ein Feature, ein Auftragnehmer oder eine Integration entfernt wurde. Testen Sie die Berechtigungen mit der Identität der Anwendung und nicht nur mit einem Administratorkonto; andernfalls können übermäßige Zugriffe unbemerkt bestehen bleiben.
Zugangsdaten bei der Übertragung und Speicherung schützen
Eine Verschlüsselung während der Übertragung ist unverzichtbar, wenn eine Anwendung über ein Netzwerk eine Verbindung zu einer Datenbank herstellt. Konfigurieren Sie Datenbank und Client so, dass sie TLS verwenden, sofern dies unterstützt wird, validieren Sie Zertifikate ordnungsgemäß und vermeiden Sie Einstellungen, die den Datenverkehr zwar verschlüsseln, das Ziel aber nicht verifizieren. Ein Connection String mit enthaltenem Passwort bleibt vertraulich, selbst wenn die Verbindung selbst verschlüsselt ist.
Bei der Speicherung sollten Geheimnisse durch das System verschlüsselt werden, in dem sie abgelegt sind. Der Zugriff ist auf die benötigten Identitäten zu beschränken. Verschlüsselung macht Zugriffskontrollen nicht überflüssig. Jeder, der ein Geheimnis entschlüsseln, auf den Schlüssel zugreifen oder einen ungeschützten Export abrufen kann, kann die Zugangsdaten möglicherweise dennoch erhalten.
Gehen Sie nicht davon aus, dass das Löschen einer Zeile aus der aktuellen Konfigurationsdatei sie auch aus der Historie entfernt. Git-Repositories behalten frühere Commits, Container-Registries behalten Image-Schichten, Ticketsysteme behalten Anhänge und Backups behalten ältere Versionen. Wenn ein Geheimnis committed oder weitergegeben wurde, behandeln Sie es als offengelegt und rotieren Sie es, selbst wenn die sichtbare Kopie entfernt wurde.
Zugangsdaten bewusst rotieren und widerrufen
Die Rotation sollte vor einem Vorfall geplant werden. Legen Sie fest, wie jedes Datenbankpasswort, jeder API-Schlüssel und jedes Zertifikat geändert wird, wo der neue Wert gespeichert wird und wie Anwendungen ihn erhalten. Wenn ein Dienst während des Übergangs nicht zwei gültige Zugangsdaten unterstützt, planen Sie ein kontrolliertes Wartungsfenster und bestätigen Sie einen Rollback-Plan, der das alte Geheimnis nicht dauerhaft wiederherstellt.
Priorisieren Sie kurzlebige Zugangsdaten oder eine automatische Rotation, sofern die Technologie dies unterstützt. Langlebige Passwörter erfordern stärkere betriebliche Kontrollen, da sie in alten Backups, auf Entwickler-Laptops, in Build-Caches oder vergessenen Skripten verbleiben können.
Widerruf und Rotation sind nicht dasselbe. Bei der Rotation wird ein Zugangsdatenwert ersetzt, während der alte möglicherweise kurzzeitig gültig bleibt; beim Widerruf wird der Zugriff beendet. Widerrufen Sie Zugangsdaten sofort, wenn der Verdacht auf eine Offenlegung besteht, wenn ein Mitarbeiter oder Dienstleister keinen Zugriff mehr benötigt oder wenn eine Integration außer Betrieb genommen wird. Prüfen Sie nach dem Widerruf die Protokolle auf Verwendung der alten Zugangsdaten und stellen Sie sicher, dass abhängige Dienste mit dem Ersatz funktionieren.
Geheimnisse aus Entwicklungs- und Bereitstellungsprozessen heraushalten
Eine lokale .env-Datei kann bei der Entwicklung praktisch sein, sollte aber nicht in ein Repository committed, in ein Support-Bundle hochgeladen oder in ein Produktions-Image kopiert werden. Stellen Sie eine sichere Beispieldatei mit Variablennamen, aber ohne echte Werte bereit, und erzwingen Sie Ignore-Regeln sowie Secret-Scanning im Repository.
Für CI/CD-Pipelines gilt dieselbe Sorgfalt. Speichern Sie vertrauliche Variablen in der geschützten Secret-Funktion der Pipeline oder rufen Sie sie zur Laufzeit aus einem Vault ab. Maskieren Sie Werte in Ausgaben, verhindern Sie nach Möglichkeit, dass Geheimnisse in Befehlszeilenargumenten erscheinen, beschränken Sie, wer Pipeline-Definitionen bearbeiten darf, und schützen Sie Deployment-Branches. Prüfen Sie Build-Artefakte und Caches, da ein Geheimnis durch eine generierte Konfiguration offengelegt werden kann, selbst wenn das Pipeline-Protokoll sauber aussieht.
Container-Images erfordern eine besondere Prüfung. Verwenden Sie Build-Argumente oder Umgebungsanweisungen nicht als dauerhaften Speicher für Geheimnisse. Untersuchen Sie Image-Historie und -Schichten, nutzen Sie die Injektion zur Laufzeit, halten Sie Registries privat und entfernen Sie kompromittierte Images, nachdem Zugangsdaten widerrufen wurden. Ein Container, der ein Geheimnis lesen kann, sollte außerdem daran gehindert werden, auf fremde Geheimnisse anderer Kunden oder Umgebungen zuzugreifen.
Tickets, Protokolle und Fehlerbehebung sicher handhaben
Supportteams benötigen einen Standard für die Anforderung diagnostischer Informationen. Bitten Sie statt vollständiger Connection Strings um geschwärzte Konfigurationen, Fehlercodes, Zeitstempel und Ressourcenkennungen. Legen Sie fest, welche Felder immer entfernt werden müssen: Passwörter, Token, private Schlüssel, Sitzungscookies und vollständige Authentifizierungs-Header.
Die Protokollierung sollte getestet und nicht nur als sicher angenommen werden. Durchsuchen Sie Anwendungsprotokolle, Webserver-Protokolle, Datenbank-Audit-Protokolle, CI-Ausgaben und Monitoring-Warnungen nach passwortähnlichen Feldern, Token-Mustern, Connection-String-Schemata und Datenbank-Hostnamen. Regeln zur Schwärzung sollten sowohl strukturierte Felder als auch unstrukturierte Exception-Nachrichten abdecken.
Senden Sie Zugangsdaten niemals über gewöhnliche Chats oder E-Mails. Wenn eine Weitergabe im Notfall unvermeidbar ist, verwenden Sie einen genehmigten sicheren Kanal mit beschränktem Zugriff und festgelegtem Ablaufdatum und rotieren Sie die Zugangsdaten anschließend. Ein Passwort, das in einem privaten Teamraum veröffentlicht wurde, wird dennoch auf mehrere Geräte kopiert, von einem Dienstanbieter gespeichert und ist möglicherweise später für Personen sichtbar, die dem Raum beitreten.
Zugangsdaten in Server-Backups berücksichtigen
Server-Backups enthalten häufig Zugangsdaten, weil sie Anwendungskonfigurationen und Betriebssystemdateien sichern. Der Schutz von Backups trägt daher zur Sicherheit von Datenbank-Zugangsdaten bei, ersetzt aber weder einen Secret-Manager noch eine gute Rotationspraxis. Ein Backup kann ein altes Passwort bewahren, lange nachdem die Anwendung zu einem neuen gewechselt hat, und jeder mit Wiederherstellungsrechten kann möglicherweise die Dateien untersuchen.
Bei Servern, die der Kunde kontrolliert, sollten Verschlüsselung, Schlüsselverwaltung, Aufbewahrungsfrist und Wiederherstellungsrechte des Backups gemeinsam betrachtet werden. Safenix bietet Offsite-Backups für Unternehmensserver. Die Daten werden in Deutschland gespeichert, mit einem Schlüssel verschlüsselt, den Safenix niemals besitzt, und für die Dauer des gewählten Aufbewahrungszeitraums unveränderlich gespeichert. Diese Verschlüsselung von Backups und der kundengesteuerte Schutz der Schlüsselverwaltung tragen dazu bei, das Risiko zu verringern, dass ein gestohlenes Backup zur Quelle von Datenbank-Zugangsdaten wird.
Dieser Schutz erfordert weiterhin betriebliche Entscheidungen. Legen Sie fest, wer eine Wiederherstellung anfordern darf, wer auf wiederhergestellte Dateien zugreifen kann, ob die Wiederherstellung in einer isolierten Umgebung erfolgt und wie wiederhergestellte Zugangsdaten anschließend behandelt werden. Ein wiederhergestellter Server sollte nicht automatisch zu einem Zugang in die Produktion werden. Stellen Sie für Untersuchungen nach Möglichkeit in einem eingeschränkten Netzwerk wieder her, binden Sie Backup-Daten schreibgeschützt ein und entfernen oder rotieren Sie alle Zugangsdaten, die in der wiederhergestellten Kopie gefunden werden.
Safenix schützt Server, die vom Kunden kontrolliert werden; die Lösung ist kein Backup-Konzept für Websites auf Shared Hosting. Der Kunde oder sein Dienstleister bleibt für die Secret-Management-Konfiguration des Servers, Zugriffsberechtigungen und Entscheidungen darüber verantwortlich, welche Daten in ein Backup aufgenommen werden.
Ein sicheres Notfallverfahren verwenden
Wenn Zugangsdaten möglicherweise offengelegt wurden, zählt die Geschwindigkeit. Überstürzte Änderungen können jedoch einen Ausfall verursachen oder Beweise zerstören. Halten Sie für die Personen, die sie benötigen könnten, ein kurzes, getestetes Verfahren für Sicherheitsvorfälle bereit.
- Offenlegung eindämmen: Beschränken Sie den Zugriff auf Repository, Ticket, Chat, Pipeline oder Speicher und sichern Sie relevante Aufzeichnungen.
- Geheimnis klassifizieren: Ermitteln Sie Datenbank, Kunde, Umgebung, Berechtigungen und Systeme, die es verwenden können.
- Widerrufen oder rotieren: Deaktivieren Sie die offengelegten Zugangsdaten und stellen Sie über den genehmigten Secret-Management-Prozess einen Ersatz aus.
- Auf Verwendung prüfen: Kontrollieren Sie Datenbank-Authentifizierungsprotokolle, Anwendungsprotokolle, VPN-Aufzeichnungen, Repository-Zugriffe sowie Cloud- und Server-Audit-Ereignisse.
- Kopien entfernen: Löschen Sie offengelegte Tickets, Artefakte, Images oder Dateien, sofern angemessen, und bewahren Sie Beweise zum Vorfall sicher auf.
- Backups prüfen: Ermitteln Sie, welche Backup-Versionen das alte Geheimnis enthalten, und stellen Sie sicher, dass der Wiederherstellungszugriff eingeschränkt ist.
- Wiederherstellung bestätigen: Testen Sie die Anwendung mit den neuen Zugangsdaten und verifizieren Sie, dass die alten nicht mehr funktionieren.
- Kontrolle verbessern: Dokumentieren Sie die Ursache und ergänzen Sie eine vorbeugende Prüfung, etwa Secret-Scanning, bessere Schwärzung oder eine kürzere Gültigkeitsdauer der Zugangsdaten.
Verwenden Sie die Wiederherstellung eines Backups nicht als erste Reaktion auf ein offengelegtes Passwort. Die Wiederherstellung eines älteren Servers kann auch die kompromittierten Zugangsdaten, verwundbare Software oder veraltete Zugriffsregeln zurückbringen. Backups dienen der Wiederherstellung; die Reaktion auf kompromittierte Zugangsdaten sollte über Widerruf, Untersuchung und kontrollierte erneute Bereitstellung erfolgen.
Praktische Prüfungen für Agenturen und Unternehmen
Führen Sie diese Prüfungen beim Onboarding, während größerer Deployments und nach Änderungen bei Mitarbeitern oder Dienstleistern durch:
- Durchsuchen Sie Repositories, Commit-Historien, Deployment-Skripte und Container-Schichten nach Passwörtern, Token und Mustern von Connection Strings.
- Prüfen Sie, ob .env-Dateien, Konfigurationsexporte oder Datenbank-Dumps öffentlich erreichbar sind oder in Support-Bundles enthalten werden.
- Untersuchen Sie Protokolle und CI/CD-Ausgaben auf Authentifizierungsfelder, SQL-Fehler, Befehlsargumente und nicht maskierte Variablen.
- Listen Sie jedes Produktionsdatenbankkonto auf und bestätigen Sie Eigentümer, Zweck, Berechtigungen, letzte Rotation und letzte Nutzung.
- Stellen Sie sicher, dass Entwicklungs- und Staging-Systeme sich mit ihren normalen Zugangsdaten nicht bei der Produktion authentifizieren können.
- Prüfen Sie, welche Mitarbeiter, Auftragnehmer, Dienstkonten und Backup-Administratoren Geheimnisse abrufen oder Serverdaten wiederherstellen können.
- Bestätigen Sie, dass Datenbankverbindungen Verschlüsselungszertifikate validieren und nicht auf eine unverschlüsselte Übertragung zurückfallen.
- Überprüfen Sie die Aufbewahrung von Backups und Wiederherstellungsrechte, einschließlich der Frage, wer auf wiederhergestellte Konfigurationsdateien zugreifen kann.
- Testen Sie Widerruf und Ersatz, ohne auf ein undokumentiertes Administratorkennwort angewiesen zu sein.
Stellen Sie für jedes Zugangsmittel abschließend die folgende Frage: Wenn dieser Wert heute in einem öffentlichen Repository auftauchen würde, wie schnell könnte der Zugriff gestoppt werden, wie ließe sich die betroffene Umgebung identifizieren und wer wäre für die Reaktion verantwortlich? Wenn die Antwort davon abhängt, eine Person zu finden, die sich an einen alten Prozess erinnert, ist die Kontrolle noch nicht zuverlässig.