¿Autenticación centralizada o cuentas separadas? Cómo elegir un modelo de identidad para aplicaciones autoalojadas

La arquitectura de inicio de sesión se convierte en una decisión operativa a medida que crece su pila

Una aplicación autoalojada normalmente puede gestionarse con cuentas de usuario locales. Sin embargo, cuando un equipo opera varias aplicaciones, el diseño del inicio de sesión afecta a más aspectos que la comodidad de los usuarios. Afecta a quién crea las cuentas, con qué rapidez se elimina el acceso, dónde conservan los administradores el acceso de recuperación y qué ocurre si un servicio de identidad centralizado no está disponible.

Un proveedor de identidad centralizado para aplicaciones autoalojadas puede reducir el trabajo repetido de gestión de cuentas. También puede convertirse en una dependencia crítica: si fallan el proveedor de identidad, su proceso de administración o su proceso de recuperación, los usuarios podrían no poder acceder a varios servicios a la vez. Por tanto, la elección correcta no es automáticamente «centralizarlo todo». Es el modelo que su equipo puede operar y recuperar de forma segura.

Airbip gestiona la infraestructura en la nube en torno a cargas de trabajo de aplicaciones Docker desplegadas, incluido el enrutamiento y la automatización de certificados TLS, las comprobaciones de DNS, la gestión del ciclo de vida de los servicios y las copias de seguridad configurables. Esos servicios de infraestructura no eligen la fuente de identidad, el modelo de permisos, el proceso de recuperación de cuentas ni la gobernanza de acceso de una aplicación. Las copias de seguridad configurables tampoco sustituyen las decisiones del cliente sobre retención, restauración y gobierno de datos; estas siguen siendo decisiones que deben tomarse aplicación por aplicación.

• Trate la arquitectura de identidad como una decisión de diseño operativo, no solo como una preferencia de pantalla de inicio de sesión.
• Evalúe el impacto probable de una interrupción del proveedor de identidad antes de convertirlo en el punto de entrada para todas las aplicaciones.
• Asigne responsables identificados para las actividades del ciclo de vida de los usuarios, el acceso privilegiado y los procedimientos de recuperación.
• Mantenga la decisión de identidad separada de las decisiones sobre copia de seguridad de la aplicación, retención de datos, gestión de sesiones y autorización de la aplicación.

Empiece por la distinción: autenticación, autorización y roles

