Datos de oficina: por qué exigen una base de datos aislada

Cuando un equipo de TI o de seguridad evalúa una herramienta de reservas para la oficina, el cuestionario suele preguntar por el cifrado, el inicio de sesión único y dónde están los servidores. Rara vez hace la pregunta que más importa para esta categoría de datos: ¿están los datos de nuestra organización físicamente separados de los de todos los demás clientes, o son una columna en una tabla compartida?

La reserva de escritorios parece un dato de bajo riesgo hasta que se enumera lo que contiene: quién estuvo en qué edificio qué día, en qué escritorio, junto a quién, con qué visitantes y dónde aparcó su coche. Eso es un registro de movimientos de su plantilla. Merece el mismo aislamiento que exigiría para los datos de RR. HH. o de nóminas.

Este artículo explica las dos formas en que los proveedores SaaS almacenan datos multiinquilino, por qué Desk & Park da a cada organización su propia base de datos aislada y qué significa esa decisión para las personas que firman la aprobación de seguridad, privacidad y cumplimiento.

Dos arquitecturas, un compromiso

Casi todos los productos SaaS son multiinquilino: una aplicación sirve a muchos clientes. La cuestión es dónde vive la frontera entre clientes.

Base de datos compartida, columna de inquilino

El enfoque habitual. Las filas de todos los clientes están en las mismas tablas, y cada fila lleva un tenant_id. Toda consulta debe filtrar por él. La aplicación, no la base de datos, es la responsable de mantener separados a los clientes.

Es popular porque es barato de operar: una base de datos, un esquema, una migración. También es el origen de toda una clase de incidentes de seguridad. Un solo WHERE tenant_id = ? que falte en una de miles de consultas, un informe que cruce tablas sin el filtro, un error de caché, y el cliente A ve los datos del cliente B. Estos errores no son hipotéticos; son una categoría recurrente de brechas de SaaS divulgadas, y son difíciles de encontrar porque cada consulta individual parece correcta.

Base de datos aislada por organización

Cada cliente recibe su propia base de datos, con sus propias tablas, sus propias credenciales y sus propias copias de seguridad. La aplicación se conecta a la base de datos correcta para la organización que hace la petición. No hay ningún filtro tenant_id que olvidar, porque no hay otro inquilino en la base de datos del que pueda filtrarse nada.

Cuesta al proveedor más disciplina operativa: aprovisionar, migrar y monitorizar cientos o miles de bases de datos en lugar de una. Ese coste es precisamente la cuestión. Lo paga el proveedor, una vez, en ingeniería, en lugar de pagarlo el cliente, más tarde, en un incidente.

Cómo está construido Desk & Park

Desk & Park funciona con una arquitectura de base de datos por organización. En concreto:

• Un plano de control guarda solo lo necesario para enrutar y facturar: nombres de las organizaciones, plan, la correspondencia entre una organización y su base de datos, y el registro de auditoría de la propia plataforma. No contiene reservas, ni planos, ni directorio de empleados.
• Una base de datos PostgreSQL por organización guarda todo lo relativo a esa organización: usuarios, roles, ubicaciones, mapas, escritorios, plazas de parking, salas, reservas, check-ins, visitantes, notificaciones y el registro de auditoría de la organización.
• Credenciales por organización. La aplicación abre una conexión a la base de datos de una organización con credenciales limitadas a esa base de datos. Una petición de la organización A no puede ejecutarse contra la base de datos de la organización B ni siquiera por error, porque nunca mantiene una conexión con ella.
• Copias de seguridad, restauración y borrado por organización. Las copias de seguridad se hacen por base de datos. Restaurar una organización al estado de ayer no toca a nadie más. Eliminar una organización al final de un contrato significa borrar su base de datos, lo que es un borrado completo y verificable, y no un DELETE WHERE tenant_id que espera haber encontrado todas las filas.

El código de la aplicación es compartido; los datos no. Esa es la frontera que un auditor puede señalar.

Qué aporta el aislamiento a quienes firman la aprobación

Para el CISO: un radio de impacto más pequeño

