Arquitectura multiusuario: por qué la necesitan los sistemas de marcación automática.

Si gestionas una empresa de externalización de procesos de negocio (BPO), un negocio de reventa o cualquier operación que preste servicios a múltiples clientes en la misma plataforma de marcación automática, la arquitectura multiusuario no es un lujo, sino la base sobre la que se sustenta todo lo demás.

Qué significa realmente la arquitectura multiusuario

La arquitectura multiusuario implica que varios clientes independientes (inquilinos) comparten la misma infraestructura de software, manteniendo datos, configuraciones y reglas de cumplimiento completamente aislados. Cada inquilino opera como si tuviera su propio sistema dedicado, pero la plataforma subyacente es compartida.

La palabra clave es isolationNo es separación. No es filtrado. Es aislamiento.

Por qué el aislamiento importa

Protección de datos. Los contactos, las grabaciones de llamadas, los datos de los agentes y los resultados de las campañas del Cliente A deben ser invisibles para el Cliente B. No solo ocultos, sino inaccesibles de forma demostrable. Si un desarrollador comete un error en una consulta, la base de datos debe impedir el acceso a los datos entre usuarios.

Independencia en materia de cumplimiento normativo. El cliente A podría operar bajo las normas TDRA (EAU). El cliente B bajo las normas CITC (Arabia Saudita). El cliente C bajo las normas TCPA (EE. UU.). Cada inquilino necesita sus propias normas de cumplimiento, listas de no llamar, horarios de llamadas y seguimiento del consentimiento. Una infracción de cumplimiento por parte de un inquilino no puede afectar a otro.

Aislamiento de grabación. Las grabaciones de llamadas son los datos más sensibles en un centro de contacto. Las grabaciones de cada cliente deben almacenarse en rutas de almacenamiento aisladas con controles de acceso específicos para cada cliente. Una URL firmada para la grabación del Cliente A nunca debe funcionar para el Cliente B.

Aislamiento de facturación. Cada inquilino tiene su propio número de agentes, métricas de uso y ciclo de facturación. Los datos de facturación deben ser precisos para cada inquilino, sin que se produzcan errores de conexión entre ellos.

El método incorrecto: Filtrado a nivel de aplicación

Muchos marcadores implementan la "multitenencia" con un simple DONDE tenant_id = ? El filtro se añade al código de la aplicación. Cada consulta agrega este filtro. Funciona... hasta que alguien se olvida.

Los problemas:

• Un filtro omitido = fuga de datos entre inquilinos
• Es fácil equivocarse con las consultas complejas que incluyen uniones.
• Las consultas de agregación (informes, paneles de control) son especialmente riesgosas.
• No hay red de seguridad cuando la aplicación comete un error.

El filtrado a nivel de aplicación no es aislamiento. Es un filtro que se basa en el mejor esfuerzo posible y que depende de que cada desarrollador, en cada consulta, en cada ruta de código, lo haga correctamente el 100 % de las veces. Eso no es suficiente.

La forma correcta: Aislamiento a nivel de base de datos

DialerBee utiliza la seguridad a nivel de fila (RLS) de PostgreSQL como una capa de defensa en profundidad. Así es como funciona:

1. Cada mesa propiedad del inquilino tiene una tenant_id column
2. Las políticas RLS están habilitadas y FORZADAS en cada tabla de inquilinos.
3. Al inicio de cada transacción de base de datos, establecemos ESTABLECER LOCAL app.current_tenant_id = :tid
4. La propia base de datos filtra cada consulta (SELECT, INSERT, UPDATE, DELETE) para devolver únicamente las filas que coincidan con el inquilino actual.
5. El usuario de la aplicación no tiene permiso BYPASSRLS; ni siquiera SQL sin procesar puede escapar del filtro.

Esto significa que, incluso si el código de la aplicación contiene un error (una cláusula WHERE faltante, una unión incorrecta, una agregación sin agrupación), la base de datos impide el acceso a datos entre usuarios. El filtro de la aplicación es la principal defensa. La seguridad a nivel de fila (RLS) es la red de seguridad.

Pruebas de aislamiento

No basta con afirmar que existe aislamiento. Hay que demostrarlo. DialerBee ejecuta pruebas de aislamiento de inquilinos adversarias en cada punto final de la API:

1. El inquilino A crea un recurso (contacto, campaña, grabación, etc.).
2. El inquilino B intenta realizar operaciones GET, PATCH y DELETE en ese recurso.
3. Cada intento debe devolver 404 (no encontrado), nunca 403 (prohibido).

¿Por qué 404 en lugar de 403? Porque el error 403 ("no tienes permiso") confirma que el recurso existe. El error 404 ("no encontrado") no revela nada. El inquilino B ni siquiera debería saber que el recurso existe.

Estas pruebas se ejecutan en el sistema de integración continua (CI) con cada cambio de código. Si alguna prueba falla, el código no se fusiona.

Lo que los socios deberían exigir

Si está evaluando un marcador telefónico para su uso con marca blanca o para revendedores, hágase estas preguntas:

• ¿El aislamiento de inquilinos se aplica a nivel de base de datos o solo en el código de la aplicación?
• ¿Puedes mostrarme el conjunto de pruebas de aislamiento adversario?
• ¿Qué ocurre si una consulta omite accidentalmente el filtro de inquilino?
• ¿Se almacenan las grabaciones de llamadas en rutas aisladas para cada inquilino?
• ¿Puede la infracción de un inquilino afectar a otro?
• Si creo un inquilino a través del portal de socios, ¿queda inmediatamente aislado del resto de inquilinos?

Si la respuesta a alguna de estas preguntas es vaga, siga buscando. Una implementación incorrecta de la arquitectura multiusuario es peor que no tenerla en absoluto, ya que genera una falsa sensación de seguridad.