Datenbank-Security: So sichern Unternehmen ihre Cloud-Datenbanken ab
Eine Datenbank ist das Herzstück vieler Anwendungen. Umso gefährlicher wird es, wenn dieses Herzstück Hackern ein Hintertürchen in die Systemarchitektur öffnet. Kein Wunder also, dass etliche Unternehmen die Migration ihrer Datenbank in die Cloud scheuen. Zu groß scheinen die damit verbundenen Unsicherheiten, auch wenn Vorteile wie Hochverfügbarkeit und Skalierbarkeit locken.
Acht von zehn Unternehmen nutzen laut dem letzten Cloud-Monitor des Digitalverbandes Bitkom bereits Cloud-Computing [1]. Das Spektrum der Anwendungen ist breit und viele Unternehmen setzen Cloud-Datenbanken ein. Auch grenzübergreifend ergibt sich ein ähnliches Bild: Einer Umfrage der International Data Corporation (IDC) zufolge sind 63 Prozent der befragten Unternehmen dabei, ihre Datenbanken in die Cloud zu verschieben oder haben das bereits getan [2]. Das Vertrauen in diese Form der Datenbankmanagementsysteme (DBMS) ist also hoch. Es erstreckt sich nicht nur auf Performance, Skalierbarkeit und einfache Konfiguration, sondern auch auf die Datenbanksicherheit.
Die Aufgabenteilung zwischen Anbieter und Unternehmen
Viele Security-Maßnahmen sind leicht umzusetzen, da die Anbieter ihre Systeme mit zahlreichen Konfigurationsoptionen für Security ausgerüstet haben. Das darf die nutzenden Unternehmen aber nicht zu einem Missverständnis verführen: dass nur der Anbieter alleine für die Datenbanksicherheit zuständig sei. Das ist falsch, denn in der Cloud gilt die geteilte Verantwortung. Dabei sind die Provider in einem genau definierten Rahmen für Security und andere Anforderungen zuständig, doch die nutzenden Unternehmen müssen ebenfalls Aufgaben bei der Datenbanksicherheit übernehmen. Leider wird dies gelegentlich übersehen oder nicht präzise umgesetzt. So gab es einige Security-Pannen, bei denen Millionen Datensätze in den Storage-Diensten von Cloud-Providern frei verfügbar für Zugriffe aus dem Internet waren. In der Praxis kann diese geteilte Verantwortung unterschiedliche Ausprägungen annehmen. So gibt es:
- Die Datenbank als selbstgemanagte Infrastruktur: Im ersten Fall nutzen die Unternehmen bei einem Anbieter virtuelle Server, auf denen auch Datenbanksysteme installiert werden können. Hier ist der Provider lediglich für den störungsfreien Betrieb der physischen Infrastruktur verantwortlich, aber nicht für die virtuellen Server und die Datenbanksicherheit – diese liegt bei den Admins selbst.
- Die Datenbank als providergemanagter Service: Bei der Nutzung von Cloud-Datenbanken nach diesem Modell reicht die Verantwortung der Provider etwas weiter. Es handelt sich dabei um ein Serviceangebot, häufig als Database-as-a-Service (DBaaS) bezeichnet. Hier kümmert sich der Anbieter nicht nur um die physische Infrastruktur, sondern auch um die virtuellen Maschinen und um die Datenbank-Server selber.
Bei DBaaS hat das nutzende Unternehmen eine geringere Verantwortung für die Datenbanksicherheit: Die Administratoren ersparen sich den Roll-out von Aktualisierungen und erhalten oft zusätzlich eine übersichtliche und entsprechend moderner Standards gestaltete Admin-Lösung. Einige wenige Security-Maßnahmen bleiben aber beim nutzenden Unternehmen.
Vor der Erstkonfiguration: An Governance und Compliance denken!
Datenbanksicherheit beginnt nicht erst mit dem "Anschalten" des ersten Servers oder der Plattform-Services. Bereits bei der Auswahl des Anbieters und des DBMS sind sicherheitsrelevante Überlegungen nötig. So sollte der gebuchte Service in die IT-Governance des nutzenden Unternehmens passen. Wichtig sind hier Zertifizierungen, etwa nach ISO 27001. Im Geschäftsverkehr hat es sich inzwischen eingebürgert, eine ISO-Zertifizierung zu besitzen, um überhaupt als Zulieferer oder Dienstleister gelistet zu werden. Dies wirkt sich auch auf genutzte Cloud-Datenbanken aus.
Der einfachste Weg: Die Unternehmen buchen einen vertrauenswürdigen Anbieter, der nach einschlägigen Normen und Standards zertifiziert ist. Hier gibt es inzwischen einen ganzen Katalog, beispielsweise ISO 27001 als genereller Security-Standard und andere Normen wie ISO 2718 zum Schutz von personenbezogenen Daten in der Public Cloud. Weitere Signale für vertrauenswürdige Anbieter sind die C5-Cloud-Zertifizierung des Bundesamtes für Sicherheit in der Informationstechnik (BSI), eine Bewertung der Organisation nach SOC 2 Type 1 oder 2 sowie Gütesiegel wie SaaS von EuroCloud, CSA STAR Level 2 und TÜV Trust IT. Mit solchen Zertifizierungen beweisen Provider die Erfüllung von Sicherheitsanforderungen. Das gilt für die Verankerung von Security in den Unternehmensprozessen, im Design der Plattform als auch im Betrieb.
Sowohl Verfügbarkeit als auch Business Continuity sind eine Frage des richtigen Providers. Sie bieten häufig eine Mindestverfügbarkeit von 99,99 Prozent an, was einer durchschnittlichen Ausfallzeit von etwa 52 Minuten im Jahr entspricht. Einige Anbieter werben sogar mit 99,999 Prozent. Das bedeutet bezogen auf ein Jahr gut fünf Minuten Stillstand. Diese 99.99% werden unter anderem durch die Nutzung von mehreren Verfügbarkeitszonen erreicht. Bei Ausfall der Hauptdatenbank wird die permanent aktuell gehaltene Kopie einer anderen Zone oder Region aktiv. Wenn dieser Service angeboten wird, ist er aber mit zusätzlichen Kosten verbunden. Kund:innen sollten sich jedoch vor Buchung auch die Ausfallhistorie des Providers ansehen.
Eine weitere Frage bei der Auswahl des richtigen Datenbank-Service betrifft die Compliance, in erster Linie zur Datenschutz-Grundverordnung (DSGVO) der EU. Hier gibt es unterschiedliche Philosophien: So gilt in zahlreichen deutschen Unternehmen, vor allem aus dem industriellen Mittelstand, häufig die Devise: deutsche Anbieter und Private Cloud für alle Kernsysteme. Das bedeutet allerdings nicht, dass die Firmen auf Hyperscaler verzichten müssen. Normalerweise ist es möglich, die geographische Region – in diesem Fall Europa – für die Datenspeicherung selbst zu wählen. Außerdem können die US-Anbieter für alle Systeme genutzt werden, in denen es nicht um personenbezogene Daten geht. So ist es beispielsweise datenschutzrechtlich unproblematisch, anonyme Prozess- und Maschinendaten verschlüsselt dort zu speichern.
Weitere Compliance-Überlegungen betreffen einzelne Branchen. So gelten für Unternehmen in den sogenannten KRITIS-Branchen (Kritische Infrastrukturen) zusätzliche Anforderungen an die IT-Security [3]. Dies betrifft unter anderem die Berichtspflichten nach dem IT-Sicherheitsgesetz. Hierfür benötigen Unternehmen regelmäßig Zugriff auf sämtliche Protokolldateien sowie die Angaben eines Monitoring-Systems, um rechtssichere Ereignis-Meldungen an die Behörden zu senden. Zudem gibt es weitere spezifische Regulierungen beispielsweise für Finanzinstitute und Versicherungen, etwa SOX (Sarbanes-Oxley) oder Solvency II. Sie haben auch Auswirkungen auf die IT und damit die genutzten Datenbanken. In aller Regel müssen hier ebenfalls spezifische Security-Maßnahmen in Audits nachgewiesen werden.
Kurz: Unternehmen sollten sich auf jeden Fall intensiv mit Fragen der Compliance und Governance beschäftigen, die vom Einsatz der Cloud-Datenbanksysteme aufgeworfen werden. Inzwischen gibt es fast keine Branche mehr, die nicht jenseits der Anforderungen an einen IT-Grundschutz nach BSI-Vorgaben einen größeren Katalog zusätzlicher Security-Richtlinien zu erfüllen hat.
Bedrohungsszenarien in der Cloud
Cloud-Datenbanken sehen sich unterschiedlichen Bedrohungen gegenüber.
- Packet Sniffing ist eine Angriffsform, bei denen Cyberkriminelle die Datenpakete in einem Computernetzwerk sammeln und versuchen, Informationen über einen möglichen Zugang zu dem DBMS zu erhalten.
- Bei einem Man-in-the-Middle-Angriff schiebt sich ein von Cyberkriminellen betriebener Server zwischen Anwender:in und Datenbanksystem. Er könnte zum Beispiel Nutzername und Passwort abfangen und sich somit Zugang zum DBMS verschaffen. Meist beginnt ein solcher Angriff mit einer Phishing-Mail, die zu unvorsichtigen Aktionen verleiten will. So versteckt sich beispielsweise hinter einer unvermuteten Aufforderung zum Ändern des Passwortes möglicherweise ein Cyberangriff.
- Ein weiteres Angriffsmuster sind (Distributed-)Denial-of-Service-Attacken (DDoS). Sie verwenden kompromittierte Anwendungen oder (IoT-)Geräte, um Datenbanksysteme mit einer Vielzahl von Abfragen zu überfluten. Dies betrifft häufig E-Commerce-Anbieter, bei denen gleichzeitig Webserver und die Shopsysteme überlastet werden.
- Ein direkter Eingriff in die Anwendung ist eine SQL-Injection-Attacke. Hierbei senden Angreifer gezielt manipulierte Anfragen an die Datenbank, sodass sie sensible Daten lesen, löschen oder verändern können.
Zur Abwehr einiger Angriffe bieten Cloud-Datenbanken heutzutage üblicherweise einen sogenannten Datenbank-Proxy. Er sitzt zwischen der Anwendung und der eigentlichen Datenbank und stellt im Namen dieser Anwendung eine Verbindung zur Datenbank her. Ein moderner Datenbank-Proxy ist mit Filtern ausgestattet, mit denen alle Abfragen untersucht werden. Zudem kann er Datenbankanfragen blockieren, wenn sie laut einer Whitelist nicht erlaubt sind. So wird es Cyberkriminellen erschwert, die Datenbank auszunutzen. Darüber hinaus schützt ein solcher Proxy auch vor DDoS-Angriffen. Er absorbiert einen Teil der Last oder ist mit einem Loadbalancer verbunden, der diese Angriffe ins Leere laufen lässt.
Absicherung der Netzwerkverbindungen
Doch die Aktivierung solcher in das Datenbanksystem integrierten Module reicht nicht aus. Eine grundlegende Security-Überlegung betrifft die Verbindung der einzelnen Nutzer:innen bzw. Anwendungen mit der Cloud-Datenbank. Entscheidend ist hierbei, ob sie sich in derselben oder einer anderen Infrastruktur oder Cloud befindet. Der einfachste Fall tritt dann ein, wenn das Unternehmen seine IT-Infrastruktur und die Datenbankplattform beim selben Cloudanbieter betreibt. In diesem Fall gibt es nur eine cloud-interne Verbindung, die leicht zu schützen ist.
In den beiden anderen Fälle laufen die Unternehmensanwendungen im klassischen Unternehmensnetzwerk (Abb. 2) oder in einer anderen Cloud (Abb. 3).
In diesen beiden Fällen (Abb. 2 & 3), läuft die Verbindung zur Datenbank über das Internet. Hier sind besondere Schutzmaßnahmen erforderlich. Die erste Sicherungsoption ist ein VPN-Zugang. Er baut einen verschlüsselten, privaten Tunnel zwischen dem Datenbanknetzwerk und dem Netzwerk des Unternehmens auf. Sollte der Provider das nicht anbieten, muss dem Datenbankzugang eine Firewall mit IP-Adress-Filterung vorgeschaltet sein. In diesem Fall dürfen sich nur ganz bestimmte Clients mit dem DBMS verbinden und sie werden anhand ihrer IP-Adresse erkannt. Dabei gibt es die Möglichkeit, nur IP-Adressen oder Adressbereiche aus dem Firmennetzwerk zu erlauben.
Ein Problem sind hier die Anwendungen von Roaming-Usern, die unter Umständen weltweit von unterschiedlichen Internetzugängen aus auf die Datenbank zugreifen. Hierfür muss die Datenbank frei zugänglich im Internet sein. Inzwischen dürfte dies in vielen Unternehmen der Regelfall sein, Schutzmaßnahmen wie VPN oder Firewall sind zwar vorgelagert, aber eher als zusätzliche Maßnahme zu verstehen. Grundsätzlich müssen zwei Maßnahmen gleichzeitig umgesetzt werden, um Datenbanksysteme wirksam zu schützen: Zugangskontrolle und Verschlüsselung.
Rollen- und rechtebasierte Zugangskontrolle
Zugangskontrolle richtet sich auf die strenge Vergabe von Benutzerrollen und -rechten mit einem Identity-&-Access-Management (IAM). Viele Unternehmen setzen damit das sogenannte Zero-Trust-Prinzip in ihrem IT-Service-Management um. Es bedeutet vereinfacht ausgedrückt, dass sich alle Anwender:innen bei Computersystemen anmelden müssen und einen mit entsprechenden Rechten versehenen Zugang erhalten. Das betrifft auch die Cloud-Datenbanken.
- Zugangskontrollen auf Admin-Ebene: Wichtig ist hier der Unterschied zwischen dem eigentlichen Datenbankzugang und der Managementebene, die den Zugriff auf alle Managementfunktionen gibt, etwa das Anlegen oder Löschen von Datenbank-Instanzen. Admin-Benutzerkonten auf der Managementebene sollten auf jeden Fall stärker geschützt sein, beispielsweise mit zwingender Zwei-Faktor-Authentifizierung oder automatischer Trennung nach einer Zeit der Inaktivität. Mindestens ein Admin-Konto sollte auch ohne Single Sign-On (SSO) verfügbar sein, da bei einem Ausfall des SSO-Servers sonst der Zugang der Admins zur Datenbank blockiert ist. Für den administrativen Zugang können Token die richtige Lösung sein: Sie sind eine stärkere Alternative zu Nutzername und Passwort und werden insbesondere benötigt, wenn ein programmatischer Zugang zur Management-Schnittstelle genutzt werden soll.
- Zugangskontrollen auf Datenbankebene (für Anwender:innen): Auf Anwenderebene ist Zwei-Faktor-Authentifizierung als Standardverfahren für den Zugriff der Nutzer:innen auf ihre Anwendung sehr zu empfehlen. Ein herkömmlicher Schutz mit Passwörtern ist nicht ausreichend sicher, da die Anwender:innen dazu neigen, sie entweder aufzuschreiben oder sehr einfache und damit leicht zu knackende Passwörter zu nutzen. Zudem ist es sinnvoll, eine spezifische Zugriffskontrolle zu etablieren, um weitere Faktoren für die Erkennung von Anwender:innen zu haben. Beispiele: Anwender:in A darf nur auf bestimmte Tabellen und nur im Lesemodus zugreifen und Anwender:in B nur über bestimmte IP-Adressen zugreifen.
Transport- und Datenverschlüsselung
Verschlüsselung ist neben Zugriffskontrolle ein zweiter wirksamer und einfach umzusetzender Schutz. Dabei gibt es zwei Arten der Verschlüsselung: Transport- und Datenverschlüsselung.
Die Transportverschlüsselung sichert die Daten während der Verbindung von der Anwendung über das Internet in die Public Cloud und zurück. Hierfür wird üblicherweise das Protokoll TLS 1.2 genutzt. Wenn vorhanden, sollte die neuere Version TLS 1.3 aktiviert werden. Bei einigen Providern ist nicht sicher, ob diese Verbindung eine Ende-zu-Ende-Verbindung ist, die bis zum eigentlichen Datenbankserver reicht. Sie haben oft noch einen Loadbalancer zwischengeschaltet, in dem die gesicherte Verbindung abschließt. Er verbindet sich dann unter Umständen über eine zweite gesicherte Verbindung mit der Datenbank. Ideal ist eine Ende-zu-Ende-Verbindung, die direkt zur Datenbank führt.
Wie üblich werden Verbindungen mit einer Transportverschlüsselung über ein Zertifikat autorisiert. In den meisten Fällen handelt es sich dabei um eines, das von einer offiziellen Certificate Authority (CA) ausgestellt wurde. Alternativ gibt es auch die Möglichkeit, ein selbst signiertes Zertifikat bei der Erstkonfiguration des Datenbanksystems einzurichten. Nur wenige Anbieter geben den nutzenden Unternehmen die Möglichkeit, ein eigenes Zertifikat mitzubringen. Diese Option ist bei einigen Unternehmen für die Compliance vorgeschrieben.
Mit der Transportverschlüsselung allein entsteht noch nicht ausreichend Sicherheit. Die Daten sollten verschlüsselt werden, wenn sie auf Datenträgern gespeichert werden. Andernfalls sind sie zumindest für Mitarbeiter:innen des Providers im Klartext lesbar.
Eine Datenverschlüsselung mit dem AES (Advanced Encryption Standard) mit 128-Bit-Schlüssellänge verhindert dies. Für die Datenverschlüsselung gibt es drei Optionen:
- Client-Side Encryption: Die Anwendung verschlüsselt die Daten, bevor sie in die Datenbank geschrieben werden. Das ist nicht immer praktikabel, da die Datenbankfunktion beeinträchtigt wird.
- Server-Side Encryption, Variante 1: Die Datenbanksoftware besitzt eine eigene Verschlüsselungsfunktion und kodiert die Daten auf dem Server. Hierfür bieten viele Provider eine automatische Schlüsselverwaltung, die den Umgang mit der Funktion vereinfacht.
- Server-Side Encryption, Variante 2: Die Daten werden im darunterliegenden Dateisystem verschlüsselt, also auf der Ebene der virtuellen Festplatte. Hier wird häufig das DEK/KEK-Verfahren genutzt. Dabei werden die Daten mit einem zufällig erzeugten Data Encryption Key (DEK) verschlüsselt und dieser wiederum wird mit dem Key Encryption Key (KEK) kodiert und in einer Schlüsseldatenbank abgelegt – meist auf einem speziellen Server. Die Datenbankanwendungen greifen mit einer API und über eine geschützte Verbindung auf die Schlüssel zu.
Entscheidend ist die Frage, ob der Schlüssel spezifisch für das Unternehmen oder für jede genutzte Datenbank ist. Optimale Sicherheit bietet Letzteres, aber kundenspezifische Schlüssel sind ebenfalls hinreichend sicher. Unter Umständen nutzen einige Provider Shared Keys oder bieten sie als Option an. Dabei handelt es sich um "Einheitsschlüssel", die von mehreren Kund:innen des Anbieters eingesetzt werden. Von dieser Variante ist abzuraten.
Protokolldaten und Backups
Zur Datenbanksicherheit gehört auch Transparenz darüber, welche Anwender:innen sich wann und von welcher Adresse aus mit der Datenbank verbunden haben. Hierfür kennen alle Cloud-Datenbanken Logging-Funktionen. Sie sollten direkt bei der Erstkonfiguration aktiviert werden, sofern das nicht bereits automatisch geschehen ist. Die aufgezeichneten Protokolle sind ein sinnvolles Hilfsmittel für die Leistungsmessung sowie das Ermitteln von Störungsursachen, Konfigurationsproblemen und Hacker-Angriffen. So werden Auffälligkeiten im Datenbankbetrieb aufgezeichnet, beispielsweise oft wiederholte Anmeldeversuche mit wechselnden Passworteingaben. Die Management-Oberflächen der Datenbanksysteme bewahren in aller Regel die Protokolle eine gewisse Zeit auf und löschen dann die ältesten. Um jedoch auch länger zurückliegende und bisher nicht entdeckte Cyberangriffe nachvollziehen zu können, sollten die Protokolldaten noch in anderen kundeneigenen Systemen gesichert werden.
Ein weiteres Hilfsmittel bei der Bewältigung von Risiken wie Cyberangriffen, versehentlichem Löschen oder Ausfall eines Rechenzentrums sind Back-ups. Jede Cloud-Datenbank kennt eine entsprechende Funktion, die oft direkt ab Werk aktiviert ist. Sie erzeugt regelmäßig eine Sicherungskopie der gesamten Datenbankinstanz mit allen aktiven Tabellen. Die Vorgehensweise ist dabei in vielen Fällen inkrementell. Zunächst wird also eine vollständige Datensicherung angelegt, anschließend werden nur die an jedem Tag veränderten Daten gespeichert. Diese Sicherungskopien reichen bei den meisten Anbietern etwa 90 Tage zurück, ältere werden gelöscht. Für die Back-ups sollte es eine Verschlüsselungsfunktion geben, die natürlich auf jeden Fall aktiviert werden sollte.
Die Anbieter sichern die Daten oft auf eine Art und Weise, so dass nur die Back-up-Funktion darauf zugreifen kann. Deshalb sollten Unternehmen überlegen, eine erweiterte Strategie einzuführen: Ihr Ziel sollte es sein, regelmäßig vollständige und verschlüsselte Datensicherungen in einem zusätzlichen, kundeneigenen Speichersystem anzulegen. Zwischen diesen Zeitpunkten sind auch hier wieder inkrementelle Backups sinnvoll. Dabei können die Unternehmen selbst bestimmen, wie lange sie aufbewahrt werden. Je nach Auslastung der Datenbank und dem geschäftlichen Risiko eines auch nur geringen Datenverlustes ist es überdies sinnvoll, über eine häufigere Back-up-Frequenz nachzudenken, beispielsweise stündlich. Auch hierfür gibt es spezielle Cloudservices, die entsprechende Routinen anbieten.
Fazit: Geteilte Verantwortung und umfassende Sicherheit
Cloud-Datenbanken sind leistungsfähiger, skalierbarer, verfügbarer und einfacher zu managen als On-Premises-Datenbanken. Die Übersicht zeigt aber auch, wieviele Punkte bei der Absicherung bedacht werden müssen. Der Komfort von Cloud-Datenbanken sollte nicht dazu verführen, ihre Sicherheit zu vernachlässigen. DBaaS-Angebote können Admins entlasten, da hier mehr Sicherheitsaspekte vom Anbieter übernommen werden – damit Cyberkriminelle keine Chance haben.
- Bitkom: Cloud-Monitor 2021
- IDC: Experience in Migrating Databases to the Cloud
- BBK: Sektoren und Branchen KRITIS
