¿Puede aprovisionar y desaprovisionar usuarios de forma fiable? Lista de verificación para aplicaciones autoalojadas
Una lista de verificación práctica para probar la creación de cuentas, los cambios de permisos, la desactivación y los casos límite antes de adoptar u operar una aplicación autoalojada.
Trate el ciclo de vida de las cuentas como un proceso operativo
El aprovisionamiento de usuarios no se limita al momento en que alguien obtiene sus credenciales de acceso. El ciclo de vida puede incluir la creación de una cuenta, la actualización de sus atributos o permisos y, finalmente, su desactivación o eliminación. OneLogin describe el aprovisionamiento y el desaprovisionamiento como procesos que pueden incluir la creación, actualización y eliminación de cuentas en aplicaciones y sistemas (https://www.onelogin.com/learn/what-is-user-provisioning-and-deprovisioning/). Microsoft Learn también ofrece directrices para planificar una implementación de aprovisionamiento automático (https://learn.microsoft.com/en-us/entra/identity/app-provisioning/plan-auto-user-provisioning).
En una aplicación autoalojada, la pregunta importante es si cada paso funciona con el método de gestión de cuentas que usted haya elegido. No dé por sentado que una aplicación admite la sincronización con directorios, un proveedor de identidad concreto o un comportamiento específico al desactivar cuentas. Confirme esos detalles en la documentación oficial vigente tanto de la aplicación como del proveedor de identidad.
- Invitación o creación de la cuenta
- Primer inicio de sesión y activación
- Asignación de roles o grupos y cambios posteriores
- Suspensión, salida y posible reactivación
- Titularidad del contenido, los registros, las integraciones y las credenciales después de la salida
Determine cómo llegan las cuentas a la aplicación
Empiece por documentar la vía real de creación de cuentas. Puede consistir en que un administrador las introduzca manualmente, que los usuarios acepten invitaciones, que se utilice una integración de directorio documentada u otro método. Son alternativas que debe investigar, no capacidades que deba presuponer.
Para cada vía, identifique quién inicia la acción, qué información se necesita y qué prueba confirma que la cuenta está lista para usarse. Compruebe si una persona invitada que aún no ha aceptado la invitación ocupa una licencia, recibe acceso a algún contenido o puede volver a recibir una invitación; verifique cada comportamiento en la documentación de la aplicación de destino o mediante una prueba controlada.
- Anote cuál es la fuente autorizada de atributos de identidad, como el nombre y la dirección de correo electrónico.
- Establezca cómo puede saber un administrador que una cuenta se ha creado correctamente.
- Pruebe una invitación que se acepta, otra que no se acepta y otra enviada a una dirección incorrecta.
- Confirme si la aplicación ofrece una integración de aprovisionamiento automatizado documentada antes de diseñar el proceso en torno a ella.
Pruebe los roles, los grupos y los cambios de asignación
Que un inicio de sesión se complete correctamente no demuestra que los permisos se estén gestionando bien. Si el acceso se asigna mediante roles de la aplicación, grupos del proveedor de identidad o una correspondencia entre ambos, pruebe todo el recorrido, desde la asignación de origen hasta los permisos visibles en la aplicación.
A continuación, cambie la asignación. Compruebe qué ocurre cuando una persona pasa a otro grupo, pierde un grupo o recibe un rol que no tiene una correspondencia configurada. El resultado esperado depende de las políticas de su organización; el comportamiento de la aplicación debe determinarse mediante su documentación oficial y pruebas.
- Pruebe con un usuario nuevo que tenga el mínimo acceso necesario.
- Cambie un grupo o rol y compruebe los permisos resultantes en la aplicación.
- Retire una asignación y confirme si el acceso se reduce según lo previsto.
- Cambie una correspondencia y determine si se actualizan los usuarios existentes, permanecen sin cambios o requieren la intervención de un administrador.
- Documente qué ocurre cuando falta una asignación o esta es ambigua; no se base en un valor predeterminado supuesto.
Compruebe qué accesos revoca realmente la desactivación
Desactivar o eliminar una cuenta quizá no resuelva todas las dudas sobre el acceso. Pruebe el comportamiento documentado de la aplicación para las sesiones activas del navegador, las credenciales de API, los tokens de acceso personal, las cuentas conectadas y otras vías de acceso que utilice su equipo. No deduzca que desactivar a un usuario revoca automáticamente todas sus credenciales o sesiones.
Distinga el estado de la cuenta de los recursos relacionados. Una persona que se marcha puede ser propietaria de registros, tareas programadas, integraciones o contenido que otras personas aún necesiten. Defina si esos elementos se transfieren, se conservan, se eliminan o se revisan, y quién aprueba esa acción.
- Después de la desactivación, pruebe un inicio de sesión nuevo y compruebe cualquier sesión existente en un entorno de prueba controlado.
- Haga un inventario de los tokens, las credenciales de API y las cuentas conectadas; después, verifique el proceso de revocación documentado para cada elemento.
- Compruebe si la eliminación de una cuenta es reversible y si afecta al contenido o al historial de auditoría.
- Anote quién es responsable de los recursos de la persona que se marcha y qué proceso de aprobación se sigue para transferirlos o eliminarlos.
Gestione las excepciones sin crear cuentas fuera de control
La mayoría de los equipos tienen usuarios que no encajan en el flujo de trabajo habitual de los empleados: contratistas, colaboradores temporales, administradores, cuentas de servicio y cuentas de acceso de emergencia. Decida cómo se crea, revisa y elimina cada categoría antes de que se acumulen las excepciones.
En algunos entornos puede ser necesario usar cuentas locales, pero estas pueden crear un ciclo de vida independiente si no están cubiertas por el proceso de identidad habitual. Para cada excepción, defina una persona responsable, un propósito, el acceso permitido, una fecha de revisión y el motivo que activará su eliminación. En el caso del acceso de emergencia, documente cómo se protege la cuenta y cómo se revisa su uso, siguiendo directrices adecuadas para la aplicación y su organización.
- Enumere las categorías de cuentas e identifique cuáles gestiona la fuente de identidad principal.
- Asigne a cada cuenta que no corresponda a una persona una persona responsable identificada y un propósito documentado.
- Fije una fecha de revisión o caducidad para el acceso temporal y el de contratistas.
- Documente el acceso de emergencia y pruebe el procedimiento de recuperación aprobado.
- Compruebe que las excepciones estén incluidas en las revisiones de acceso y en los procedimientos de salida.
Pruebe los fallos y los cambios de identidad
Un ciclo de vida que solo funciona en condiciones ideales no es un proceso fiable. Prepare pruebas controladas para retrasos, interrupciones de conectividad y cambios de identidad. El resultado exacto depende de la integración y la aplicación, así que consulte la documentación oficial para determinar qué debería ocurrir y compárelo con lo que observe.
Preste especial atención a la correspondencia de identidades. Según el sistema, un usuario cuyo nombre haya cambiado, una dirección de correo electrónico modificada, una identidad duplicada o una cuenta recreada podrían vincularse con una identidad existente, rechazarse o tratarse como una persona nueva. No dé por sentado qué identificador es el que prevalece: confirme las reglas antes de aplicarlas a cuentas reales.
- Si su configuración permite una prueba segura, retrase o pause un proceso de sincronización y mida cómo se detecta y resuelve la interrupción.
- Compruebe cómo responde el sistema a la indisponibilidad del proveedor de identidad, según el comportamiento documentado para el inicio de sesión y la gestión de cuentas.
- Use una cuenta de prueba para examinar el cambio de nombre de un usuario y la modificación de su dirección de correo electrónico.
- Compruebe cómo se notifican los duplicados, una identidad eliminada y recreada, y un intento de aprovisionamiento fallido.
- Anote quién investiga los fallos y cómo confirma el equipo que el estado final es correcto.
Prepare una matriz de pruebas repetible
Convierta las preguntas anteriores en una prueba de aceptación breve y repetible. Microsoft Learn ofrece directrices para planificar una implementación de aprovisionamiento automático de usuarios (https://learn.microsoft.com/en-us/entra/identity/app-provisioning/plan-auto-user-provisioning); consulte también la documentación oficial de su aplicación y proveedor de identidad concretos para añadir pasos específicos del producto. La siguiente matriz es una guía de escenarios que puede adaptar, no un procedimiento validado para todas las aplicaciones ni una afirmación sobre las funciones que admite una aplicación determinada.
Ejecute las pruebas antes de adoptar la aplicación, después de cambios importantes en las correspondencias o integraciones y, cuando corresponda, como parte de las revisiones periódicas de acceso. Mantenga las identidades de prueba separadas de los usuarios de producción y registre el resultado esperado, el resultado observado, las pruebas que lo respaldan y la persona responsable del seguimiento.
- Crear: ¿Se puede añadir a la persona prevista mediante la vía documentada y puede un administrador ver el resultado?
- Activar: ¿Qué debe hacer el usuario para que funcione el acceso y qué ocurre con una invitación que no se acepta?
- Cambiar el acceso: ¿Las altas y bajas de roles o grupos producen los permisos previstos?
- Suspender o dar de baja: ¿Qué vías de inicio de sesión, sesiones y credenciales se ven afectadas y cuáles requieren una acción aparte?
- Reactivar: ¿Se restablece la cuenta existente o hace falta otro proceso? Confirme cómo se gestionan la correspondencia de identidades y el acceso conservado.
- Casos límite: ¿Qué ocurre ante retrasos, servicios no disponibles, usuarios con nombres modificados, duplicados y actualizaciones fallidas?
- Responsabilidades: ¿Quién se ocupa de las cuentas, las excepciones, los recursos y los fallos sin resolver?
Asigne responsabilidades y evalúe el modelo de alojamiento
Un proceso fiable asigna una persona responsable a cada paso. Los administradores de identidad pueden controlar las identidades de origen y las asignaciones de grupos, mientras que los administradores de la aplicación pueden gestionar los roles locales, el contenido y las integraciones. Deje por escrito dónde se cruzan las responsabilidades, cómo se aprueban las excepciones y cómo se escalan los cambios fallidos o retrasados.
El alojamiento gestionado puede reducir el trabajo de infraestructura, pero por sí solo no determina cómo aprovisiona usuarios una aplicación ni cómo administra su organización los accesos. Airbip ofrece despliegues gestionados de aplicaciones del catálogo como cargas de trabajo de Docker en servidores en la nube de Airbip, con automatización del enrutamiento y TLS, comprobaciones de DNS, gestión del ciclo de vida de los servicios y copias de seguridad configurables. No confunda esas funciones de infraestructura con una integración de aprovisionamiento de usuarios. Confirme por separado el comportamiento de las cuentas específico de la aplicación y elija un modelo de despliegue que se ajuste a sus requisitos de identidad, seguridad y operación.
- Designe a una persona responsable de los cambios en la fuente de identidad, los permisos de la aplicación y las excepciones de cuentas.
- Documente quién revisa los accesos y quién debe resolver las discrepancias de aprovisionamiento.
- Defina cómo se gestionan los datos y las integraciones propiedad del usuario cuando alguien se marcha.
- Considere la documentación oficial vigente de la aplicación y del proveedor de identidad como referencia para el comportamiento admitido.
- Compare las opciones de despliegue gestionado y autogestionado según sus requisitos operativos; el alojamiento no elimina la responsabilidad de gobernar los accesos y los datos.
Preguntas frecuentes
¿Qué incluye el aprovisionamiento de usuarios?
Puede incluir la creación de cuentas, la actualización de atributos o accesos y la desactivación o eliminación de cuentas en aplicaciones y sistemas. Los pasos exactos dependen de la aplicación y del método de gestión de cuentas.
¿Una integración con un proveedor de identidad gestiona automáticamente todas las tareas del ciclo de vida de las cuentas?
No lo dé por sentado. Verifique en la documentación del proveedor de identidad y de la aplicación que se admite la creación de cuentas, las actualizaciones, los cambios de roles o grupos, la desactivación, las sesiones y las credenciales.
¿Qué debemos probar antes de adoptar una aplicación autoalojada?
Pruebe la creación y activación de cuentas, los cambios de permisos, la desactivación, la reactivación, los cambios de identidad, la gestión de fallos, las excepciones y la titularidad del contenido o las integraciones relacionadas con los usuarios. Registre los resultados esperados y observados; confirme en la documentación de la aplicación qué comportamientos admite y cuáles se aplican a su configuración.
¿El alojamiento gestionado se hace responsable del acceso de los usuarios?
No necesariamente. El alojamiento puede gestionar tareas de infraestructura, pero debe verificar qué funciones del ciclo de vida de las cuentas ofrece la aplicación y definir quién se encarga en su organización de gestionar las identidades, los permisos y los datos de los usuarios.
Fuentes y lecturas adicionales
- Plan an automatic user provisioning deployment for Microsoft Entra ID — Microsoft Learn
- What is User Provisioning & Deprovisioning? — OneLogin