PostgreSQL
Row-Level Security para aplicar políticas por fila, aislar tenants y combinar contexto de sesión, roles y permisos sin confiar solo en filtros de aplicación.
Row-Level Security agrega una política de visibilidad y escritura por fila. Es una defensa potente para multi-tenancy, pero solo funciona si roles, variables de sesión, pooling, ownership y pruebas están diseñados como un sistema completo.
RLS modifica qué filas puede ver o cambiar un role:
ALTER TABLE app.orders ENABLE ROW LEVEL SECURITY;Policy:
CREATE POLICY orders_tenant_policy
ON app.orders
USING (tenant_id = current_setting('app.tenant_id')::uuid)
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);USING: filas visibles para SELECT y elegibles para UPDATE/DELETE.WITH CHECK: filas que pueden insertarse o resultar después de UPDATE.Cuando RLS está habilitado y no existe policy aplicable, el acceso de roles sujetos a RLS se niega. Esto es preferible a una política permisiva accidental.
Las policies permisivas suelen combinarse con OR. Las restrictivas se combinan con AND sobre el resultado permisivo. Esto permite separar tenant, estado o compliance, pero una combinación mal entendida puede abrir o cerrar acceso inesperadamente.
BYPASSRLS la saltan.Para probar al owner:
ALTER TABLE app.orders FORCE ROW LEVEL SECURITY;No uses como runtime un role que bypassa la política.
Patrón transaccional:
BEGIN;
SET LOCAL app.tenant_id = '...';
-- queries
COMMIT;SET LOCAL se revierte al terminar la transacción. Es más seguro que estado de sesión persistente en un pool.
La aplicación debe validar tenant antes de establecerlo. No aceptes directamente un header sin asociarlo al usuario autenticado.
Con session pooling, una conexión puede conservar settings entre requests si no se limpian.
Con transaction pooling, el estado de sesión puede no persistir entre statements.
Por eso un patrón robusto es:
obtener client
→ BEGIN
→ SET LOCAL tenant y actor
→ ejecutar toda la unidad
→ COMMIT/ROLLBACK
→ releaseNo uses SET global y luego devuelvas el client al pool.
RLS se aplica a cada tabla accedida. Una fila parent visible no vuelve visible automáticamente sus children. Las joins pueden perder coincidencias porque una tabla relacionada está filtrada por su propia policy.
Esto puede ser correcto o indicar policies inconsistentes.
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid)impide insertar una fila para otro tenant aunque el SQL envíe ese ID.
También puedes evitar que el cliente suministre tenant y derivarlo mediante una función segura o columna/default, pero revisa search path y privileges.
Una actualización debe poder ver la fila mediante USING y el nuevo estado debe pasar WITH CHECK.
Mover una fila entre tenants debe estar prohibido salvo operación administrativa explícita.
CREATE POLICY orders_read
ON app.orders
FOR SELECT
TO app_runtime
USING (...);Separa lectura y escritura cuando sus reglas difieren.
Una policy puede llamar funciones, pero:
SECURITY DEFINER puede bypassar RLS.Funciones LEAKPROOF tienen implicaciones de reordenamiento y solo deben marcarse correctamente por roles privilegiados.
RLS añade predicados. Para:
tenant_id = current_setting(...)::uuidcrea índices que comiencen por tenant cuando el workload lo necesite:
CREATE INDEX orders_tenant_created_idx
ON app.orders(tenant_id, created_at DESC, id DESC);Revisa EXPLAIN con el role real; un plan como owner puede ser distinto porque bypassa RLS.
Constraints deben incluir tenant:
UNIQUE (tenant_id, external_id)FK compuesta:
FOREIGN KEY (tenant_id, customer_id)
REFERENCES customers(tenant_id, id)RLS protege acceso; constraints protegen integridad cross-tenant incluso ante bugs, migrations o roles privilegiados.
Un support role puede necesitar acceso controlado. Opciones:
SECURITY DEFINER estrechas.No otorgues BYPASSRLS a herramientas ordinarias.
Cada job debe establecer tenant explícitamente o usar un role con policy apropiada. Un worker multi-tenant que olvida cambiar contexto puede operar con el tenant anterior si usa session state inseguro.
El role owner puede bypassar RLS y tocar todas las filas. Esto es útil, pero peligroso. Los scripts deben filtrar explícitamente, registrar alcance y probarse con datos de varios tenants.
Es una capa de defense in depth.
current_setting sin valor puede fallar; current_setting(name, true) devuelve NULL.SET persistente en pool.WITH CHECK.USING filtra filas; WITH CHECK valida el nuevo estado.SET LOCAL es preferible en pools?WITH CHECK?Autenticación, pg_hba.conf y TLS define quién puede abrir una sesión y cómo se protege el canal.