Datenbanksicherheit: 11 Tipps für besseren Schutz

Wie kann ich meine Datenbanksicherheit verbessern?

Dieser Guide gibt Dir die besten 11 Tipps, um jede Datenbank abzusichern.

Starten wir!

1. Schiebe den Haustürriegel vor – Sichere API

Viele Programme bestehen heute aus 3 Komponenten. Die Datenbank zum Speichern der Daten, das Backend für die Verarbeitungslogik und das Frontend zur Darstellung. Das Backend ist so stark mit der Datenbank verwoben, dass der wichtigste Schutz der Datenbank das Backend ist. Das Backend muss jede Anfrage und jede AUSGABE validieren:

• Welche Daten kommen herein?
• Sind diese im passenden Format?
• Welche Daten fragt hier wer wann ab?
• Was spukt die Datenbank aus? Ist das viel zu viel?

Ein sicheres Backend ist die absolute Grundlage für die Datenbank-Sicherheit.

2. Eingabe oder Code – Richtige Encodierung

Der Klassiker für Kriminelle ist es, ein fehlendes Encoding auszunutzen. Eingaben, die ein normaler Nutzer tätig, nutzen die Kriminellen aus, um eine eigene Datenbankabfrage zu stellen. Sie versuchen die eigentliche Abfrage abzuschließen und ihre eigene Abfrage umzuwandeln.

Die effektivste Methode ist es, dass eine Funktion jede Nutzereingabe encodiert. Die Datenbank interpretiert ein Semikolon oder ein einfaches Anführungszeichen nicht mehr falsch.

3. Der Weg des geringsten Widerstands – Härtung

Viele sind so fokussiert auf ihre Datenbanksicherheit – die Realität ist aber profan. Kriminelle gehen den Weg des geringsten Widerstands.

• Ist das Betriebssystem, auf dem die Datenbank läuft, mit Schwachstellen gespickt?
• Kann ich einfach in das „Rechenzentrum“ als Reinigungsfachkraft hereinmarschieren und die Daten auslesen?
• Kann ich den Backend-Spezialisten mit einer Gehaltserhöhung phishen?

Du brauchst einen ganzheitlichen Ansatz, um eine Datenbank sicherzumachen. Kein Krimineller versucht Deine Absicherung zu knacken, wenn es einfachere Wege gibt.

4. Bitte nicht kreativ sein – Standards

Neulinge und Berufsanfänger tippen sinnvollen Code zusammen, ohne sich über die Implikationen klar zu sein. Die Software funktioniert und sieht sicher aus, ist diese aber nicht. Die Hersteller von API-Frameworks oder Bibliotheken erklären Dir im Detail, wie eine sichere Datenbankabfrage geht. Halte Dich an die Best Practices und sei nicht kreativ.

• PHP Plain Weg
• Laravel Weg

5. Weniger aber besser – Komplexe Abfrage vermeiden

Endlich hast Du das Problem gelöst, die Anwendung funktioniert – aber Deine SQL-Abfrage ist eine DIN-A4 Seite lang.

Blöd.

Dem Computer ist das egal, aber nicht dem Menschen. Die enorme Komplexität führt dazu, dass Kriminelle häufig mehr Spielraum haben. SQL ist eine sehr mächtige Sprache, aber Du solltest nicht immer den vollen Umfang nutzen.

Das Selektieren der Daten geht einfach und schnell, während ein Aufsummieren in Gruppen das Backend übernehmen kann. Die Aufgabenaufteilung entlastet den Datenbank-Server und verschafft Übersicht.

6. Wer was wann wie? – Berechtigungskonzept

Eine Datenbank überprüft, wer oder was auf die Daten zugreift. Jede Operationsart oder Tabelle kann für bestimmte Nutzer freigegeben werden und für andere nicht. Keiner braucht alle Rechte für alles. Der Admin braucht nur die Rechte, um die Nutzer zu verwalten und diesen Rechten zu geben, aber braucht keinen Zugriff auf die Daten selbst.

Jede Anwendung braucht einen eigenen technischen Nutzer, welche das perfekt zugeschnitten Berechtigungspaket erhält.

7. Natürliche Grenzen überall – Segmentierung

