Immer mehr Unternehmen betreiben ihre Datenbanken in der Cloud. Doch gerade bei sensiblen Daten kommt es auf die richtige Absicherung an. Sie müssen auch auf externen Servern und in Rechenzentren zuverlässig geschützt sein. Redgate, führender Anbieter von Database-DevOps-Lösungen für umfassende Datenbankkontrolle, empfiehlt dafür ein mehrschichtiges Sicherheitsmodell.
Cloudbasierte Datenbankdienste bieten viele Vorteile. Unternehmen benötigen keine eigene umfangreiche Serverumgebung und auch kein eigenes Rechenzentrum. Doch wie bei allen Cloud-Diensten ist besondere Vorsicht geboten, denn auch wenn Hyperscaler die grundsätzlichen Sicherheitsvorkehrungen ihrer IT-Infrastruktur großschreiben, vernachlässigen Unternehmen oft ihren Eigenanteil an holistischer Datenbanksicherheit. Redgate empfiehlt deshalb ein dreistufiges Modell. Es umfasst eine sichere Architektur, operative Security-Funktionen und Compliance.
Layer #1: Eine resistente Sicherheitsarchitektur
Eine gut durchdachte Sicherheitsarchitektur für cloudbasierte Datenbanken setzt vor allem auf Isolation, Segmentierung und klar geregelte Zugriffsrechte. Unternehmen sollten dabei die Control Plane und die Data Plane strikt voneinander trennen. So kann nicht automatisch jeder mit Verwaltungsrechten auch auf die gespeicherten Daten zugreifen. Auch der Netzwerkzugriff muss klar geregelt sein. Unternehmen sollten öffentliche Endpoints deaktivieren und den Zugriff nur über Private Link und VNET-Isolation ermöglichen. Ergänzend schützen Network Security Groups die Netzwerkverbindungen. Bei der Datenübertragung kommt es ebenfalls auf eine sichere Verbindung an. Dafür empfiehlt sich mindestens TLS (Transport Layer Security) 1.2, noch besser 1.3. Bei der Anmeldung von Usern und Anwendungen sollte man auf das Zero-Trust-Prinzip setzen. Dafür eignen sich beispielsweise Microsoft Entra ID und Managed Identities. Besonders weitreichende Zugriffsrechte sollten Unternehmen zudem nur zeitlich begrenzt vergeben.
Auf dieser Grundlage lassen sich weitere Sicherheitsfunktionen der Plattform nutzen. In Microsoft Azure kann beispielsweise der Defender for SQL ungewöhnliche Aktivitäten erkennen, etwa SQL-Injection-Angriffe oder auffällige Datenexporte. Viele Plattformen bieten außerdem automatische Schwachstellenanalysen an. Diese überprüfen die Einstellungen der Datenbank und gleichen sie mit festgelegten Sicherheitsstandards ab. Zusätzlichen Schutz bieten sogenannte Ledger-Tabellen. Durch eine kryptografische Verkettung lässt sich damit nachweisen, ob Daten nachträglich verändert wurden. Mit Always Encrypted können Unternehmen sensible Spalten in SQL Server oder Azure SQL Database bereits direkt auf dem Client verschlüsseln. Die benötigten Schlüssel verwalten sie in einem Key Vault. Eine weitere Möglichkeit ist dynamisches Data Masking. Die Funktion macht bestimmte Werte für User ohne UNMASK-Berechtigung unkenntlich.
Layer #2: Erweiterte Sicherheitsfunktionen
Im zweiten Security Layer geht es darum, die Sicherheitsgrundlagen in der Praxis umzusetzen. Ein wichtiger Baustein ist dabei die Zugriffskontrolle nach dem Least-Privilege-Prinzip. Das bedeutet: User sollten nur die Rechte erhalten, die sie wirklich benötigen. Dafür eignen sich rollenbasierte Modelle (RBAC), eine klare Separation of Duties und regelmäßige Überprüfungen der vergebenen Rechte. Auch die Verschlüsselung spielt eine wichtige Rolle. Neben TLS für die Datenübertragung und Transparent Data Encryption sowie Spaltenverschlüsselung für gespeicherte Daten braucht es ein sicheres Key-Management. Dazu gehören die Speicherung in Hardware Security Modules (HSM) und die regelmäßige Erneuerung von Keys und Zertifikaten.
Ein kontinuierliches Monitoring behält die Datenbank im Blick. Es erfasst Anmeldungen, Änderungen an Berechtigungen und Schemas sowie auffällige Queries. AI-gestützte Anomalieerkennung hilft zusätzlich, Angriffe und kompromittierte Accounts frühzeitig zu erkennen. Wichtig sind auch manipulationssichere Audit-Protokolle. Einheitliche Timestamps machen es möglich, Incidents später genau nachzuvollziehen. Weitere Maßnahmen sind sichere Standardeinstellungen, deaktivierte unnötige Funktionen, geschützte Admin-Interfaces und regelmäßige Konfigurationsprüfungen. Im Ernstfall können automatische Reaktionen die Sicherheit zusätzlich erhöhen. Sie sperren beispielsweise betroffene Accounts, isolieren Datenbank-Instanzen oder erstellen forensische Snapshots. Auch die Weiterleitung von Vorfällen an das Security Operations Center (SOC) lässt sich automatisieren.
Gerade in regulierten Branchen müssen Unternehmen diese Maßnahmen dokumentieren. Dazu gehören beispielsweise Protokolle zu Rechteprüfungen, Konfigurationsberichte und Nachweise zum Log- und Key-Management. Das Database-Team sollte diese Unterlagen deshalb regelmäßig erstellen und aufbewahren.
Layer #3: Weiterführende Cloud-Compliance
Cloud-Compliance umfasst mehr als nur einzelne Zertifizierungen. Entscheidend ist das Zusammenspiel aus technischen Sicherheitsmaßnahmen, klaren Workflows und gesetzlichen Policies. Cloud-Anbieter schaffen dafür eine Grundlage, indem sie Standards wie ISO 27001, SOC 2 und PCI DSS sowie europäische und nationale Vorgaben wie die DSGVO berücksichtigen. Unternehmen können diese Nachweise für ihre eigenen Audits nutzen. Das schafft Transparenz und Vertrauen.
Auch die Datenbanken selbst bieten verschiedene Möglichkeiten, um Compliance-Anforderungen einzuhalten. Über die Wahl der Cloud-Region und der Replikationsziele bestimmen Unternehmen, wo ihre Daten gespeichert werden und welche Länder sie nicht verlassen dürfen. Für die Verwaltung und regelmäßige Erneuerung der Verschlüsselungs-Keys stehen ein Key Vault oder ein Hardware Security Module (HSM) zur Verfügung. Auch die Zugriffe darauf werden protokolliert. Audit-Logs lassen sich außerdem in Storage, Log Analytics oder eine SIEM-Plattform (Security Information and Event Management) übertragen und dort sicher aufbewahren. Über einstellbare Backup-Aufbewahrungszeiten können Unternehmen zusätzlich vorgeschriebene Speicher- und Löschfristen einhalten.
„Cloud-Sicherheit ist kein Schalter, den man einfach umlegt, sondern funktioniert nur als Zusammenspiel mehrerer Security Layer“, warnt Oliver Stein, Geschäftsführer DACH bei Redgate. „Der Hyperscaler liefert beim Betrieb von Datenbanken in der Cloud das Sicherheitsfundament. Doch für Architektur, Zugriffe und Compliance bleibt das Unternehmen selbst verantwortlich. Wer das versteht und seine Sicherheitsstrategie entsprechend umsetzt, verwandelt seine Cloud-Implementierung vom Risikofaktor in einen Sicherheitsgewinn.“
Mehr Informationen dazu finden sich im Whitepaper von Redgate „Datenbanksicherheit in regulierten DACH-Umgebungen: Sicherheitsarchitekturen im KI-Zeitalter“.