Sicherheit im Produktivbetrieb

Sicherheit im Produktivbetrieb

0:00 Wenn über IT-Sicherheit gesprochen wird, geht es meistens um Webanwendungen, Netzwerke oder Endgeräte. Die Datenbank kommt selten vor — dabei liegt genau dort das, worauf es Angreifer abgesehen haben. In diesem Modul gehen wir den Weg einer Verbindung entlang: Wer darf überhaupt bis zum Server durchkommen, wie weist er sich aus, wie wird die Übertragung geschützt, was darf er danach tun, und was davon wird aufgezeichnet.

0:24 Am Ende sehen wir uns an, wie man den Zugriff sogar bis auf einzelne Zeilen begrenzt.

Sicherheit in PostgreSQL im Überblick

0:29 Beginnen wir mit dem Bild, das dieses Modul zusammenhält — dem Bild von den Schichten, die nacheinander greifen. Sicherheit ist in PostgreSQL keine einzelne Einstellung, sondern eine Kette von Kontrollen, die eine Verbindung nacheinander passieren muss. Wir sehen uns an, welche das sind, in welcher Reihenfolge sie wirken und warum genau diese Staffelung der Grund ist, dass ein einzelner Fehler nicht gleich alles offenlegt.

0:54 Sicherheit ist kein Schalter, den man umlegt. Sie ist eher wie ein Gebäude mit Zaun, Eingangstür, Ausweiskontrolle und abschließbaren Räumen. Jede dieser Ebenen für sich ist überwindbar. Zusammen ergeben sie einen Schutz, bei dem ein einzelner Fehler nicht gleich alles offenlegt. Genau so ist auch der Aufbau in PostgreSQL: Netzzugang, Authentifizierung, Verschlüsselung, Rechte, Aufzeichnung.

1:18 Fällt eine Schicht aus, tragen die übrigen weiter — und das ist der ganze Gedanke hinter dem Begriff Tiefenverteidigung. Der zweite Punkt ist der, der die Prioritäten verschiebt. Eine einzelne kompromittierte Anwendung ist ärgerlich. Eine kompromittierte Datenbank enthält in der Regel alles auf einmal — Kundendaten, Zahlungsdaten, Betriebswissen. Das macht sie zum lohnendsten Ziel im Haus.

1:42 Und der dritte Punkt ist die eigentlich gute Nachricht: Die meisten Vorfälle entstehen nicht durch Fehler im Produkt, sondern durch Konfiguration. Das heißt nämlich auch, dass die meisten von ihnen vermeidbar sind — mit Wissen, nicht mit Budget. Lesen Sie diese Tabelle von oben nach unten wie den Weg einer Verbindung. Zuerst muss sie überhaupt ankommen — das entscheidet die erste Zeile. Dann muss sich jemand ausweisen.

2:07 Dann wird die Leitung geschützt. Dann stellt sich die Frage, was jemand tun darf. Und ganz unten steht das, was übrig bleibt, wenn etwas schiefgeht: der Nachweis. Jede dieser Zeilen kann die Verbindung beenden, und in genau dieser Reihenfolge arbeiten wir das Modul ab. Der erste Punkt ist die häufigste Fehlvorstellung: Härten ist kein Projekt mit Enddatum, sondern ein Zustand, der gepflegt wird.

2:31 Der dritte Punkt ist der, der in der Praxis die meisten Löcher reißt — eine Konfiguration, die für die Entwicklung völlig in Ordnung war, wandert unbemerkt in den Produktivbetrieb. Wir sehen gleich das klassische Beispiel dafür. Und der vierte Punkt ist die Aufgabe, die niemand gerne übernimmt: einmal vergebene Rechte auch wieder zurückzunehmen.

Datenbankbenutzer sicher authentifizieren

2:51 Fangen wir bei der Frage an, wer sich überhaupt anmelden darf — und wie er das nachweist. Dahinter stecken zwei Einstellungen, die gern verwechselt werden, weil beide mit Kennwörtern zu tun haben und trotzdem verschiedene Dinge regeln. Wir trennen die beiden sauber, stellen sie auf den aktuellen Stand und sehen uns an, welcher Schritt bei dieser Umstellung regelmäßig vergessen wird.

