Row-Level Security

Große Mengen an Daten werden meist in einer Datenbank gespeichert. Man kann sich das wie eine riesige Tabelle vorstellen: jede Spalte ein Merkmal, jede Zeile ein einzelner Eintrag. In einer Tabelle mit Krankmeldungen steht in jeder Zeile also eine Person mit ihrem Fall. Row-Level Security bedeutet: Die Datenbank entscheidet für jede einzelne Zeile, wer sie sehen darf. Ein Mitarbeiter fragt die gesamte Tabelle ab und bekommt trotzdem nur seine eigene Zeile zurück. Die Filterregel liegt nicht im Programm, das die Abfrage stellt, sondern direkt bei den Daten.

Warum ein vergessener Filter zum Datenleck wird

Ohne diese Technik muss jedes Programm selbst daran denken, die Daten zu filtern. Eine Personalabteilungs-App würde also bei jeder Abfrage ergänzen: nur Zeilen mit meiner Mitarbeiternummer. Das funktioniert, solange niemand einen Fehler macht. In der Praxis greifen aber viele Programme auf dieselbe Datenbank zu: die Web-App, die Handy-App, ein Auswertungswerkzeug, ein Skript für den Monatsbericht. Vergisst eine einzige dieser Stellen den Filter, liegen plötzlich alle Datensätze offen.

Genau so entstehen viele der Datenpannen, über die berichtet wird. Oft ist nicht die Datenbank gehackt worden. Häufiger hat eine Schnittstelle schlicht mehr zurückgegeben, als sie sollte. Wer ein einzelnes Zeichen in der Web-Adresse änderte, sah plötzlich fremde Bestellungen oder Rechnungen. Row-Level Security schließt diese Lücke an einer zentralen Stelle.

Ein zweiter Grund ist rechtlicher Natur. Die Datenschutz-Grundverordnung verlangt, dass persönliche Daten nur für befugte Personen zugänglich sind. Eine Regel, die in der Datenbank selbst verankert ist, lässt sich prüfen und dokumentieren. Das ist deutlich überzeugender als die Zusicherung, alle Programme seien schon richtig geschrieben.

Regeln, die an der Zeile kleben

Technisch hinterlegt man für eine Tabelle eine sogenannte Richtlinie. Das ist eine Bedingung, die für jede Zeile wahr oder falsch sein kann. Ein Beispiel: Die Spalte Mitarbeiternummer muss der Nummer des angemeldeten Nutzers entsprechen. Bei jeder Abfrage hängt die Datenbank diese Bedingung unsichtbar an. Der Nutzer fragt nach allen Zeilen und erhält nur die passenden.

Wichtig ist dabei, dass die Datenbank weiß, wer gerade fragt. Dafür gibt es je nach System eigene Nutzerkonten oder ein mitgeschicktes Merkmal, etwa eine Nutzerkennung aus dem Anmeldevorgang. Diese Kennung darf der Nutzer natürlich nicht selbst fälschen können. Sonst behauptet er einfach, jemand anderes zu sein.

Die Regeln können auch komplizierter sein. Eine Führungskraft sieht alle Zeilen ihrer Abteilung, die Geschäftsführung alle. Das lässt sich in derselben Richtlinie ausdrücken. Man sollte Row-Level Security aber nicht mit Rechten auf Tabellenebene verwechseln. Dort entscheidet man nur, ob jemand eine Tabelle überhaupt anfassen darf. Row-Level Security wirkt eine Ebene feiner, nämlich innerhalb der Tabelle.

Von SaaS-Plattformen bis zum KI-Chatbot im Unternehmen

Man findet die Technik in praktisch jeder Software, die viele Kunden über dasselbe System bedient. Ein Buchhaltungsdienst im Internet speichert die Daten hunderter Firmen in denselben Tabellen. Eine Regel auf Zeilenebene sorgt dafür, dass Firma A niemals Zahlen von Firma B sieht. Datenbanken wie PostgreSQL, SQL Server oder Plattformen wie Supabase und Snowflake bieten dafür fertige Funktionen.

In den Tech-News taucht der Begriff derzeit vor allem im Zusammenhang mit KI auf. Viele Unternehmen bauen Assistenten, die Fragen zu internen Dokumenten und Datenbanken beantworten. Ein solcher Assistent darf einem Praktikanten keine Gehaltsliste vorlesen. Da das Sprachmodell selbst keine verlässliche Zugriffskontrolle leisten kann, muss die Beschränkung in der Datenquelle sitzen. Row-Level Security ist hier eines der gängigen Werkzeuge.

Ein verbreiteter Irrtum ist, die Technik ersetze alle anderen Schutzmaßnahmen. Sie schützt nur vor Abfragen über die reguläre Datenbankverbindung. Wer eine Sicherungskopie der ganzen Datenbank in die Hände bekommt, liest darin alles. Verschlüsselung, Zugangskontrolle und Protokollierung bleiben also weiterhin nötig.