Arquitectura multiempresa y conexión segura entre tenants

Lo primero es convertir la relación en un objeto del sistema. Una conexión entre el tenant A y el tenant B debería existir como registro propio, con estado, alcance, fecha de alta, quién la aprobó en cada lado y cuándo caduca. Sobre esa base hay varios patrones:

No hay un patrón mejor en abstracto. La elección depende de si los datos deben seguir bajo control de su propietario, de si el receptor necesita trabajar sobre ellos y de qué debe pasar el día que la relación termine.

Cuando la plataforma necesita intercambiar datos con un sistema instalado en la red de un cliente, un patrón habitual es un conector: un pequeño servicio desplegado en la infraestructura del cliente que inicia conexiones salientes hacia la plataforma. Así no hay que abrir puertos de entrada en el cortafuegos del cliente, y es el propio cliente quien decide qué sistemas locales puede leer el conector.

• Identidad propia por conector: cada instalación tiene sus credenciales, ligadas a un único tenant. Nunca una credencial común para todos los clientes.
• Autenticación entre máquinas: el marco OAuth 2.0 (RFC 6749) describe el flujo de credenciales de cliente para que una aplicación obtenga un token con sus propias credenciales, sin usuario final. Puede reforzarse con certificados de cliente en la conexión.
• Alcance acotado: el token del conector solo debe permitir las operaciones necesarias. En OAuth 2.0 esto se expresa con el parámetro scope, y el servidor puede conceder menos de lo pedido.
• Rotación y caducidad: credenciales con vida limitada y procedimiento probado para renovarlas sin cortar el servicio.
• Separación de lectura y escritura: un conector que solo debe leer pedidos no necesita permiso para modificar el ERP.

Las conexiones entre tenants dentro de la plataforma pueden seguir la misma lógica: cada conexión tiene su identidad técnica y sus permisos, separados de los de cualquier usuario concreto. Si una persona deja la empresa, la integración no debería romperse; y si la integración se revoca, ningún usuario debería conservar el acceso que proporcionaba.

El principio que evita la mayoría de problemas es simple: los datos compartidos siguen bajo las reglas de su propietario. El tenant A decide qué comparte, con quién y durante cuánto tiempo; el tenant B decide qué usuarios suyos pueden usar lo que A le ha abierto. Eso lleva a un esquema de doble autorización:

1. Un administrador de A crea o acepta la conexión y fija su alcance: qué tipos de datos, qué operaciones, qué centros o proyectos.
2. Un administrador de B acepta la conexión y asigna qué usuarios o roles de B pueden ejercerla.
3. El permiso efectivo de un usuario de B sobre datos de A es la intersección de ambos: nunca más de lo que A concedió ni de lo que B asignó.
4. Los cambios de alcance que amplían el acceso requieren de nuevo la aprobación de A.

El personal de la propia plataforma es un caso aparte. Su acceso de soporte a una conexión entre clientes debería pedirse para un caso concreto, limitarse en el tiempo y quedar visible para ambas organizaciones.

En una conexión entre organizaciones, cada parte necesita poder responder a la pregunta «quién de la otra empresa ha visto o cambiado mis datos». Por eso el registro de auditoría tiene que ser visible para el propietario de los datos, no solo para quien accede.

• Eventos de la conexión: alta, aceptación, cambios de alcance, suspensión y revocación, con la persona que los hizo.
• Accesos y operaciones: qué usuario o conector, de qué organización, sobre qué registro y con qué resultado.
• Sincronizaciones: qué se copió, cuándo y con qué versión de los datos.
• Accesos de soporte de la plataforma, con su justificación.

El registro debe estar protegido frente a modificaciones por las mismas cuentas que generan los eventos y conservarse el tiempo que se haya acordado. Una vista sencilla por conexión, que cada administrador pueda consultar sin pedir nada al proveedor, resuelve buena parte de las dudas antes de que se conviertan en incidencias.

Una conexión que no se puede cerrar limpiamente es un riesgo permanente. La revocación debe poder iniciarla cualquiera de las dos partes y tener efecto inmediato y comprobable. Técnicamente implica varias acciones:

• Invalidar las credenciales y tokens asociados. La especificación OAuth 2.0 Token Revocation (RFC 7009) define cómo un cliente indica al servidor que un token ya no es necesario y recomienda que, al revocar un token de actualización, se invaliden también los de acceso del mismo grant si el servidor lo admite.
• Comprobar los permisos en cada petición frente al estado actual de la conexión, en lugar de confiar en datos de sesión antiguos.
• Cortar las sincronizaciones pendientes y vaciar las colas de esa conexión.
• Aplicar la política acordada sobre copias: borrarlas, anonimizarlas o conservarlas como históricas de solo lectura si el contrato lo permite.
• Avisar a los administradores de ambos lados y dejar constancia en la auditoría.

La revocación también debe probarse como cualquier otra función: tras revocar, una batería automática intenta todas las operaciones que la conexión permitía y verifica que fallan.

Imagina una plataforma de calidad para fabricantes. El fabricante es un tenant y cada uno de sus subcontratistas, otro. El fabricante crea una conexión con un subcontratista limitada a las órdenes de un proyecto, con permiso para leer especificaciones y subir certificados. El subcontratista acepta y asigna a dos personas de su departamento de calidad. Los certificados quedan en el tenant del fabricante; el subcontratista conserva una copia de solo lectura de lo que subió. Al terminar el proyecto, el fabricante revoca la conexión: los tokens se invalidan, las dos personas dejan de ver las órdenes y ambos tenants conservan en su auditoría el historial completo.

1. ¿Existe la conexión como objeto propio, con estado, alcance y aprobaciones de ambos lados?
2. ¿Tiene cada conector o integración su propia identidad, ligada a un solo tenant y con alcance mínimo?
3. ¿El permiso efectivo es la intersección de lo que concede el propietario y lo que asigna el receptor?
4. ¿Puede cada organización ver quién de la otra ha accedido a sus datos?
5. ¿Está definido qué pasa con los datos copiados al revocar, y se prueba la revocación de forma automática?

Estas decisiones condicionan el modelo de datos y conviene tomarlas antes de la primera integración, no cuando un cliente pide conectar con su proveedor. Si estás diseñando un producto SaaS con relaciones entre organizaciones, podemos ayudarte a definir el modelo de conexiones y permisos desde el análisis inicial.