3:12 Hier werden zwei Dinge oft verwechselt, die getrennt eingestellt werden. Das eine ist, wie ein Kennwort gespeichert wird. Das andere ist, wie ein Client sich beim Verbinden ausweisen muss. Beides muss stimmen — ein sicher gespeichertes Kennwort nützt nichts, wenn die Verbindungsregel gar kein Kennwort verlangt. Der Standard für beides heißt SCRAM.

3:32 Und in Version 18 kommt für größere Organisationen noch die Anbindung an einen externen Identitätsanbieter dazu. Der wichtigste Satz zu diesem Ablauf steht in der Fußzeile: Die Umstellung wirkt nur nach vorn. Bestehende Kennwörter bleiben in ihrem alten Format liegen, bis sie einmal neu gesetzt werden. Das ist die Falle bei dieser Migration — man stellt um, sieht in der Abfrage den neuen Wert und hält die Sache für erledigt, während die Hälfte der Konten weiterhin im alten Verfahren gespeichert ist.

4:00 Die letzte Abfrage hier ist deshalb Ihr Prüfmittel: Am Anfang des gespeicherten Werts steht, welches Verfahren verwendet wurde. Zwei Schritte verdienen Beachtung. Schritt zwei ist der, den man organisieren muss — bestehende Kennwörter neu setzen zu lassen, ist Kommunikation, nicht Technik. Und Schritt fünf ist die Lebensversicherung: Testen Sie jeden Zugangsweg einmal, bevor Sie den alten abschalten.

4:25 Die Anwendung, der Wartungszugang, das Auswertungswerkzeug — jeder für sich. Es ist bemerkenswert leicht, sich hier selbst auszusperren, und der ungünstigste Zeitpunkt, das zu merken, ist Freitag um achtzehn Uhr. Der zweite Punkt ist der Klassiker, den ich vorhin angekündigt habe: Die Vertrauensmethode für lokale Verbindungen — also gar keine Prüfung — ist in einer Entwicklungsumgebung bequem und in einem Produktivsystem eine offene Tür.

4:50 Sie steht dort meistens nicht aus Nachlässigkeit, sondern weil das Bild einer Entwicklungsinstanz zur Vorlage wurde. Und der letzte Punkt ist der, der einen den Abend kostet: Prüfen Sie, dass Ihre eigene Verbindung von der neuen Regelmenge noch gedeckt ist, bevor Sie neu laden.

Übertragung verschlüsseln

5:06 Wir wissen jetzt, wer sich anmelden darf. Bleibt die Frage, was auf dem Weg zwischen Client und Server mit den Daten passiert — mit den Abfragen, den Ergebnissen und, im ungünstigsten Fall, den Zugangsdaten. In diesem Kapitel schalten wir die Verschlüsselung nicht nur ein, sondern weisen auch nach, dass sie tatsächlich benutzt wird. Das ist ein Unterschied, den man kennen sollte.

5:28 Authentifizierung klärt, wer hereindarf. Sie sagt nichts darüber, wer unterwegs mithören kann. Ohne Verschlüsselung gehen Abfragen, Ergebnisse und im ungünstigsten Fall auch Zugangsdaten offen über die Leitung. Eine begriffliche Stolperfalle noch: In den Einstellungen heißt das alles bis heute SSL. Gemeint ist das moderne TLS — der alte Name ist aus Kompatibilitätsgründen geblieben.

5:53 Sie lesen also SSL und dürfen TLS denken. Die eigentliche Botschaft dieser Folie ist die zweite Abfrage. Dass der Server Verschlüsselung anbietet, heißt nämlich nicht, dass sie auch benutzt wird — Clients können auch unverschlüsselt verbinden, wenn die Regeln es zulassen. Diese Abfrage zeigt Ihnen je Sitzung, was tatsächlich passiert.