Mandanten (Tenant) sind eine gute Wahl für mehr Sicherheit. Jeder Kunde kann auch seine eigene Datenbank erhalten.

Komplett abgekapselt mit eigenen lokalen Admins.

Keine Überschneidungen.

Kein Zugriff.

Diese Art der Segmentierung kannst Du mit physischen verschiedenen Computern schaffen oder mit VMs oder Docker-Container.

version: "3.9"
services:
  adguardhome:
    container_name: guard
    image: adguard/adguardhome
    restart: unless-stopped
    ports:
      - 53:53/udp
      - 81:80/tcp
      - 444:443/tcp
      - 853:853/tcp
      - 3000:3000/tcp
    volumes:
      - adguardconf:/opt/adguardhome/conf
      - adguardwork:/opt/adguardhome/work

volumes:
  adguardconf:
  adguardwork:

8. Schweigen ist Gold – Fehler richtig behandeln

Kriminelle versuchen die Randfälle Deiner Anwendung auszureizen.

Was passiert, wenn ich eine unbekannte ID eingebe? Was gibt die Datenbank zurück, wenn ich alle IDs abfrage?

Wenn die API durcheinander kommt oder ein Fall nicht betrachtet wurde, sollte diese einen 500-Fehler zurückgeben und den Nutzer auf den Admin verweisen. Der Admin erhält in den Logdateien das Durcheinander präsentiert.

9. Big Brother is watching – Historie

Super praktisch ist eine eigenen Historie.

Welcher Nutzer hat auf welche Daten erstellt, zugegriffen, diese geändert oder gelöscht?

Einige Datenbanken bringen die Funktion ab Werk mit. Wenn jemand Mist baut, kann der Admin Daten wiederherstellen oder die kriminellen Aktivitäten rekonstruieren.

Für Buchungssysteme ist diese „Sorgfalt“ Pflicht, da das System zu keinen Zeitpunkt Geld schaffen oder vernichten soll, wenn eine Transaktion abbricht (Stromausfall, Fehler, Deppigkeit). Alles soll zurücksetzbar sein, alles soll zu jederzeit konsistent bleiben.

public function saveHistory($log_message, $todo = "")
    {
        $user = JWTAuth::user();
        $user_id = $user->id;
        $history = new History();
        $history->user_id_fk = $user_id;
        $history->log_message = $log_message;
        $history->todo = $todo;
        $history->save();
    }

10. Kopiere nicht die Datenbank – Backup

Datenbanken sind nicht einfach zu sichern. Große Datenbanken, die aktiv genutzt werden, stehen unter einem Dauerhagel an Anfragen und Änderungen. Über Nacht reduziert sich die Anzahl der Anfragen, aber bei weltweiten Nutzern kann sich ein Unternehmen keine Ausfallzeit für ein Backup leisten.

Das Dümmste, was ein Admin machen kann, ist es ein Backup eine logische oder Bit-für-Bit Kopie zu erstellen. Die Datenbank hat sich an 100 Stellen schon verändert, bevor der Backup-Prozess durchgelaufen ist. Viele Datenbank-Systeme haben ein Dump-Kommando, um die Inhalte zu sichern. Daten können sich zugleich auf der Festplatte oder im Hauptspeicher befinden.

# Mariadb
mysqldump -u root -p super > database-backup.sql

# Postgres
pg_dump -U postgres -d test -F tar -f postgres-backup.tar

11. Die gefährliche Freiheit – Vermeide Schemafreiheit

NoSQL erweitert die strenge Vorstellung der tabellenbasierten Denkweise, aber ist nicht für die Sicherheit förderlich.

Tabellen sind einfach und immer so wie man sie erwartet. Bei einer Key-Value-Datenbank kann Dir alles ausgespuckt werden. Da eine NoSQL-Datenbank komplett schemafrei sein kann, sind Databreaches wahrscheinlicher, weil jeder Depp irgendeinen (alten) Datensatz an eine Stelle schreibt, wo diese nicht hingehört.

Eine SQL-Datenbank diszipliniert die Nutzer: Die Inhalte müssen immer perfekt in Datentyp oder Länge passen. Viele Datensätze sind mit IDs verknüpft, lösch-geschützt oder stark verwoben. Der Nutzer muss ein Formular dreimal verändern, bevor die Eingabe es in die Datenbank schafft.