Eine Unternehmensdatenbank wird nur selten absichtlich unsicher gestaltet. Häufiger entsteht die Exponierung durch eine Standardeinstellung, eine vorübergehende Firewall-Regel, einen übersehenen Testdienst oder eine Wartungsabkürzung, die dauerhaft bestehen bleibt.
Die Folgen können schwerwiegend sein. Ein Angreifer kann Kundendaten stehlen, Finanzdaten verändern, Produktionssysteme verschlüsseln oder den Datenbankserver als Weg in eine andere Infrastruktur nutzen. Selbst wenn nicht sofort Daten entwendet werden, stellt ein exponierter Dienst einen vermeidbaren Einstiegspunkt dar, der überwacht und geschützt werden muss.
Die folgenden sieben Fehler betreffen Datenbankserver, die von einem Unternehmen, einer Agentur oder einem IT-Administrator kontrolliert werden. Sie sind für PostgreSQL, MySQL, Microsoft SQL Server, MongoDB und andere Plattformen relevant. Die konkreten Befehle unterscheiden sich, die Sicherheitsentscheidungen sind jedoch gleich: Erreichbarkeit minimieren, Identität überprüfen, Berechtigungen begrenzen, Datenverkehr verschlüsseln, Aktivitäten überwachen und die Wiederherstellung unabhängig vom zu schützenden Server halten.
1. Die Datenbank an eine öffentliche Schnittstelle binden
Ein Datenbankdienst lauscht möglicherweise standardmäßig auf jeder Netzwerkschnittstelle. Oder ein Administrator konfiguriert ihn für eine öffentliche IP-Adresse, um den Fernzugriff zu erleichtern. Verfügt der Server über eine routbare Adresse, kann die Datenbank direkt aus dem Internet erreichbar sein, sofern keine andere Kontrolle dies verhindert.
Angriffsweg und Auswirkungen auf das Unternehmen
Ein Angreifer durchsucht Adressbereiche nach bekannten Datenbankports, identifiziert Software und Version und versucht anschließend, Zugangsdaten anzugreifen oder eine bekannte Schwachstelle auszunutzen. Öffentliche Sichtbarkeit bedeutet nicht automatisch eine Kompromittierung, bietet Angreifern jedoch ein dauerhaftes und leicht auffindbares Ziel.
Ein erfolgreicher Zugriff kann personenbezogene Daten, Bestellungen, Zugangsdaten, geistiges Eigentum und Betriebsdaten offenlegen. Ein Datenbankkonto kann einem Angreifer außerdem ermöglichen, Datensätze zu verändern, neue privilegierte Benutzer anzulegen oder Datenbankfunktionen zu verwenden, um den zugrunde liegenden Server zu erreichen.
So erkennen und beheben Sie den Fehler
Prüfen Sie die Konfiguration des Datenbank-Listeners und die Socket-Liste des Betriebssystems. Befehle wie ss -lntp oder netstat -lntp zeigen, ob der Dienst auf 0.0.0.0, :: oder einer öffentlichen Adresse lauscht, statt nur auf localhost oder einer privaten Schnittstelle. Testen Sie den Zugriff von außerhalb des Netzwerks und nicht nur direkt vom Server aus. Ein externer Portscan sowie die Prüfung von Cloud-Sicherheitsgruppen oder Firewall-Regeln des Hostinganbieters sollten mit der vorgesehenen Architektur übereinstimmen.
Binden Sie die Datenbank für die meisten Anwendungen an localhost oder eine private Netzwerkadresse und platzieren Sie sie hinter der Anwendungsschicht. Wenn eine Fernadministration erforderlich ist, verlangen Sie ein privates VPN, einen Bastion-Host oder einen anderen kontrollierten Zugangsweg. Betrachten Sie einen ungewöhnlichen Port nicht als Schutz. Er kann zufälliges Rauschen reduzieren, verhindert aber keine Entdeckung.
Administratoren können beim Überprüfen des Designs zuverlässige Anleitungen zur Prüfung einer internetexponierten Datenbank und sicherer Expositionsmuster nutzen. Ziel sollte sein, die öffentliche Erreichbarkeit überall dort zu entfernen, wo sie nicht zwingend erforderlich ist, und den Dienst nicht lediglich zu verstecken.
2. Standardzugangsdaten oder schwache Authentifizierung beibehalten
Datenbankprodukte, Appliances und Bereitstellungs-Images enthalten teilweise Standardbenutzernamen, temporäre Passwörter oder Authentifizierungsmodi, die nur für die Ersteinrichtung vorgesehen sind. Bei einer überhasteten Installation bleibt möglicherweise auch ein einfaches Passwort bestehen, ein Anwendungsschlüssel wird wiederverwendet oder passwortlose lokale Verbindungen werden umfassender erlaubt als geplant.
Angriffsweg und Auswirkungen auf das Unternehmen
Nach der Entdeckung eines Datenbankports versuchen Angreifer routinemäßig veröffentlichte Standardzugangsdaten und häufige Passwörter. Auch Credential-Stuffing ist wirksam, wenn Administratoren Passwörter aus anderen Systemen wiederverwenden. Nach der Authentifizierung verfügt der Angreifer möglicherweise über deutlich mehr Zugriff, als die ursprüngliche Anwendung benötigt.
Die Folge können unbemerkte Datenextraktion, destruktive Abfragen, betrügerische Änderungen oder ein Ausgangspunkt für spätere Ransomware-Angriffe sein. Werden dieselben Zugangsdaten von Skripten, Entwicklern und Administratoren verwendet, kann ein durchgesickertes Geheimnis jede Umgebung gefährden.
So erkennen und beheben Sie den Fehler
Überprüfen Sie jedes Datenbankkonto, seine Authentifizierungsmethode, Informationen zur letzten Verwendung und die zugewiesene Rolle. Testen Sie die Installation anhand eines Kontoinventars, statt davon auszugehen, dass dokumentierte Standardzugänge entfernt wurden. Untersuchen Sie Konfigurationsdateien, Bereitstellungsmanifeste, CI/CD-Variablen und Skripte auf eingebettete Passwörter.
Deaktivieren Sie nicht verwendete Herstellerkonten und benennen Sie Notfallkonten gegebenenfalls um oder sperren Sie sie. Für Konten, die bestehen bleiben müssen, sind lange, einzigartige Zugangsdaten erforderlich. Bevorzugen Sie zentral verwaltete Authentifizierung, Multi-Faktor-Authentifizierung für menschliche Administratoren und kurzlebige Zugangsdaten für Automatisierung, sofern die Plattform dies unterstützt. Speichern Sie Geheimnisse in einem dedizierten Secrets-Manager und nicht im Quellcode, in Tickets, Tabellen oder der Shell-Historie. Rotieren Sie Zugangsdaten nach Personalwechseln, vermuteter Offenlegung und größeren Systemänderungen.
Authentifizierungsprotokolle sollten fehlgeschlagene und erfolgreiche Anmeldungen, Quelladressen und das verwendete Konto erfassen. Lösen Sie Warnungen bei wiederholten Fehlversuchen, Anmeldungen zu ungewöhnlichen Zeiten, Zugriffen aus unerwarteten Netzwerken und der Erstellung neuer privilegierter Konten aus.
3. Uneingeschränkten Netzwerkzugriff erlauben
Die Bindung einer Datenbank an eine private Schnittstelle reicht nicht aus, wenn das Netzwerk jedem internen Host, VPN-Benutzer oder Cloud-Workload eine Verbindung erlaubt. Eine weitreichende Regel wie „gesamtes Büronetzwerk zulassen“ oder „gesamten Zugriff aus der virtuellen Private Cloud zulassen“ bleibt oft lange bestehen, nachdem der ursprüngliche Bedarf zur Fehlerbehebung verschwunden ist.
Angriffsweg und Auswirkungen auf das Unternehmen
In diesem Szenario kompromittiert ein Angreifer zunächst einen Laptop, Webserver, ein Entwicklerkonto oder einen unabhängigen Workload. Der Netzwerkzugriff auf die Datenbank ist bereits vorhanden. Der Angreifer kann daher nach dem Dienst suchen und ihn angreifen, ohne den Perimeterschutz des Internets überwinden zu müssen.
Eine übermäßige interne Erreichbarkeit vergrößert die Auswirkungen von Phishing, Malware- und Lieferkettenvorfällen. Sie kann außerdem unbefugte laterale Bewegungen zwischen Produktions-, Staging- und Entwicklungssystemen ermöglichen. Ein kompromittierter Testserver sollte Kundendaten nicht abfragen können, nur weil beide Systeme durch eine weitreichende Netzwerkregel verbunden sind.
So erkennen und beheben Sie den Fehler
Überprüfen Sie Host-Firewalls, Netzwerk-Firewalls, Cloud-Sicherheitsgruppen, Kubernetes-Netzwerkrichtlinien und datenbankbasierte Regeln für Hostzugriffe gemeinsam. Dokumentieren Sie, welche Anwendungsserver, Reporting-Tools, Backup-Dienste und administrativen Jump-Hosts tatsächlich Verbindungen benötigen. Vergleichen Sie diese Liste mit aktiven Verbindungen und Firewall-Regeln.
Ersetzen Sie breite Quellbereiche durch explizite IP-Allowlists oder Sicherheitsgruppen. Erlauben Sie nur den erforderlichen Zielport und das notwendige Protokoll. Verweigern Sie Datenverkehr standardmäßig, trennen Sie Produktions- und Nichtproduktionsnetzwerke und entfernen Sie vorübergehende Regeln mit einem Verantwortlichen und einem Ablaufdatum. Wenn Mitarbeiter aus der Ferne zugreifen, sollte die Wartung über ein VPN oder einen Bastion-Host erfolgen, statt jede private oder mobile IP-Adresse direkt zuzulassen.
Überprüfen Sie die Regeln nach Migrationen und Änderungen am Büronetzwerk. Eine vierteljährliche Zugriffsprüfung ist sinnvoll, risikoreiche Änderungen sollten jedoch sofort kontrolliert werden. Eine Firewall-Regel ohne eindeutig benannten fachlichen Verantwortlichen ist ein Kandidat für die Entfernung.
4. Datenbankdaten ohne TLS übertragen
Eine Datenbank kann im Ruhezustand geschützt sein und dennoch Zugangsdaten und sensible Datensätze offenlegen, während diese zwischen Anwendung, Administratorarbeitsplatz, Reporting-Tool oder Replikationspartner übertragen werden. Unverschlüsselte Verbindungen sind besonders in gemeinsam genutzten Netzwerken, Cloud-Segmenten, WLANs und bei der Fernwartung gefährlich.
Angriffsweg und Auswirkungen auf das Unternehmen
Ein Angreifer mit Netzwerkzugriff zeichnet Datenverkehr auf oder platziert sich zwischen Client und Server. Ohne TLS können Benutzernamen, Passwörter, Abfragen und zurückgegebene Daten lesbar sein. Schwaches oder nicht überprüftes TLS kann ebenfalls Abfangen ermöglichen, weil der Client nicht bestätigt, dass er tatsächlich mit der legitimen Datenbank kommuniziert.
Zu den Folgen gehören gestohlene Zugangsdaten, die Offenlegung von Kundendaten, manipulierte Abfragen und Compliance-Probleme. Replikations- und Backup-Übertragungswege verdienen dieselbe Aufmerksamkeit wie der normale Anwendungsdatenverkehr.
So erkennen und beheben Sie den Fehler
Untersuchen Sie Datenbankverbindungszeichenfolgen und Servereinstellungen, um zu bestätigen, dass TLS vorgeschrieben und nicht lediglich verfügbar ist. Nutzen Sie die Statusausgabe des Datenbankclients, Verbindungsprüfprotokolle und eine kontrollierte Paketerfassung, um die Verschlüsselung zu verifizieren. Prüfen Sie Zertifikatsgültigkeit, Hostnamenprüfung, vertrauenswürdige Aussteller, Protokollversionen und die Ablehnung eines unverschlüsselten Fallbacks.
Installieren Sie Zertifikate über einen kontrollierten Erneuerungsprozess, beschränken Sie den Zugriff auf private Schlüssel und überwachen Sie Ablaufdaten. Konfigurieren Sie Anwendungen so, dass sie bei fehlgeschlagener Zertifikatsprüfung keine Verbindung akzeptieren. Aktualisieren Sie alte Treiber und Bibliotheken, die aktuelle TLS-Einstellungen nicht unterstützen. Dokumentieren Sie, welche Verbindungen verschlüsselt sind, einschließlich Administration, Monitoring, Replikation und ETL-Datenverkehr.
TLS schützt Daten während der Übertragung, entscheidet aber nicht, wer sie abfragen darf. Kombinieren Sie TLS mit Netzwerkbeschränkungen, starker Authentifizierung und dem Prinzip der geringsten Rechte.
5. Übermäßige Datenbankberechtigungen vergeben
Anwendungen werden häufig mit einem Administrator- oder Besitzerkonto konfiguriert, weil dies die Installation erleichtert. Entwickler geben Reporting-Benutzern möglicherweise auch Schreibzugriff oder gewähren einem Dienstkonto „für zukünftige Anforderungen“ Berechtigungen für jedes Schema. Dies verletzt das Prinzip der geringsten Rechte und macht aus einer begrenzten Kompromittierung einen datenbankweiten Vorfall.
Angriffsweg und Auswirkungen auf das Unternehmen
Eine SQL-Injection-Schwachstelle, ein gestohlenes Anwendungsgeheimnis oder ein kompromittiertes Reporting-Tool verschafft dem Angreifer die Berechtigungen dieses Kontos. Gehören dem Konto Tabellen, kann es Benutzer anlegen oder Betriebssystemfunktionen ausführen, kann der Angreifer möglicherweise die gesamte Datenbank kopieren, Datensätze ändern oder auf den Host übergreifen.
Übermäßige Rechte erhöhen zudem die Wahrscheinlichkeit versehentlicher Schäden. Eine fehlerhafte Migration oder ein fehlerhaftes Skript kann Produktionsdaten löschen, wenn es unter einer hochprivilegierten Identität ausgeführt wird.
So erkennen und beheben Sie den Fehler
Erfassen Sie Benutzer, Gruppen, Rollen und Berechtigungen. Suchen Sie nach Anwendungskonten mit administrativen Rechten, direktem Zugriff auf nicht zugehörige Schemata, uneingeschränktem Lesezugriff auf sensible Tabellen und Berechtigungen, die noch nie verwendet wurden. Prüfen Sie Datenbank-Auditprotokolle, um zugewiesene Berechtigungen mit der tatsächlichen Aktivität zu vergleichen.
Erstellen Sie separate Identitäten für jede Anwendung, Umgebung und Funktion. Gewähren Sie nur Zugriff auf die benötigten Tabellen, Ansichten, Prozeduren und Vorgänge. Verwenden Sie schreibgeschützte Rollen für Reports, trennen Sie Migrationszugangsdaten von normalen Laufzeit-Zugangsdaten und beschränken Sie den Zugriff auf personenbezogene, finanzielle oder Authentifizierungsdaten. Entziehen Sie geerbte Berechtigungen, die nicht benötigt werden, und entfernen Sie inaktive Konten.
Produktionszugriff sollte nicht der Standard für Entwickler oder Agenturen sein, die mehrere Kunden betreuen. Nutzen Sie benannte Administratorkonten, eine Genehmigung für erhöhte Zugriffe, zeitlich begrenzte Berechtigungen und einen dokumentierten Wartungsweg. Gemeinsame Administratorkonten verhindern eine sinnvolle Zuordnung von Aktivitäten und erschweren den schnellen Entzug von Zugriffsrechten.
6. Administrative Ports und Tools exponieren
Datenbankverwaltungsschnittstellen, Remote-Desktop-Dienste, SSH, Webkonsolen und Management-APIs sind häufige Ziele. Sie aus Bequemlichkeit dem öffentlichen Internet auszusetzen, schafft eine zweite Angriffsfläche, selbst wenn der Datenbank-Listener selbst eingeschränkt ist.
Angriffsweg und Auswirkungen auf das Unternehmen
Angreifer scannen gängige Managementports, identifizieren Dienste und versuchen Passwortangriffe, den Einsatz gestohlener Zugangsdaten oder die Ausnutzung bekannter Schwachstellen. Ein kompromittierter Administrationsdienst kann direkte Kontrolle über das Betriebssystem, Zugriff auf Konfigurationen oder die Möglichkeit bieten, Protokollierung zu deaktivieren und Daten zu löschen.
Für ein kleines Unternehmen kann ein einziger exponierter Fernverwaltungsport einen Datenbankvorfall in die vollständige Übernahme des Servers verwandeln. Bei einer Agentur kann eine gemeinsam genutzte Verwaltungsmethode mehrere Kundensysteme gefährden, wenn die Zugriffsgrenzen schwach sind.
So erkennen und beheben Sie den Fehler
Führen Sie einen externen Scan der Adressen Ihrer Organisation sowie einen internen Scan aus nicht vertrauenswürdigen Netzwerksegmenten durch. Prüfen Sie die lauschenden Ports mit Host-Tools und vergleichen Sie sie mit den Firewall-Richtlinien. Kontrollieren Sie Cloud-Konsolen auf öffentliche IP-Zuweisungen, Load-Balancer-Listener und freizügige Sicherheitsgruppen. Überwachen Sie Protokolle auf Managementanmeldungen, fehlgeschlagene Authentifizierungen, neue Sitzungen und Konfigurationsänderungen.
Schließen Sie nicht verwendete Dienste. Halten Sie SSH, Remote Desktop und Datenbankkonsolen von öffentlichen Schnittstellen fern. Verlangen Sie ein VPN, einen Bastion-Host oder ein Zero-Trust-Zugangs-Gateway mit Multi-Faktor-Authentifizierung, Gerätekontrollen und individuellen Konten. Beschränken Sie den administrativen Zugriff, wo praktikabel, auf bestimmte Quell-IP-Adressen, deaktivieren Sie direkte Root- oder gemeinsame Administratorkonten und protokollieren Sie Befehle oder Sitzungsaktivitäten bei sensiblen Arbeiten.
Trennen Sie Produktionszugriff und Wartungszugriff. Die Anwendung sollte einen eng begrenzten Pfad verwenden, während Administratoren einen anderen kontrollierten Pfad nutzen, der nur bei Bedarf aktiviert wird. Geben Sie einer externen Agentur keinen dauerhaften uneingeschränkten Zugriff, wenn ein genehmigtes und protokolliertes Wartungsfenster ausreicht.
7. Patches und die Behebung von Schwachstellen verzögern
Datenbank-Engines, Betriebssysteme, Treiber, Erweiterungen und Verwaltungstools enthalten allesamt Schwachstellen. Ein System kann weiterhin exponiert sein, selbst wenn sein Anwendungscode gut gepflegt wird, sobald die zugrunde liegende Datenbankversion nicht mehr unterstützt wird oder ein kritisches Sicherheitsupdate auf unbestimmte Zeit verschoben wurde.
Angriffsweg und Auswirkungen auf das Unternehmen
Angreifer ermitteln die Datenbankversion über exponierte Dienste, Fehlermeldungen, gestohlene Inventardaten oder kompromittierte interne Systeme. Anschließend nutzen sie einen öffentlichen Exploit, eine verwundbare Erweiterung oder eine Schwachstelle in der Verwaltungsschicht. Für manche Angriffe ist eine Authentifizierung erforderlich, für andere nicht.
Ein erfolgreicher Exploit kann Daten offenlegen oder verändern, ein privilegiertes Konto anlegen, Code ausführen oder die Verfügbarkeit beeinträchtigen. Verzögertes Patchen erschwert außerdem die Wiederherstellung, weil Notfalländerungen unter Druck und ohne ausreichende Tests vorgenommen werden.
So erkennen und beheben Sie den Fehler
Benennen Sie einen eindeutigen Verantwortlichen für Betriebssystem, Datenbank-Engine, Erweiterungen, Treiber und Sicherheitstools. Führen Sie ein Inventar mit Versionen, Supportstatus, Exponierung, fachlichem Verantwortlichen und Wartungsfenster. Abonnieren Sie Sicherheitshinweise der Hersteller und verwenden Sie Schwachstellenscans. Gleichen Sie Scanergebnisse jedoch mit den tatsächlich installierten Versionen und der realen Konfiguration ab.
Setzen Sie risikobasierte Fristen für kritische Schwachstellen, testen Sie Updates auf einem repräsentativen Staging-System und halten Sie einen Rollback-Plan bereit. Installieren Sie Sicherheitsupdates zeitnah, entfernen Sie nicht unterstützte Komponenten und dokumentieren Sie akzeptierte Ausnahmen mit einem Ablaufdatum. Lösen Sie eine Warnung aus, wenn die Patch-Compliance unter die Richtlinie der Organisation fällt. Das Patchen ist erst abgeschlossen, wenn Dienste korrekt neu gestartet wurden und das Monitoring einen normalen Betrieb bestätigt.
Eine exponierte Datenbank erkennen, bevor es ein Angreifer tut
Beginnen Sie mit der Frage: Kann ein nicht vertrauenswürdiges Gerät die Datenbank oder ihre Verwaltungsschnittstelle erreichen? Testen Sie aus dem öffentlichen Internet und aus internen Netzwerken, die keinen Zugriff haben sollten. Prüfen Sie DNS-Einträge, IPv4- und IPv6-Adressen, Cloud-Firewalls, Host-Firewalls und Load-Balancer. Ein Dienst, der über IPv4 sicher ist, kann über IPv6 weiterhin exponiert sein.
Bestätigen Sie anschließend, was nach dem Verbindungsaufbau geschieht. Verlangt der Server TLS? Lehnt die Authentifizierung Standardzugänge und schwache Passwörter ab? Kann ein Anwendungskonto Tabellen außerhalb seiner Rolle lesen oder ändern? Werden fehlgeschlagene Anmeldungen, Berechtigungsänderungen, Schemaänderungen und ungewöhnliche Exporte zentral protokolliert?
Protokollierung ist nur hilfreich, wenn jemand oder etwas sie prüft. Senden Sie Datenbank-, Betriebssystem- und Firewall-Protokolle an ein geschütztes zentrales System, in dem ein Angreifer sie nicht unbemerkt ändern kann. Erstellen Sie Warnungen für wiederholte Authentifizierungsfehler, neue privilegierte Benutzer, Zugriffe aus neuen Ländern oder Netzwerken, große Exporte, deaktivierte Audits, ungewöhnliches Abfragevolumen und unerwartete Neustarts von Diensten. Stimmen Sie die Warnungen so ab, dass Mitarbeiter reagieren können, statt ständiges Rauschen zu ignorieren.
Mit unabhängigen Backups auf eine Kompromittierung vorbereiten
Eine sichere Konfiguration senkt die Wahrscheinlichkeit einer Kompromittierung, kann jedoch nicht garantieren, dass ein Konto, eine Anwendung oder ein Administratorarbeitsplatz niemals angegriffen wird. Die Wiederherstellungsplanung sollte davon ausgehen, dass ein Angreifer die Kontrolle über den Produktionsserver erlangt und versucht, Daten sowie lokale Backups zu verschlüsseln, zu beschädigen oder zu löschen.
Bewahren Sie getestete, verschlüsselte Backups außerhalb des Standorts auf, die der kompromittierte Server nicht löschen kann. Safenix bietet Offsite-Backups für Unternehmensserver. Die Daten werden in Deutschland gespeichert, für die Dauer des Aufbewahrungszeitraums unveränderbar gehalten und mit einem kundengesteuerten Schlüssel verschlüsselt, den Safenix niemals besitzt. Erfahren Sie mehr über verschlüsselte Offsite-Backups mit kundengesteuerten Schlüsseln und reduziertem Zugriff von einem kompromittierten Server.
Das Backup-Design sollte zu den vom Kunden kontrollierten Systemen passen, einschließlich Datenbankserver und unterstützender Infrastruktur. Es handelt sich nicht um einen Backup-Plan für eine Website auf Shared Hosting, und es sollte kein Shared-Hosting-Tarif vorausgesetzt werden. Bevor Sie sich auf ein Backup verlassen, bestätigen Sie, dass die Datenbank konsistent erfasst wird, die Aufbewahrung den geschäftlichen Anforderungen entspricht, Verschlüsselungsschlüssel bei Bedarf zugänglich sind und Wiederherstellungen erfolgreich durchgeführt wurden.
Unveränderbarkeit hilft, Löschung oder Veränderung während des Aufbewahrungszeitraums zu verhindern, während die externe Speicherung vor einem Ausfall oder Vorfall am Produktionsstandort schützt. Kundengesteuerte Verschlüsselung bedeutet, dass der Backup-Anbieter nicht über den Schlüssel zum Lesen der geschützten Daten verfügt. Diese Kontrollen verringern die Auswirkungen auf die Wiederherstellung, reparieren jedoch keine unsichere Datenbank. Die Wiederherstellung eines kompromittierten Servers ohne Behebung seiner Exponierung, Zugangsdaten oder Patches führt lediglich zum selben Vorfall zurück.
Produktionszugriff und Wartungszugriff für kleine Teams
Kleine Unternehmen und Agenturen verfügen häufig über begrenztes Personal, weshalb eine Trennung besonders wichtig ist. Halten Sie den normalen Anwendungspfad eng begrenzt und vorhersehbar. Für Wartung sollten benannte Konten, ein separater Netzwerkpfad und eine zeitlich begrenzte Rechteerhöhung verwendet werden. Ein Supportanbieter sollte nur den für die vereinbarte Aufgabe erforderlichen Zugriff erhalten und kein dauerhaftes Administratorkennwort, das über mehrere Kunden hinweg geteilt wird.
Führen Sie ein Zugriffsregister für Mitarbeiter, Auftragnehmer, Agenturen, Dienstkonten und Notfallzugangsdaten. Überprüfen Sie es nach Personaländerungen und bei der Übergabe von Kunden. Verwenden Sie einen sicheren Prozess zur Verwaltung von Geheimnissen, verlangen Sie eine Genehmigung für Produktionsänderungen und dokumentieren Sie, wer welche Änderung vorgenommen hat. Ein Notfallkonto kann vorhanden sein, seine Nutzung sollte jedoch eine Warnung auslösen und regelmäßig getestet werden.
Checkliste zur Überprüfung des Datenbankschutzes
- Öffentliche Erreichbarkeit: Kann ein externer oder nicht vertrauenswürdiger interner Host die Datenbank oder einen Administrationsport erreichen? Sind IPv4 und IPv6 gleichermaßen abgedeckt?
- Netzwerkkontrollen: Erlauben Firewall-Regeln und IP-Allowlists nur ausdrücklich benannten Quellen für Anwendungen, Reports und Wartung?
- Authentifizierung: Wurden Standard-, inaktive und gemeinsam genutzte Konten entfernt oder kontrolliert? Werden starke Zugangsdaten und Multi-Faktor-Authentifizierung für Administratoren eingesetzt?
- Geheimnisse: Sind Passwörter und Schlüssel aus Quellcode, Skripten, Tickets und Konfigurations-Repositories entfernt? Wird die Rotation getestet?
- Geringste Rechte: Verfügt jedes Anwendungs- und Benutzerkonto nur über die benötigten Zugriffsrechte, gegebenenfalls mit schreibgeschützten Rollen?
- Verschlüsselung: Ist TLS für Anwendungen, Administration, Replikation und Datenübertragung vorgeschrieben und korrekt verifiziert?
- Monitoring: Werden Authentifizierungs-, Berechtigungs-, Datenexport-, Firewall- und Konfigurationsereignisse zentral mit umsetzbaren Warnungen protokolliert?
- Patch-Verantwortung: Wer ist für jede Datenbank, jedes Betriebssystem, jede Erweiterung und jedes Verwaltungstool verantwortlich? Werden Schwachstellen bis zur Behebung verfolgt?
- Wiederherstellungsbereitschaft: Sind Backups verschlüsselt, extern gespeichert, für den Aufbewahrungszeitraum unveränderbar und vom Produktionsserver aus nicht löschbar? Wurde eine vollständige Wiederherstellung getestet?
Diese Fragen machen Datenbanksicherheit von einer einmaligen Installationsaufgabe zu einer dauerhaften Betriebsdisziplin. Überprüfen Sie sie nach Migrationen, größeren Änderungen an Anwendungen, Personalwechseln und Sicherheitsvorfällen. Eine Datenbank, die schwer erreichbar, streng berechtigt, gepatcht und wiederherstellbar ist, wird wesentlich seltener zu einem existenzbedrohenden Unternehmensvorfall.