12 Wege ins Datenbankdesaster

Allerdings ist das beileibe keine einfache Aufgabe. Zwar geben die Database-Anbieter ihren Kunden in der Regel alle Werkzeuge an die Hand, die Sie benötigen, ziehen Sicherheitsmaßnahmen ein und dokumentieren diese. Leider können Anwender jedoch Dutzenden weiteren potenziellen Fehlern, Versäumnissen und Irrtümern unterliegen, die einen Bereich von "dumm" bis "nachvollziehbar" abdecken.

Nachfolgend haben wir zwölf Wege skizziert, die Sie keinesfalls beschreiten sollten, weil sie unweigerlich ins Datenbankdesaster führen.

1. Access Management ungenügend

Viele Datenbanken befinden sich auf einer eigenen Appliance, die so weit wie möglich abgeschottet sein sollte. Als Datenbankadministrator sollten sich nur entsprechend berechtigte Benutzer anmelden können - generell sollten Anmeldungen auf einen bestimmten Bereich von Netzwerken und Rechnern beschränkt sein. Per Firewall lassen sich zudem spezifische IP-Adressen blockieren.

Auf Betriebssystemebene sollten dieselben Regeln gelten. Läuft Ihre Datenbank auf einer virtuellen Maschine, gilt Entsprechendes für den Hypervisor oder die Cloud-Administration. Diese Einschränkungen verlangsamen zwar Software Updates und auch die Problembehebung, das sollte es Ihnen allerdings wert sein.

2. Physischer Zugang kein Problem

Man mag gar nicht darüber nachdenken, was ein raffinierter EindringlingEindringling im Serverraum anstellen könnte. Deshalb bieten viele Cloud- und Co-Location-Anbieter speziell gesicherte Käfigkonstruktionen innerhalb schwer bewachter Gebäudekomplexe mit begrenztem Zugang an. Alles zu Security auf CIO.de

An diesen Maßnahmen sollten Sie sich orientieren, wenn Ihre Daten lokal im eigenen Rechenzentrum gespeichert werden. Sorgen Sie in jedem Fall dafür, dass nur ausgewählte, vertrauenswürdige Personen Zugang zu dem Raum haben, in dem sich die physischen Laufwerke befinden.

3. Backups sind ungeschützt

Dass ein Datenbankserver gut abgesichert wird, dabei aber die Backups vergessen werden, ist leider nicht ungewöhnlich. Dabei ist es eigentlich logisch, dass das Backup dieselben Informationen enthält wie die Datenbank und deshalb die gleiche Sorgfalt erfordert, wenn es um die Absicherung geht.

Es empfiehlt sich, Bänder, Laufwerke und andere statische Medien in einem Tresor aufzubewahren. Vorzugsweise jedoch nicht am selben Ort, an dem die Originaldaten liegen: Werden diese durch ein Feuer oder einen Wasserschaden zerstört, sind die Datensicherungen ebenfalls ebenfalls hinüber.

4. Ruhende Daten sind unverschlüsselt

Algorithmen zur Datenverschlüsselung sind im Allgemeinen vertrauenswürdig, da sie ausgiebig getestet wurden und die aktuellen Standards keine bekannten Schwachstellen aufweisen. Sie erleichtern es, die Daten (im Ruhezustand) in Datenbank und Backups zu verschlüsseln. Doch selbst wenn die Algorithmen und deren Implementierungen sicher sind: Auch die zugehörigen Keys müssen sorgfältig geschützt werden. Cloud-Anbieter und Serverentwickler haben dafür spezielle Hardware im Angebot. Auch wenn diese Systeme nicht perfekt sind, sie sind besser als nichts.

Sollen Daten über einen längeren Zeitraum verschlüsselt bleiben, bevorzugen manche, die Keys an einem gesonderten Ort zu hinterlegen - vorzugsweise offline. Sie können die Schlüssel auch ausdrucken und in einen Safe legen.

5. Datenschutz ohne Algorithmus

Verschlüsselung ist ein gutes Mittel zum Schutz physischer Kopien von Datenbanken - solange der Key gut geschützt ist. Wie in Punkt 4 bereits erwähnt, verschlüsselt eine Vielzahl qualitativ hochwertiger Algorithmen die Daten auch dauerhaft. Das löst nicht jedes Problem, kann aber überraschend effektiv sein, wenn es nicht notwendig ist, alle sensiblen Daten verfügbar zu halten. Das einfachste Verfahren hierbei ist die Pseudonymisierung. Andere Ansätze gehen einen Mittelweg zwischen Verschlüsselung und Zugänglichkeit.

6. Verbreitungskontrolle Fehlanzeige

