Arquitectura multiinquilino con aislamiento total de los datos por empresa
Basta con un filtro de consulta olvidado para filtrar un inquilino
En un despliegue compartido, la separación entre inquilinos es tan sólida como la consulta más débil. Los filtros a nivel de fila dependen de que cada desarrollador recuerde acotar cada lectura y escritura — y el día que alguien se olvida, los registros de tratamiento, los contratos con proveedores o las evaluaciones de riesgo de una empresa pueden aparecer en la vista de otra.
Ese modo de fallo es difícil de descartar y aún más difícil de demostrar que ya no existe. Cuando un equipo de seguridad o un auditor pregunta «¿cómo garantizan que el cliente A no puede ver los datos del cliente B?», una respuesta basada en filtros invita a una revisión de código línea a línea que no puede ganar solo con confianza.
Gestionar cada entidad como una configuración y un almacén de datos independientes, sin aislamiento nativo, no hace más que multiplicar la superficie por donde una frontera puede romperse en silencio.
Qué puede hacer con el aislamiento multiinquilino
- Aislar cada empresa a nivel de almacén de datos — cada colección lleva automáticamente el prefijo del identificador de inquilino.
- Acotar cada consulta al inquilino activo — el contexto de empresa se resuelve por solicitud, sin filtro manual que añadir.
- Heredar el aislamiento en los más de 100 modelos de dominio — la separación procede del modelo base, no de código por funcionalidad.
- Encauzar el acceso entre empresas por una única vía autorizada — solo un alcance explícito de superadministrador puede leer entre inquilinos.
- Representar y enrutar por empresa — el nombre para mostrar, el identificador y los metadatos rigen la interfaz y la navegación.
Qué aporta a su programa
- Demuestre a los auditores que la separación es estructural, no procedimental — las fronteras se aplican mediante el alcance de colecciones, de modo que defiende una arquitectura en lugar de una promesa de revisión de código.
- Elimine toda una clase de fugas entre inquilinos — una consulta no puede llegar al almacén de otra empresa sin un alcance explícito, de modo que el incidente de «alguien olvidó el filtro» no tiene dónde producirse.
- Incorpore una nueva entidad o cliente sin reconstruir el aislamiento — cada uno obtiene su propio almacén de datos acotado bajo el mismo modelo gobernado.
- Dé a los equipos de seguridad un único control que verificar — un único mecanismo de alcance sustituye a la lógica de inquilino por consulta que, de otro modo, auditaría en todas partes.
Diseñado para el cumplimiento
Esto corresponde la funcionalidad con la intención de los controles de ISO 27001 y SOC 2; Priverion respalda sus evidencias en este punto y no afirma la certificación en su nombre.
| Qué hace DPMS | Se corresponde con | Cómo |
|---|---|---|
| Separa los datos de los inquilinos a nivel de almacén | ISO 27001 — segregación en los entornos | Prefijado de colecciones por empresa aplicado a cada modelo |
| Confina el acceso al inquilino activo de forma predeterminada | SOC 2 — controles de acceso lógico | El contexto de empresa por solicitud acota todas las lecturas y escrituras |
| Restringe el acceso entre empresas a una única vía | SOC 2 — acceso de privilegio mínimo | Las consultas entre inquilinos requieren un alcance explícito de superadministrador |
Por qué Priverion
A diferencia de las herramientas de GRC de propósito general que añaden la separación entre inquilinos sobre un esquema compartido con filtros a nivel de fila, DPMS hace que el aislamiento sea estructural: un único CompanyHandler antepone a cada colección el identificador de empresa, y los más de 100 modelos de dominio heredan ese alcance de una sola clase base. No hay lógica de inquilino por consulta que olvidar. Los datos de registro de tratamientos, EIPD, riesgo y proveedores permanecen cada uno dentro de la frontera de su empresa mediante el mismo mecanismo gobernado — el aislamiento forma parte de la plataforma, no se añade por funcionalidad.


