Cómo usamos RLS de Supabase en aplicaciones empresariales | Temas

¡Hola! Soy Matsun de Liberogic.

En el artículo anterior presentamos una aplicación web con autenticación basada en Supabase Auth y Cloudflare. En esta ocasión continuamos con el tema que mencionamos brevemente: **RLS (Row Level Security)**.

Con Supabase Auth es posible

verificar "quién ha iniciado sesión"

, pero en las aplicaciones empresariales la autenticación por sí sola no es suficiente.

Es necesario definir qué datos puede consultar esa persona
y qué datos puede modificar

. Para ello se utiliza RLS.
En este artículo explicamos cómo usar RLS de Supabase en aplicaciones empresariales.

Qué es RLS

RLS son las siglas de Row Level Security, un mecanismo que controla el acceso a nivel de "fila" en la base de datos.
Por ejemplo, supongamos que los datos de solicitudes tienen este aspecto.

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

Todas las solicitudes de todos los usuarios están en la misma tabla,

pero cuando inicia sesión un empleado general, quiero que solo se muestren sus propias solicitudes.
Si es un supervisor, quiero mostrar las solicitudes de su departamento o sede.
Si es un administrador de la sede central, quiero mostrar todas las solicitudes.

RLS es la función que controla este tipo de acceso en el lado de la base de datos, y es una característica importante en las aplicaciones de negocio.

Auth y RLS tienen funciones diferentes

Como mencioné en el artículo anterior, Supabase Auth y RLS tienen funciones diferentes.
La relación entre ambos al separar sus roles es la siguiente.

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

Por ejemplo, supongamos que el Sr. Morimoto inicia sesión. Mediante Supabase Auth,

ユーザーID：12345

se identifica que es este usuario. RLS utiliza ese ID de usuario para

申請者ID = 12345

obtener únicamente los datos correspondientes.
Así, aunque la misma tabla contenga 10 000 registros de solicitudes, el Sr. Morimoto solo verá sus propias solicitudes.

Separar por empresa

En portales para socios comerciales, a veces los datos se muestran por empresa en lugar de por usuario.

Por ejemplo,

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

Si hay tres usuarios, los tres pueden ver los proyectos de la empresa A, pero no los de la empresa B. Este es el tipo de control que se aplica. A nivel de datos, se establece la siguiente relación:

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

Así establecemos esa relación.
Y en RLS, hacemos que cada usuario solo pueda acceder a los datos de la empresa a la que pertenece.
Es una arquitectura muy habitual en portales para clientes y socios: aunque la misma aplicación web la utilicen decenas o cientos de empresas, los datos visibles cambian según la empresa con la que se haya iniciado sesión.

Separar por sucursal

A medida que la aplicación empresarial se vuelve más compleja, además de la empresa también intervienen las sucursales. Por ejemplo:

本部

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

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

Esta es la estructura.

El personal de la sucursal de Tokio solo accede a los datos de la sucursal de Tokio.
El personal de la sucursal de Osaka solo accede a los datos de la sucursal de Osaka.
La oficina central puede verlo todo.

Es una estructura bastante común en la gestión de tiendas, oficinas comerciales, agencias y similares. A partir de aquí,

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

se convierte en un diseño de permisos, y en las aplicaciones de negocio este diseño de permisos resulta muy importante.

Los administradores pueden verlo todo

Por supuesto, también existe el rol de administrador. Por ejemplo,

usuario general
Administrador de sucursal
Administrador general
Administrador del sistema

así se separan los permisos.

Un usuario general solo accede a sus propios datos.
Un administrador de sede solo accede a su propia sede.
Un administrador central accede a todas las sedes.
Un administrador del sistema puede gestionar usuarios, entre otras funciones.

Así es el esquema.

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

Estas reglas se aplican no solo en la aplicación, sino también en RLS.
Ocultar el menú del panel de administración no basta para controlar los permisos, por lo que es necesario asegurar que los datos en sí no sean accesibles.

Controlar no solo si se puede "ver", sino también si se puede "modificar"

RLS no se utiliza únicamente para controlar la visualización de datos.

Por ejemplo, en una aplicación de solicitudes:

Los empleados generales

pueden crear sus propias solicitudes
pueden editar sus propios borradores
no pueden modificar las solicitudes aprobadas

Los superiores

pueden consultar las solicitudes de sus subordinados
Puede aprobar o devolver

El administrador general puede

revisar todos los casos

Existen reglas como estas. Es decir,

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

Hay que considerar cada uno de ellos por separado. No se trata simplemente de que "esta persona puede ver estos datos", sino que el diseño de permisos también incluye cómo debe manejar esos datos en su trabajo.

