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.
¿Qué es diagrama del proceso de aprovisionamiento de usuarios (alta, cambio, baja)?
El aprovisionamiento de usuarios falla en silencio, y por eso suele arreglarse después de una auditoría y no antes. La mitad del alta se ve: quien se incorpora sin buzón se queja el primer día y alguien lo resuelve. Todo lo demás es invisible. Los accesos se copian de quien ocupaba antes la silla, así que una cuenta con permisos de más se convierte en la referencia del departamento. Los externos llegan sin ficha en RR. HH., sin fecha de fin y con un patrocinador que para entonces ya se ha marchado. La mitad del parque está detrás del inicio de sesión único y se aprovisiona sola, mientras la otra mitad (el programa de contabilidad, la herramienta que un equipo compró con una tarjeta, el portal del proveedor) es una cola manual que nadie mide. Y un cambio de rol suma sin restar nunca, porque en ningún sitio hay nada que informe de un acceso que simplemente ha dejado de ser necesario. Nada de esto provoca un incidente. Provoca una acumulación lenta que aflora años después como hallazgo de una revisión de accesos, como una prueba de control fallida o como la cuenta de un antiguo empleado que sigue autenticándose.
Este diagrama es la maquinaria de identidades y cuentas, no el formulario de solicitud ni la cadena de aprobación. Cuando alguien que ya está en su puesto pide un permiso más, con las aprobaciones y el ciclo de recertificación alrededor, eso es el proceso de solicitud de accesos en /es/templates/proceso-de-solicitud-de-accesos; la misma petición disparada por un alta o un cambio de rol de RR. HH. y acotada por un perfil de rol está en /es/templates/proceso-de-solicitud-de-accesos-de-empleados. El acceso a un conjunto de datos, donde decide un propietario de los datos según la clasificación y la finalidad y no según el puesto, está en /es/templates/proceso-de-solicitud-de-acceso-a-datos. La rama de baja es aquí deliberadamente corta y enseguida traspasa: el flujo completo de desaprovisionamiento, con cuentas compartidas y de servicio, desactivar frente a eliminar y captura de evidencias, está en /es/templates/proceso-de-retirada-de-accesos-de-usuario. El contrato, las verificaciones, el equipo y el primer día pertenecen a /es/templates/proceso-de-incorporacion-de-empleados. Lo que queda es todo lo que hay entre el evento y un conjunto de cuentas operativo, verificado y registrado (la identidad, la credencial, el paquete de permisos, el parque de sistemas de destino), más la única población que ninguna de esas páginas cubre: quien llega sin ninguna ficha en RR. HH. En términos de control, esto es la mitad de identidad del Anexo A de la ISO/IEC 27001:2022 (A.5.16, gestión de identidades, que gobierna la vida entera de una identidad, y A.5.17, información de autenticación, que gobierna la credencial emitida contra ella) y no A.5.15 ni A.5.18, que gobiernan a qué puede llegar después esa identidad.
Aquí se dibujan tres decisiones que la mayoría de los procedimientos de aprovisionamiento deja implícitas. «¿Empleado o personal externo?» va antes de que exista la identidad, porque un externo necesita un patrocinador con nombre y una fecha de fin que ningún flujo de RR. HH. va a suministrar, y una identidad creada sin ellos es la cuenta huérfana que una revisión de accesos encuentra dos años después. «¿Está dentro del paquete estándar?» parte el flujo en dos: todo lo que está en el paquete del rol se aprovisiona automáticamente sin nadie en medio, y solo los permisos privilegiados o fuera del paquete llegan a un propietario, que es lo que impide que la aprobación degenere en un sello aplicado a buzones de correo. Y «¿El acceso concedido coincide con lo pedido?» es una puerta y no una formalidad de cierre, porque lee lo que los sistemas de destino conceden de verdad y lo compara con lo que se pidió; los permisos que se aplicaron sin aprobación no los reporta jamás quien los ha recibido. La rama de cambio de rol añade una cuarta, «¿Permisos antiguos fuera del nuevo paquete?», y la recertificación una quinta, «¿Los permisos siguen ajustados al rol?»: las dos desembocan en el mismo paso de revocación, de modo que hay una sola salida para un permiso, sea como sea que se haya descubierto que sobra.
Qué cubre este diagrama de flujo
En esta plantilla
- Seis fases (Disparador, Identidad, Permisos, Aprovisionamiento, Verificación y Cambios y revisión) repartidas en cinco carriles: RR. HH. o patrocinador, Equipo de identidades, Responsable directo, Propietario del permiso y Seguridad.
- Una única entrada para cinco eventos. «¿Qué evento de identidad?» encamina un alta, un cambio de rol, una baja, una petición de emergencia y una recertificación programada por el mismo diagrama, de modo que la maquinaria se comparte en vez de reinventarse para cada caso.
- La fase de identidad completa: «¿Empleado o personal externo?» deriva a externos, personal de ETT y socios de servicio por «Registrar el patrocinador y la fecha de fin» (el único paso que les da un responsable con nombre y una fecha de término) antes de que las dos rutas se junten en «Crear la identidad en el directorio» y «Emitir credenciales y registrar el MFA».
- «¿Está dentro del paquete estándar?»: la rama estándar va directa a «Aprovisionar automáticamente el paquete estándar», sin ningún aprobador en medio, mientras los permisos privilegiados o fuera del paquete pasan por «¿El propietario del permiso aprueba?», cuya rama de rechazo termina en «Permiso denegado y cerrado».
- El aprovisionamiento en el orden en que lo recorre el diagrama: «Aprovisionar automáticamente el paquete estándar», después «Crear las cuentas en los sistemas de destino» tanto en el parque automatizado como en el manual, y después «¿El acceso concedido coincide con lo pedido?», cuya rama de discrepancia pasa por «Corregir el exceso o el defecto de permisos» y vuelve a comprobar en lugar de cerrar el ticket.
- La mitad de cambios: a un cambio de rol se le pregunta «¿Permisos antiguos fuera del nuevo paquete?» y lo que aparezca va a «Revocar los permisos sobrantes» antes de volver a «¿Está dentro del paquete estándar?»; una baja llega a «Traspasado al proceso de retirada de accesos»; y «¿Los permisos siguen ajustados al rol?» envía una respuesta desviada a ese mismo paso de revocación.
Cuándo usar esta plantilla
- Estás escribiendo el apartado de identidades y accesos del manual de operaciones de TI y necesitas una sola imagen de lo que pasa entre un evento de RR. HH. y un conjunto de cuentas que funciona.
- Vas a comprar o a configurar una herramienta de gobierno de identidades y quieres las bifurcaciones decididas (qué se aprovisiona solo, qué necesita un propietario, qué sigue siendo una cola manual) antes de que las decida por ti el flujo por defecto de un proveedor.
- Las revisiones de accesos siguen sacando permisos de puestos que la gente dejó hace años y necesitas el paso de retirada del cambio de rol dibujado con un responsable y un plazo detrás.
- Tu parque está lleno de personal externo (contratistas, personal de ETT, auditores, socios, cuentas de servicio) y ninguno de ellos viene del flujo de RR. HH. del que depende el resto del proceso.
- Un auditor, el cuestionario de seguridad de un cliente o un revisor de ISO 27001 te ha preguntado cómo se crean las identidades, cómo se conceden los permisos y cómo sabes que el acceso que existe es el que se aprobó.
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ó.
Dónde encaja este proceso
En la mayoría de las organizaciones, este proceso sigue a Diagrama de credencialización de proveedores sanitarios y da paso a Diagrama del proceso de retirada de accesos (desaprovisionamiento).
Es un paso de Gobernanza de accesos.
Paso 1: Diagrama del proceso de aprovisionamiento de usuarios (alta, cambio, baja) Estás aquí
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.
Paso 2: Diagrama de flujo del proceso de solicitud de accesos
Proceso de solicitud de accesos: petición por rol, aprobación del responsable y del propietario del sistema, segregación de funciones, aprovisionamiento y recertificación.
Paso 3: Diagrama del proceso de solicitud de accesos (alta y cambio de rol)
Paso 4: Diagrama del proceso de retirada de accesos (desaprovisionamiento)