Hoe we Supabase RLS gebruiken in bedrijfsapplicaties

Hallo, ik ben Matsun van Liberogic.

In het vorige artikel introduceerden we een webapplicatie met authenticatie, gebouwd met Supabase Auth en Cloudflare. In dit vervolg gaan we dieper in op **RLS (Row Level Security)**, waar we kort op ingingen.

Met Supabase Auth kunt u

"vaststellen wie er is ingelogd"

, maar in zakelijke applicaties is authenticatie alleen niet voldoende.

"welke gegevens deze persoon mag bekijken"
"welke gegevens deze persoon mag wijzigen"

moet ook worden bepaald, en daarvoor gebruiken we RLS.
In dit artikel laten we zien hoe u RLS van Supabase gebruikt in zakelijke applicaties.

Wat is RLS

RLS staat voor Row Level Security en is een mechanisme dat de toegang beheert op basis van individuele "rijen" in de database.
Stel dat een aanvraaggegevens er bijvoorbeeld zo uitzien.

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

Alle aanvragen van alle gebruikers staan in dezelfde tabel,

• maar wanneer een gewone medewerker inlogt, wil ik dat die alleen de eigen aanvragen ziet.
• Een leidinggevende wil ik de aanvragen van de eigen afdeling en vestiging laten zien.
• Een hoofdbeheerder wil ik alle aanvragen laten zien.

Dit soort beperkingen regelt RLS aan de databasekant, en het is een belangrijke functie in zakelijke applicaties.

Auth en RLS hebben verschillende rollen

Zoals ik in het vorige artikel al schreef, hebben Supabase Auth en RLS verschillende rollen.
Hieronder ziet u hoe die rollen zich tot elkaar verhouden.

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

Stel dat de heer Morimoto inlogt. Via Supabase Auth wordt vastgesteld dat

ユーザーID：12345

deze gebruiker is. RLS gebruikt vervolgens die gebruikers-ID om

申請者ID = 12345

alleen de bijbehorende gegevens op te halen.
Zo ziet de heer Morimoto, ook al staan er in dezelfde tabel 10.000 aanvragen, uitsluitend zijn eigen aanvragen.

Het makkelijkst te begrijpen is "alleen eigen gegevens"

Het patroon dat je bij RLS het eerst voor ogen hebt, is alleen de eigen data tonen.

Denk bijvoorbeeld aan een mijnpagina voor leden,

• de eigen registratiegegevens
• de eigen aanvraaggeschiedenis
• de eigen contractgegevens
• de eigen contactgeschiedenis
• de eigen geüploade bestanden

tonen we alleen.

Ook in de applicatie halen we uiteraard gegevens op via de gebruikers-ID, maar we vertrouwen daar niet alleen op. In de database hanteren we daarnaast de regel **"alleen de gegevens van de ingelogde persoon zelf"**.
Het is belangrijk om dit zowel in de applicatie als in de database te regelen.
Zelfs als er aan de schermkant een fout wordt gemaakt, kan dankzij RLS geen data van een andere gebruiker worden opgehaald.

Scheiden per bedrijf

In portals voor zakelijke klanten tonen we gegevens soms niet per gebruiker, maar per bedrijf.

Neem bijvoorbeeld

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

Stel dat er drie gebruikers zijn. Alle drie kunnen de projecten van bedrijf A zien, maar niet die van bedrijf B. Dat is de regeling. Qua data wordt de volgende relatie vastgelegd:

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

Zo leggen we die relatie vast.
Vervolgens zorgen we met RLS ervoor dat gebruikers alleen toegang krijgen tot de gegevens van het bedrijf waartoe de ingelogde gebruiker behoort.
Dit is een opzet die vaak wordt gebruikt voor partnerportalen. Dezelfde webapp wordt door tientallen of zelfs honderden bedrijven gebruikt, maar welke gegevens zichtbaar zijn, hangt af van het bedrijf waarmee is ingelogd.

Scheiden per vestiging

