¿Una aplicación autoalojada o varias? Un marco de decisión para separar equipos y clientes

Un espacio de trabajo, un rol y un despliegue resuelven problemas distintos

La cuestión no es simplemente si las personas deben ver carpetas, proyectos o registros diferentes. Es qué límite debe aplicarse, en quién se confía para operar a cada lado de ese límite y con qué independencia debe cambiar y recuperarse cada grupo.

Un rol dentro de la aplicación normalmente regula lo que puede hacer un usuario autenticado. Un espacio de trabajo, organización, proyecto u otro contenedor lógico similar puede organizar registros y limitar qué usuarios pueden verlos o editarlos. Estos controles pueden ser eficaces cuando la aplicación los implementa correctamente y se configuran, revisan y prueban. Siguen siendo controles dentro de un único despliegue de aplicación.

Un despliegue independiente es un límite de infraestructura y operaciones. En una configuración basada en contenedores, un [proyecto de Docker Compose](https://docs.docker.com/compose/intro/compose-application-model/) agrupa los recursos de un despliegue y puede aislarlos de otras instalaciones que usan parámetros diferentes. Un proyecto independiente también puede tener su propia red predeterminada. Esto no lo convierte en un host totalmente independiente ni elimina la importancia de la administración del host, pero es materialmente distinto de crear otro espacio de trabajo en la misma aplicación.

No utilice el nombre de un espacio de trabajo como abreviatura de una arquitectura de seguridad. Primero determine qué aísla realmente la aplicación; después decida si ese aislamiento coincide con la promesa hecha a un equipo, cliente, entidad jurídica u organismo regulador.

• Límite de rol de usuario: qué acciones pueden realizar los usuarios que han iniciado sesión.
• Límite lógico de datos: a qué registros, proyectos o espacios de trabajo pueden acceder los usuarios dentro de una aplicación.
• Límite de despliegue: qué servicios de aplicación, configuración, datos persistentes, credenciales, rutas y calendario de versiones pertenecen conjuntamente.
• Límite de administración del host: quién puede administrar el servidor, el entorno de ejecución de contenedores, el almacenamiento y la configuración del despliegue.
• Límite de recuperación: qué datos pueden restaurarse de forma independiente, quién puede hacerlo y qué efecto tiene sobre otros usuarios.

Empiece por definir el límite real

Un equipo no siempre es la unidad que necesita separación. El límite relevante puede ser una organización cliente, una entidad jurídica, una unidad de negocio con administradores separados, un entorno de producción o una categoría de datos con requisitos especiales de tratamiento. Un diseño útil empieza con una declaración en lenguaje claro sobre lo que no debe cruzar el límite.

Por ejemplo: «El personal del Cliente A no debe acceder a los registros del Cliente B» es principalmente un requisito de acceso a la aplicación. «El Cliente A debe disponer de un conjunto de datos restaurable por separado, integraciones de propiedad independiente y no depender de la aprobación de versiones del Cliente B» exige un límite operativo más sólido. «Un cliente externo no debe tener que confiar en nuestros administradores internos para el acceso a la configuración de su servicio y los datos almacenados» plantea una cuestión de alojamiento y confianza administrativa, no solamente una cuestión de diseño de roles.

Cuando intervienen datos personales, la gobernanza debe abarcar tanto la prevención como la recuperación. El [artículo 5 del RGPD](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=EN) exige medidas técnicas u organizativas apropiadas que protejan contra el tratamiento no autorizado o ilícito y contra la pérdida, destrucción o daño accidental. También incluye la limitación del plazo de conservación: los datos personales identificables no deben conservarse más tiempo del necesario para su finalidad, con sujeción a las excepciones establecidas. Las obligaciones diferentes de conservación o eliminación son con frecuencia una razón práctica para evitar un patrimonio de datos único e indiferenciado.

• Identifique la población protegida: personal interno, un cliente, una entidad jurídica, una función regulada o un entorno de producción.
• Indique la consecuencia de un error de acceso: inconveniente, incumplimiento contractual, exposición de información confidencial o impacto regulatorio.
• Enumere a las personas que necesitan acceso elevado: administradores de la aplicación, responsables de integraciones, administradores de infraestructura y personal de soporte.
• Registre si los datos deben exportarse, conservarse, eliminarse o restaurarse según un calendario diferente para cada grupo.
• Deje por escrito si el límite es una preferencia de organización o un requisito contractual, legal o de seguridad.

Cuándo una instancia compartida es la opción más sencilla y adecuada

Una instancia compartida puede ser la respuesta correcta cuando los grupos operan realmente bajo el mismo modelo de gobernanza. Centraliza las actualizaciones, la supervisión, la administración de autenticación, la configuración de la aplicación, las rutinas de copia de seguridad y el soporte a usuarios. También puede hacer que la colaboración y los informes entre equipos estén menos fragmentados cuando la compartición es intencionada y el propio modelo de acceso de la aplicación admite las restricciones necesarias.

Un modelo compartido es más sólido cuando la organización puede describir y operar un único dominio administrativo. Los mismos administradores de confianza pueden gestionar el sistema, un único calendario de versiones es aceptable, las integraciones pueden gobernarse de forma centralizada y una restauración que afecte a toda la aplicación es un evento de recuperación aceptable. Esto suele ser un punto de partida sensato para departamentos internos de una organización con sensibilidad y necesidades de ciclo de vida comparables.

La contrapartida es el acoplamiento. Un cambio de configuración para toda la aplicación, un rol de administrador amplio, una credencial de integración compartida o una restauración de toda la instancia pueden tener consecuencias para todos los grupos. El modelo no es inseguro por definición; simplemente necesita una gobernanza disciplinada y proporcional a los datos y las partes interesadas implicadas.

• Elija una instancia compartida cuando se espere y permita la colaboración entre grupos.
• Confirme que la aplicación tiene los roles y controles de aislamiento lógico requeridos antes de incorporar grupos sensibles.
• Aplique el principio de mínimo privilegio tanto a usuarios normales como a administradores; no otorgue acceso administrativo amplio solo por comodidad.
• Mantenga un proceso rutinario de revisión de accesos, especialmente tras cambios de personal o la baja de un cliente.
• Trate las actualizaciones de toda la aplicación, los cambios de configuración, las exportaciones y las restauraciones como cambios que pueden afectar a todos los grupos.

Cuándo las instancias separadas suelen ser la opción operativa más segura

Las instancias separadas suelen ser la opción más segura cuando los grupos tienen datos gobernados de forma independiente, administradores de confianza distintos, credenciales de integración incompatibles o requisitos de ciclo de vida y recuperación diferentes. Las agencias suelen encontrarse con esta situación cuando cada cliente espera tener sus propios usuarios, dominio, servicios conectados, exportaciones de datos, proceso de baja y vía de aprobación de cambios.

Las instancias separadas pueden reducir el radio de impacto de un cambio de configuración o una restauración erróneos, porque cada instancia puede tener su propia configuración de aplicación y ámbito de datos persistentes. También facilitan explicar la propiedad: este dominio, ruta, instancia, conjunto de credenciales, ámbito de copias de seguridad y manual operativo pertenecen a esta organización. El beneficio no es que los contenedores hagan desaparecer todos los riesgos. Es que los controles operativos pueden alinearse más estrechamente con el límite organizativo real.

[Docker aconseja](https://docs.docker.com/engine/security/) que solo usuarios de confianza controlen el demonio de Docker, porque sus capacidades pueden permitir montar directorios del host en contenedores sin limitar los derechos de acceso del contenedor. Por tanto, las aplicaciones separadas en un host compartido no eliminan la necesidad de gobernar el acceso de los administradores de infraestructura. El [modo Rootless de Docker](https://docs.docker.com/engine/security/rootless/) puede reducir la exposición al ejecutar el demonio y los contenedores como un usuario no root, pero es una medida de refuerzo del host, no un sustituto de dominios administrativos independientes.

• Separe por organización cuando un cliente necesite propiedad, baja o decisiones de recuperación independientes.
• Separe cuando el administrador de un grupo no deba administrar la configuración de la aplicación de otro grupo.
• Separe cuando las credenciales, webhooks, claves de API o cuentas externas deban tener propietarios distintos y rotarse de forma independiente.
• Separe cuando el calendario de versiones, la configuración personalizada, la retención o la aprobación de cambios difieran de forma sustancial.
• Vaya más allá de instancias separadas en un mismo host cuando el límite requerido incluya confianza independiente en los administradores de infraestructura o un aislamiento contractual más fuerte.

Evalúe cinco factores de decisión antes de elegir el modelo

Utilice los siguientes factores como una prueba práctica. Asigne a cada factor una valoración para cada grupo propuesto: necesidad baja, media o alta de independencia. Un único requisito de alto riesgo puede pesar más que varias ventajas de comodidad de un modelo compartido.

La clave es evaluar controles demostrados, no etiquetas. Si la aplicación afirma tener organizaciones o espacios de trabajo, pruebe las acciones exactas que importan: ver registros, buscar, exportar, invitar usuarios, cambiar permisos, administrar integraciones y eliminar datos. Si un requisito no puede demostrarse en un entorno de prueba ni respaldarse con la documentación de la aplicación, trátelo como no cumplido hasta que se demuestre lo contrario.

• 1. Visibilidad de datos: ¿Pueden los usuarios, administradores y personal de soporte ver solo los registros que están autorizados a gestionar? Pruebe navegación directa, búsquedas, informes, notificaciones, exportaciones y acciones masivas, no solo la interfaz de usuario habitual.
• 2. Acceso de administrador: ¿Quién puede cambiar roles, configuración, almacenamiento, registros y ajustes de despliegue? Distinga los roles de aplicación del acceso al host de Docker, al entorno de ejecución y al almacenamiento persistente. Aplique separación de funciones y mínimo privilegio cuando sea práctico.
• 3. Integraciones y secretos: ¿Necesita cada grupo sus propias claves de API, cuenta de correo, destino de webhook, configuración de identidad o conexión de datos externa? [Docker Compose puede conceder un secreto](https://docs.docker.com/compose/how-tos/use-secrets/) únicamente a los servicios que lo declaren explícitamente y lo monta como archivo. Evite tratar las variables de entorno como un almacén de secretos inocuo; Docker advierte que las contraseñas y claves de API allí pueden quedar expuestas de forma no intencionada, incluso mediante registros de depuración.
• 4. Independencia de ciclo de vida: ¿Puede cada organización aceptar la misma ventana de actualización, base de configuración, proceso de soporte y vía de aprobación de cambios? Si no es así, la tenencia compartida crea deuda de coordinación.
• 5. Límites de copia de seguridad y restauración: ¿Puede restaurarse un grupo sin revertir, exponer ni interrumpir a otro? La cuestión importante es si el procedimiento de restauración previsto demuestra el límite que necesita.

Trace el modelo de aislamiento de la aplicación antes de confiar en él

Cada aplicación tiene su propio modelo, y los términos genéricos no bastan. Antes de decidir que una instancia compartida es adecuada, elabore un mapa de sus controles basado en evidencias. Utilice la versión y la documentación relevantes para el despliegue previsto y, después, valide los supuestos importantes con cuentas de prueba.

Empiece por el comportamiento de los usuarios normales y avance hacia fuera. ¿Qué define la pertenencia? ¿Puede una persona pertenecer a más de un espacio de trabajo? ¿Los roles tienen alcance global o están limitados a un espacio de trabajo? ¿Pueden los usuarios descubrir registros mediante búsquedas, enlaces, informes, notificaciones o exportaciones fuera de su ámbito previsto? ¿Las pantallas de auditoría, administración e integraciones están disponibles para una categoría de usuarios más amplia que las pantallas operativas?

A continuación, trace el recorrido de los datos. Identifique la base de datos o el almacén persistente, los archivos cargados, los registros de la aplicación, las exportaciones, los destinos de correo electrónico o webhook y las copias de seguridad. Un contenedor de frontend separado no constituye un límite de recuperación independiente si dos organizaciones siguen usando el mismo almacén de datos o artefacto de copia de seguridad. La [guía de Docker sobre volúmenes](https://docs.docker.com/engine/storage/volumes/) incluye procedimientos para archivar y restaurar volúmenes con nombre, lo que refuerza una regla básica de planificación: los datos persistentes y un procedimiento de restauración probado deben formar parte del diseño del límite.

• Documente por separado los roles globales y los roles con alcance limitado.
• Pruebe la eliminación de pertenencia, la desactivación de usuarios, los flujos de invitación y el traspaso de administración.
• Pruebe la visibilidad de registros mediante pantallas normales, búsquedas, API cuando corresponda, informes generados, notificaciones y exportaciones.
• Identifique dónde residen los archivos adjuntos, los registros, las exportaciones y los datos persistentes.
• Documente quién puede acceder a la configuración de la aplicación, los manifiestos de despliegue, el almacenamiento del host, las copias de seguridad y el material secreto.
• Conserve las evidencias de prueba con el registro de decisión, especialmente para compromisos con clientes o datos sensibles.

Compare tres patrones de despliegue prácticos

El primer patrón es una instancia de aplicación compartida. Es económicamente eficiente desde el punto de vista operativo y puede funcionar bien para una sola organización o un conjunto de equipos internos estrechamente gobernados. Depende en gran medida del modelo de autorización de la aplicación y de una gestión cuidadosa de los administradores globales, la configuración compartida, las integraciones y los procedimientos de recuperación.

El segundo patrón es una instancia de aplicación por organización. Cada organización recibe su propia configuración de despliegue, ámbito de datos persistentes, nombre de host o regla de enrutamiento, administración de aplicación y registro operativo. Esto suele proporcionar una base más clara para credenciales, decisiones de versión, exportaciones, acciones de retención y restauraciones separadas. Introduce trabajo operativo repetido que debe planificarse, no improvisarse.

El tercer patrón son servicios de infraestructura compartidos con instancias de aplicación separadas. Por ejemplo, [proyectos de Compose separados pueden usar](https://docs.docker.com/compose/how-tos/networking/) sus propias redes específicas de proyecto para componentes internos como una aplicación y una base de datos, mientras se conectan deliberadamente a una red compartida creada externamente cuando se requiere comunicación con un servicio perimetral o de soporte compartido. Esto puede equilibrar la consistencia con una conectividad de aplicación acotada, pero la pertenencia a la red y las rutas deben diseñarse y revisarse explícitamente.

• Una instancia compartida: es mejor cuando la gobernanza, la administración, el ciclo de vida y la recuperación son realmente compartidos.
• Una instancia por organización: es mejor cuando la propiedad y las decisiones operativas deben ser independientes.
• Servicios compartidos con instancias de aplicación separadas: es mejor cuando una organización puede centralizar de forma segura funciones concretas de plataforma y mantener diferenciados los límites de aplicación y capa de datos.
• Para cada patrón, decida explícitamente si la administración del host es compartida, restringida o requiere un modelo de separación más fuerte.

Planifique el trabajo operativo que se multiplica con cada instancia

Las instancias separadas reducen parte del acoplamiento de gobernanza, pero aumentan el inventario operativo. Cada instancia necesita un propietario conocido, un modelo de acceso, un dominio o regla de enrutamiento, configuración de aplicación, credenciales, ámbito de copia de seguridad, expectativas de supervisión, historial de actualizaciones y una vía de respuesta ante incidentes. Una agencia que crea instancias rápidamente pero no puede identificar su propietario o procedimiento de restauración ha creado un riesgo evitable.

La gestión de dominios y TLS forma parte de este trabajo. La [configuración dinámica de Traefik](https://doc.traefik.io/traefik/reference/routing-configuration/dynamic-configuration-methods/) determina cómo se enrutan las solicitudes entrantes a los servicios, y esa configuración puede entregarse mediante mecanismos que incluyen etiquetas y archivos de Docker. Por tanto, cada instancia necesita una asignación precisa y mantenida entre el nombre de host o regla y su servicio. Un [router de Traefik configurado para TLS](https://doc.traefik.io/traefik/v3.2/routing/routers/) gestiona solicitudes HTTPS y termina TLS antes de enviar tráfico descifrado al servicio configurado.

La automatización de certificados también tiene un ciclo de vida. [Let’s Encrypt aplica límites de emisión](https://letsencrypt.org/docs/rate-limits/) a las solicitudes realizadas a través de su punto de conexión de API de nuevos pedidos. Utilice un esquema de nombres controlado, valide el DNS antes de la puesta en producción, evite solicitar certificados repetidamente durante pruebas improvisadas y conserve un procedimiento claro para los cambios de dominio.

Airbip ejecuta instancias de aplicaciones como cargas de trabajo de Docker en servidores cloud de Airbip y automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt. También proporciona comprobaciones de DNS, gestión del ciclo de vida de los servicios, copias de seguridad diarias, semanales y mensuales configurables, y la opción de usar un subdominio de Airbip o un dominio personalizado compatible. Estas capacidades de plataforma pueden reducir el trabajo repetitivo de infraestructura, pero los clientes siguen necesitando definir la propiedad, el acceso, el tratamiento de datos, el ámbito de las copias de seguridad, los procedimientos de restauración y el modelo de separación adecuado.

• Mantenga un registro de instancias: organización, propietario, propósito, dominio, administradores, servicios conectados, clasificación de datos y fecha de baja, si corresponde.
• Utilice una convención de dominios predecible y verifique la propiedad del enrutamiento antes del lanzamiento.
• Realice seguimiento de las versiones de aplicación, cambios de configuración y requisitos de aprobación por instancia.
• Defina contactos de supervisión e incidentes para cada instancia; no dé por hecho que un equipo central conoce el contexto relevante del cliente.
• Programe pruebas de copia de seguridad y restauración en el ámbito prometido a la organización.
• Planifique el trabajo de migración antes de adoptar instancias separadas, incluido cómo se mueven los datos, cómo se realiza el cambio de acceso y cómo se conservan o eliminan los datos originales.