La autenticación responde a la pregunta: «¿Puede esta persona demostrar que controla el autenticador asociado a esta identidad?». Una autenticación satisfactoria permite a un verificador afirmar un identificador y, opcionalmente, atributos ante el servicio al que se accede [según NIST SP 800-63-4](https://pages.nist.gov/800-63-4/sp800-63.html).

La autorización es una decisión independiente: «¿Qué puede hacer aquí esta persona autenticada?». Una aplicación puede utilizar información recibida durante la autenticación al tomar esa decisión, pero aún necesita su propia lógica de acceso. Los roles a nivel de aplicación expresan después los permisos disponibles dentro de esa aplicación, como un rol de administrador, editor o solo lectura.

Esta distinción evita un error de diseño común. Un inicio de sesión centralizado puede establecer quién es una persona en varias aplicaciones, pero no hace que los permisos sean coherentes entre ellas de forma inherente. La misma persona puede ser adecuadamente administradora en un sistema y tener acceso limitado en otro. La documentación oficial vigente de cada aplicación debe ser la fuente de referencia para sus roles, comportamiento de grupos y cualquier integración de identidad compatible.

• Autenticación: verifica el control del reclamante sobre un autenticador.
• Autorización: determina el acceso a un servicio o recurso.
• Roles y grupos: representan permisos y responsabilidades específicos de la aplicación.
• Sesiones: regulan cómo un navegador o cliente autenticado permanece con la sesión iniciada; necesitan sus propios controles y revisiones.

Los tres modelos de identidad viables

Las cuentas locales separadas implican que cada aplicación mantiene sus propios usuarios y métodos de autenticación. Este modelo requiere una administración más repetitiva, pero una interrupción o un problema de configuración en una aplicación no impide automáticamente iniciar sesión en el resto de la pila.

Un modelo de proveedor de identidad centralizado utiliza federación cuando existe compatibilidad: el proveedor de identidad autentica a la persona y envía una declaración a la aplicación que confía en ella. La aplicación verifica la declaración, crea una sesión autenticada y concede acceso a sus funciones. La federación puede reducir la necesidad de autenticadores separados en varias aplicaciones y centralizar partes de la gestión de cuentas.

Un modelo híbrido combina ambos. Por ejemplo, un equipo puede utilizar un proveedor de identidad centralizado para las aplicaciones que lo admiten y conservar cuentas locales cuidadosamente controladas cuando una aplicación las requiere o cuando se necesita acceso administrativo de emergencia. El enfoque híbrido suele ser un modelo operativo deliberado, no una migración incompleta.

• Cuentas locales: menos dependencias compartidas; más administración de cuentas en cada aplicación.
• Proveedor de identidad centralizado: un proceso principal de autenticación; mayor concentración del riesgo operativo.
• Híbrido: se adapta a las distintas capacidades de las aplicaciones y preserva una ruta de respaldo documentada.
• No suponga que un producto admite federación, aprovisionamiento automatizado, asignación granular de grupos o un protocolo concreto. Confirme su documentación principal vigente y la configuración de su despliegue.

Cuándo las cuentas separadas pueden ser una opción proporcional y resiliente

Las cuentas separadas pueden ser proporcionales para un equipo pequeño y estable con un número limitado de aplicaciones, pocas altas y bajas, y sin nadie responsable de operar un proveedor de identidad dedicado. En esta situación, una plataforma de identidad centralizada puede añadir más trabajo de configuración, recuperación y supervisión del que elimina.

Esta elección no es inherentemente más segura. Reduce una dependencia central compartida, pero también puede aumentar la proliferación de cuentas y el riesgo de omisiones al retirar accesos. Solo resulta adecuada cuando el trabajo repetido es realmente manejable y el equipo mantiene de forma fiable un inventario de cuentas, controles de autenticación, recuperación y bajas de acceso.

Aplique el principio de mínimo privilegio en cada aplicación: conceda únicamente el acceso requerido para una responsabilidad definida, limite las cuentas administrativas y registre quién es responsable de cada rol. Un entorno pequeño puede utilizar un registro sencillo y una revisión programada en lugar de una plataforma de identidad compleja, siempre que el registro se mantenga actualizado.

• Elija cuentas locales cuando el número de usuarios sea reducido y los cambios de cuentas sean poco frecuentes.
• Elija cuentas locales cuando su equipo no tenga capacidad para administrar, proteger y recuperar un proveedor de identidad centralizado.
• Use cuentas individuales en lugar de una cuenta compartida por el equipo para poder atribuir las acciones y retirar el acceso a una sola persona.
• Mantenga un inventario de cada aplicación, responsable de cuenta, cuenta privilegiada, contacto de recuperación y fecha de revisión.
• Asegúrese de que cada administrador crítico tenga un método de recuperación documentado y evite diseñar la recuperación en torno a una única persona.

Cuándo se justifica la autenticación centralizada

La autenticación centralizada resulta más convincente cuando las incorporaciones y bajas ocurren con frecuencia, cuando el número de aplicaciones hace que la administración repetida sea poco fiable o cuando la organización ya dispone de controles de identidad maduros y una propiedad administrativa clara. El beneficio no consiste simplemente en tener menos contraseñas; consiste en una forma más repetible de establecer y retirar acceso a servicios compatibles.

La federación no elimina a la aplicación que confía en ella del modelo de acceso. [NIST indica](https://pages.nist.gov/800-63-4/sp800-63c/Federation/) que una cuenta federada de aplicación debe aprovisionarse antes de poder crear una sesión autenticada, y que la aplicación puede deshabilitar o cancelar su cuenta local independientemente del proveedor de identidad. Planifique ambos lados: el registro de identidad y la cuenta de aplicación o el registro de autorización.

Centralice únicamente cuando la ganancia sea real. Una aplicación que no tenga una integración compatible, necesite un administrador local o tenga un ciclo de vida distinto puede seguir siendo local. Forzar todos los servicios a través de una ruta de acceso puede crear soluciones frágiles y ocultar la responsabilidad.

• Priorice la autenticación centralizada cuando la rotación de cuentas haga que la administración local manual sea propensa a errores.
• Verifique la opción de integración exacta, el comportamiento de los roles y el método de aprovisionamiento de cuentas en la documentación oficial antes de comprometerse con un diseño.
• Defina quién puede administrar el proveedor de identidad, aprobar el acceso y cambiar las asignaciones de roles de aplicación.
• Documente cómo se revoca el acceso tanto en el proveedor de identidad como en cada aplicación que confía en él.
• Pruebe el efecto de la indisponibilidad del proveedor de identidad sobre los usuarios normales y los administradores.

Preguntas que responder antes de centralizar la autenticación

Empiece por la compatibilidad, pero no se detenga ahí. Para cada aplicación, identifique las opciones de autenticación y federación compatibles en la documentación principal vigente, la configuración necesaria, el comportamiento de aprovisionamiento de cuentas y la forma en que funcionan las excepciones locales. Las capacidades de un producto pueden variar según el producto, la edición, la versión y la configuración del despliegue.

Después, diseñe la administración y la recuperación. La recuperación de cuentas es distinta de la autenticación habitual. [NIST identifica](https://pages.nist.gov/800-63-4/sp800-63b/events/) enfoques de recuperación que incluyen códigos de recuperación guardados o emitidos, contactos de recuperación, verificación de identidad repetida y métodos específicos de la aplicación basados en un análisis de riesgos documentado. [NIST también recomienda](https://pages.nist.gov/800-63-4/sp800-63b.html) animar a los usuarios a mantener al menos dos medios de autenticación separados para reducir los eventos de recuperación.

Por último, decida qué sucede si la ruta habitual no está disponible. Una cuenta de emergencia es una vía de acceso administrativo de emergencia, no un atajo cotidiano para eludir la gobernanza. Debe tener un responsable identificado, uso restringido, material de recuperación protegido, un procedimiento de prueba documentado y una revisión después de cada uso.

• ¿Qué opciones de autenticación o federación admite actualmente cada aplicación?
• ¿Quién es responsable del proveedor de identidad, sus cuentas privilegiadas y sus cambios de configuración?
• ¿Qué cuentas de aplicación aún deben existir localmente y por qué?
• ¿Cómo se crean los nuevos usuarios, se aprueban los cambios de roles y se elimina a los usuarios que se van?
• ¿Cuál es la ruta de emergencia si el proveedor de identidad, una cuenta de administrador o un autenticador no están disponibles?
• ¿Quién conserva los contactos o el material de recuperación, y cómo se protege y prueba ese acceso?
• ¿Cómo se cierran o reautentican las sesiones cuando el riesgo o los cambios de rol lo requieren?
• ¿Qué evidencia demostrará que se revisaron el acceso y los permisos?

La autenticación centralizada no crea permisos coherentes

Un proveedor de identidad centralizado puede proporcionar a una persona una experiencia de autenticación única en las aplicaciones compatibles. No define automáticamente lo que esa persona puede hacer después de iniciar sesión. La autorización y la determinación de acceso siguen siendo decisiones de la aplicación, y distintas aplicaciones pueden interpretar los roles, grupos y atributos de manera diferente.

Evite asignar amplios derechos administrativos solo porque un usuario haya iniciado sesión correctamente mediante el servicio central. En su lugar, defina una matriz de acceso para cada aplicación: responsabilidad laboral, rol de aplicación, aprobador, responsable de cuenta y frecuencia de revisión. Cuando exista asignación de grupos o atributos, verifique su comportamiento real en la documentación vigente del producto y pruébelo con cuentas que no sean de producción cuando sea posible.

Las capas externas de autenticación también pueden tener un papel limitado. Por ejemplo, [Traefik ForwardAuth](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) delega la autenticación a un servicio externo y permite el acceso cuando ese servicio devuelve una respuesta 2XX. Esto describe una puerta de autenticación; no establece por sí misma los roles internos de una aplicación, los permisos sobre datos ni los controles de ciclo de vida.

• Mantenga definiciones de roles específicas de cada aplicación incluso cuando la autenticación sea centralizada.
• Exija aprobación explícita para los roles privilegiados.
• Revise las asignaciones de grupo a rol cada vez que cambie la configuración de identidad o la configuración de la aplicación.
• No considere una puerta de autenticación de proxy inverso como un sistema de autorización completo.
• Mantenga los controles de sesión y las reglas de acceso a datos dentro del alcance como cuestiones de seguridad independientes de la aplicación.

Opere el modelo con evidencias, revisiones y responsabilidades documentadas

Independientemente del modelo que elija, mantenga un registro de identidad aplicación por aplicación. Registre la fuente de identidad, el responsable de la aplicación, las cuentas privilegiadas, las excepciones de cuentas locales, los contactos de recuperación, el método habitual de aprovisionamiento, el método de desaprovisionamiento y las evidencias de la última revisión de permisos. Esto proporciona a un equipo en crecimiento un registro operativo auditable sin presuponer automatización no compatible.

Estructure las revisiones en torno a incorporaciones, cambios de puesto y salidas. Una incorporación necesita únicamente el acceso aprobado requerido para comenzar a trabajar. En un cambio de puesto, los derechos anteriores deben reevaluarse a medida que cambian las responsabilidades, no limitarse a añadir derechos nuevos. Una salida requiere la eliminación o desactivación rápida del acceso por todas las rutas pertinentes, incluidas las excepciones locales y las cuentas privilegiadas. Establezca una cadencia basada en el volumen de cambios y el riesgo, y conserve pruebas de que se realizó la revisión y se resolvieron las excepciones.

El [Marco de Ciberseguridad 2.0 de NIST](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) destaca la gobernanza mediante roles, responsabilidades, autoridades, políticas y supervisión. Aplique ese principio de forma práctica: alguien debe ser responsable del proveedor de identidad, alguien debe ser responsable del modelo de autorización de cada aplicación y las rutas de escalado deben conocerse antes de que se produzca un bloqueo o una salida.

El alojamiento gestionado de aplicaciones Docker puede reducir la administración de infraestructura en torno a los servicios desplegados. No sustituye la ingeniería de identidad ni la gobernanza empresarial de identidad. Si la integración con directorios, las obligaciones regulatorias, la alta disponibilidad o los requisitos formales de garantía de identidad superan la capacidad de su equipo, utilice un servicio de identidad especializado o un acuerdo de alojamiento empresarial en lugar de tratar una plataforma general de aplicaciones gestionadas como una solución completa de gestión de identidades.

• Cree y mantenga un registro de identidad para cada aplicación.
• Revise el acceso después de cambios de rol, no solo durante auditorías periódicas.
• Revise las cuentas privilegiadas más estrechamente que las cuentas ordinarias.
• Documente las excepciones de cuentas locales y elimínelas cuando dejen de estar justificadas.
• Pruebe los procedimientos de recuperación y de emergencia con una cadencia planificada; registre los resultados y las medidas correctivas.
• Utilice la documentación oficial de la aplicación y del proveedor de identidad como base para las decisiones de configuración y control.
• Reevalúe el modelo cuando cambien el número de aplicaciones, la rotación de personal, la sensibilidad de los datos o los requisitos operativos.