6:13 Und genau das ist der Unterschied zwischen einer Konfiguration, die gut aussieht, und einem Nachweis, den Sie auch in einem Audit vorlegen können. Der zweite Punkt formuliert das Prinzip, um das es geht: Ein Netz gilt nur dann als vertrauenswürdig, wenn es nachweislich abgeschottet ist — nicht, weil es intern heißt. Verbindungen laufen heute zwischen Rechenzentren, über Verwaltungsnetze, durch Cloud-Umgebungen.

6:37 Und der dritte Punkt macht es konkret: Über dieselbe Leitung gehen auch die Zugangsdaten. Der letzte Punkt ist eher organisatorisch, aber wichtig — Zertifikate kommen aus dem Prozess Ihrer Organisation, nicht aus einem Skript von der Übung. Diese Aufgabe verlangt genau das, was ich eben von einem Nachweis unterschieden habe: nicht die Konfiguration lesen, sondern die Wirklichkeit.

6:59 Interessant wird sie durch den zweiten Teil — die unverschlüsselten Sitzungen zu benennen. In gewachsenen Systemen findet sich fast immer eine, meist ein altes Werkzeug oder ein Auswertungszugang. Und die Ausbaustufe zeigt den nächsten Schritt: Man kann Verschlüsselung in den Verbindungsregeln nicht nur anbieten, sondern verlangen.

7:18 Der zweite Punkt ist der, den die Aufgabe gerade adressiert hat, und er ist so verbreitet, dass ich ihn zweimal nenne: angeboten ist nicht benutzt. Und der dritte Punkt ist eine Betriebsfrage, die regelmäßig vergessen wird: Zertifikate laufen ab. Wenn niemand das überwacht, erleben Sie den Ablauf als plötzlichen, vollständigen Verbindungsausfall — und zwar zu einem Zeitpunkt, den Sie sich nicht ausgesucht haben.

Netzzugang begrenzen

7:42 Jetzt gehen wir eine Schicht nach außen. Die sicherste Anmeldung ist nämlich die, die gar nicht erst versucht werden kann. Zwei Ebenen entscheiden darüber, wer den Server überhaupt erreicht — und die Regeldatei dahinter hat eine Eigenschaft, die immer wieder falsch gelesen wird. Wir sehen uns an, wie sie funktioniert, wie man sie prüft und wie man verhindert, sich dabei selbst auszusperren.

8:05 Zwei Ebenen wirken hier zusammen. Die eine bestimmt, auf welchen Netzschnittstellen der Server überhaupt lauscht — das ist der grobe Schnitt. Die andere ist die Regeldatei, die festlegt, welche Herkunft mit welcher Methode zugelassen ist. Und diese Datei hat eine Eigenschaft, die man kennen muss: Sie wird von oben nach unten gelesen, und die erste passende Regel gewinnt.

8:26 Alles, was danach kommt, sieht der Server gar nicht mehr an. Diese Sicht ist ein unterschätztes Werkzeug. Sie zeigt Ihnen nicht, was in der Datei steht, sondern wie der Server sie verstanden hat — und das ist bei einer Datei mit strenger Spaltensyntax ein Unterschied. Achten Sie besonders auf die letzte Spalte: Zeilen mit einem Fehler übernimmt der Server nicht. Eine Regel, die Sie für aktiv halten, kann also schlicht wirkungslos sein.

8:51 Diese Abfrage gehört deshalb hinter jede Änderung an der Datei, ohne Ausnahme. Der zweite Punkt ist der Fehler, der am schwersten zu sehen ist: Eine großzügige Regel weiter oben macht jede strenge Regel darunter wirkungslos. Sie können ganz unten so viel Sicherheit hinschreiben, wie Sie wollen — wenn oben eine Zeile alles durchlässt, wird sie nie erreicht.

9:12 Wer das nicht weiß, liest die Datei falsch herum und hält eine offene Konfiguration für gehärtet. Und der letzte Punkt fasst das Verhältnis zum vorigen Kapitel: Netzbegrenzung und Anmeldung ersetzen einander nicht, sie ergänzen sich. Der anspruchsvollste Teil dieser Aufgabe ist der letzte: für jede verbleibende Regel den Zweck angeben zu können. Das ist mühsamer, als es klingt, und genau deshalb lohnt es sich.

