Comment utiliser le RLS de Supabase dans une application métier | Actualités

Bonjour, je suis Matsun de Liberogic.

Dans notre article précédent, nous avons présenté une application web avec authentification reposant sur Supabase Auth et Cloudflare. Cette fois, nous poursuivons avec le sujet abordé brièvement : le **RLS (Row Level Security)**.

Avec Supabase Auth, il est possible de savoir

« qui est connecté »

. Toutefois, dans une application métier, l'authentification seule ne suffit pas.

« quelles données cette personne peut consulter »
« quelles données elle peut modifier »

doivent également être définies, et c'est là qu'intervient le RLS.
Cet article présente donc l'utilisation du RLS de Supabase dans une application métier.

Qu'est-ce que le RLS ?

Le RLS est l'abréviation de Row Level Security, un mécanisme qui contrôle l'accès au niveau des « lignes » de la base de données.
Prenons par exemple des données de demandes telles que celles-ci.

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

La même table contient les demandes de tous les utilisateurs,

mais lorsqu'un employé standard se connecte, il ne doit voir que ses propres demandes.
Pour un supérieur hiérarchique, on souhaite afficher les demandes de son service ou de son site.
Pour un administrateur du siège, on souhaite afficher toutes les demandes.

C'est la base de données qui assure ce contrôle grâce à RLS, une fonctionnalité essentielle pour les applications métier.

Auth et RLS ont des rôles différents

Comme je l'ai expliqué dans l'article précédent, Supabase Auth et RLS ont des rôles différents.
Voici comment se répartissent leurs responsabilités.

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

Prenons l'exemple de M. Morimoto qui se connecte. Grâce à Supabase Auth,

ユーザーID：12345

on identifie qu'il s'agit bien de cet utilisateur. Avec RLS, on utilise cet identifiant utilisateur pour

申請者ID = 12345

ne récupérer que les données correspondantes.
Ainsi, même si la table contient 10 000 demandes, M. Morimoto ne voit que les siennes.

Le plus simple à comprendre : « uniquement mes propres données »

Avec RLS, le modèle le plus facile à imaginer est celui qui n'affiche que ses propres données.

Par exemple, pour une page de compte réservée aux membres,

ses propres informations d'inscription
son propre historique de demandes
ses propres informations contractuelles
son propre historique de demandes de contact
les fichiers qu'il a importés

seuls sont affichés.

Côté application, on récupère bien sûr les données en précisant l'identifiant de l'utilisateur, mais sans s'y fier uniquement : la base de données applique aussi la règle **« seules les données de la personne connectée »**.
Il est essentiel de contrôler à la fois l'application et la base de données.
Même si le code d'affichage contient une erreur, RLS garantit qu'il est impossible de récupérer les données d'un autre utilisateur.

Séparer par entreprise

Dans les portails destinés aux partenaires commerciaux, les données sont souvent affichées par entreprise plutôt que par utilisateur.

Par exemple,

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

Prenons trois utilisateurs appartenant à l'entreprise A : ils peuvent tous voir les projets de l'entreprise A, mais pas ceux de l'entreprise B. Ce contrôle repose sur la relation suivante entre les données :

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

Côté RLS,
seules les données de l'entreprise à laquelle appartient l'utilisateur connecté sont accessibles.
Cette architecture est courante dans les portails partenaires : une même application web peut être utilisée par des dizaines, voire des centaines d'entreprises, et chacune ne voit que ses propres données.

Séparer par site

Lorsqu'une application métier gagne en envergure, les sites entrent aussi en jeu. Par exemple :

本部

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

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

Cette structure est la suivante :

Le personnel de l'agence de Tokyo n'accède qu'aux données de l'agence de Tokyo.
Le personnel de l'agence d'Osaka n'accède qu'aux données de l'agence d'Osaka.
Le siège peut consulter l'ensemble des données.

C'est une structure courante dans la gestion de magasins, de bureaux régionaux ou de réseaux de revendeurs. À partir de là,

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

la conception des droits d'accès devient essentielle, et dans les applications métier, elle joue un rôle très important.

Les administrateurs peuvent tout voir

Il existe bien sûr un rôle d'administrateur. Par exemple,

utilisateur standard
Administrateur de site
Administrateur principal
Administrateur système

, les droits sont séparés ainsi.

Un utilisateur standard accède uniquement à ses propres données.
Un administrateur de site accède à son propre site.
Un administrateur du siège accède à tous les sites.
Un administrateur système peut notamment gérer les utilisateurs.

C'est le principe.

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

Ces règles ne sont pas appliquées uniquement côté application, mais aussi dans RLS.
Masquer un menu dans l'interface d'administration ne suffit pas à contrôler les droits d'accès : il faut également empêcher l'accès aux données elles-mêmes.

Contrôler non seulement la « consultation », mais aussi la « modification »

RLS ne sert pas uniquement à contrôler la consultation des données.

Par exemple, dans une application de demandes,

un employé standard peut

créer ses propres demandes
modifier ses brouillons
mais ne peut pas modifier les demandes déjà approuvées

un supérieur hiérarchique peut

consulter les demandes de ses subordonnés
Approbation et renvoi possibles

Les administrateurs du siège peuvent

consulter l'ensemble des dossiers