Naarmate een applicatie meer op een bedrijfsapp gaat lijken, komen er naast bedrijven ook vestigingen bij. Bijvoorbeeld:

本部

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

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

Zo ziet de opzet eruit.

• Medewerkers van het kantoor in Tokio zien alleen de gegevens van het kantoor in Tokio.
• Medewerkers van het kantoor in Osaka zien alleen de gegevens van het kantoor in Osaka.
• Het hoofdkantoor ziet alles.

Dit is een veelvoorkomende opzet bij winkelbeheer, kantoorbeheer, dealerbeheer en vergelijkbare systemen. Vanaf dit punt,

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

wordt een rechtenstructuur nodig, en in bedrijfsapplicaties is dit ontwerp van rechten erg belangrijk.

Beheerders kunnen alles inzien

Uiteraard is er ook een beheerdersrol. Bijvoorbeeld:

• gewone gebruiker
• Locatiebeheerder
• Hoofdbeheerder
• Systeembeheerder

zo worden rechten verdeeld.

• Een gewone gebruiker ziet zijn eigen gegevens.
• Een locatiebeheerder ziet de eigen locatie.
• Een hoofdbeheerder ziet alle locaties.
• Een systeembeheerder kan onder meer gebruikersbeheer uitvoeren.

Zo ziet de opzet eruit.

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

Deze regels passen we niet alleen toe in de applicatie, maar ook in RLS.
Het verbergen van een menu-item in het beheerscherm is geen toegangscontrole. Zorg daarom dat gebruikers de gegevens zelf niet kunnen benaderen.

Bepalen niet alleen wie gegevens kan "bekijken", maar ook wie ze kan "wijzigen"

RLS wordt niet alleen gebruikt om gegevens te bekijken.

Bij een aanvraagapplicatie bijvoorbeeld:

Reguliere medewerkers:

• kunnen hun eigen aanvragen aanmaken
• kunnen hun eigen concepten bewerken
• kunnen goedgekeurde aanvragen niet wijzigen

Leidinggevenden:

• kunnen aanvragen van hun teamleden inzien
• Goedkeuren en terugsturen mogelijk

Een hoofdbeheerder kan

• alle items controleren

. Er gelden dus regels zoals deze. Met andere woorden,

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

u moet voor elk van deze situaties nadenken. Het gaat niet alleen om de vraag of iemand bepaalde gegevens mag zien. Ook hoe die gegevens in de dagelijkse werkzaamheden mogen worden gebruikt maakt deel uit van het ontwerp van de toegangsrechten.

Naast inzien moet u ook rechten ontwerpen voor handelingen zoals toevoegen en bijwerken.

Beheer rechten niet alleen in de app

Aan de frontend-kant kunt u bijvoorbeeld

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

laten bepalen. Dat is op zich gebruikelijk, maar het aansturen van wat er op het scherm zichtbaar is, is niet voldoende.

• Wat gebeurt er als iemand de knop in de browser niet ziet, maar de API rechtstreeks aanroept?
• Wat gebeurt er als iemand rechtstreeks een URL opgeeft?
• Wat gebeurt er als iemand een andere gebruikers-ID opgeeft om gegevens op te halen?

Zulke situaties komen vaak voor. Daarom wordt in de praktijk op meerdere plaatsen gecontroleerd,

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

zoals hierboven beschreven.
RLS beschermt gegevens het dichtst bij de databank, op het diepste niveau.
In zakelijke applicaties is het niet voldoende om te vertrouwen op het feit dat iets op het scherm verborgen is. Het is belangrijk dat gegevens helemaal niet opvraagbaar zijn.

RLS alleen lost niet alles op

Omgekeerd hoeft u ook niet alle toegangsrechten uitsluitend met RLS te regelen.

Neem bijvoorbeeld

• Mag deze pagina worden geopend?
• Mag deze API worden uitgevoerd?
• Moet deze knop worden weergegeven?
• Controleer vóór het uitvoeren van deze verwerking of deze is goedgekeurd.

