Wie wir Supabase RLS in Geschäftsanwendungen einsetzen

Hallo, hier ist Matsun von Liberogic.

Im letzten Artikel habe ich eine Web-App mit Authentifizierung vorgestellt, die auf Supabase Auth und Cloudflare basiert. Heute knüpfe ich daran an und gehe auf **RLS (Row Level Security)** ein, das ich dort nur kurz angesprochen habe.

Mit Supabase Auth lässt sich feststellen,

"wer gerade angemeldet ist"

Für Geschäftsanwendungen reicht die Authentifizierung allein jedoch nicht aus.

"welche Daten die Person einsehen darf"
"welche Daten sie ändern darf"

muss ebenfalls festgelegt werden, und genau dafür wird RLS eingesetzt.
In diesem Artikel zeige ich, wie Sie Supabase RLS in Geschäftsanwendungen verwenden.

Was ist RLS?

RLS steht für Row Level Security und ist ein Mechanismus, der den Zugriff auf Datenbankzeilen steuert.
Nehmen wir zum Beispiel an, in einer Antragsdaten-Tabelle sieht es so aus.

申請ID, 申請者, 所属会社, 所属拠点, 申請内容, ステータス

Dieselbe Tabelle enthält die Anträge aller Benutzer,

doch wenn sich ein normaler Mitarbeiter anmeldet, soll nur der eigene Antrag angezeigt werden.
Vorgesetzte sollen dagegen die Anträge der eigenen Abteilung oder Niederlassung sehen können.
Ein Administrator der Zentrale soll hingegen alle Anträge einsehen können.

Eine solche Steuerung auf Datenbankebene umzusetzen ist die Aufgabe von RLS, und in Geschäftsanwendungen ist sie eine wichtige Funktion.

Auth und RLS haben unterschiedliche Aufgaben

Wie im letzten Artikel beschrieben, haben Supabase Auth und RLS unterschiedliche Aufgaben.
Die Aufteilung der Aufgaben sieht etwa so aus.

Supabase Auth → 誰なのか確認する
RLS → その人がどのデータにアクセスできるか決める

Angenommen, Frau Morimoto meldet sich an. Supabase Auth stellt dann fest,

ユーザーID：12345

dass es sich um diesen Benutzer handelt. RLS verwendet diese Benutzer-ID, um

申請者ID = 12345

ausschließlich die Daten dieses Benutzers abzurufen.
Auf diese Weise sieht Frau Morimoto auch dann nur ihre eigenen Anträge, wenn in derselben Tabelle 10.000 Anträge gespeichert sind.

Am verständlichsten ist das Muster "nur die eigenen Daten"

Bei RLS lässt sich das am leichtesten vorstellen: Das Muster zeigt nur die eigenen Daten an.

Bei einem Mitgliederbereich etwa

die eigenen Registrierungsdaten
der eigene Anmeldeverlauf
die eigenen Vertragsdaten
der eigene Anfrageverlauf
die selbst hochgeladenen Dateien

werden angezeigt.

Die Anwendung fragt Daten selbstverständlich ebenfalls mit der Benutzer-ID ab. Darauf verlassen wir uns jedoch nicht allein: Auch in der Datenbank gilt die Regel **"nur die Daten des angemeldeten Benutzers selbst"**.
Entscheidend ist, dass die Kontrolle sowohl in der Anwendung als auch in der Datenbank erfolgt.
Selbst wenn bei der Implementierung der Oberfläche ein Fehler passiert, lässt sich durch RLS verhindern, dass Daten anderer Benutzer abgerufen werden können.

Nach Unternehmen getrennt

In Partnerportalen werden Daten oft nicht pro Benutzer, sondern pro Unternehmen angezeigt.

Zum Beispiel:

A株式会社
 ├ 森本さん
 ├ 大塚さん
 └ 山田さん

Gibt es beispielsweise drei Benutzer, die alle zur A Co., Ltd. gehören, können alle drei Projekte der A Co., Ltd. sehen, aber keine Projekte der B Co., Ltd. Die Daten werden dafür wie folgt verknüpft:

ユーザー → 所属会社 → 案件

Auf der RLS-Seite wird der Zugriff so gesteuert, dass nur die Daten des Unternehmens zugänglich sind, dem der angemeldete Benutzer angehört.
Dieser Aufbau ist in Partnerportalen weit verbreitet: Obwohl dieselbe Web-App von Dutzenden oder Hunderten Unternehmen genutzt wird, unterscheiden sich die sichtbaren Daten je nach angemeldetem Unternehmen.

Nach Standort getrennt

