RLS: aislamiento que la base de datos garantiza
Row‑Level Security de PostgreSQL: por qué aislar los datos de cada organización en la base —y no solo en la aplicación— convierte un error de código en un no‑evento.
En una plataforma multi‑inquilino, muchas organizaciones comparten la misma base de datos. La pregunta crítica es: ¿qué impide que la organización A vea los datos de la organización B? En la mayoría de los sistemas, la única respuesta es «el código de la aplicación se acuerda de filtrar por organización en cada consulta». Es una respuesta frágil, porque depende de que nadie se equivoque nunca.
El problema del aislamiento «solo en la aplicación»
Cuando el aislamiento vive únicamente en la capa de aplicación, cada consulta debe incluir manualmente algo como WHERE org_id = :actual. Basta con que una consulta olvide ese filtro —en una función nueva, en un reporte, en un endpoint de exportación— para que se filtren datos entre inquilinos. Y esos olvidos son exactamente el tipo de error que las pruebas no siempre atrapan, porque la consulta «funciona»: devuelve datos, solo que de más.
Qué es Row‑Level Security
Row‑Level Security (RLS) es una capacidad de PostgreSQL que mueve la regla de aislamiento de la aplicación a la base de datos misma. Se define una política que dice, en esencia: «una sesión solo puede ver las filas cuyo org_id coincide con la organización activa». A partir de ahí, la base de datos aplica ese filtro automáticamente en toda consulta, la haya escrito bien el programador o no.
La diferencia es de naturaleza, no de grado. Sin RLS, la seguridad depende de que el código recuerde filtrar. Con RLS, aunque el código olvide el filtro, la base de datos no devuelve las filas ajenas. El error deja de ser una filtración y pasa a ser, como mucho, una consulta que no trae nada.
Defensa en profundidad
RLS no reemplaza al control de la aplicación: lo respalda. La aplicación sigue validando permisos y roles; la base de datos añade una segunda muralla que no depende de la primera. Para que un dato se filtre entre organizaciones tendrían que fallar las dos capas a la vez, y la de más abajo es la más difícil de sortear, porque no se puede «olvidar» en una consulta suelta.
- Capa 1 — aplicación: autenticación, roles y permisos por vista.
- Capa 2 — base de datos: políticas RLS que filtran por inquilino en cada fila.
Lo que exige hacerlo bien
RLS es poderoso pero tiene aristas: hay que tener cuidado con las conexiones que usan roles con bypass, con las operaciones administrativas legítimas que cruzan inquilinos, y con no dejar «puertas traseras» que anulen la política. Implementarlo requiere disciplina; el premio es que el aislamiento deja de ser una promesa del equipo de desarrollo y pasa a ser una garantía del motor de base de datos.
Cómo lo aborda Verodatas
Verodatas aísla los datos de cada organización con RLS de PostgreSQL, además del control en la aplicación. Aunque hubiera un error en el código, la base bloquea el acceso a filas de otra organización. Las operaciones de plataforma que legítimamente cruzan organizaciones están acotadas y auditadas, de modo que el privilegio se usa a propósito y queda registrado — nunca por accidente.