Diagrama del proceso de aprovisionamiento de usuarios (alta, cambio, baja)
Diagrama del proceso de aprovisionamiento de usuarios: evento de RR. HH., identidad en el directorio, credenciales y MFA, paquete de permisos del rol, aprobación del propietario, cuentas de destino y recertificación.
Cómo funciona
Renombra los carriles con tus propios roles
Sustituye RR. HH. o patrocinador, Equipo de identidades, Responsable directo, Propietario del permiso y Seguridad por los roles que de verdad tienes. Mantén a propósito RR. HH. y patrocinador en un mismo carril: son el mismo trabajo hecho para poblaciones distintas, y separarlos es la forma en que el personal externo acaba sin nadie que responda por él. El carril del propietario del permiso es el que la mayoría de las organizaciones descubre que no tiene cubierto. Si hoy no puedes poner nombre a un propietario para tus permisos privilegiados, ese hueco es un hallazgo y no un problema de redacción, y el carril debe quedarse en el diagrama, visiblemente vacío, hasta que se cierre.
Declara cuál es tu fuente de referencia, y qué no está en ella
El diagrama da por hecho que existe un flujo autorizado de altas, cambios de rol y bajas. Escribe qué sistema es, qué campos lleva —puesto, responsable, fecha de inicio, fecha de efecto de un cambio, último día— y en cuánto tiempo aparece en él una modificación. Después escribe quién no está. Los externos, los miembros del consejo, el personal de ETT, quienes hacen prácticas y las identidades de máquina normalmente no están, y cada uno de esos colectivos necesita su propio registro y su propio patrocinador antes de que el resto del proceso pueda funcionar.
Escribe los paquetes de permisos antes de publicar
«Derivar el paquete de permisos del rol» es un paso inerte mientras los paquetes no existan. Empieza por los diez puestos que más contratas y escribe lo que cada uno necesita de verdad el primer día. Donde tengas datos de inicio de sesión o de último uso, constrúyelo a partir de lo que quienes ocupan hoy el puesto usan realmente y no de lo que tienen concedido; la diferencia entre ambas cosas suele ser grande, y es la razón entera por la que merece la pena escribir el paquete. Que cada uno sea un suelo y no un techo, para que todo lo que quede fuera siga siendo lo bastante visible como para que valga la pena pedirlo.
Fija el listón de la aprobación del propietario
«¿Está dentro del paquete estándar?» solo funciona si los criterios están escritos al lado. Los disparadores habituales de la rama de aprobación son los derechos de administrador y de root, el acceso a producción, los sistemas de pagos o de nóminas, los datos personales y de salud, y cualquier cosa que pueda cambiar el acceso de otra persona. Contrasta esa lista con las concesiones del último trimestre antes de publicarla: un criterio que atrapa a la mayoría no es un criterio. Si todo acaba en el propietario del permiso, las aprobaciones llegan más deprisa de lo que nadie puede leerlas y el control se convierte en una cola por la que la gente aprende a pasar a golpe de clic.
Convierte la retirada del cambio de rol en una obligación con seguimiento
«Revocar los permisos sobrantes» es el paso que decide si los accesos se acumulan en tu organización. Dale el mismo ticket, el mismo responsable y el mismo plazo que la concesión, y cierra el evento de cambio de rol solo cuando estén hechas las dos mitades: un ticket que se cierra con la mitad de altas es el mecanismo por el que la retirada no ocurre nunca. El diagrama pone la comparación en el responsable directo y no en el equipo de identidades a propósito: el equipo puede producir la lista de diferencias, pero solo el responsable sabe si un permiso sobra de verdad o todavía hace falta para un traspaso.
Recórrelo con quienes lo ejecutan y después publica una versión
Resuelve antes de publicar las dos ramas que por defecto no tienen dueño. Decide quién puede invocar el acceso de emergencia fuera de horario y quién lee después el registro de la sesión, y decide quién actúa sobre una respuesta «Desviados» en la recertificación y en qué plazo, porque una revisión que produce una lista de la que nadie revoca es peor que no revisar. Después lleva el diagrama a alguien de la mesa de servicio, a un responsable que haya contratado hace poco y a quien llevó la última revisión de accesos, y corrígelo hasta que refleje lo que pasa de verdad. Publica la versión corregida, conserva legibles las anteriores y cítala desde tu política de control de accesos.
Preguntas frecuentes
¿Cuáles son los pasos de un proceso de aprovisionamiento de usuarios?
Toma un evento de alta, cambio de rol o baja del sistema de referencia; decide si la persona es empleada o personal externo, y da a los externos un patrocinador y una fecha de fin; crea o empareja una identidad en el directorio con un identificador que no se reutilice nunca; emite las credenciales y registra la autenticación multifactor contra esa identidad; deriva el paquete de permisos del puesto; aprovisiona automáticamente todo lo que está dentro del paquete y envía los permisos privilegiados o fuera del paquete al propietario del permiso para que los apruebe; crea las cuentas en los sistemas de destino, tanto en los automatizados como en la cola manual; verifica que lo que los sistemas conceden de verdad coincide con lo que se pidió; haz que el responsable directo lo confirme; y anota los permisos en la identidad. Después el proceso sigue funcionando: un cambio de rol recalcula el paquete y revoca lo que el rol anterior ya no justifica, una baja se desactiva y se traspasa a la retirada, y la recertificación comprueba cada cierto tiempo que los permisos y el puesto siguen de acuerdo.
¿Qué es un paquete de permisos por rol?
Es el conjunto de accesos que un puesto necesita su primer día, asociado al rol y no a la persona: correo y calendario, la intranet, los sistemas de negocio propios de esa función, las unidades compartidas de ese equipo. En inglés se le llama birthright access, el acceso que se tiene por el mero hecho de ocupar el puesto. Como se deriva del rol, puede concederse sin ningún aprobador en medio, y esa es justamente la idea: saca las concesiones rutinarias de la cola de aprobación para que las excepciones se lean bien. Dos reglas mantienen honestos los paquetes. Constrúyelos a partir de lo que el puesto exige, nunca exportando los accesos de quien lo ocupó antes, porque eso copia todos los extras acumulados junto con lo necesario. Y da a cada paquete un propietario con nombre y una fecha de revisión, porque un paquete sin dueño solo crece: cada petición que no se pudo rechazar se le añade, y en dos años concede mucho más de lo que necesita ningún puesto.
¿En qué se diferencia del proceso de solicitud de accesos?
Se encuentran a mitad de camino y son dueños de mitades distintas. El proceso de solicitud de accesos en /es/templates/proceso-de-solicitud-de-accesos empieza con una persona que ya está en su puesto y necesita un sistema más: crea una petición, la aprueban el responsable directo y el propietario del sistema, se aprovisiona y más adelante se recertifica. El proceso de solicitud de accesos de empleados en /es/templates/proceso-de-solicitud-de-accesos-de-empleados cubre esa misma petición cuando la dispara un alta o un cambio de rol de RR. HH. y la acota un perfil de rol. Los dos van de decidir. Esta página va de hacer: crear la identidad, emitir la credencial y registrar la autenticación multifactor, derivar el paquete, crear las cuentas en todos los sistemas de destino y volver a leer los permisos desde esos sistemas para comprobar que son los que se aprobaron. Si estás diseñando un formulario de petición o una cadena de aprobación, usa esas dos. Si estás construyendo o documentando la maquinaria de aprovisionamiento que hay detrás, incluidas las identidades del personal externo y la mitad de retirada de un cambio de rol, usa esta. Y si la pregunta es el acceso a un conjunto de datos y no a un sistema, mira /es/templates/proceso-de-solicitud-de-acceso-a-datos.
¿Cuánto del aprovisionamiento de usuarios se puede automatizar de verdad?
Más de lo que ha automatizado la mayoría de las organizaciones, y nunca todo. Los sistemas que están detrás del inicio de sesión único pueden funcionar sin ticket: la identidad del directorio se crea a partir de la ficha de RR. HH., se aplica el paquete del rol y la pertenencia a grupos va detrás. Lo que impide la cobertura total es el parque con el que nadie contaba: el sistema de nóminas sin API, el instrumento de laboratorio que mantiene su propia lista local de usuarios, la extranet del socio donde una cuenta se crea respondiendo a un correo. Esos necesitan una cola con responsable y tiempo objetivo, y necesitan estar listados, porque un sistema manual que no está en la lista se aprovisiona tarde en un alta y se olvida por completo en una baja. Mantén un inventario de qué sistemas están conectados y cuáles no, revísalo cada vez que se compre algo y trata el acortar la lista manual como el verdadero programa de trabajo. Automatizar la concesión sin automatizar la relectura es una trampa en sí misma: los conectores fallan en silencio, y por eso el paso de verificación lee los permisos del sistema de destino y no del ticket.
¿Cómo se aprovisiona a contratistas y a otro personal externo?
Igual que a la plantilla, salvo que nada aguas arriba te avisa de que existen. Los contratistas, el personal de ETT, los auditores, los ingenieros de un socio, quienes hacen prácticas y las identidades de máquina rara vez aparecen en el sistema de RR. HH., así que los dos atributos que hacen gestionable una identidad hay que capturarlos a propósito: un patrocinador interno con nombre que responda por ella y una fecha de fin tomada del contrato o del encargo en lugar de dejarla abierta. Haz que la caducidad sea automática: la cuenta se desactiva sola en esa fecha, y la renovación es un acto explícito del patrocinador con una fecha de término nueva. Reasigna el patrocinio cuando un patrocinador se marcha, porque una identidad patrocinada cuyo patrocinador ya no está es exactamente la cuenta que nadie revisa. El personal externo suele merecer además paquetes más estrechos y un intervalo de recertificación más corto, porque su trabajo es más acotado y su rotación más rápida. La mayoría de las cuentas huérfanas que saca una revisión de accesos pertenecen a alguien a quien la organización nunca empleó.