Aislamiento aplicado por la base de datos
Cada tabla que contiene datos de tenants incluye untenant_id y está protegida mediante
seguridad a nivel de fila (RLS) de PostgreSQL:
- La tabla tiene RLS habilitada y forzada (
FORCE ROW LEVEL SECURITY), de modo que la política se aplica a todos los roles. No hay ninguna vía privilegiada para eludirla. - Una única política rige tanto las lecturas como las escrituras: las filas son visibles (
USING) y modificables (WITH CHECK) solo cuando sutenant_idcoincide con el tenant de la solicitud actual.
Como la frontera reside en la base de datos, una consulta que olvide filtrar por
tenant simplemente no devuelve nada de otro tenant. El motor se niega a mostrar
o modificar filas fuera del tenant activo.
El contexto del tenant acompaña a cada solicitud
- El tenant se resuelve a partir del subdominio de la solicitud en el middleware. Si no se puede resolver, la solicitud se rechaza antes de llegar a ningún controlador.
- Para cada transacción de base de datos, Iru establece el tenant (junto con el usuario
que actúa y un id de correlación/rastreo) como un ajuste limitado a la transacción
(
SET LOCAL). Como está limitado a la transacción, no puede filtrarse a la siguiente solicitud que reutilice una conexión del pool. - La política RLS lee exactamente ese ajuste, por lo que la frontera de seguridad es el mismo valor que estableció la aplicación, fijado de forma transaccional en cada conexión.
Privilegio mínimo, para que el historial de auditoría no se pueda reescribir
El rol de base de datos con el que se ejecuta la aplicación puede leer y escribir datos activos, pero solo tiene acceso de lectura al esquema de auditoría. Aunque se abusara de algún modo del SQL de la aplicación, este no tiene permisos para modificar ni eliminar el historial de auditoría. El registro está protegido en la capa de privilegios, con independencia de cualquier lógica de la aplicación. La integridad referencial también está limitada al tenant: las claves foráneas son compuestas (tenant_id + id), por lo que un registro solo puede hacer referencia a otro registro del
mismo tenant.
Cada cambio queda registrado (solo anexión)
Iru conserva un historial completo de los cambios en los datos de los tenants que deja constancia de cualquier manipulación.Qué se captura
Qué se captura
Cada tabla modificable tiene una tabla de auditoría (diario) espejo en la que escribe un
disparador de base de datos al insertar, actualizar y eliminar. Cada entrada registra qué
ocurrió (la acción), quién (tanto la entidad de base de datos que actúa como el
usuario autenticado), cuándo, un id de correlación/rastreo que la vincula con la
solicitud de origen y el estado completo anterior y posterior de la fila.
Por qué es de solo anexión
Por qué es de solo anexión
El registro está protegido de tres formas independientes: el disparador solo inserta
filas en el diario; el rol de base de datos de la aplicación tiene acceso de solo lectura al
esquema de auditoría; y el disparador se ejecuta con los derechos del definidor. No existe ninguna vía para que
la aplicación altere o borre un registro de auditoría.
No puede desviarse sin que se note
No puede desviarse sin que se note
Una comprobación de coherencia permanente compara las columnas de cada tabla activa con su
tabla de auditoría y falla si falta alguna columna, de modo que los campos nuevos no pueden
escapar del registro de auditoría sin que se note. Las migraciones de esquema también tienen versiones,
se verifican mediante sumas de comprobación y quedan registradas.
Los campos sensibles tienen una capa adicional
Además del aislamiento, los valores especialmente sensibles se cifran a nivel de campo con AES-256-GCM (cifrado autenticado) antes de almacenarse, y solo se descifran cuando los lee la aplicación. Las claves de cifrado se proporcionan en tiempo de ejecución desde un almacén de secretos gestionado, nunca desde el código ni la base de datos.Cómo encaja esto en el panorama general
El aislamiento funciona de la mano de la residencia regional de datos: cada región tiene su propia base de datos, y las consultas de un tenant solo se ejecutan en la base de datos de su región (consulta Arquitectura de la plataforma). Dentro de esa base de datos, RLS mantiene separado a cada tenant.Arquitectura de la plataforma
Las regiones, los planos y la infraestructura sobre los que se ejecuta este aislamiento.
Arquitectura de autenticación
Cómo se hacen resistentes al phishing y a prueba de manipulaciones el inicio de sesión y las solicitudes de API.
Registro de actividad
El registro de auditoría, disponible para que los administradores lo revisen.
Seguridad y privacidad
Las garantías que suman estos mecanismos.