9:36 In fast jeder gewachsenen Regeldatei stehen Zeilen, die niemand mehr erklären kann — und ungeklärte Zeilen sind entweder überflüssig oder gefährlich. Beides ist ein Grund, sie anzufassen. Der erste Punkt ist der grobe Schnitt, den man leicht übersieht: Auf allen Schnittstellen zu lauschen ist die bequeme Voreinstellung vieler Umgebungen und selten das, was gebraucht wird.

9:57 Und der letzte Punkt ist der praktische Rat, den ich in diesem Modul am häufigsten gebe: Halten Sie einen zweiten Zugangsweg offen, solange Sie an diesen Regeln arbeiten. Eine Konsole, die noch verbunden ist, hat schon viele Abende gerettet.

Rechte einschränken

10:11 Die Verbindung steht, der Benutzer ist ausgewiesen. Jetzt die Frage, die im Ernstfall über die Schadenshöhe entscheidet: Was darf er eigentlich? In diesem Kapitel bauen wir ein Rollenmodell, das Eigentum, Rechte und Anmeldung sauber trennt. Das ist etwas mehr Aufwand als ein einzelner Benutzer mit allen Rechten — und es ist die Struktur, die in gewachsenen Systemen als Einzige noch beherrschbar bleibt.

10:34 In PostgreSQL gibt es keine Benutzer und Gruppen als getrennte Konzepte — es gibt nur Rollen, und ein Benutzer ist eine Rolle, die sich anmelden darf. Das klingt zunächst nach einer Kleinigkeit, eröffnet aber ein sehr sauberes Muster: eine Rolle, die die Objekte besitzt, eine, die die Rechte bündelt, und eine, die sich anmeldet und die Rechte der zweiten erbt.

10:55 Drei Rollen, drei klar getrennte Aufgaben. Sehen Sie sich vor allem an, was hier nicht steht. Kein DELETE, weil diese Anwendung nichts löscht. Kein Eigentum, weil sie die Tabellen nur benutzt. Keine weitreichenden Verwaltungsrechte, weil sie sie nicht braucht. Das ist das Prinzip der geringsten Berechtigung, und es ist unbequem — man muss jedes Recht einzeln begründen.

11:17 Der Gewinn zeigt sich im Ernstfall: Wenn die Zugangsdaten der Anwendung abhandenkommen, ist der Schaden auf genau diese vier Rechte begrenzt. Der erste Punkt ist der eigentliche Sicherheitsgewinn: Die Anmelderolle kann die Tabellen benutzen, aber nicht verändern oder löschen — sie besitzt sie ja nicht. Der zweite Punkt ist der Verwaltungsgewinn, und der zeigt sich erst nach ein paar Jahren: Eine zweite Anwendung mit gleichem Zugriff braucht eine einzige Zuweisung, statt zwanzig Rechte noch einmal einzeln zu vergeben.

11:47 Und der letzte Punkt ist eine sehr praktische Eigenheit — eine Rolle, die Objekte besitzt, lässt sich nicht einfach löschen. Deshalb sollte Eigentum bewusst gesetzt sein. Wichtig ist hier der Nachweis über die Rollenmitgliedschaft: Sie sollen zeigen können, dass die Anmelderolle ihre Rechte tatsächlich erbt und nicht etwa direkt zugewiesen bekommen hat.

12:06 Und die Ausbaustufe bildet ab, was Sie in der Praxis ohnehin brauchen: einen zweiten, nur lesenden Zugang für Auswertungen. Wenn Sie beide gegeneinander prüfen, sehen Sie sofort, ob die Trennung wirklich trägt. Der zweite Punkt ist die Abkürzung, die alles wieder einreißt: Wenn die Anwendung mit der Eigentümerrolle verbindet, ist die ganze schöne Trennung hinfällig.

