Aislamiento de Tenant

1.1 La Defensa en Profundidad No Es una Metáfora

En ciberseguridad clásica, la defensa en profundidad es un principio teórico. En una infraestructura compartida que aloja clientes MSP con intereses contrapuestos, se convierte en una necesidad vital. Un proveedor de servicios gestionados puede alojar simultáneamente un bufete de abogados, una clínica y un competidor directo del primero — en el mismo servidor físico.

El enfoque tradicional del multi-tenant se basa en una separación a nivel de aplicación: la aplicación filtra las consultas según un tenant_id. Este enfoque fracasa estrepitosamente cuando un bug, una falla de inyección o una escalada de privilegios elude esa única capa.

1.2 El Modelo Biológico: Membrana Celular y Uniones Estrechas

El epitelio intestinal humano ilustra nuestro paradigma. Cada célula posee su propia membrana fosfolipídica — es la primera barrera. Entre las células, las uniones estrechas (tight junctions) forman una segunda barrera, impermeable incluso a las moléculas pequeñas. Una tercera barrera — el glucocáliz — filtra las macromoléculas. Ninguna de estas barreras es suficiente por sí sola; su superposición crea una estanqueidad cercana a lo absoluto.

1.3 Las Nueve Capas

2.1 Row-Level Security (Capa 1)

Row-Level Security de PostgreSQL es el mecanismo más profundo del aislamiento. Cada fila de cada tabla lleva un tenant_id. Una política RLS aplicada a cada tabla garantiza que la sesión de PostgreSQL conectada para el tenant A no puede leer físicamente las filas del tenant B.

La función current_setting lee una variable de sesión de PostgreSQL. Esta variable la establece el pool de conexiones en el momento de la autenticación del tenant. Ninguna consulta de la aplicación puede modificarla — es de solo lectura desde la aplicación. Esta capa es inviolable sin acceso de superusuario de PostgreSQL.

2.2 Esquema por Tenant (Capa 2)

Más allá del RLS, cada tenant dispone de un esquema lógico dedicado — no un esquema PostgreSQL en el sentido de CREATE SCHEMA, sino una proyección de datos restringida. Las vistas materializadas, los índices parciales y las secuencias se filtran por tenant_id. Un tenant no puede enumerar a los demás tenants, porque la propia tabla tenants está protegida por RLS.

Esta capa impide los ataques por inferencia: aunque un tenant lograse medir el tiempo de ejecución de una consulta (timing attack), los índices parciales garantizan que los datos de los demás tenants nunca se recorren.

2.3 Restricciones y Triggers (Capa 3)

La tercera capa de PostgreSQL utiliza restricciones CHECK y triggers BEFORE INSERT/UPDATE para impedir la escritura de datos que no respetasen el aislamiento:

Un trigger adicional bloquea cualquier intento de modificar la columna tenant_id tras la inserción. Esta redundancia es deliberada: si la política RLS se desactivara por error (por ejemplo durante un mantenimiento), las restricciones y los triggers mantienen el aislamiento.

3.1 SPINA v2 — Firma por Tenant (Capa 4)

SPINA (Signature Protocol for Integrity and Non-repudiation of Assets) es el protocolo de firma de 0DATA. En la versión 2, cada tenant posee:

• Una clave HMAC-SHA256 local, generada y almacenada en el espacio del tenant
• Un certificado eIDAS RFC 3161 para el sellado de tiempo cualificado
• Un keystore aislado, cifrado con una frase de contraseña derivada del secreto del tenant

Dos tenants nunca comparten material criptográfico. Si el tenant A compromete su clave HMAC, las firmas del tenant B siguen siendo válidas. El sellado de tiempo eIDAS está federado a nivel de infraestructura, pero el timestamp token se almacena en el esquema del tenant.

La verificación de firma se ejecuta en el contexto PostgreSQL del tenant. La función spina_verify() utiliza SECURITY DEFINER con un SET app.current_tenant_id explícito — no puede fugarse fuera del tenant.

3.2 NOVA — Instancia por Tenant (Capa 5)

NOVA es el motor de observación de la red. Cada tenant MSP posee su propia instancia NOVA, ejecutada como un proceso dedicado:

• Bind exclusivo en 127.0.0.1, puerto distinto para cada tenant
• Base de datos de escaneo local (SQLite o esquema PostgreSQL aislado)
• Ningún uso compartido de memoria entre instancias
• Archivo de configuración distinto (/opt/nova/tenants/<tenant_id>/config.yaml)

Un tenant que controla su red local (y por tanto los objetivos escaneados por NOVA) no puede influir en la instancia NOVA de otro tenant. Los procesos están aislados a nivel del sistema operativo — kill -9 sobre el PID del tenant A no afecta al tenant B.

3.3 ALFA — Motor Común, Memoria Aislada (Capa 6)

ALFA (Analytics Layer for Forensic Assessment) es el motor decisional compartido. A diferencia de NOVA, ALFA utiliza un motor común para la eficiencia de recursos, pero con un aislamiento de memoria estricto:

• Cada nivel de análisis (tenant, sitio, equipo) está compartimentado
• Los datos se cargan en segmentos de memoria estancos
• Los resultados del análisis se escriben en el esquema PostgreSQL del tenant
• No se realiza ninguna correlación entre tenants sin consentimiento explícito

ALFA aplica el principio de necesidad de conocer a nivel algorítmico: un modelo de análisis ejecutado para el tenant A solo recibe los datos del tenant A. Las estadísticas agregadas multi-tenant (útiles para el benchmarking) utilizan datos anonimizados con privacidad diferencial (ε = 1.0).

4.1 Cockpit — Dominio Propio y JWT por Tenant (Capa 7)

Cada tenant accede a la interfaz Cockpit a través de un dominio dedicado: client.odata.fr. El certificado SSL (Let's Encrypt) se emite para este dominio. El JWT de autenticación se firma con una clave secreta propia del tenant y contiene el tenant_id en sus claims.

El middleware de nginx valida el JWT antes de enrutar la solicitud. Un intento de acceso a client-b.odata.fr con un JWT del tenant A se rechaza a nivel del reverse proxy — antes incluso de que la solicitud llegue a la API. El propio dominio constituye una frontera de aislamiento: un tenant no puede adivinar el subdominio de otro tenant (los nombres son UUIDs o identificadores opacos).

4.2 DNS Wildcard y NATS con Espacio de Nombres (Capa 8)

La capa 8 opera a nivel de la comunicación entre servicios:

DNS wildcard. El registro *.odata.fr apunta a la infraestructura. Cada subdominio se resuelve, pero el servidor de aplicaciones filtra los dominios no registrados. Un tenant no puede crear un subdominio arbitrario — el registro DNS está controlado por la infraestructura.

NATS con espacio de nombres. El bus de mensajes NATS utiliza sujetos con prefijo del tenant:

Las ACL de NATS están configuradas para que las credenciales del tenant A solo puedan publicar o suscribirse a los sujetos tenant.a1b2c3d4.*. El servidor NATS aplica estas ACL a nivel de protocolo — un cliente no puede eludir el espacio de nombres.

4.3 Mapa de Puertos — Ningún Servicio en 0.0.0.0 (Capa 9)

La capa 9 es la más física: el mapa de puertos documentado. Ningún servicio interno escucha en 0.0.0.0. Cada servicio está vinculado a 127.0.0.1 con un puerto explícito. El firewall (UFW, política default deny) bloquea todo el tráfico entrante que no esté explícitamente autorizado. Esta capa se documenta en detalle en la sección 5.