Dit soort controles worden ook in de applicatielaag uitgevoerd.

Wanneer Cloudflare Workers wordt gebruikt, worden de communicatie met externe API's en serverzijdige verwerking soms ook in Workers afgehandeld.
In de praktijk gaat het dan om het volgende:

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

Zo ziet dat er ongeveer uit.
In plaats van alles op één plek te willen oplossen, beveiligen we op elke laag wat daar nodig is.

Beheerprocessen slaan RLS soms over

Een klein technisch detail.
In bedrijfsapplicaties draaien naast de handelingen van de gebruiker ook processen die door het systeem zelf worden uitgevoerd.

Neem bijvoorbeeld

• Bulkverwerking door beheerders
• Batchverwerking
• Integratie met externe systemen
• Datamigratie
• Beheer-API

enzovoort.
Bij dergelijke verwerking worden gegevens soms behandeld zonder de RLS-beperkingen toe te passen.
Supabase beschikt over beheerrechten voor gebruik in serverbeheerprocessen, maar deze mogen uiteraard nooit aan de browserkant worden blootgesteld.

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

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

zo is het opgedeeld.
Als alles met beheerrechten wordt uitgevoerd, verliest de RLS-configuratie zijn betekenis.

Bij bedrijfsapplicaties maak je eerst een rechtentabel

Voordat je RLS schrijft, breng je eerst de zakelijke rechten in kaart.
Bij een aanvraagapplicatie ziet dat er bijvoorbeeld zo uit.

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

In de praktijk is het nog gedetailleerder,

• Bekijken
• Registreren
• Bijwerken
• Verwijderen
• Goedkeuren
• Output

etc. Dit wordt opgesplitst.
Zodra dit is vastgelegd,

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

wordt overwogen.
Breng eerst de zakelijke autorisaties in kaart voordat je de RLS-instellingen opzet.
RLS is in essentie het mechanisme dat de autorisaties die je zakelijk hebt bepaald, vastlegt in de database.

Autorisatieontwerp is makkelijker als je er vanaf het begin over nadenkt

Bij het bouwen van een bedrijfsapplicatie komt het vaak voor dat men zegt: "Laten we het eerst voor iedereen zichtbaar maken en later de autorisaties toevoegen."
Voor een kleine proof of concept is dat misschien prima, maar als je vooruitkijkt naar productiegebruik, is het makkelijker om het autorisatieontwerp vroeg te bepalen.

later,

• Bedrijven splitsen
• Locaties splitsen
• Beheerders toevoegen
• Partners toevoegen
• Externe medewerkers toevoegen

Dan moet de datastructuur zelf soms worden aangepast.
Hetzelfde geldt wanneer je RLS in Supabase gebruikt.

Wie deelt welke gegevens, en op welk niveau

moet je vooraf goed bepalen. Dat maakt het ontwerp aanzienlijk overzichtelijker.

Conclusie

Met RLS van Supabase kun je in de database zelf fijnmazig bepalen wie welke gegevens mag openen, zoals vaak nodig is in bedrijfsapplicaties.

Neem bijvoorbeeld

• gebruikers alleen hun eigen gegevens zien
• Alleen gegevens van het eigen bedrijf tonen
• Toon alleen de gegevens van dezelfde vestiging
• Beheerders kunnen alle records bekijken
• Alleen specifieke personen kunnen bijwerken

Dit zijn voorbeelden van zulke regels.

Supabase Auth controleert wie iemand is, terwijl RLS bepaalt welke gegevens die persoon mag gebruiken.

Met deze combinatie kun je de toegangscontrole implementeren die een bedrijfsapplicatie nodig heeft.
Het belangrijkste is echter niet het schrijven van RLS op zich.
Begin met

wie wat mag doen en tot waar

. Zodra dat is vastgelegd, liggen de rol van Supabase Auth, de autorisatielogica in de applicatie en de rol van RLS vanzelf vast.

In het volgende artikel behandelen we waarom Cloudflare Workers en Supabase goed samenwerken.