Aufgabe 24 - Backup, Löschung, Wiederherstellung

Worum geht es?

Sie erstellen eine Sicherung Ihrer Datenbank, löschen danach absichtlich Daten und spielen die Sicherung vollständig zurück (siehe Kapitel Datenbank produktionsnah). Der Fehlerfall bei Sicherungen ist selten „es gibt keine”, sondern fast immer „sie lässt sich nicht zurückspielen”. Am Ende dieser Übung wissen Sie, dass Ihre funktioniert, weil Sie es getan haben.

Nebenbei sichern Sie die Stellen ab, an denen ein ORM nicht vor SQL-Injection schützt, nämlich dort, wo etwas dynamisch sein soll, das kein Parameter sein kann.

Was Sie dafür brauchen

Kapitel Datenbank produktionsnah, Abschnitte Sicherheit auf Datenebene und Sicherung und Rückspielung.
Ihr Projekt aus Aufgabe 23 mit gefüllter Datenbank in der Vorschauumgebung.
Dokploy aus Aufgabe 11 für die geplante Sicherung.

Welche Kompetenzen Sie erwerben und zeigen

Sie erstellen eine Sicherung und spielen sie vollständig in eine leere Datenbank zurück.
Sie verhindern SQL-Injection durch parametrisierte Abfragen und Positivlisten, auch bei dynamischer Sortierung.
Sie schätzen ein, welche Daten Sie überhaupt speichern sollten.

Pädagogische Einordnung

Reproduktion: eine Sicherung erstellen und ihren Inhalt prüfen (Teil A).
Reorganisation und Transfer: einen Datenverlust herbeiführen und die Rückspielung durchführen (Teil B).
Reflexion, Problemlösung und Urteilsbildung: Injektionslücken schließen und den Datenbestand beurteilen (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Eine Sicherung erstellen

Erstellen Sie eine Sicherung Ihrer Vorschaudatenbank und notieren Sie den Befehl:
Terminal-Fenster
```
docker compose exec -T db pg_dump -U project project > backup-2026-11-14.sql
```
Sehen Sie sich die Datei an. Notieren Sie ihre Größe und die ersten zehn Zeilen. Suchen Sie darin die Anweisung, die eine Ihrer Tabellen anlegt, und notieren Sie die Zeilennummer.
Prüfen Sie, ob die Sicherung auch Daten enthält und nicht nur das Schema. Zählen Sie dafür die INSERT- oder COPY-Zeilen zu einer Ihrer Tabellen.
Richten Sie in Dokploy eine geplante Sicherung ein. Notieren Sie den Zeitplan und den Ablageort.
Beantworten Sie in zwei bis drei Sätzen, was passiert, wenn dieses geplante Skript seit sechs Wochen mit einem Fehler endet, und woran Sie das bemerken würden.

Teil B - Löschen und zurückspielen

Notieren Sie vor dem Löschen die Zeilenzahl jeder Ihrer Tabellen mit SELECT count(*).
Löschen Sie Daten. Ein DELETE über eine ganze Tabelle genügt. Prüfen Sie danach mit denselben Abfragen, dass die Zeilen weg sind.
Rufen Sie Ihre Anwendung auf und notieren Sie, was ein Benutzer jetzt sieht.
Spielen Sie die Sicherung zurück. Legen Sie dafür eine leere Datenbank an, statt in die bestehende zu schreiben, und notieren Sie beide Befehle.
Stoppen Sie die Zeit vom ersten Befehl bis zur wieder funktionierenden Anwendung. Notieren Sie jeden Schritt, den Sie unterwegs gebraucht haben, auch die, die nicht funktioniert haben.
Prüfen Sie mit den Zählabfragen aus Punkt 1, ob alle Zeilen wieder da sind. Notieren Sie Abweichungen.
Schreiben Sie eine Kurzanleitung Wiederherstellung von höchstens zwölf Zeilen, die eine andere Person unter Zeitdruck befolgen kann. Legen Sie sie in docs/betrieb.md ab, zusammen mit der gemessenen Dauer.
Beantworten Sie in drei bis vier Sätzen, wie viele Daten Sie im Ernstfall verloren hätten. Rechnen Sie dafür mit dem Zeitplan aus Teil A Punkt 4: Wenn die letzte Sicherung um drei Uhr früh lief und der Schaden um vierzehn Uhr passiert, wie viel Arbeit ist weg?

Teil C - Injektion und Datensparsamkeit

Bauen Sie in Ihr Projekt einen Endpunkt mit dynamischer Sortierung, etwa ?sort=start, und setzen Sie den Wert zunächst absichtlich direkt in die SQL-Abfrage ein.
Nutzen Sie die Lücke aus. Schicken Sie einen Wert, der die Abfrage verändert, und notieren Sie, was Sie damit erreichen konnten. Bleiben Sie beim Lesen, es geht ums Zeigen.
Erklären Sie in drei bis vier Sätzen, warum das ORM hier nicht geschützt hat, obwohl es an allen anderen Stellen schützt.
Schließen Sie die Lücke mit einer Positivliste nach dem Muster im Kapitel. Prüfen Sie danach, dass Ihr Angriff aus Punkt 2 nicht mehr funktioniert und dass ein unbekannter Wert auf die Standardsortierung fällt.
Suchen Sie Ihr Projekt nach weiteren Stellen ab, an denen Benutzereingaben in einen Abfragetext geraten könnten. Filterfelder, Spaltennamen, Suchbegriffe und Seitengrößen sind die üblichen Kandidaten. Notieren Sie jede gefundene Stelle und wie Sie sie abgesichert haben.
Gehen Sie Ihr Datenmodell durch und legen Sie eine Tabelle an mit den Spalten Feld, wozu gebraucht, wo angezeigt. Markieren Sie jedes Feld, das Sie speichern, ohne es zu brauchen.
Beurteilen Sie in vier bis fünf Sätzen, welche der markierten Felder Sie entfernen. Ein Geburtsdatum, das nirgends gebraucht wird, ist kein Feature. Nennen Sie zusätzlich jedes Feld, das niemals im Klartext liegen sollte, und was in Kapitel 8 damit geschieht.
Legen Sie die Tabelle und Ihre Entscheidungen als Abschnitt Gespeicherte Daten in docs/architektur.md ab. Sie ist der Ausgangspunkt für das Verarbeitungsverzeichnis in der 5. Klasse.

Wissenscheck

Warum ist eine Sicherung, die nie zurückgespielt wurde, nur eine Vermutung?
Nennen Sie drei Gründe, warum sich eine vorhandene Sicherung nicht zurückspielen lässt.
Warum spielt man in eine leere Datenbank zurück und nicht in die bestehende?
Wie berechnet sich der mögliche Datenverlust aus dem Zeitplan der Sicherung?
Warum schützt ein ORM bei dynamischen Spaltennamen nicht?
Wie funktioniert eine Positivliste, und warum wird die Benutzereingabe dabei nie zu SQL?
Warum ist ein gespeichertes Feld, das nirgends gebraucht wird, ein Risiko?

Abgabe

In docs/betrieb.md stehen die Kurzanleitung Wiederherstellung, die gemessene Dauer und die Schritte aus Teil B. Der abgesicherte Endpunkt mit Positivliste liegt im Repository. In docs/architektur.md steht der Abschnitt Gespeicherte Daten. In protokoll.md stehen die Zeilenzahlen vorher und nachher, das Ergebnis des Injektionsversuchs vor und nach der Absicherung sowie die Liste der weiteren abgesicherten Stellen.