12:27 Der dritte Punkt passiert unbemerkt in fast jedem Projekt — jemand legt eine Tabelle mit seinem administrativen Zugang an, und schon gehört sie der falschen Rolle. Und der letzte Punkt ist der ehrlichste in dieser Liste: Weitreichende Rechte zu vergeben, damit eine Fehlermeldung verschwindet, ist verständlich und trotzdem falsch.

Rechteprobleme aufspüren

12:45 Kommen wir zu dem, was im Betrieb tatsächlich schiefgeht. Und das ist fast nie zu wenig Berechtigung, sondern zu viel. Drei Muster sehe ich dabei immer wieder, und alle drei sind leicht zu finden, wenn man weiß, wonach man sucht. Wir gehen sie der Reihe nach durch und sehen uns außerdem an, wie man dafür sorgt, dass auch künftige Tabellen automatisch die richtigen Rechte bekommen.

13:07 Drei Muster sehe ich immer wieder. Erstens: ein Recht, das jemand zur Fehlersuche vergeben und danach vergessen hat. Zweitens: Zugriff über die allgemeine Rolle, die jeder Anmeldung automatisch mitgegeben wird — die fällt bei einer Prüfung je Benutzer gar nicht auf. Und drittens: Standardrechte, die neue Objekte ungewollt öffnen oder, häufiger, ungewollt verschlossen halten. Alle drei sind leicht zu finden, wenn man weiß, wonach man sucht.

13:35 Der interessanteste Teil ist der letzte. Rechte gelten immer nur für Objekte, die es zum Zeitpunkt der Vergabe schon gab. Legt jemand nächste Woche eine neue Tabelle an, steht die Anwendung wieder vor verschlossener Tür — mit einer Fehlermeldung, die niemand erwartet hat. Standardrechte lösen das: Sie sagen einmal, was künftige Objekte einer bestimmten Rolle in einem bestimmten Schema bekommen sollen.

13:57 Und dann funktioniert es auch beim zwanzigsten Mal noch, ohne dass jemand daran denken muss. Der letzte Punkt ist der subtilste und verdient eine Erklärung. Wenn eine Abfrage einen Tabellennamen ohne Schema nennt, entscheidet eine Suchreihenfolge, welches Objekt gemeint ist. Ist diese Reihenfolge weit gefasst, kann eine Anwendung unter Umständen ein ganz anderes Objekt erwischen, als beabsichtigt — und daraus lässt sich im ungünstigen Fall mehr machen als ein Versehen.

14:24 Eine eng gesetzte Suchreihenfolge ist deshalb billiger Schutz mit gutem Nutzen. Diese Aufgabe entspricht dem, was in vielen Organisationen einmal im Quartal ansteht — und was viel leichter fällt, wenn man es einmal geübt hat. Der entscheidende Teil ist das Zurücknehmen: mindestens ein Recht, das nachweislich nicht gebraucht wird.

14:43 Das ist erfahrungsgemäß der unangenehmste Schritt, weil immer jemand fragt, ob es nicht doch irgendwo verwendet wird. Genau deshalb sollten Sie ihn einmal in der geschützten Umgebung gehen. Der erste Punkt ist die häufigste Enttäuschung mit Standardrechten: Sie wirken nur nach vorn. Bestehende Tabellen müssen Sie zusätzlich einmal von Hand nachziehen.

15:03 Der zweite Punkt ist der blinde Fleck bei jeder Prüfung — Rechte an der allgemeinen Rolle tauchen bei keinem einzelnen Benutzer auf und gelten trotzdem für alle. Und der dritte Punkt ist ein tückisches Detail der Syntax: Ohne die Angabe der Rolle beziehen sich die Standardrechte auf Ihren eigenen Zugang und nicht auf den, den Sie gemeint haben.

Sicherheit von Erweiterungen

15:21 Ein kurzes, aber wichtiges Kapitel: Erweiterungen sind eine große Stärke von PostgreSQL — und eine Abhängigkeit wie jede andere. Sie führen Code im Server aus, und deshalb gelten für sie dieselben Fragen wie für jede Bibliothek in einem Projekt: Woher kommt sie, brauchen wir sie noch, und wer darf sie einspielen? Wir sehen uns an, wie man den Bestand prüft und was das Etikett vertrauenswürdig wirklich bedeutet.