Wird mit Daten gearbeitet, werden diese in Caches und laufende ServerServer kopiert. Storage-Architekten halten die Anzahl der Kopien so gering wie möglich und stellen sicher, dass diese nach Gebrauch vernichtet werden. Optionen für die routinemäßige Spiegelung oder Sicherung bieten viele Datenbanken zum Schutz vor Ausfällen. Alles zu Server auf CIO.de

Das kann der Servicequalität zuträglich sein, jedoch lohnt es sich, bei der Konzeption einer Datenbank sorgfältig über diesen Aspekt nachzudenken. In einigen Fällen ist es möglich, Datenkopien zu minimieren, ohne dabei den Service zu beeinträchtigen. In anderen Fällen ist es jedoch die langsamere die bessere Option, wenn sie dazu führt, dass potenziellen Angreifern der Weg versperrt bleibt.

7. Datenbank ohne Monitoring

Gute Datenbanken sind das Ergebnis jahrzehntelanger Entwicklungsarbeit, endloser Tests und Sicherheitsforschung. Die Anbieter der Databases haben im Regelfall auch gute Werkzeuge für Management und Zugriffsverwaltung. Sie tun gut daran, diese auch zu nutzen.

Stellen Sie sicher, dass nur berechtigte Anwendungen auf Daten zugreifen. Verwenden Sie nicht für alle Anwendungen das gleiche Passwort und auf keinen Fall das Standardkennwort. Beschränken Sie den Zugriff wenn möglich auf lokale Prozesse oder das lokale Netzwerk.

8. Sekundäre DBs sind anfällig

Viele Stacks greifen auf schnelle In-Memory-Caches wie Redis zurück, um die Antwortzeiten zu beschleunigen. Diese sekundären Datenbanken und Content-Delivery-Netzwerke beinhalten oft Kopien der Datenbank-Informationen. Sie sollten deshalb genauso viel Zeit in die korrekte Konfiguration dieser Datenbanken investieren, wie Sie auch in die Hauptdatenbanken stecken.

9. Applikationen öffnen Hintertüren

Sämtliche Bemühungen um die Datenbanksicherheit laufen ins Leere, wenn sich vertrauenswürdige Applikationen maliziös verhalten. Insbesondere dann, wenn die Anwendung Zugriff auf alle Daten hat. Ein häufiges Problem sind in diesem Zusammenhang SQL-Injection-Angriffe. Sie "verleiten" schlecht programmierte Anwendungen dazu, bösartige SQL-Anfragen an die Datenbank weiterzuleiten.

Ein weiteres Problem ist oft mangelnde Sicherheit bei der Anwendung selbst. In vielen Architekturen sieht die Applikation alles. Wenn sie nicht zuverlässig die richtigen Nutzer aussperrt, können all diese Daten abgegriffen werden.

10. Bequemlichkeit schafft Risiko

Eine Datenbank sollte nicht öffentlich über das Internet zugänglich sein. Einige Entwickler wollen sich so das Leben leicht machen, aber jeder der nicht-triviale Daten schützen muss, sollte das grundlegend anders sehen. Soll Ihre Datenbank nur mit Frontend-Servern kommunizieren, macht es auch nichts, wenn sie nur von diesen erreichbar ist.

11. Integritätsmanagement fehlt

Moderne Datenbanken bieten eine Vielzahl von Funktionen, die Fehler und Inkonsistenzen verhindern sollen. Indem Sie ein Schema für die Daten festlegen, stellen Sie sicher, dass die einzelnen Datenelemente einer Reihe von Regeln genügen müssen. Transaktionen und Sperrvorgänge verhindern, dass Fehler auftreten, wenn eine Tabelle oder Zeile aktualisiert wird und eine andere nicht. Der Einsatz dieser Integritätsmanagement-Optionen ist mit zusätzlichem Rechenaufwand verbunden. Das lohnt sich aber, wenn die Fehlerquote sinkt.

12. Daten werden gehortet

Eine Datenbank einzustampfen, ist manchmal die sicherste Lösung. Gerade Entwicklerteams legen oft ein "Packratten"-Mindset an den Tag und bewahren sämtliche Informationen für einen Tag in der Zukunft auf, der wahrscheinlich niemals kommt.

Um sich vor Datenschutzverstößen zu schützen, empfiehlt es sich, die Daten zu löschen. Zumindest, wenn Sie sich sicher sind, die Informationen jetzt und auch in Zukunft nicht zu benötigen. Bedenken Sie: Was Sie löschen, müssen Sie nicht mehr schützen. Um auf Nummer Sicher zu gehen, können Sie zusätzlich Offline-Backups anfertigen.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.