Es necesario diseñar no solo los permisos de visualización, sino también los de operaciones como el registro y la actualización.

No gestionar los permisos solo en la aplicación

Por ejemplo, en el frontend,

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

es habitual hacerlo así, pero controlar solo la visualización en pantalla no es suficiente.

Aunque el botón no sea visible en el navegador, ¿qué ocurre si alguien llama directamente a la API?
¿Qué pasa si se accede directamente a la URL?
¿Qué pasa si alguien especifica otro ID de usuario para obtener datos?

surgen este tipo de situaciones. Por eso, en la práctica,

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

la verificación se realiza en varios niveles.
RLS cumple la función de proteger los datos en la capa más profunda, lo más cerca posible de la base de datos.
En las aplicaciones empresariales, no basta con pensar «la pantalla lo oculta, así que está bien»; lo importante es asegurarse de que los datos ni siquiera puedan obtenerse.

RLS por sí solo no lo resuelve todo

Por el contrario, tampoco es necesario intentar gestionar todo el control de permisos únicamente con RLS.

Por ejemplo,

¿Se debe permitir abrir esta pantalla?
¿Se debe permitir ejecutar esta API?
¿Se debe mostrar este botón?
Antes de ejecutar este proceso, verificar que esté aprobado

La aplicación también verifica estos puntos.

Si usa Cloudflare Workers, a veces el Worker también se encarga de la comunicación con APIs externas y del procesamiento del lado del servidor.
Por eso, en la práctica,

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

es algo así.
En lugar de intentar resolverlo todo en un solo punto, protegemos lo necesario en cada capa.

En los procesos administrativos, a veces no se pasa por RLS

Es un tema algo técnico.
En las aplicaciones de negocio, además de los procesos que ejecuta directamente el usuario, existen procesos que corren del lado del sistema.

Por ejemplo,

Procesos por lotes masivos para administradores
Procesamiento por lotes
Integración con sistemas externos
Migración de datos
API de administración

etc.
En algunos casos de este tipo de procesamiento, también se manejan datos sin estar sujetos a las restricciones de RLS.
Supabase cuenta con permisos para uso en procesos de administración del lado del servidor, pero por supuesto, estos no deben exponerse en el navegador.

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

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

así es como lo separamos.
Si todo se ejecutara con privilegios de administración, la configuración de RLS perdería todo su sentido.

En las aplicaciones de negocio, lo primero es crear una tabla de permisos

Antes de escribir cualquier RLS, primero organizamos los permisos según las necesidades del negocio.
Por ejemplo, en una aplicación de solicitudes, podría verse así.

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

En la práctica, se desglosa con más detalle,

Consultar
Crear
Actualizar
Eliminar
Aprobar
Salida

etc.
Una vez decidido esto,

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

consideraremos
primero los permisos de negocio antes de configurar RLS.
RLS es simplemente el mecanismo que traslada a la base de datos los permisos que hemos definido según el negocio.

Es más sencillo diseñar los permisos desde el principio

Al desarrollar una aplicación de negocio, a menudo surge la propuesta de "permitir que todos vean todo al principio y añadir los permisos más adelante".
Esto puede estar bien para un prototipo pequeño, pero si pensamos en la operación en producción, conviene diseñar los permisos con antelación.

más adelante,

Separar por empresa
Separar por sede
Añadir administrador
Añadir agencia
Agregar personal externo

En ese caso, a veces es necesario cambiar la propia estructura de datos.
Lo mismo ocurre cuando se usa RLS en Supabase:

Definir de antemano quién comparte qué datos y en qué unidad

hace que el diseño sea mucho más limpio.

Conclusión

Con RLS de Supabase, el control detallado del acceso a los datos que requieren las aplicaciones empresariales puede gestionarse en el lado de la base de datos.

Por ejemplo,

se puede mostrar solo los datos propios de cada usuario.
Mostrar solo los datos de la misma empresa
Mostrar solo los datos de la misma sede
Los administradores pueden ver todos los registros
Solo determinadas personas pueden actualizar

son ejemplos de este tipo de control.

Supabase Auth verifica "quién es" el usuario, mientras que RLS controla "qué datos puede manejar" esa persona.

Con esta combinación se pueden implementar los controles de acceso que necesita una aplicación de negocio.
Sin embargo, lo importante no es escribir las RLS en sí.
Primero,

quién puede hacer qué y hasta dónde

es lo que hay que definir en términos de permisos de negocio.
Una vez definido eso, Supabase Auth, el control de permisos en la aplicación y el papel de las RLS también quedan claros de forma natural.

En la próxima entrega hablaremos sobre por qué combinar Cloudflare Workers con Supabase.