Mit zunehmender Ausrichtung auf Geschäftsanwendungen kommen neben Unternehmen auch Standorte ins Spiel. Zum Beispiel:

本部

東京支店
 ├ 担当者A
 └ 担当者B

大阪支店
 ├ 担当者C
 └ 担当者D

Die Struktur sieht dann so aus.

Mitarbeiter der Filiale Tokio sehen nur Daten der Filiale Tokio.
Mitarbeiter der Filiale Osaka sehen nur Daten der Filiale Osaka.
Die Zentrale hat Zugriff auf alle Daten.

Das ist ein typischer Aufbau für Verwaltungssysteme wie Filial-, Niederlassungs- oder Vertriebspartnerverwaltung. Ab hier

ユーザー → 会社 → 拠点 → 役割 → アクセスできるデータ

wird ein Berechtigungskonzept erforderlich, und in Geschäftsanwendungen ist dieses Konzept von großer Bedeutung.

Administratoren können alles einsehen

Natürlich gibt es auch die Rolle des Administrators. Zum Beispiel:

Standardbenutzer
Standortverwaltung
Hauptadministrator
Systemadministrator

– so werden die Berechtigungen aufgeteilt.

Standardbenutzer sehen nur ihre eigenen Daten.
Niederlassungsadministratoren sehen ihre eigene Niederlassung.
Zentraladministratoren sehen alle Niederlassungen.
Systemadministratoren können unter anderem Benutzer verwalten.

So sieht die Umsetzung aus.

一般ユーザー → 自分だけ
拠点管理者 → 所属拠点
本部管理者 → 全拠点

Diese Regeln setzen wir nicht nur in der App um, sondern auch in RLS.
Es reicht nicht aus, nur den Menüpunkt in der Admin-Oberfläche auszublenden, um Berechtigungen zu steuern. Daher muss sichergestellt sein, dass der Zugriff auf die Daten selbst nicht möglich ist.

Nicht nur das "Ansehen", sondern auch, ob "Änderungen vorgenommen werden können", wird gesteuert

RLS wird nicht nur dafür eingesetzt, Daten einzusehen.

Bei einer Antrags-App zum Beispiel:

Reguläre Mitarbeitende

können eigene Anträge erstellen
können eigene Entwürfe bearbeiten
Genehmigte Anträge können nicht mehr geändert werden

Vorgesetzte

können Anträge ihrer Mitarbeitenden einsehen
Genehmigen oder zurückweisen

Ein Hauptverwalter kann

alle Einträge einsehen

usw. Es gibt also Regeln wie diese. Das bedeutet,

見る・登録する・変更する・削除する

dass man für jede Rolle genau überlegen muss. Es reicht nicht aus, nur festzulegen, dass eine Person diese Daten sehen darf. Zur Rollenplanung gehört auch, wie diese Daten im Arbeitsalltag korrekt verwendet werden dürfen.

Neben dem Ansehen müssen auch Berechtigungen für Aktionen wie Anlegen oder Aktualisieren geplant werden.

Berechtigungen nicht allein in der App verwalten

Beispielsweise im Frontend,

if 管理者 → 管理ボタンを表示

ist es durchaus üblich, so vorzugehen. Die reine Steuerung der Anzeige in der Oberfläche reicht jedoch nicht aus.

Was passiert, wenn die Schaltfläche im Browser nicht sichtbar ist, die API aber trotzdem direkt aufgerufen wird?
Was passiert, wenn jemand direkt eine URL angibt?
Was passiert, wenn jemand eine andere Benutzer-ID angibt, um Daten abzurufen?

Solche Fragen tauchen immer wieder auf. Deshalb wird in der Praxis

画面
↓
アプリケーション
↓
API
↓
RLS
↓
Database

an mehreren Stellen geprüft.
RLS schützt die Daten ganz unten, möglichst nah an der Datenbank.
In Geschäftsanwendungen reicht es nicht, sich darauf zu verlassen, dass Daten auf dem Bildschirm verborgen sind. Entscheidend ist, dass die Daten gar nicht erst abrufbar sind.

RLS allein löst nicht alle Probleme.

Umgekehrt ist es auch nicht nötig, sämtliche Berechtigungsprüfungen allein über RLS abzubilden.

Zum Beispiel:

Darf diese Ansicht geöffnet werden?
Darf diese API ausgeführt werden?
Soll diese Schaltfläche angezeigt werden?
Vor der Ausführung dieses Vorgangs prüfen, ob er genehmigt wurde.

Diese Prüfung erfolgt auch in der Anwendung.

Wenn Cloudflare Workers verwendet werden, übernehmen die Workers manchmal auch die Kommunikation mit externen APIs und die serverseitige Verarbeitung.
In der Praxis sieht das dann etwa so aus:

Cloudflare
↓
Next.js
↓
Supabase Auth
↓
アプリケーション側の権限確認
↓
RLS
↓
Database

So ungefähr.
Anstatt zu versuchen, alles an einer einzigen Stelle zu lösen, sichern wir auf jeder Ebene die Bereiche ab, die dort nötig sind.

Administrative Prozesse umgehen manchmal RLS.

Ein kleiner technischer Einblick:
In Geschäftsanwendungen gibt es neben den Vorgängen, die Nutzer selbst auslösen, auch Prozesse, die vom System im Hintergrund ausgeführt werden.

Zum Beispiel:

Administrative Massenverarbeitung
Batch-Verarbeitung
Integration externer Systeme
Datenmigration
Administrative API

und Ähnliches.
Bei solchen Verarbeitungen kommt es manchmal vor, dass Daten ohne die Einschränkungen durch RLS verarbeitet werden.
Supabase verfügt über Berechtigungen für administrative Serverprozesse, die dürfen selbstverständlich niemals auf der Browserseite erscheinen.

ユーザーからの操作
↓
RLSを通す

管理・システム処理
↓
サーバー側で必要な権限を使う

so aufgeteilt.
Würde man alles mit administrativen Rechten ausführen, wäre der Sinn der RLS-Einstellung hinfällig.

Bei Geschäftsanwendungen erstellt man zuerst eine Berechtigungstabelle

Bevor man RLS-Regeln schreibt, sollte man zunächst die fachlichen Berechtigungen strukturieren.
Bei einer Antragsanwendung könnte das zum Beispiel so aussehen.

                自分   拠点   全体   承認
一般ユーザー      ○     ×      ×      ×
上長              ○     ○      ×      ○
本部管理者        ○     ○      ○      ○

In der Praxis wird es deutlich feiner gegliedert,

Lesen
Anlegen
Aktualisieren
Löschen
Genehmigen
Ausgabe

usw. unterteilen.
Erst wenn dies festgelegt ist,

どのテーブルに
どんな情報を持たせるか
↓
どのユーザーが
どの行にアクセスできるか
↓
RLSをどう設定するか

lohnt es sich, darüber nachzudenken.
Bevor Sie RLS konfigurieren, sollten Sie die geschäftlichen Berechtigungen klären.
RLS ist lediglich der Mechanismus, der die festgelegten geschäftlichen Berechtigungen in der Datenbank umsetzt.

Das Berechtigungsdesign von Anfang an zu berücksichtigen, ist einfacher

Wenn man eine Geschäftsanwendung entwickelt, kommt es oft zu dem Vorschlag: „Lassen wir zunächst alle Nutzer alles sehen, und vergeben die Berechtigungen später.“
Bei einem kleinen Prototyp mag das in Ordnung sein, aber im Produktivbetrieb ist es einfacher, das Berechtigungsdesign frühzeitig zu durchdenken.

später,

Unternehmen trennen
Standorte trennen
Administratoren hinzufügen
Vertriebspartner hinzufügen
Externe Mitarbeitende hinzufügen

Dann kann es nötig werden, die Datenstruktur selbst zu ändern.
Dasselbe gilt, wenn Sie RLS in Supabase verwenden:

Wer mit wem welche Daten auf welcher Ebene teilt

sollten Sie daher früh festlegen. Das macht das Design deutlich sauberer.

Fazit

Mit RLS in Supabase lassen sich die feingranularen Datenzugriffe, die Geschäftsanwendungen benötigen, direkt auf Datenbankebene steuern.

Zum Beispiel:

dass Nutzende nur ihre eigenen Daten sehen.
Nur Daten derselben Firma anzeigen
Nur Daten des eigenen Standorts anzeigen
Administratoren sehen alle Datensätze
Nur bestimmte Personen dürfen aktualisieren

usw.

Supabase Auth prüft, wer jemand ist, und RLS legt fest, welche Daten diese Person verarbeiten darf.

Mit dieser Kombination lassen sich die für Geschäftsanwendungen erforderlichen Zugriffskontrollen umsetzen.
Entscheidend ist jedoch nicht allein das Schreiben von RLS-Regeln.
Zunächst gilt es,

wer was und in welchem Umfang darf

festzulegen, also die fachlichen Berechtigungen zu klären.
Sobald dies feststeht, ergeben sich Supabase Auth, die Berechtigungslogik auf Anwendungsebene und die Rolle von RLS nahezu von selbst.

Im nächsten Beitrag geht es um die Gründe, Cloudflare Workers und Supabase zu kombinieren.