Multi-tenant: aislar las multas de cada empresa

Un sistema multi-tenant atiende a varias empresas desde la misma instalación: el mismo código, la misma base y casi siempre los mismos trabajadores en segundo plano. La ventaja es operativa: se corrige una vez para todos. El costo es que el límite entre una flota y otra deja de ser físico y pasa a ser una decisión de diseño.

Llamamos aislamiento a esa propiedad: que una operación de una empresa no pueda leer, modificar ni degradar lo que pertenece a otra. Comprobarlo con intentos cruzados es un tema propio, tratado en las pruebas negativas que una API multi-tenant necesita. Acá interesa cómo se construye: de dónde nace la identidad de la empresa que consulta, hasta dónde viaja y qué sigue siendo común aunque los datos estén separados.

El tenant no es un parámetro de la consulta

La empresa a la que pertenece una consulta de patente se deriva de la credencial autenticada. No de un campo del cuerpo ni de un encabezado editable. Si el cliente puede escribir ese valor, el aislamiento depende de que nadie lo escriba mal.

NIST SP 800-207 describe una arquitectura donde el acceso a cada recurso se decide en el momento contra una política y donde estar dentro de una red no otorga confianza. Un servicio interno tampoco hereda permiso por ser interno: necesita un contexto de empresa explícito.

La resolución ocurre una sola vez, en el borde, y produce un valor que el resto del sistema recibe pero no elige. Si hay usuarios con distintos alcances dentro de una misma empresa, esa decisión se combina con roles y atributos; no se reemplaza.

Un contexto que viaja por todas las capas

El pedido HTTP es el tramo fácil. El aislamiento se rompe donde ya no parece haber un pedido: un trabajo asíncrono que se retoma horas después, un mensaje en una cola, la exportación programada del informe de multas.

Conviene que la empresa forme parte de la firma de cada operación y no sea un valor global que alguien pueda olvidar. Si una función de repositorio puede ejecutarse sin contexto, tarde o temprano se ejecuta sin contexto.

Ese contexto tiene que llegar a:

• consultas y escrituras a la base;
• claves de caché y de idempotencia;
• rutas de los archivos generados;
• mensajes encolados y sus reintentos;
• destinatarios de webhooks y avisos;
• etiquetas de métricas y trazas.

En cada uno, un valor faltante puede volverse el de otro.

Aislamiento lógico, aislamiento físico y radio de daño

Con una base compartida y una columna de empresa, el límite lo sostiene el código. Con esquemas o bases separadas, lo sostiene además la infraestructura. Ninguna es correcta en abstracto: la primera es más barata de operar y migrar; la segunda vuelve más difícil un error silencioso y permite restaurar a una empresa sin tocar a las demás.

La pregunta útil no es cuál es más segura, sino cuál es el radio de daño de una falla: si una consulta de patente mal filtrada, un backup mal restaurado o una credencial expuesta alcanzan a una empresa o a todas.

Ese radio también depende de las claves de cifrado. NIST SP 800-57 trata la gestión de claves como un ciclo con alcance, período de uso y destrucción definidos. Una única clave para todo el almacenamiento no acota nada; separar por empresa hace que rotar o dar de baja tenga un efecto delimitado, a cambio de más gestión.

Lo que se sigue compartiendo aunque los datos no

Aun con los datos separados hay recursos comunes: cómputo, colas de trabajo, conexiones a la base y, sobre todo, el cupo de consultas contra los portales oficiales. Una carga masiva de una empresa puede demorar las consultas de otra sin haber leído un solo dato ajeno.

Por eso el aislamiento tiene una dimensión de capacidad y no sólo de acceso: límites por empresa, colas donde un lote de patentes grande no monopolice a los trabajadores y prioridades declaradas.

La observabilidad también es compartida. Medimos consumo por empresa con identificadores internos, sin patentes, CUIT ni nombres en las etiquetas: un incidente se investiga sin que el panel sea otra copia.

Alta, baja y qué revisar antes del próximo cliente

El alta debería ser un procedimiento repetible: credenciales propias, alcance mínimo y límites declarados. Dar de baja es la prueba más dura del diseño, porque obliga a saber dónde quedó cada copia de sus actas, incluidos backups, exportaciones y adjuntos.

La Ley 25.326 entiende el tratamiento de datos personales de manera amplia e impone deberes de seguridad y confidencialidad al responsable de la base; la Agencia de Acceso a la Información Pública publica esas obligaciones. Una flota reúne patentes, actas y personas: el límite entre clientes no es sólo una preferencia de arquitectura.

Antes de sumar una empresa más conviene responder tres cosas: de dónde sale el tenant en cada camino de entrada, qué recursos comparte con las demás y qué habría que ejecutar para darla de baja sin tocar a nadie. Si alguna respuesta empieza con “depende de que el código se acuerde de filtrar”, el límite todavía es una intención.

Preguntas frecuentes

¿Alcanza con filtrar por empresa en cada consulta a la base?

Es la defensa principal, pero no la única. El mismo contexto tiene que llegar a colas, trabajos asíncronos, exportaciones, cachés, nombres de archivo y notificaciones. Un filtro correcto en la consulta no evita que un archivo generado quede en una ruta accesible ni que un mensaje encolado se procese sin empresa asociada.

¿Conviene una base separada por empresa?

Depende del volumen, del costo operativo y de los compromisos asumidos. Separar reduce el alcance de un error de filtrado y facilita restaurar o eliminar a una sola empresa; compartir es más simple de operar y migrar. Lo importante es declarar la elección y conocer sus consecuencias antes de tener muchos clientes.

¿El aislamiento incluye el rendimiento?

Sí. Aunque ninguna empresa vea datos de otra, comparten capacidad de cómputo, colas y el cupo de consultas contra las fuentes oficiales. Sin límites por empresa ni prioridades explícitas, un lote grande puede demorar el trabajo de las demás sin haber leído un solo dato ajeno.

¿Qué pasa con los datos cuando una empresa deja de ser cliente?

Hay que poder ubicar y retirar cada copia: base, backups, exportaciones, cachés, colas y adjuntos. La normativa argentina de protección de datos personales impone deberes de seguridad y confidencialidad a quien es responsable de la base, así que la baja conviene diseñarla como un procedimiento con evidencia y no como un borrado manual.

Notas relacionadas