Saltar al contenido

Conectividad e interoperabilidad

Arquitectura multiempresa: conectar organizaciones sin mezclar sus datos

Hay plataformas donde cada empresa no solo usa la aplicación, sino que la conecta con sus propios sistemas: el ERP de cada cliente envía pedidos, el subcontratista consulta planos del fabricante, las sociedades de un grupo comparten maestros pero no su contabilidad. Eso añade a la separación de datos entre organizaciones otro problema: cómo entra cada conexión, con qué identidad y qué ocurre cuando una relación termina. Esta página trata de esas conexiones entre la plataforma y la red de cada empresa, de los accesos que una organización concede a otra y de la revocación. El diseño interno de un SaaS multitenant y las pantallas de un portal B2B se tratan en sus capacidades.
Plantear un proyectoVer escenarios
Ejemplo de conexión de varias empresas a una plataforma comúnEsquema ilustrativo

  1. 01 · Red de cada empresa

    • Sistema local: ERP o base de datos
    • Agente conector con conexión saliente

  2. 02 · Entrada autenticada

    • Certificado o token por empresa y conector
    • Pasarela que asigna el tenant según la credencial

  3. 03 · Plataforma

    • Datos separados por empresa
    • Concesiones entre empresas con alcance y caducidad

  4. 04 · Control

    • Auditoría consultable por cada empresa
    • Revocación y rotación de credenciales

El problema

Por qué hay que decidirlo bien

Cuando varias organizaciones comparten plataforma, un único error de diseño puede exponer datos de una empresa a otra, y eso tiene consecuencias contractuales y de confianza difíciles de reparar. A la vez, las empresas no quieren abrir puertos de su red para que una plataforma externa lea su ERP, y necesitan poder cortar un acceso en minutos si un socio deja de serlo o una credencial se filtra. El reto es conectar sistemas de organizaciones distintas con identidades separadas, permisos que se puedan explicar y una auditoría que muestre quién accedió a qué.

Escenarios

Situaciones en las que se plantea

Ejemplos de lo que se podría diseñar. No describen proyectos realizados.

  • 01

    Agente conector en la red de cada cliente

    Cada empresa instala un pequeño agente junto a su ERP o su base de datos. El agente abre una conexión saliente y autenticada hacia la plataforma, sin puertos entrantes en la red del cliente, y solo lee las vistas que la empresa ha autorizado.

  • 02

    Grupo empresarial con varias sociedades

    Las sociedades comparten el catálogo de artículos y la lista de proveedores homologados del grupo, pero cada una ve solo sus pedidos y su facturación. El modelo distingue datos de grupo y datos de sociedad, y los permisos lo reflejan en cada consulta.

  • 03

    Acceso delegado a un subcontratista

    Un fabricante concede a un taller externo acceso a los pedidos y planos de un proyecto concreto durante su vigencia. La concesión tiene alcance, responsable y fecha de caducidad, y el taller no ve nada más de la empresa que la otorga.

  • 04

    Fin de la relación con un socio

    Cuando un socio deja de colaborar se revocan sus credenciales y concesiones, se detienen sus conectores y se ejecuta lo acordado sobre sus datos: exportación, conservación durante un plazo o borrado, con constancia de cada paso.

  • 05

    Credencial comprometida de una empresa

    Se detecta uso anómalo de la credencial de un conector. Se revoca y se emite una nueva solo para esa empresa, sin afectar a las demás, y la auditoría permite saber qué datos se consultaron con la credencial antes del corte.

Decisiones técnicas

Qué hay que decidir y con qué criterio

  1. 01

    Cómo entra cada conexión

    Agente con conexión saliente, VPN entre redes o API pública con autenticación por organización. El agente suele ser lo menos intrusivo para el cliente; la VPN añade complejidad de operación; la API exige que el cliente sepa integrarse.

  2. 02

    Identidad por empresa y por conector

    Cada organización y cada conector tienen credenciales propias, preferiblemente certificados o tokens de corta duración. La plataforma identifica al tenant por la credencial, nunca por un dato que el propio mensaje declare.

  3. 03

    Nivel de aislamiento de datos

    Separación por fila con filtros obligatorios, esquema por empresa o base de datos dedicada. Se elige según el riesgo, los requisitos contractuales y el coste de operación, y se comprueba con pruebas automáticas que intentan cruzar datos.

  4. 04

    Concesiones entre organizaciones

    Los accesos de una empresa a datos de otra se modelan como concesiones explícitas: quién concede, a quién, sobre qué conjunto de datos, con qué permisos y hasta cuándo. Se pueden listar, revisar y retirar.

  5. 05

    Sincronización y propiedad

    Se decide qué datos se copian a la plataforma y cuáles se consultan bajo demanda en el sistema de cada empresa. Copiar menos reduce riesgos y facilita la retirada; consultar en origen depende de que el sistema del cliente esté disponible.

  6. 06

    Auditoría y revocación

    Registro por empresa de accesos, cambios de permisos y uso de conectores, consultable por cada organización sobre lo suyo. La revocación debe ser efectiva en minutos y su procedimiento, probado antes de necesitarlo.

Riesgos y límites

Lo que conviene tener presente

  • Ninguna arquitectura asegura por sí sola que no habrá fugas entre empresas; el aislamiento exige revisión de código, pruebas específicas y vigilancia continua.
  • Revocar el acceso no recupera los datos que el socio ya descargó; los límites de uso posterior deben fijarse por contrato.
  • Un agente instalado en la red del cliente es software que hay que actualizar y soportar; su ciclo de vida y su permiso de actualización se acuerdan desde el principio.
  • Las concesiones caducadas que nadie retira acumulan accesos innecesarios; conviene una revisión periódica con cada organización.

Preguntas frecuentes

¿Tenemos que abrir puertos en nuestra red para conectarnos a la plataforma?

Con un agente que inicia la conexión desde dentro, normalmente no. El agente sale hacia la plataforma por un canal cifrado y autenticado, y vuestro equipo de sistemas decide qué puede leer y desde qué equipo se ejecuta.

¿Cómo se demuestra que otra empresa no ha visto nuestros datos?

Con la auditoría de accesos de vuestra organización, que muestra quién consultó qué y con qué credencial, y con las pruebas de aislamiento que se ejecutan en cada versión. Qué se entrega como evidencia y con qué periodicidad se pacta en el contrato.

¿Qué pasa con nuestros datos si dejamos de usar la plataforma?

Depende de lo acordado: lo habitual es ofrecer una exportación en un formato documentado, un plazo de conservación y después el borrado, con constancia de cada paso. Conviene definirlo antes de empezar, no al terminar.

Sectores, capacidades y lecturas relacionadas

Sectores donde se plantea

Capacidades relacionadas

Para profundizar

Más en integraciones

Cuéntanos qué organizaciones deben conectarse y qué deben poder ver unas de otras

Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.

Plantear un proyecto

Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.