Diagrama de flujo del proceso de solicitud de accesos

¿Qué es diagrama de flujo del proceso de solicitud de accesos?

Un proceso de solicitud de accesos es la forma de que alguien obtenga los permisos que necesita para hacer su trabajo sin que la organización pierda el control de quién puede hacer qué. Empieza con la petición de un rol definido, y no con una lista de la compra de permisos sueltos; pasa por la aprobación de quien responde por la persona y de quien responde por el sistema; y termina con un permiso anotado en un registro que lleva una fecha para su próxima revisión.

Los pasos que más se saltan son justo los que acaban convertidos en hallazgos de auditoría. Una comprobación de segregación de funciones impide que una sola persona acumule dos roles que nunca debieron convivir, como dar de alta a un proveedor y pagarle. Una revisión de seguridad aparte mantiene los accesos de administrador y a datos sensibles fuera del mismo circuito de aprobación que un informe de solo lectura. Y la recertificación es la única razón por la que el registro sigue siendo cierto: sin una revisión programada, los accesos se acumulan cada vez que alguien cambia de equipo y nunca se retira nada.

Esta plantilla traza el recorrido completo, de la solicitud a la recertificación, en cinco carriles: solicitante, responsable directo, propietario del sistema o datos, mesa de servicio TI y seguridad. Incluye los dos puntos de decisión sobre los que más se discute, qué ocurre cuando un rol solicitado entra en conflicto con los accesos que la persona ya tiene y qué peticiones necesitan revisión de seguridad antes del aprovisionamiento. Y cierra el círculo con una revisión programada que reconfirma el acceso o lo revoca. La estructura sigue el patrón de los controles del Anexo A de ISO/IEC 27001:2022 sobre control de acceso (A.5.15), gestión de identidades (A.5.16) y derechos de acceso (A.5.18).

Qué cubre este diagrama de flujo

En esta plantilla

• La petición en el carril del solicitante: «Crear la solicitud de acceso» y después «Elegir rol y justificar la necesidad», con un rol definido del catálogo, un motivo de negocio y una fecha de fin cuando el acceso es temporal.
• Dos puertas de aprobación antes de cualquier comprobación técnica: el responsable directo aprueba o rechaza, y después el propietario del sistema o datos revisa los permisos que el rol concede de verdad y aprueba o rechaza. Las dos ramas de rechazo terminan en un único nodo «Solicitud denegada y cerrada».
• Una decisión «¿Conflicto de segregación de funciones?» en el carril de la mesa de servicio TI, con una rama de conflicto que devuelve la petición al propietario para «Ajustar alcance o añadir control compensatorio» y vuelve a comprobarla en lugar de dejarla pasar.
• Una decisión «¿Acceso privilegiado o sensible?» que deriva las peticiones de administrador y de alto riesgo a una aprobación de seguridad aparte, mientras las ordinarias siguen directas al aprovisionamiento.
• Aprovisionamiento y evidencia: aprovisionar con mínimo privilegio, confirmar el acceso al solicitante, hacer que acepte las normas de uso y anotar el permiso en el registro de accesos.
• El bucle de recertificación de la última columna: seguridad inicia la revisión programada, el propietario decide en «¿Sigue siendo necesario el acceso?» y la rama No revoca el acceso en el sistema y actualiza el registro.

Cuándo usar esta plantilla

• Estás escribiendo o revisando un procedimiento de control de acceso para ISO 27001, SOC 2 o una auditoría interna, y necesitas una imagen acordada de quién aprueba qué y qué queda registrado.
• Vas a configurar un flujo de peticiones en una herramienta de servicio o de gobierno de identidades y quieres que la herramienta recoja un proceso ya acordado en lugar de inventarlo durante la implantación.
• Tienes que responder a un auditor o a un cuestionario de seguridad de un cliente que pregunta cómo se solicitan, aprueban, aprovisionan y revisan los accesos.
• Vas a formar a nuevos aprobadores, sobre todo responsables directos y propietarios de sistema, que necesitan saber qué están firmando en realidad y qué pasa si dejan la petición parada.
• Estás atacando la acumulación de accesos después de una revisión que sacó cuentas con permisos que nadie sabía explicar ni atribuir a una aprobación.

Cómo funciona

1. Pon el nombre de tus aprobadores reales

   Renombra los cinco carriles con los roles que tienes. En organizaciones pequeñas el propietario del sistema y el revisor de seguridad suelen ser la misma persona: funde esos carriles en vez de dibujar una aprobación que nunca ocurre. Mantén un carril por decisor, no por individuo, para que el diagrama sobreviva a un cambio de puesto.

