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.
Cómo funciona
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.
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.
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.
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.
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.
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.