Telles sont les règles. En d'autres termes,

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

il faut réfléchir à chacun de ces points. Il ne suffit pas de définir qui peut voir telles données : la conception des droits doit aussi intégrer la manière dont ces données peuvent être utilisées dans le cadre du travail.

Il est nécessaire de concevoir les droits non seulement pour la consultation, mais aussi pour les opérations d'ajout et de mise à jour.

Ne pas gérer les droits uniquement côté application

Par exemple, côté frontend,

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

masquer des boutons selon le rôle est une pratique courante, mais le contrôle de l'affichage à l'écran ne suffit pas.

Même si le bouton n'est pas visible dans le navigateur, que se passe-t-il si quelqu'un appelle directement l'API ?
Que se passe-t-il si quelqu'un accède directement à l'URL ?
Que se passe-t-il si quelqu'un spécifie un autre identifiant utilisateur pour récupérer les données ?

Ce type de question se pose souvent. En pratique, il faut donc

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

vérifier à plusieurs niveaux.
RLS joue le rôle de protection des données au niveau de la base de données, le plus profond de l'architecture.
Dans une application métier, il ne suffit pas de se dire que les données sont « cachées à l'écran ». Il est essentiel de faire en sorte que ces données ne puissent tout simplement pas être récupérées.

RLS ne résout pas tout à lui seul

À l'inverse, il n'est pas nécessaire de tout gérer uniquement avec RLS pour contrôler les droits d'accès.

Par exemple,

Faut-il autoriser l'ouverture de cet écran ?
Faut-il autoriser l'exécution de cette API ?
Faut-il afficher ce bouton ?
Vérifier que cette opération a bien été approuvée avant son exécution

Ces points sont également vérifiés côté application.

Si vous utilisez Cloudflare Workers, la communication avec des API externes et certains traitements côté serveur peuvent aussi être gérés dans les Workers.
Concrètement, cela peut ressembler à ceci :

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

Plutôt que de tout résoudre à un seul endroit, nous protégeons ce qui est nécessaire à chaque couche.

Dans les traitements d'administration, il arrive que RLS ne soit pas appliqué.

Un petit point technique.
Dans les applications métier, certains traitements sont exécutés par le système, indépendamment des actions effectuées directement par l'utilisateur.

Par exemple,

Traitements groupés réservés aux administrateurs
Traitements par lots
Intégration avec des systèmes externes
Migration de données
API d'administration

etc.
Dans certains traitements de ce type, il arrive aussi que les données soient manipulées sans être soumises aux contraintes de RLS.
Supabase dispose de privilèges destinés aux traitements de gestion côté serveur, mais ceux-ci ne doivent bien entendu jamais être exposés côté navigateur.

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

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

Nous les séparons ainsi.
Si tout était exécuté avec des privilèges d'administration, la mise en place de RLS perdrait tout son intérêt.

Dans les applications métier, on commence par établir une table des droits

Avant d'écrire les règles RLS, on commence par clarifier les droits liés aux métiers.
Par exemple, pour une application de demande, cela pourrait ressembler à ceci.

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

En pratique, c'est beaucoup plus détaillé :

Consultation
Inscription
Mise à jour
Suppression
Approbation
Sortie

en plusieurs catégories.
Une fois cela défini,

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

, réfléchissez-y.
Avant de configurer la RLS, clarifiez d'abord les droits liés aux opérations métier.
La RLS est simplement un mécanisme qui traduit dans la base de données les droits que vous avez définis pour l'activité.

Concevoir les droits dès le départ, c'est plus simple

Lorsqu'on développe une application métier, on entend parfois dire : « Pour commencer, laissons tout le monde voir toutes les données, et ajoutons les droits plus tard. »
Pour un petit prototype, cela peut suffire, mais en production, il est préférable de concevoir les droits assez tôt.

Plus tard,

Séparer par entreprise
Séparer par site
Ajouter un administrateur
Ajouter un distributeur
Ajouter des membres externes

il arrive alors qu'il faille modifier la structure de données elle-même.
Il en va de même lorsqu'on utilise RLS avec Supabase :

qui partage quoi avec qui, et à quel niveau

doit être défini en amont, ce qui rend la conception nettement plus claire.

Conclusion

Avec RLS dans Supabase, le contrôle fin des accès aux données nécessaire dans une application métier peut être géré directement au niveau de la base de données.

Par exemple,

chaque utilisateur ne voit que ses propres données
n'afficher que les données de la même entreprise
Afficher uniquement les données de la même base
les administrateurs voient tous les enregistrements
seules certaines personnes peuvent modifier les données

et ainsi de suite.

Supabase Auth vérifie « qui » est l'utilisateur, tandis que RLS contrôle « quelles données » cette personne peut manipuler.

Cette combinaison permet de mettre en place les contrôles d'accès nécessaires à une application métier.
Toutefois, l'essentiel n'est pas d'écrire les RLS en tant que telles.
Il faut d'abord

définir qui peut faire quoi, et jusqu'où

en clarifiant les droits métier.
Une fois cela défini, l'authentification Supabase Auth, le contrôle des droits côté application et le rôle des RLS se dessinent naturellement.

Le prochain article abordera les raisons de combiner Cloudflare Workers et Supabase.