15:45 Erweiterungen bringen Datentypen, Indexverfahren, Überwachung oder Kryptofunktionen mit — und sie führen dabei Code im Server aus. Manche sind als vertrauenswürdig eingestuft und dürfen auch ohne weitreichende Rechte installiert werden. Dieses Etikett wird gern missverstanden: Es heißt nicht risikofrei. Es heißt, dass das Projekt die Installation ohne Administratorrechte für vertretbar hält.

16:09 Das ist eine Aussage über die Installationsberechtigung, nicht über die Abwesenheit von Risiko. Die erste Abfrage sollten Sie in jedem System, das Sie übernehmen, einmal ausführen — sie ist die Inventarliste. Erfahrungsgemäß steht dort mindestens eine Erweiterung, an die sich niemand mehr erinnert. Die zweite zeigt, was zusätzlich verfügbar wäre, und dabei besonders die beiden Spalten am Ende: Sie sagen, wer eine Erweiterung überhaupt einspielen darf.

16:36 Das ist die Information, die Sie brauchen, bevor Sie eine Freigabe erteilen. Der dritte Punkt beschreibt das Muster, das ich in fast jedem gewachsenen System finde: Etwas wurde einmal für einen Sonderfall eingespielt, der Sonderfall ist längst erledigt, die Erweiterung ist geblieben. Sie tut nichts, sie schadet scheinbar nicht — und sie vergrößert trotzdem die Fläche, die gepflegt und bei jedem Versionswechsel geprüft werden muss.

17:00 Der letzte Punkt ist deshalb ein sehr guter Handel: ein paar Minuten im Quartal gegen eine unangenehme Überraschung. Der erste Punkt ist das Missverständnis, das ich vorhin schon erwähnt habe, und er verdient die Wiederholung: vertrauenswürdig heißt installierbar, nicht harmlos. Der zweite Punkt ist die Sammelleidenschaft — man spielt etwas ein, weil es nützlich sein könnte.

17:20 Und der letzte Punkt ist eine ganz praktische Betriebsregel: Beziehen Sie Erweiterungen aus derselben Quelle wie die Instanz selbst, sonst haben Sie beim nächsten Versionswechsel zwei Probleme statt einem.

Sicherheitsrelevante Ereignisse überwachen

17:32 Kontrollen sind das eine. Das andere ist die Frage, ob Sie hinterher sagen können, was passiert ist. Wenn ein Verdacht im Raum steht, kommen immer dieselben Fragen — und ohne Aufzeichnung sind sie dauerhaft unbeantwortbar, denn nachträglich lässt sich nichts einschalten. Wir sehen uns an, welche Einstellungen dafür zuständig sind und wo die Grenze zwischen nützlich und kontraproduktiv verläuft.

17:55 Wenn ein Verdacht im Raum steht, kommen immer dieselben Fragen: Wer hat sich wann verbunden? Von wo? Gab es fehlgeschlagene Anmeldeversuche? Was geschah kurz davor? Ohne Aufzeichnung sind das unbeantwortbare Fragen — und zwar dauerhaft, denn nachträglich lässt sich nichts einschalten. Deshalb ist die Sicherheitsprotokollierung eine Vorsorgemaßnahme wie ein Backup: Man richtet sie ein, wenn nichts los ist, und man ist froh darüber, wenn etwas los ist.

18:23 Die letzte Zeile ist die, die am häufigsten vergessen wird und ohne die der Rest wenig wert ist. Ein Protokolleintrag ohne Benutzer, Datenbank und Herkunft sagt Ihnen, dass etwas passiert ist — aber nicht, wem Sie es zuordnen sollen. Nehmen Sie sich also einmal die Zeit, diese Zeile ordentlich zu setzen. Das ist eine Fünf-Minuten-Arbeit, die im Ernstfall darüber entscheidet, ob Ihre Protokolle brauchbar sind.

