Die wichtigsten Erkenntnisse
- Trennen Sie Datenbankserver von Webservern, damit Angreifer nicht auf die Datenbank zugreifen können, wenn der Webserver kompromittiert wurde. (Zum Abschnitt springen)
- Überprüfen und überwachen Sie die Datenbankaktivitäten regelmäßig, um verdächtiges Verhalten zu erkennen und darauf zu reagieren. (Zum Abschnitt springen)
- Implementieren Sie strenge Zugriffskontrollen nach dem Prinzip der geringstmöglichen Berechtigungen und überprüfen Sie die Benutzerberechtigungen regelmäßig. (Zum Abschnitt springen)
Datenbanken enthalten einige der sensibelsten Daten eines Unternehmens. Daher ist die Befolgung von Best Practices für Datenbanksicherheit entscheidend, um diese Daten vor Cyberangriffen und Datendiebstahl durch Insider zu schützen.
Eine wirksame Datenbanksicherheit schützt sensible Informationen durch mehrere Kontrollschichten, die das Risiko eines Sicherheitsverstoßes verringern und den möglichen Schaden eines erfolgreichen Angriffs begrenzen. Wir stellen sieben Best Practices für Datenbanksicherheit vor, die sich überschneidende Kontrollen schaffen, gefolgt von sieben weiteren Best Practices für verwandte Systeme. Das Ergebnis ist eine umfassende, mehrschichtige Abwehr, die Risiken im gesamten Unternehmen minimiert.
- Was ist Datenbanksicherheit?
- 7 Best Practices für Datenbanksicherheit
- 7 Best Practices für die Sicherheit verwandter Systeme
- Fazit: Best Practices für Datenbanksicherheit
Was ist Datenbanksicherheit?
Datenbanksicherheit umfasst die Kontrollen, die Unternehmen implementieren, um unbefugten Zugriff oder Datenverletzungen durch Datenbankdateien, Datenbankmanagementsysteme (DBMS) und verbundene Systeme zu verhindern. Zu den Sicherheitskontrollen gehören Architekturtechniken, Anwendungsdesign, Richtlinien, Prozesse und Tools, die den Zugriff auf und die Nutzung von Daten erschweren.
Eine schlecht umgesetzte Datenbanksicherheit beeinträchtigt die Effizienz des Betriebs, die Anwendungsleistung und die Benutzerfreundlichkeit. Die Sicherheit muss mit den Anforderungen des Betriebs abgewogen werden. Ziel ist es, das Risiko auf ein akzeptables Maß zu reduzieren und gleichzeitig die Benutzerfreundlichkeit zu erhalten.
Best Practices und Kontrollen für Datenbanksicherheit gelten speziell für Datenbanken. Datenbanken existieren jedoch nicht völlig isoliert, daher müssen Unternehmen auch das gesamte Ökosystem schützen. Für einen ausreichenden Schutz erfordert eine wirksame Datenbanksicherheit außerdem die Umsetzung allgemeinerer Best Practices für die Sicherheit verbundener Systeme.
Siehe die Top-Lösungen für Datenbanksicherheit
7 Best Practices für Datenbanksicherheit
Um eine Datenbank zu schützen, muss sie sich in einer abgesicherten Umgebung befinden, durch einen eigenen Perimeterschutz geschützt sein und von abgesicherten Benutzern genutzt werden. Diese sieben Best Practices sichern Datenbanken und Datenbanken-Daten gezielt ab.
1. Datenbankserver trennen
Webserver müssen definitionsgemäß öffentlich zugänglich sein, damit sie genutzt werden können. Dadurch werden sie jedoch zu einem vorrangigen Angriffsziel. Ein erfolgreicher Angriff kann einem Angreifer Zugriff auf den Hostserver der Website oder Anwendung verschaffen, wodurch er auf alles zugreifen kann, was sonst noch auf dem Server gehostet wird.
Datenbanken sollten in einen separaten Container, auf einem physischen Server oder auf einem virtuellen Server ausgelagert werden. So lassen sie sich zusätzlich härten und der Zugriff bleibt verwehrt, wenn die Website oder Anwendung kompromittiert wird. Auf dem separaten Server sollten nur die erforderlichen Ports geöffnet werden. Wenn möglich, sollte ein Unternehmen die standardmäßigen Kommunikationsports ändern, um Angriffe zu erschweren.
Manche empfehlen, zwischen Datenbank und Abfragen einen HTTPS-Proxyserver einzurichten. Die funktionale Trennung von Webserver und Datenbankserver erzielt jedoch dasselbe Ergebnis. Ein Proxyserver kann allerdings bei Datenbanken im internen Netzwerk sinnvoll sein, auf die autorisierte Netzwerkbenutzer oder -geräte direkt zugreifen können.
Um die Datenbank zusätzlich abzusichern, sollten Sie den Datenbankserver in einem separaten physischen oder virtuellen Netzwerksegment mit stark eingeschränkten Zugriffsberechtigungen platzieren. Mikrosegmentierung dieser Art kann verhindern, dass sich Angreifer mit allgemeinerem Netzwerkzugriff problemlos lateral zu einem Datenbankserver bewegen, der möglicherweise nicht im Netzwerk eines kompromittierten Benutzers sichtbar ist.
2. Datenbank-Firewalls verwenden
Datenbanken sind nur nützlich, wenn auf sie zugegriffen wird, doch dieser Zugriff muss geschützt werden. Die erste Verteidigungsschicht bilden datenbankspezifische Firewalls, die den Zugriff standardmäßig verweigern. Durch die Firewall sollte nur Datenverkehr von bestimmten Anwendungen, Webservern oder Benutzern zugelassen werden, die auf die Daten zugreifen müssen. Ohne konkreten Bedarf sollte die Firewall der Datenbank außerdem das Initiieren ausgehender Verbindungen untersagen.
Der direkte Zugriff auf die Datenbank sollte eingeschränkt oder verweigert werden, sofern der Anwendungsfall dies zulässt. Änderungen an Firewallregeln müssen durch Änderungsmanagementprozesse kontrolliert werden und Warnmeldungen für die Sicherheitsüberwachung auslösen.
Unternehmen können spezialisierte Datenbanktools einsetzen, die spezielle Firewalls enthalten, etwa die Oracle Audit Vault and Database Firewall, dedizierte physische oder virtuelle Next-Generation-Firewall (NGFW) oder Web Application Firewall (WAF). Unternehmen mit begrenzteren Ressourcen können einfach eine gehärtete Version der Betriebssystem-Firewall des Datenbankservers einsetzen.
3. Zugriff von Datenbankbenutzern absichern
Auf die Datenbank sollten möglichst wenige Benutzer, Anwendungen und Anwendungsprogrammierschnittstellen (APIs) zugreifen. Jeder Zugriff sollte erst nach einer Autorisierung durch das Netzwerk oder die Anwendung gewährt werden. Auch dann sollte jeder Zugriff nach dem Prinzip der geringstmöglichen Berechtigungen erfolgen und nur so lange wie unbedingt nötig bestehen. Diese Best Practice lässt sich in drei Unterkategorien aufteilen: Benutzerautorisierung, privilegierter Zugriff sowie die Datenbanknutzung durch Entwicklung und Betrieb (DevOps).
Benutzerautorisierung
Die Zugriffskontrolle für die Datenbank wird vom Systemadministrator oder Admin verwaltet. Der Admin erteilt Berechtigungen, die durch Rollen definiert werden, und fügt Benutzerkonten diesen Datenbankrollen hinzu. So schränkt beispielsweise die rollenbasierte Sicherheit auf Zeilenebene (Row-Level Security, RLS) den Lese- und Schreibzugriff auf Datenzeilen anhand der Identität eines Benutzers, seiner Rollenzugehörigkeit oder des Ausführungskontexts einer Abfrage ein.
Spezialisierte Lösungen für Datenbanksicherheit ermöglichen möglicherweise die zentrale Verwaltung von Identitäten und Berechtigungen, minimieren die Speicherung von Passwörtern und unterstützen Richtlinien für den Passwortwechsel. Eine umfassende Zugriffsverwaltung ist für kleinere Unternehmen möglicherweise nicht praktikabel. Dennoch bleibt es wichtig, Berechtigungen über Rollen oder Gruppen statt über einzelne Benutzer zu verwalten.
Administratoren müssen außerdem die Zugriffsregeln der Datenbank härten:
- Leere Passwörter dürfen nicht zugelassen werden
- Temporäre Installationsdateien, die Passwörter enthalten können, sollten gelöscht werden
- Standardkonten sollten gelöscht werden, wenn sie nicht benötigt werden; andernfalls sollten die Standardpasswörter geändert werden
- Für alle Benutzer müssen eindeutige IDs zur Nachverfolgung und Protokollierung vorgeschrieben werden
- Benutzer und Anwendungen sollten separate Konten verwenden
- Inaktive Benutzer sollten regelmäßig deaktiviert oder gelöscht werden
- Erweiterte Datenbankberechtigungen sollten protokolliert und gemeldet werden und gegebenenfalls Sicherheitswarnungen auslösen
- Benutzergruppen und Zugriffsrechte sollten regelmäßig überprüft werden
- Konten sollten nach einer bestimmten Anzahl fehlgeschlagener Anmeldungen automatisch gesperrt werden; in der Regel werden sechs fehlgeschlagene Anmeldeversuche empfohlen
Privilegierter Zugriff
Administratoren sollten nur über die unbedingt erforderlichen Berechtigungen verfügen, und auch nur für die Dauer, in der sie den Zugriff tatsächlich benötigen. Privilegierter Zugriff sollte vorübergehend gewährt und kontinuierlich entzogen werden. Größere Unternehmen automatisieren die Zugriffsverwaltung mithilfe von Software für Privileged Access Management (PAM). PAM stellt autorisierten Benutzern ein temporäres Passwort bereit, protokolliert Aktivitäten und verhindert die Weitergabe von Passwörtern.
Datenbanknutzung durch DevOps
Obwohl sie normalerweise nicht als Benutzer betrachtet werden, müssen DevOps-Teams Testumgebungen erstellen, um zu überprüfen, ob Anwendungen korrekt auf Datenbanken zugreifen und diese nutzen können. Die Verwendung von Daten aus Live- oder Produktionsdatenbanken führt jedoch häufig zu versehentlichen Datenlecks.
Um Probleme zu vermeiden, sollte DevOps die folgenden Best Practices anwenden:
- Sensible Daten sollten auf die Produktionsumgebung beschränkt werden
- Testumgebungen sollten physisch und logisch von Produktionsumgebungen getrennt sein
- Testumgebungen sollten andere Rollen und Berechtigungen verwenden als Produktionsumgebungen
- Entwickler sollten keinen Zugriff auf Produktionsumgebungen erhalten, sofern dies nicht unbedingt erforderlich ist
- Testumgebungen sollten niemals echte Produktionsdaten enthalten; stattdessen sollten synthetische oder anonymisierte Datensätze verwendet werden
4. Datenbank härten
Ebenso wie der Server muss auch die Datenbank gehärtet werden, um einfache Angriffe und Exploits zu verhindern.
Die Härtung einer Datenbank hängt vom jeweiligen Datenbanktyp ab. Zu den gängigen Maßnahmen gehören die Verbesserung des Passwortschutzes und der Zugriffskontrollen, die Absicherung des Netzwerkverkehrs sowie die Verschlüsselung sensibler Felder in der Datenbank.
Alle nicht verwendeten oder unnötigen Dienste und Funktionen der Datenbank sollten entfernt oder deaktiviert werden, um eine unerkannte Ausnutzung zu verhindern.
Alle von der Datenbank bereitgestellten Sicherheitskontrollen sollten aktiviert werden. Einige sind standardmäßig aktiviert, bei anderen kann es konkrete Gründe für eine Deaktivierung geben. Jede Kontrolle sollte jedoch bewertet und alle Gründe für deaktivierte Kontrollen sollten dokumentiert werden. Wenn möglich, können Administratoren die Sicherheit auf Zeilenebene und dynamisches Datenmasking für sensible Daten aktivieren.
DevOps sollte die Datenbank so konzipieren, dass sensible Informationen in getrennten Tabellen verbleiben. Administratoren sollten die Daten außerdem kontinuierlich überprüfen, um sensible Daten zu erkennen und festzustellen, ob die getrennten Tabellen angepasst oder zusätzliche Sicherheitsmaßnahmen angewendet werden müssen. Einige regulatorische oder Compliance-Standards schreiben konkrete Anforderungen an die Datenermittlung vor, die implementiert, befolgt und dokumentiert werden müssen, um die Compliance nachzuweisen.
Außerdem lesenswert: Netzwerkschutz: So sichern Sie ein Netzwerk ab
5. Datenbankaktivitäten überprüfen und kontinuierlich überwachen
DevOps-Konzepte basieren auf bestimmten Erwartungen. Nach der Integration von Datenbanken in Anwendungen und ihrer Überführung in eine Produktionsumgebung kann es jedoch zu unerwarteten Zugriffen, Benutzerabfragen oder Datenverhalten kommen. Administratoren müssen Datenbankprotokolle, Daten und Aktivitäten kontinuierlich überwachen und überprüfen, darunter:
- Benutzeranmeldeprotokolle, insbesondere versuchte und fehlgeschlagene Anmeldungen
- Gesperrte Konten (aufgrund zu vieler fehlgeschlagener Anmeldeversuche)
- Ausweitung von Datenbankberechtigungen
- Extraktion, Kopieren oder Löschen von Daten aus der Datenbank (insbesondere umfangreiche Änderungen oder Extraktionen)
- Zugriff auf sensible oder regulierte Daten (kann für die Compliance erforderlich sein)
- Erstellung neuer Konten
Überprüfungen können häufig anomale Aktivitäten erkennen, und Sicherheitsteams können für kritische Ereignisse Sicherheitswarnungen einrichten, um Sicherheitsteams zu warnen oder Security Information and Event Management (SIEM)-Tool-Warnungen zu ermöglichen. Software zur Datenbankaktivitätsüberwachung (DAM) und zur Überwachung der Dateiintegrität kann unabhängig von den nativen Protokollierungs- und Überprüfungsfunktionen der Datenbank spezialisierte Sicherheitswarnungen bereitstellen.
6. Datenbanksicherheit testen
Obwohl Überprüfungen laufende böswillige Aktivitäten erkennen können, sollten Unternehmen nicht auf Angriffe warten, um ihre Datenbankbereitstellungen zu testen. Datenbankanbieter sollten auf Aktualisierungen überwacht werden, und Patch-Management-Prozesse sollten Datenbanken mit minimaler Verzögerung aktualisieren.
Durch das Patchen werden jedoch nur öffentlich bekannt gegebene Schwachstellen behoben. Einige Datenbankanbieter stellen Tools für Sicherheits- und Konfigurationstests bereit, etwa Oracles Database Security Assessment Tool, mit denen sich Risiken erkennen lassen. Es sollte jedoch nicht davon ausgegangen werden, dass diese Tools eine 100-prozentige Sicherheit gewährleisten. Sie sollten durch anschließende Tests mit Schwachstellenscans und Penetrationstests ergänzt werden, die potenzielle Angriffe simulieren, um Fehlkonfigurationen, versehentlich zugängliche Daten und andere Probleme aufzudecken.
7. Best Practices für Daten
Datenbanken strukturieren Daten, doch auch die in der Datenbank enthaltenen Daten müssen geschützt werden. Der erste Schritt besteht darin, dass ein Unternehmen nur die für die Geschäftsfunktion erforderlichen geschützten Daten speichert. Durch die Beseitigung übermäßiger Datenmengen oder das Löschen unnötiger historischer Informationen lässt sich die Risikoexposition minimieren.
Anschließend müssen die Daten gezielt kontrolliert werden. Redundante geschützte Daten sollten im gesamten System beseitigt werden, und eine Spiegelung geschützter Daten außerhalb des führenden Systems muss nach Möglichkeit vermieden werden. Hashing-Funktionen können auf geschützte Datenelemente angewendet werden, bevor die für Abgleichzwecke erforderlichen Daten außerhalb des Systems gespeichert werden. Nach Möglichkeit sollten geschützte Daten wie Gesundheitsinformationen oder Kreditkartennummern von personenbezogenen Daten (PII) getrennt werden.
Verschlüsselung sollte ebenfalls zum zusätzlichen Schutz eingesetzt werden. Viele Anbieter stellen Lösungen bereit zur Verschlüsselung ruhender Daten, übertragener Daten oder sogar genutzter Daten. Innerhalb der Datenbank kann DevOps Daten verschlüsseln oder Datenmaskierung verwenden, um Daten in Tabellen zu verbergen. Einige Verschlüsselungstools ermöglichen sogar die Verarbeitung und Suche von Daten ohne Entschlüsselung, sodass die Daten stets verschlüsselt und geschützt bleiben.
Einige Cloudanbieter wie Oracle verschlüsseln gespeicherte Daten standardmäßig oder stellen Tools zur Verwaltung von Verschlüsselungsschlüsseln bereit, etwa Azure Key Vault. Unternehmen selbst sind jedoch dafür verantwortlich, während der gesamten Datenspeicherung und Datenübertragung für ausreichenden Schutz zu sorgen.
7 Best Practices für die Sicherheit verwandter Systeme
Wenn eine Sicherheitsmaßnahme nicht speziell auf Datenbanken zutrifft, kann sie nicht ausschließlich als Bestandteil der Datenbanksicherheit betrachtet werden. Dies schmälert jedoch weder die Bedeutung dieser Maßnahmen noch die Notwendigkeit, sie zur Gewährleistung der Datenbanksicherheit umzusetzen.
1. Best Practices für physische Sicherheit
Obwohl sie manchmal übersehen wird, darf physische Sicherheit nicht als selbstverständlich vorausgesetzt werden. Der physische Zugriff eines Angreifers auf ein Rechenzentrum kann selbst die besten Verfahren und Technologien für Cybersicherheit untergraben. Der Schutz einer physischen Umgebung mit Servern und Netzwerkgeräten sollte die erste Best Practice für grundlegende IT-Sicherheit sein.
Lokale Rechenzentren benötigen physische Sicherheitsmaßnahmen wie Kameras, Schlösser und Sicherheitskräfte vor Ort. Jeder physische Zugriff auf Server sollte kontrolliert, protokolliert und regelmäßig überprüft werden. Wenn ein regelmäßiger Zugriff unüblich ist, sollten Warnungen erzeugt werden.
In der Cloud gehostete Ressourcen liegen möglicherweise außerhalb der direkten physischen Kontrolle eines Unternehmens, nicht jedoch außerhalb seiner Verantwortung. Das Unternehmen muss weiterhin ausreichende physische Sicherheit bestätigen. Diese wird normalerweise dadurch gewährleistet, dass der Cloudanbieter die in einer Compliance-Richtlinie wie der folgenden enthaltenen Standards für physische Sicherheit einhält:
- ISO 27001
- ISO 20000-1
- NIST SPs (SP 800-14, SP 800-23 und SP 800-53)
- US-Verteidigungsministerium Information-Assurance-Technical-Framework
- SSAE 18 SOC 1 Type II, SOC 2 Type II und SOC 3
2. Webanwendungs- und Netzwerk-Firewalls verwenden
Firewalls bieten grundlegenden Schutz für alle IT-Ressourcen. Zusätzlich zum Einsatz einer Firewall für die Datenbank müssen Unternehmen Next-Generation-Firewalls (NGFW) zum Schutz ihrer Netzwerke und Web Application Firewalls zum Schutz der Websites und Anwendungen einsetzen, die auf die Datenbank zugreifen.
Diese allgemeineren Firewalls schützen das gesamte Unternehmen vor Angriffen, die Datenbanken ebenso wie andere Systeme betreffen, etwa vor SQL-Injection-Angriffen und Distributed Denial of Service- (DDoS-)Angriffen.
3. Benutzerauthentifizierung
Wenn Datenbanken Benutzern Zugriff gewähren, wird grundsätzlich davon ausgegangen, dass der Benutzer bereits authentifiziert und seine Identität nachgewiesen wurde. Best Practices für die Sicherheit erfordern die Authentifizierung oder Identitätsprüfung aller Benutzertypen, etwa von Gästen, Mitarbeitern, Kunden und Administratoren. Zu den Unterkategorien der Sicherheit bei der Benutzerauthentifizierung gehören das Management von Insiderbedrohungen, die Benutzerüberprüfung und Privileged Access Management (PAM).
Management von Insiderbedrohungen
Manche Daten können so wertvoll sein, dass kriminelle Organisationen Mitarbeiter dafür bezahlen, sie zu verraten, oder sogar eigene Mitglieder unter falschen Voraussetzungen in Unternehmen einschleusen, um Zugriff auf Daten zu erlangen. Um diese Probleme durch Insiderbedrohungen zu minimieren, sollten Unternehmen Hintergrundüberprüfungen bei Programmierern, Auftragnehmern, Sicherheitsexperten, Datenbankadministratoren und allen anderen Personen durchführen, die auf sensible Informationen zugreifen oder diese umleiten können.
Siehe die Top-Lösungen zur Verhinderung von Datenverlust (DLP)
Nachdem die Identitäten der Mitarbeiter bestätigt wurden, implementieren Unternehmen Analysetools für das Benutzer- und Entitätsverhalten (UEBA), UEBA-Funktionen in anderen Sicherheitstools und Auditprotokolle, um Anzeichen für unangemessenes oder abnormales Verhalten zu erkennen. Dabei ist zu beachten, dass gestohlene Zugangsdaten, die von einem Hacker verwendet werden, für die meisten Sicherheitstools wie autorisierter Zugriff aussehen, bis ungewöhnliches Verhalten erkannt wird. Schließlich sollte eine Richtlinie zur Deaktivierung von Konten oder unnötigen Zugriffen erstellt werden, wenn Mitarbeiter in andere Rollen wechseln oder das Unternehmen verlassen.
Benutzerüberprüfung
Um die Integrität einer bestätigten Identität zu wahren, müssen Benutzer ihre Identität regelmäßig oder im Fall von Zero Trust) sogar ständig bestätigen. Passwörter sind nach wie vor die am häufigsten verwendete Methode zur Identitätsprüfung. Einige Unternehmen haben jedoch begonnen, passwortlose Authentifizierung einzusetzen.
Für Administrator- und andere privilegierte Konten sollten Unternehmen immer Multi-Faktor-Authentifizierung (MFA) verwenden. Für besonders wichtige Daten sollten Unternehmen den Einsatz physischer MFA in Betracht ziehen, etwa Magnetkarten, USB-Token und andere Methoden, die von Angreifern aus der Ferne nicht gestohlen oder leicht nachgebildet werden können.
Unternehmen, die Passwörter verwenden, sollten sichere Passwörter und Passwortverwaltung einsetzen:
- Passwortkomplexität (eine Mischung aus Groß- und Kleinschreibung, Zahlen und Sonderzeichen) oder Passphrasen (wesentlich längere Passwörter) sollten vorgeschrieben werden
- Die Passwortlänge sollte mindestens 8 Zeichen betragen, bei privilegierten Konten länger sein
- Passwort-Hashes sollten verschlüsselt und mit Salt gespeichert werden
- Konten sollten nach wiederholten und fehlgeschlagenen Anmeldeversuchen gesperrt werden; bei normalen Benutzerkonten nach bis zu sechs und bei privilegierten oder Administratorkonten bereits nach drei fehlgeschlagenen Versuchen
- Passwörter sollten ablaufen
Unternehmen, die Passwortmanager einsetzen, können eine höhere Komplexität und häufigere Passwortänderungen verlangen, ohne befürchten zu müssen, dass Benutzer ihre Passwörter an unsicheren oder gefährdeten Orten speichern. Der Benutzerzugriff sollte regelmäßig erneuert werden, um den Zugriff veralteter und vergessener Benutzer oder Geräte zu verhindern.
Management privilegierter Konten
Der Missbrauch von Administratorzugriffen kann enormen Schaden anrichten. Daher müssen Administratoranmeldedaten durch zusätzliche Maßnahmen geschützt werden. Nicht nur die Passwortanforderungen sollten strenger sein, sondern Unternehmen müssen möglicherweise auch Privileged-Access-Management-Tools (PAM) in Betracht ziehen, die temporäre Passwörter mit eingeschränkten Berechtigungen erzeugen, sodass sich autorisierte Benutzer bei jedem Zugriff auf die Datenbank authentifizieren müssen.
Unabhängig davon, ob spezielle Tools verwendet werden, sollte der privilegierte Zugriff zusätzlichen Regeln unterliegen:
- Keine Weitergabe von Passwörtern
- Alle Sitzungen und Aktivitäten werden protokolliert und regelmäßig überprüft
- Jede Ausweitung von Benutzerberechtigungen wird protokolliert und regelmäßig überprüft
4. Gerätesicherheit
Alle Geräte, die auf die Datenbank zugreifen, sowie das Netzwerk allgemein müssen überprüft und kontinuierlich auf eine mögliche Kompromittierung überwacht werden. Antiviren-schutz bietet ein Mindestmaß an Schutz. Für einen umfassenderen Schutz setzen Unternehmen jedoch häufig Tools für Endpoint Detection and Response (EDR) oder Tools für Extended Detection and Response (XDR) ein, die eine proaktivere Erkennung ermöglichen.
Administratorgeräte sollten durch die Beschränkung von IP- und MAC-Adressen, Positivlisten oder Netzwerkzugriffskontrolle (NAC) weiter eingeschränkt werden. Diese Maßnahmen begrenzen die Anzahl der Geräte, die auf sensible Bereiche zugreifen dürfen, und verhindern so, dass gestohlene Zugangsdaten für einen Hacker besonders nützlich sind.
Für die Infrastruktur der Datenbank (oder anderer sensibler Systeme) sollte das Unternehmen alle Geräte, Anwendungen und Tools dokumentieren. Außerdem müssen Konfigurationsdateien und Quellcode abgesichert werden. Sie dürfen nur über geschützte Administratorkonten zugänglich sein und müssen durch Richtlinien und Tools für das Änderungsmanagement geschützt werden.
Zuletzt sollten alle Systeme überwacht werden. Netzwerke sollten durch XDR oder Intrusion-Detection- und -Prevention-Systeme (IDPS)-Tools überwacht werden. Alle Sicherheitssysteme sollten Warnmeldungen an Security Information and Event Management (SIEM)-Tools, Security Operations Center (SOCs) oder Managed Detection and Response (MDR)-Teams weiterleiten.
5. Anwendungs- und API-Sicherheit
Anwendungen und APIs, die eine Verbindung zur Datenbank oder zu anderen IT-Ressourcen herstellen, müssen abgesichert werden. DevOps sollte zunächst Tools zum Schwachstellenscanning auf intern entwickelten Websites und Anwendungen einsetzen. Größere Unternehmen werden Tools für Anwendungssicherheit und API-Sicherheitstools einsetzen, um Systeme zusätzlich zu schützen und zu überwachen.
Außerdem lesenswert: Anwendungssicherheit: Vollständige Definition, Arten und Lösungen
6. Betriebssystem und Patches regelmäßig aktualisieren
Die besten Sicherheitstools und -strategien werden durch mangelhafte Wartung zunichtegemacht. Alle Systeme, Anwendungen, Tools und Firmware sollten auf neu veröffentlichte Patches oder bekannt gewordene Schwachstellen überwacht werden. Kritische Systeme, etwa solche mit Verbindung zu Datenbanksystemen, sollten für regelmäßiges Patch-Management und Schwachstellenmanagement priorisiert werden. Komponenten der Softwarelieferkette, etwa Open-Source-Bibliotheken, sollten ebenfalls auf Schwachstellen und Aktualisierungen hin verfolgt und entsprechend bearbeitet werden.
7. Best Practices für die Geschäftskontinuität
Selbst der beste Plan kann auf Probleme stoßen. Unabhängig davon, ob die Ursache ein unzufriedener Mitarbeiter, ein böswilliger Hacker, ein Stromausfall oder eine Überschwemmung ist: Die Best Practices für Geschäftskontinuität und Notfallwiederherstellung sorgen für resiliente Systeme und eine schnelle Wiederherstellung.
Redundante Architekturen gewährleisten den unterbrechungsfreien Betrieb im Falle eines Systemausfalls. Server können durch aktive-passive Redundanz für eine Ausfallsicherung oder durch Server mit Lastverteilung, die potenzielle Lasten auf mehrere Server verteilen, widerstandsfähiger gemacht werden.
Daten- und Systemsicherungen schützen vor einem vollständigen Systemausfall oder böswilligen Aktivitäten. Sicherungen sollten regelmäßig erstellt und umfassend geschützt werden. Best Practices folgen der 3-2-1-Regel für Sicherungen: drei Kopien der Sicherungsdaten, zwei Speichertypen und mindestens eine Kopie, die extern und offline gespeichert wird. Sicherungen dürfen keinesfalls öffentlich zugänglich sein und sollten verschlüsselt sowie getrennt von den Verschlüsselungsschlüsseln gespeichert werden.
Sicherungen sollten nicht nur Daten, sondern auch die Einstellungen, Softwareanwendungen und Konfigurationen der unterstützenden Infrastruktur umfassen, um eine schnelle Wiederherstellung betroffener Systeme zu ermöglichen. Sicherungen geschäftskritischer Infrastruktur sollten regelmäßig getestet werden, um die Wirksamkeit der Sicherungsprozesse zu überprüfen und zugleich Richtwerte für die erwartete Wiederherstellungsdauer festzulegen.
Außerdem lesenswert: Eine gegen Ransomware resistente Architektur entwickeln
Fazit: Best Practices für Datenbanksicherheit
Datenschutzverletzungen können eine Vielzahl von Geldstrafen, negativen Auswirkungen auf das Geschäft und Klagen nach sich ziehen. Leider können Unfälle und Sicherheitsvorfälle auch bei vorbereiteten Unternehmen auftreten, und die dadurch entstehenden Kosten stehen in direktem Zusammenhang mit den Risiken, die ein Unternehmen zu akzeptieren bereit ist. Gute Best Practices für Datenbanksicherheit wirken dem zunehmenden Risiko von Datenschutzverletzungen entgegen, selbst wenn die Zahl der Angriffe und die finanziellen Folgen zunehmen. Unternehmen sollten möglichst viele Best Practices überprüfen, übernehmen und dauerhaft umsetzen, um ihr Risiko von Datenschutzverletzungen zu senken und die erwarteten Kosten künftiger Vorfälle zu reduzieren.
Weiterlesen: Sicherheitsaspekte von Data Lakes
Dieser Artikel wurde ursprünglich von Paul Rubens verfasst und am 21. April 2023 von Chad Kime aktualisiert.