Modelos de aislamiento: base, esquema y fila

Un inquilino es cada cliente que comparte la aplicación: una empresa con sus usuarios, sus datos y su configuración. Hay tres formas habituales de separar sus datos, y cada una pone la frontera en un sitio distinto.

Base por cliente. Cada cliente tiene su base, a veces su servidor. La frontera la pone la conexión: un error en una consulta no puede devolver filas de otro, porque esas filas no están ahí. Es lo más caro de operar (copias, migraciones y monitoreo por cada cliente) y lo que mejor responde a un cliente regulado que pide su propia clave de cifrado.

Esquema por cliente. Una base con un esquema (un espacio de nombres de tablas) por cliente. La frontera la pone el esquema que se elige al conectar; si una conexión reutilizada conserva el esquema del cliente anterior, la frontera se mueve sola.

Fila con identificador de inquilino. Todos en las mismas tablas, cada fila con su columna de inquilino. Es lo más barato y lo más frágil: la frontera es una condición WHERE que tiene que estar en todas las consultas, sin excepción. Por eso se suele poner dos veces, en el código y en la propia base. La guía de seguridad multiinquilino de OWASP compara estos modelos y pide que, cualquiera que sea el elegido, haya pruebas que demuestren que un cliente no alcanza los datos de otro.

PostgreSQL permite que la base misma filtre las filas: se activa la seguridad por fila en una tabla y se escribe una política que solo deja ver las filas cuyo inquilino coincide con un ajuste que la aplicación fija al tomar la conexión. Si una consulta del código olvida el filtro, la política lo pone igual. Es la defensa en profundidad del modelo de fila.

Pero la política solo existe donde alguien la activó. Una tabla nueva creada por una migración que no la activa queda abierta, aunque todas las demás estén protegidas: la seguridad por fila es una propiedad de cada tabla, no de la base.

Abre en el laboratorio tablas-base-comun.txt y politicas-fila.sql.

Hay un detalle que convierte la segunda cerradura en decorado. La documentación oficial de PostgreSQL lo dice claro: el dueño de una tabla normalmente no queda sujeto a sus políticas por fila, salvo que la tabla se marque para forzarlas también sobre su dueño. Los superusuarios y los roles con el atributo que ignora la seguridad por fila nunca quedan sujetos.

Por eso el rol con el que se conecta la aplicación no debería ser dueño de las tablas: las tablas son del rol de migraciones, y la aplicación recibe solo permisos de lectura y escritura sobre ellas.

Cruza arquitectura.txt, conexion.php y tablas-base-comun.txt.

Algunas funciones de una plataforma necesitan leer de todos los clientes: un informe agregado, una facturación del proveedor, una migración. Eso no es un fallo si está declarado, es un rol aparte, nadie más lo usa y su salida pasa por un control (lo verás en la sala de exportaciones e informes). El fallo es no saber cuál es ese rol ni qué puede hacer.

Busca en roles.txt qué rol, sin ser superusuario, ignora siempre la seguridad por fila.

El equipo pregunta qué hacer primero con la base compartida, que guarda los datos de seis clientes.