18:47 Der zweite Punkt ist der, der bei Datenschutzfragen wichtig wird: Wer vollständig mitschreibt, was ausgeführt wurde, schreibt unter Umständen auch die Werte mit — also genau die schützenswerten Daten, die man eigentlich absichern will. Und der erste Punkt ist die praktische Seite desselben Gedankens: Zu viel Protokoll ist nicht mehr Sicherheit, sondern weniger.

19:06 Das Wichtige verschwindet dann im Rauschen, und gefunden wird es nur noch zufällig. Der Nachweis ist hier der eigentliche Prüfstein: Melden Sie sich einmal testweise an und suchen Sie den Eintrag anschließend im Protokoll. Erst wenn Sie sich selbst darin wiederfinden — mit Benutzer, Datenbank und Herkunft —, wissen Sie, dass die Aufzeichnung wirklich brauchbar ist.

19:26 Und die Ausbaustufe schließt an das Verschlüsselungskapitel an: Wenn Sie die Sicht auf die aktiven Sitzungen um den Verschlüsselungsstatus erweitern, haben Sie eine einzige Abfrage für zwei Sicherheitsfragen. Der zweite Punkt ist der, an dem Protokollierungsprojekte scheitern: Man sammelt sorgfältig und legt nie fest, wer die Daten wann ansieht.

19:45 Damit hat man einen Datenbestand geschaffen, der Platz kostet und niemandem hilft. Und der letzte Punkt ist eine Konsequenz, die selten mitgedacht wird: Wenn im Protokoll steht, wer was getan hat, dann sind diese Dateien selbst schützenswert — mit mindestens demselben Sorgfaltsanspruch wie die Datenbank.

Zugriff auf einzelne Zeilen beschränken

20:03 Und jetzt die feinste Stufe, die PostgreSQL anbietet: Zugriff nicht mehr auf Tabellenebene, sondern Zeile für Zeile. Das eröffnet Möglichkeiten, für die man sonst getrennte Datenbestände bräuchte — mehrere Mandanten in derselben Tabelle etwa. Es hat allerdings einen Vorbehalt, der fast jeden beim ersten Mal überrascht und der dafür sorgt, dass die Absicherung im Test scheinbar nicht funktioniert.

20:25 Bisher war die Frage: Darf jemand diese Tabelle lesen? Jetzt lautet sie: Welche Zeilen darf er lesen? Das ist ungefähr der Unterschied zwischen dem Schlüssel für das Archiv und dem Schlüssel für den eigenen Aktenschrank darin. Der entscheidende Vorteil: Die Regel liegt in der Datenbank. Sie gilt deshalb auch dann, wenn jemand mit einem Auswertungswerkzeug an der Anwendung vorbei zugreift — und genau dort versagen Prüfungen im Anwendungscode.

20:51 Zwei Schritte, und beide sind nötig. Der erste schaltet die Prüfung für diese Tabelle überhaupt erst ein. Der zweite legt die Regel fest: Sichtbar ist, was zur angemeldeten Rolle passt. Von da an wird diese Bedingung an jede Abfrage angehängt — automatisch, ohne dass eine Anwendung etwas davon wissen muss. Das ist die elegante Seite dieser Funktion.

21:13 Die weniger elegante steht auf der übernächsten Folie. Der zweite Punkt ist der eigentliche Gewinn. Jede Zugriffsprüfung, die in der Anwendung sitzt, gilt nur für den Weg durch die Anwendung. Sobald jemand mit einem Auswertungswerkzeug direkt an die Datenbank geht, ist sie wirkungslos. Eine Regel in der Datenbank gilt für alle Wege gleichermaßen.

21:34 Und der letzte Punkt ist die langfristige Perspektive: Anwendungen werden ersetzt, Datenbanken bleiben. Die Absicherung überlebt dann den Technologiewechsel. Diese Tabelle ist der wichtigste Vorbehalt des Kapitels, und er überrascht fast jeden beim ersten Mal. Die Regeln gelten nicht für alle. Weitreichende Verwaltungszugänge gehen daran vorbei, und — das ist der wirklich unerwartete Teil — der Eigentümer der Tabelle standardmäßig auch.