Una vulnerabilidad en una capa de consultas multiinquilino expone a todos los clientes a la vez. Con bases de datos aisladas, la misma clase de error no puede cruzar la frontera de una organización, porque la frontera la imponen el motor de base de datos y las credenciales de conexión, no la lógica de la aplicación. El aislamiento no hace a una aplicación inmune a los errores; hace que un error en un punto sea un problema de un solo cliente en lugar de uno de toda la plataforma.

Para el DPO: respuestas limpias a las preguntas del RGPD

Las revisiones de protección de datos hacen preguntas predecibles, y la base de datos por organización les da respuestas cortas.

El derecho de supresión y la obligación de limitar el tratamiento se convierten en operaciones de base de datos con un alcance claro, en lugar de funciones de la aplicación cuya exhaustividad hay que probar.

Para el responsable de cumplimiento: un control defendible

Marcos como ISO 27001 y SOC 2 piden al proveedor que demuestre la separación lógica entre clientes. "Toda consulta filtra por inquilino" es un control que hay que volver a verificar con cada nueva consulta. "Cada cliente tiene su propia base de datos y sus propias credenciales" es un control que se verifica una vez, estructuralmente, y se mantiene a medida que el producto crece. El segundo es mucho más fácil de evidenciar, tanto para el proveedor como para la propia auditoría del cliente.

Para el CIO: rendimiento y ciclo de vida predecibles

El informe pesado de una organización no ralentiza la hora punta de check-in de otra, porque no comparten tablas ni índices. Las migraciones se despliegan por base de datos, así que un problema puede detectarse en una organización antes de que llegue a la siguiente. La baja de un cliente es un borrado, no un proyecto de limpieza.

El resto de la historia de seguridad

El aislamiento es el cimiento, no el edificio entero. Los controles que los equipos de TI esperan se apoyan sobre él, y merece la pena enumerarlos porque una buena arquitectura con una autenticación débil sigue siendo débil:

• Inicio de sesión único mediante OpenID Connect con su proveedor de identidad, y aprovisionamiento SCIM para que las altas y bajas se creen y desactiven desde su directorio, no a mano.
• Autenticación de dos factores (TOTP) y passkeys (WebAuthn), con una política a nivel de organización para exigir MFA.
• Políticas de seguridad por organización: caducidad de sesión, reglas de contraseñas, listas de IP permitidas.
• Gestión de sesiones activas para que un administrador pueda ver y revocar sesiones.
• Un registro de auditoría por organización que recoge quién cambió qué, en la propia base de datos de la organización.
• Pagos a través de Stripe, de modo que los datos de tarjeta nunca llegan a la plataforma.
• Acceso basado en roles: los empleados ven y reservan; los administradores configuran; los miembros del consejo y los managers obtienen informes limitados a sus equipos.

Nada de esto es inusual en el SaaS empresarial. Lo inusual es combinarlo con una capa de datos en la que la frontera entre clientes es física.

Preguntas que hacer a cualquier proveedor de workplace

Si está comparando herramientas, estas cinco preguntas separan el marketing de la arquitectura:

1. ¿Están nuestros datos en una base de datos dedicada o en tablas compartidas con una columna de inquilino?
2. ¿Las copias de seguridad, las restauraciones y los borrados se realizan por cliente?
3. ¿Qué credenciales usa la aplicación para llegar a nuestros datos, y están limitadas a nosotros?
4. ¿Cómo evidencian la separación entre clientes ante sus auditores?
5. ¿Puede un error en un informe o en una exportación devolver alguna vez filas de otro cliente?

Un proveedor con base de datos aislada responde a las cinco con una frase cada una. Un proveedor con base de datos compartida tiene que describir un proceso de pruebas.

El aislamiento debería ser lo normal

Los datos de workplace son datos personales sobre la presencia física de sus empleados. La arquitectura más barata para el proveedor coloca esos datos junto a los de todos los demás clientes y confía en que la aplicación los mantenga separados. Desk & Park eligió la más cara, para que la frontera entre organizaciones sea una base de datos, no un filtro.

Puede leer el detalle técnico en el resumen de arquitectura de la página de cómo funciona y en la política de privacidad de la plataforma. Para un despliegue enterprise con inicio de sesión único, SCIM y una revisión de seguridad, la página de precios tiene el contacto de Enterprise.