2. Define qué cuenta como privilegiado o sensible

   La decisión «¿Acceso privilegiado o sensible?» solo funciona si los criterios están escritos al lado. Los disparadores típicos son cuentas de administrador y root, cuentas de servicio, acceso a datos personales o financieros y cualquier cosa que pueda cambiar producción. Pon el listón de forma que la rama de seguridad se active en una minoría de peticiones, o acabará siendo un trámite.

3. Escribe tus reglas de segregación de funciones

   Enumera las combinaciones que nadie puede acumular, por ejemplo dar de alta a un proveedor y aprobar su pago, o escribir código y desplegarlo a producción. Sin esa matriz, la comprobación de conflictos es puro teatro. Decide también quién firma un control compensatorio cuando el conflicto es inevitable, y déjalo anotado junto al permiso.

4. Decide dónde vive el registro de accesos

   Apunta el paso de registro al sistema que vas a mantener de verdad: una herramienta de gobierno de identidades, tu plataforma de gestión de servicios o una hoja de cálculo controlada. Asegúrate de que la rama de revocación actualiza el mismo registro; si no, poco a poco se convierte en una lista de accesos que se concedieron y no de accesos que existen.

5. Fija la frecuencia de recertificación y su responsable

   Sustituye la revisión programada genérica por tu propia frecuencia y tu disparador, por ejemplo cuentas privilegiadas cada trimestre y roles estándar una vez al año, más una revisión fuera de ciclo al cambiar de rol. Indica quién persigue a los revisores y qué pasa cuando vence un plazo, porque una revisión sin dueño es el paso que deja de ejecutarse sin que nadie se entere.

6. Haz aprobar el mapa y mantén una sola versión vigente

   Comparte el diagrama con los aprobadores que aparecen en él, recoge su firma y enlaza la versión aprobada desde tu política de control de acceso. Mantenerlo con control de versiones y con la aprobación registrada es lo que hace que el proceso que la gente sigue y el que enseñas a un auditor sean el mismo.

Preguntas frecuentes

¿Qué es un proceso de solicitud de accesos?

Es la ruta definida que sigue una petición de acceso a un sistema desde que alguien la pide hasta que se concede, se registra y más adelante se revisa. Un proceso completo tiene cuatro partes: una petición que nombra un rol definido y un motivo de negocio, la aprobación de alguien que responde por la persona y de alguien que responde por el sistema, el aprovisionamiento por parte de quien tiene los derechos administrativos, y un registro del permiso con su fecha de revisión. Pedir y aprovisionar son pasos deliberadamente separados y en manos distintas, para que nadie se conceda accesos a sí mismo.

¿Quién debe aprobar una solicitud de acceso?

Con dos aprobadores se cubre casi todo. El responsable directo confirma que la persona necesita ese acceso para su trabajo, que es una pregunta sobre el solicitante. El propietario del sistema o de los datos confirma qué concede realmente el rol y si esa persona debe tenerlo, que es una pregunta sobre el sistema. Una tercera aprobación de seguridad solo compensa para accesos privilegiados o sensibles, que es como lo enruta esta plantilla. Añadir más aprobadores rara vez mejora la decisión y siempre alarga la espera, que es lo que empuja a los atajos informales como compartir contraseñas.

¿Qué es una comprobación de segregación de funciones en la gestión de accesos?

Comprueba si el rol solicitado, sumado a los accesos que la persona ya tiene, le permitiría completar una operación sensible de principio a fin sin ningún paso independiente. Los ejemplos habituales son dar de alta a un proveedor y aprobar sus pagos, o escribir código y desplegarlo a producción. La comprobación necesita una lista acordada de combinaciones incompatibles contra la que contrastar. Cuando el conflicto no se puede evitar, por ejemplo en un equipo pequeño, la respuesta habitual es un control compensatorio documentado, como una revisión posterior por otra persona, anotado junto al permiso.

¿Con qué frecuencia hay que recertificar los accesos de usuario?

El riesgo debe marcar la frecuencia. Un patrón común es trimestral para cuentas privilegiadas y de administrador, anual para roles de negocio estándar y una revisión inmediata fuera de ciclo cada vez que alguien cambia de rol o de equipo. El control A.5.18 de ISO/IEC 27001:2022 exige revisar los derechos de acceso con regularidad, pero no fija un intervalo, así que la frecuencia es tuya y tienes que poder justificarla. Ten en cuenta que un diagrama documenta la intención, no demuestra el cumplimiento: la evidencia que pide un auditor son las aprobaciones y el registro que produce el proceso.