22:00 Wer also seine Regel mit dem Zugang testet, mit dem er die Tabelle angelegt hat, sieht schlicht alles und hält die Absicherung für kaputt. Es gibt eine Option, die das erzwingt; die steht in der Fußzeile. Der Aufbau dieser Aufgabe ist absichtlich so gewählt: zwei Rollen mit identischen Tabellenrechten. Das ist der springende Punkt — auf der klassischen Rechteebene sind die beiden nicht zu unterscheiden.

22:24 Erst die Regel macht den Unterschied, und deshalb ist der Nachweis über zwei unterschiedliche Ergebnismengen so überzeugend. Und die Ausbaustufe adressiert genau die Falle von der letzten Folie. Der dritte Punkt ist der, der eine halbe Absicherung erzeugt: Eine Regel nur für das Lesen anzulegen und Einfügen und Ändern offen zu lassen.

22:43 Dann kann jemand zwar keine fremden Zeilen sehen, aber durchaus welche schreiben — und das ist selten die Absicht. Und der letzte Punkt ist die praktische Konsequenz aus der Tabelle: Testen Sie eine solche Regel niemals mit dem Zugang, mit dem Sie sie angelegt haben.

Alles zusammengeführt

22:58 Damit sind wir am Ende — und beim Blick zurück auf die vier Module. Wir fassen zusammen, was Konfiguration, Abfragen, Betrieb und Sicherheit miteinander zu tun haben, und ich gebe Ihnen einen Vorschlag mit, wie sich das Gelernte in den nächsten Wochen im eigenen System anwenden lässt. Bewusst klein gehalten, damit es auch wirklich passiert.

23:18 Leistung und Sicherheit wirken auf den ersten Blick wie zwei getrennte Themen, manchmal sogar wie Gegner. In der Praxis leben sie von derselben Haltung: messen statt vermuten, belegen statt behaupten, regelmäßig nachsehen statt einmal einrichten. Ein System ist dann belastbar, wenn seine Konfiguration zur Arbeitslast passt und seine Kontrollen in Schichten greifen.

23:38 Beides bekommt man nicht geschenkt, aber beides ist zu großen Teilen Handwerk — und Handwerk kann man lernen. Diese vier Punkte sind die Kurzfassung der vier Module. Konfiguration schafft die Grundlage — ohne sie läuft Abfrage-Tuning ins Leere. Pläne, Indizes und die Form der Abfrage entscheiden über die tägliche Last. Überwachung und Wartung halten den erreichten Zustand, denn er verfällt sonst still.

24:02 Und Sicherheit trägt nur in Schichten, von denen jede einzelne nachgewiesen sein will. Wenn Sie sich vier Sätze aus diesem Seminar merken wollen, dann diese. Zum Schluss ein Vorschlag für die nächsten Wochen — bewusst klein gehalten, damit er auch wirklich passiert. Zuerst Inventur, denn ohne Ausgangsbild ist jede spätere Aussage wertlos. Dann eine Woche messen, statt sofort zu optimieren.

24:27 Dann die drei teuersten Abfragen angehen, nicht die auffälligsten. Parallel die offensichtlichen Sicherheitslücken schließen. Und zuletzt: Schwellwerte vereinbaren, damit aus Kennzahlen auch Handlungen werden. Fünf Schritte, gut zu schaffen — und danach wissen Sie deutlich mehr über Ihr System als heute.

Danke!

24:46 Damit sind wir am Ende dieses Seminars. Wir haben die Konfiguration an die Hardware herangeführt, Abfragen und Indizes anhand echter Pläne verbessert, den Betrieb messbar gemacht und die Datenbank in Schichten abgesichert. Nehmen Sie vor allem eines mit: Jede Empfehlung, auch meine, gilt erst dann, wenn Sie sie im eigenen System gemessen haben.

25:05 Die Materialien liegen in der Freigabe, und bei Fragen erreichen Sie uns unter der angegebenen Adresse. Vielen Dank fürs Zuhören.