Solicitud de acceso: el catálogo solicitable y el flujo de aprobación

“Igual que Sara”

Daniel acaba de sumarse al proyecto de cierre trimestral de finanzas y necesita leer el data warehouse de reportes durante las próximas seis semanas. Su jefa le manda un correo corto a la mesa de servicio: por favor, denle a Daniel acceso a la carpeta de finanzas y al warehouse, igual que Sara. Alguien de la mesa lo toma, mira lo que tiene Sara, se lo copia a Daniel y cierra el ticket. Al mediodía Daniel ya puede trabajar.

Funcionó, en el sentido estrecho de que Daniel recibió acceso. Ahora piensa en lo que nadie preguntó. Sara lleva cuatro años en finanzas, e “igual que Sara” incluye todo lo que fue acumulando, como la posibilidad de editar proveedores que le quedó de un proyecto de hace dos años. Nadie decidió que Daniel debía tener eso; vino de regalo. Nadie que entendiera el warehouse o los datos maestros de proveedores aprobó nada; la persona de la mesa ejecutó una instrucción. El proyecto termina en seis semanas, pero el acceso no tiene fecha de fin, así que se queda. Y nadie comprobó si Daniel, que en su trabajo habitual ya puede aprobar facturas, ahora puede crear un proveedor y también pagarle.

El primer módulo de este dominio construyó la base sobre la que se apoya IGA: un registro de identidad autoritativo, un ciclo de altas, traslados y bajas gobernado, un catálogo de entitlements curado con owners y niveles de riesgo, y las personas que responden de todo ello. JML cubre el acceso que la gente recibe por quién es, el birthright del primer día, el cambio que dispara un traslado. Este artículo cubre lo que queda: el acceso que la gente necesita por lo que está haciendo ahora mismo, y que ningún evento de RR. HH. puede prever. En la mayoría de las organizaciones ese resto es más grande de lo que nadie espera, y ahí es donde vive el correo de Daniel.

Lo que un ticket no puede decirte

Un ticket responde una pregunta: ¿alguien lo pidió? Rara vez responde las que harán más adelante un auditor, un revisor o quien investigue un incidente. ¿Qué se otorgó exactamente, si “igual que Sara” no es un entitlement sino la instrucción de copiar lo que Sara tenga, incluido lo que no debería tener? ¿Quién decidió que era apropiado, si quien ejecutó el ticket estaba cumpliendo un pedido y no aprobándolo? ¿Por cuánto tiempo, si un ticket no sabe lo que es una fecha de fin? ¿Y creó un conflicto, si la cola no tiene idea de lo que Daniel ya tiene?

Una solicitud de acceso gobernada responde todo eso. Es la misma necesidad humana, alguien requiere un acceso que no tiene, expresada como una transacción estructurada contra el catálogo de entitlements, enrutada por aprobaciones según el riesgo, verificada contra la política antes de otorgar nada y registrada de forma que sea evidencia desde el principio en lugar de algo que reconstruir después.

No es burocracia porque sí. Un proceso de solicitud bien diseñado suele ser más rápido que la cola que reemplaza, porque el enrutamiento, las verificaciones y la ejecución que alguien de la mesa de servicio hacía a mano pasan a ser automáticos para la mayoría de las solicitudes de bajo riesgo. El gobierno sale de la estructura, no de sumar pasos.

Qué contiene una solicitud

Toda solicitud gobernada, en cualquier plataforma, lleva cinco datos, y cada uno existe porque algo posterior depende de él.

Nombra a un beneficiario, la identidad que tendrá el acceso, que no tiene por qué ser quien lo pide. Nombra un entitlement del catálogo, nunca texto libre. Lleva una justificación, un motivo que un revisor pueda juzgar de verdad. Tiene una duración, un inicio y, en la mayoría de los accesos, un fin. Y registra al solicitante, quién la envió: el beneficiario, su jefatura o una persona delegada.

Separar al beneficiario del solicitante importa más de lo que parece. Que una jefatura pida acceso para alguien nuevo de su equipo es rutina. Que alguien pida acceso elevado para sí mismo a través de la identidad de otra persona es una señal de alarma. Mantener los dos campos permite que un auditor distinga una cosa de la otra, y que una política diga que nadie puede aprobar una solicitud en la que también es el beneficiario.

Que el entitlement sea una elección del catálogo y no texto libre es el cambio que hace posible todo lo demás. Es como el flujo sabe quién es el owner del entitlement (para enrutar la aprobación), su nivel de riesgo (para decidir cuántas aprobaciones necesita) y sus etiquetas de separación de funciones (para buscar conflictos), todo lo cual estableció el artículo del catálogo. Un sistema de solicitudes sin un catálogo debajo es una cola de tickets con formularios más bonitos.

La justificación es el campo que más se desperdicia. Un cuadro de texto obligatorio que acepta “necesito acceso” enseña a todo el mundo a escribir “necesito acceso”. Los mejores diseños hacen una pregunta concreta, como para qué proyecto o ticket es, y algunos vinculan la justificación a un elemento de trabajo de otro sistema, para que el motivo del acceso sea algo comprobable y no una frase que nadie verifica. La solicitud de Daniel llevaría la referencia del proyecto de cierre y heredaría su fecha de fin.

Qué va en el catálogo solicitable

No todo entitlement del catálogo debería poder solicitarse. El catálogo del módulo anterior es un inventario de todo lo gobernado; el catálogo solicitable es la parte que alguien puede pedir por autoservicio. Trazar esa línea es la principal decisión de diseño de un programa de solicitud de acceso, y divide el catálogo en tres.

flowchart TD
  accTitle: Tres canales por los que los entitlements llegan a las personas
  accDescr: El catálogo de entitlements gobernado se divide en tres canales. El acceso que necesita toda una población se asigna solo mediante reglas de birthright y de rol alimentadas por datos de RR. HH. El acceso que algunas personas necesitan caso por caso se publica en el catálogo solicitable y se otorga con una solicitud aprobada. El acceso que nadie debería tener de forma permanente, como la administración de producción, solo se otorga mediante una elevación temporal o justo a tiempo que vence sola.
  CAT[Catálogo de entitlements<br/>gobernado] --> Q1{¿Lo necesita toda<br/>una población?}
  Q1 -->|Sí| BR[Birthright o asignación por rol<br/>automática, con datos de RR. HH.]
  Q1 -->|No| Q2{¿Alguien debería<br/>tenerlo de forma permanente?}
  Q2 -->|Sí, caso por caso| REQ[Catálogo solicitable<br/>solicitud aprobada]
  Q2 -->|No| JIT[Elevación temporal o JIT<br/>vence sola]

El acceso que necesita toda una población queda fuera. Si todos los auxiliares de cuentas por pagar necesitan los mismos cuatro entitlements, obligar a cada persona nueva a pedirlos uno por uno hace perder tiempo a todos e invita a la inconsistencia: una jefatura aprueba los cuatro, otra se olvida del tercero. Ese acceso le corresponde al proceso de JML y a los roles y políticas que se cubren más adelante en este módulo.

El acceso caso por caso es para lo que existe el catálogo solicitable: entitlements que algunas personas necesitan de verdad, donde un owner con nombre puede juzgar cada pedido. Lectura sobre los datos de un proyecto, edición en un pipeline concreto del CRM, pertenencia al espacio de trabajo de un equipo transversal. Las seis semanas de Daniel en el warehouse son el caso de manual.

El acceso que nadie debería tener de forma permanente, la administración de producción, las cuentas break-glass, la posibilidad de exportar toda una base de clientes, no debería poder solicitarse como acceso permanente. Le corresponde un modelo temporal: una solicitud que otorga acceso por horas, no indefinidamente, y lo retira sola. Aquí es donde la solicitud de acceso empieza a solaparse con la gestión de accesos privilegiados, que tiene su propio dominio; el lado de IGA de esa frontera es asegurarse de que el catálogo marque con claridad estos entitlements para que nadie pueda pedirlos como acceso ordinario y permanente.

Ayudar a la gente a elegir bien

Un catálogo solicitable falla en silencio cuando la gente no sabe qué entrada necesita. Frente a ERP.PurchaseOrderApproval.Under10K, ERP.PurchaseOrderApproval.Over10K y ERP.VendorMaster.Edit, alguien que solo necesita “trabajar con órdenes de compra” suele elegir la que suena más importante, la que le mencionó un compañero o las tres. Quien aprueba, al ver tres entitlements, aprueba los tres para no tener otra ronda de correos.

La solución está en la presentación, no en el gobierno. Los nombres estructurados del catálogo sirven a revisores y auditores; quienes solicitan necesitan un nombre en lenguaje claro y una frase sobre quién suele necesitarlo, entitlements agrupados por lo que la gente intenta hacer (“Finanzas: compras”) y no por sistema, una búsqueda que entienda las palabras que la gente escribe de verdad (“aprobación de OC”, “compras”, “SAP”) y la ruta de aprobación y la duración por defecto a la vista. Decirle de entrada a quien pide que un entitlement necesita la aprobación del owner y vence en 90 días ajusta las expectativas y desalienta en silencio los pedidos casuales.

Muchas plataformas ofrecen un botón de “solicitar el mismo acceso que esta persona”, y es popular por la misma razón que “igual que Sara”: es rápido. También es peligroso por la misma razón. Si lo ofreces, muéstrale a quien pide la lista de entitlements que sumaría, haz que quite todo lo que no pueda justificar uno por uno y pasa cada entitlement que quede por las mismas aprobaciones y verificaciones que una solicitud normal.

Aprobaciones a la medida del riesgo

La aprobación es donde más a menudo fallan los procesos de solicitud, en una de dos direcciones opuestas. Con muy poca, el proceso es autoservicio con un registro de auditoría. Con demasiada, cada solicitud pasa días en una cadena de aprobadores en la que cada uno supone que el control de verdad es otro, así que nadie mira. Los niveles de riesgo del catálogo son lo que permite evitar los dos extremos.

Dos aprobadores no son el doble de control que uno. Solo sirven si cada uno revisa algo distinto. La jefatura está en condiciones de confirmar la necesidad de negocio: ¿Daniel está de verdad en el proyecto de cierre? El owner del entitlement está en condiciones de confirmar que es el acceso adecuado para esa necesidad: para el proyecto, ¿alcanza con leer el warehouse o hace falta más? Un segundo aprobador para el acceso privilegiado aporta independencia, alguien fuera de la línea de reporte de quien pide y sin interés en que el trabajo salga rápido. Si la jefatura y el owner revisan lo mismo, uno sobra. Si ninguno sabe qué tiene que revisar, sobran los dos.

sequenceDiagram
  accTitle: La vida de una solicitud de acceso enrutada según el riesgo
  accDescr: Alguien envía una solicitud de un entitlement del catálogo. La plataforma de IGA comprueba primero la elegibilidad por población y la separación de funciones. Si pasan, la solicitud va a la jefatura del beneficiario para confirmar la necesidad de negocio y después, en los entitlements elevados o privilegiados, al owner del entitlement para confirmar que el acceso encaja con esa necesidad. Una vez aprobada, la plataforma aprovisiona el acceso en el sistema destino con fecha de fin, y una reconciliación posterior confirma que el acceso existe tal como se otorgó.
  participant R as Solicitante
  participant IGA as Plataforma de IGA
  participant M as Jefatura
  participant O as Owner del entitlement
  participant T as Sistema destino
  R->>IGA: Entitlement, justificación, fecha de fin
  IGA->>IGA: Verificaciones (elegibilidad, SoD)
  IGA->>M: ¿Hay necesidad de negocio?
  M-->>IGA: Aprobado
  IGA->>O: ¿Es el acceso adecuado? (elevado/privilegiado)
  O-->>IGA: Aprobado
  IGA->>T: Aprovisionar con fecha de fin
  T-->>IGA: La reconciliación confirma que existe
  IGA-->>R: Otorgado hasta la fecha de fin

Cuando un aprobador no está

Toda cadena de aprobación termina encontrándose con un aprobador que no está, y cómo lo maneja el proceso decide si se degrada bien o pierde en silencio sus controles.

La delegación permite que un aprobador ceda su autoridad a otra persona durante un tiempo definido, por ejemplo una jefa de licencia por maternidad que delega en un par. Debe ser explícita, tener fecha de fin y quedar registrada, y la persona delegada nunca debería aprobar una solicitud en la que es la beneficiaria. Las cadenas de delegación, en las que A delega en B que delega en C, conviene bloquearlas directamente, porque vuelven casi imposible reconstruir quién tenía la autoridad.

El escalamiento resuelve el caso del aprobador que simplemente no responde. Un valor por defecto razonable es un recordatorio después de un día hábil, escalar a su propia jefatura después de tres y rechazar, no aprobar, de forma automática pasado un máximo fijado. La aprobación automática cuando vence el plazo es uno de los fallos ocultos más comunes de los programas de solicitud: convierte “nadie lo miró” en “aprobado”, que es justo al revés de lo que debe hacer un control.

La autoaprobación debería ser imposible por diseño. El caso evidente, una jefatura que aprueba su propia solicitud, es fácil de bloquear. El más sutil es una solicitud en la que el beneficiario resulta ser el owner del entitlement. La regla que vale la pena aplicar es simple: nadie aprueba acceso para sí mismo, en ningún papel, y la plataforma pasa al siguiente aprobador sola cuando eso ocurre.

Verificaciones que corren antes de que nadie apruebe

Lo más valioso que hace un proceso de solicitud suele ser invisible para quienes lo usan: las verificaciones que corren antes de pedirle a ninguna persona que apruebe nada. Cada una existe porque encontrar el mismo problema con el acceso ya otorgado es más lento, más caro y a veces demasiado tarde.

La más importante es la de separación de funciones. La plataforma compara lo que tendría el beneficiario después de la aprobación con las reglas de conflicto de la organización. En el caso de Daniel, si “igual que Sara” hubiera pasado por una solicitud gobernada, la plataforma habría visto que él ya aprueba facturas y estaba a punto de recibir permisos de edición de proveedores, una combinación que permite a una sola persona crear un proveedor ficticio y pagarle. Una verificación al momento de solicitar lo detecta antes de que el acceso exista y, o bien bloquea la solicitud, o bien la envía a un aprobador de riesgo que solo puede otorgarla con un control compensatorio documentado. La alternativa, encontrarlo en la siguiente revisión, significa que la ventana para el fraude estuvo abierta todo ese tiempo. La separación de funciones tiene su propio módulo más adelante en este dominio; aquí importa en qué punto del proceso vive la verificación.

La elegibilidad por población es la segunda. El artículo del catálogo recomendaba registrar qué poblaciones pueden tener cada entitlement, y aquí es donde rinde. Un contratista ni siquiera ve entitlements privilegiados en su catálogo, y una solicitud de un entitlement solo para personas a nombre de una cuenta de servicio falla de inmediato, en lugar de llegar a un aprobador que quizá no se dé cuenta.

La redundancia es la tercera. Si el beneficiario ya tiene el entitlement, directamente o a través de un rol, la solicitud sobra, y detectarlo evita asignaciones duplicadas que después confunden a los revisores y dejan otorgamientos sueltos cuando se quita el rol. Algunos programas suman también límites, como un tope de entitlements elevados por identidad o de solicitudes pendientes a la vez. No son universales, pero una persona que de repente pide una docena de entitlements elevados en una tarde merece una mirada humana aunque cada pedido por separado esté justificado.

Fechas de fin: que “hasta nuevo aviso” sea la excepción

La decisión de diseño más útil en una solicitud de acceso es darle fecha de fin a casi todo el acceso. El acceso otorgado sin plazo es la materia prima de la acumulación de privilegios: el proyecto termina, la necesidad desaparece y el entitlement se queda, porque quitarlo exige que alguien recuerde que existe, y recordar no es trabajo de nadie.

Una fecha de fin invierte el valor por defecto. En lugar de depender de que alguien note y quite el acceso que ya no hace falta, el acceso se quita solo salvo que alguien lo renueve. La renovación se convierte en una revisión liviana y dirigida: unos días antes del vencimiento se le pregunta al beneficiario o a su jefatura si la necesidad sigue, y el acceso se renueva con una justificación nueva o vence según lo previsto.

Tres tipos de duración cubren casi todos los casos. El acceso de larga duración con renovación sirve para el acceso estándar ligado a una responsabilidad continua, normalmente de seis a doce meses antes de la pregunta de renovación. El acceso ligado a un proyecto termina cuando termina el proyecto, algo fácil de acertar si la solicitud se vincula a un proyecto o ticket con su propia fecha de fin; el acceso de Daniel al warehouse termina con el cierre. Y el acceso justo a tiempo otorga acceso elevado o privilegiado durante minutos u horas para una tarea concreta y después lo quita solo. Hoy es la forma normal de dar acceso a producción y de administración, y cambia la pregunta de “¿quién tiene derechos de administración permanentes?” a “¿quién usó derechos de administración, cuándo y por qué?”, mucho más fácil de responder y de auditar.

Las fechas de fin cambian también lo que tiene que hacer una campaña de revisión. Si casi todo el acceso elevado ya vence según lo previsto, la siguiente revisión mira un conjunto más chico y deliberado de otorgamientos permanentes en lugar de limpiar todo lo que se acumuló desde la anterior. Los dos controles se refuerzan: las fechas de fin evitan la acumulación y las revisiones atrapan lo que las fechas de fin no cubrieron.

De aprobado a otorgado de verdad

Una solicitud aprobada es una decisión, no un acceso. La ejecución convierte la decisión en un cambio real en un sistema destino, y tiene dos formas con propiedades muy distintas.

La ejecución automática pasa por un conector, SCIM, una API REST, LDAP, un script de base de datos, que aprovisiona el entitlement e informa del éxito o del fallo a la plataforma de IGA. El registro de la solicitud y el estado aprovisionado quedan vinculados, y el retiro en la fecha de fin ocurre por el mismo conector.

La ejecución manual envía la solicitud aprobada a una persona, a menudo el administrador del sistema, como tarea. Es inevitable en los sistemas viejos sin API, y es donde más pierden los programas de solicitud: la tarea se cierra como hecha tanto si el acceso se otorgó tal como se aprobó, como si se otorgó con algo extra “ya que estaba”, como si nunca se otorgó.

En los dos casos, lo que vuelve confiable la ejecución es la reconciliación, presentada en el artículo de JML: leer con regularidad el estado real de cada sistema destino y compararlo con lo que la plataforma cree que debería haber. En las solicitudes, la reconciliación responde dos preguntas que el estado de una tarea nunca puede responder. ¿Se otorgó de verdad el acceso aprobado? Y, más importante, ¿hay acceso en el sistema que ninguna solicitud aprobada explica? La segunda es como un programa encuentra el acceso otorgado directamente en una consola de administración, saltándose por completo las solicitudes. El artículo de aprovisionamiento, más adelante en este módulo, profundiza en las dos.

Ayuda registrar tres estados por separado: aprobado, es decir, una persona decidió; aprovisionado, es decir, un conector o un administrador dice haber hecho el cambio; y confirmado, es decir, la reconciliación leyó el sistema y encontró el acceso ahí. Los reportes que juntan los tres en “completado” esconden justo los fallos que buscará un auditor.

Ejemplo trabajado: administración de producción en cuatro pasos

Un procesador de pagos en línea mediano corre su API de pagos en una plataforma cloud. Ocho ingenieros han tenido acceso de administrador permanente a producción “por si hay incidentes”. El equipo de seguridad quiere reemplazarlo por acceso solicitado y temporal, y el programa de IGA diseña el flujo en cuatro pasos.

Primero, se quita el acceso permanente y se define un único entitlement. El catálogo recibe Cloud.Production.Admin.JIT, de nivel privilegiado, con el líder de ingeniería de plataforma como owner y solo para empleados. Se retiran las ocho asignaciones permanentes. Desde ese momento nadie tiene administración de producción por defecto.

Segundo, la solicitud tiene que llevar evidencia. Pedir el entitlement exige un número de ticket de incidente o de cambio, comprobado contra el sistema de tickets, y una duración máxima de cuatro horas. El formulario le indica al ingeniero que el ticket debe estar abierto y asignado a él.

Tercero, el enrutamiento sigue a la situación y no a la costumbre. En un cambio planificado, la solicitud va al líder de ingeniería de plataforma y después a un segundo aprobador de seguridad: dos aprobadores que revisan cosas distintas. Durante un incidente en curso, esperar a dos aprobadores no es realista, así que el flujo cambia de forma. El ingeniero de guardia recibe el acceso de inmediato con la aprobación de quien coordina el incidente, y seguridad revisa la sesión después, en un día hábil como máximo. El control no es más débil; pasa de antes a después, con un plazo firme.

Cuarto, el acceso vence, se registra y se revisa. Se quita solo al terminar la ventana, cada sesión queda grabada y un reporte semanal lista cada elevación con su ticket, sus aprobadores y su duración. Cualquier elevación sin un ticket cerrado que le corresponda se investiga.

Después de un trimestre, la administración permanente de producción pasó de ocho personas a ninguna, la mediana de espera para obtener acceso en un cambio planificado es de menos de diez minutos y la pregunta “¿quién pudo cambiar producción el martes pasado?” tiene una respuesta precisa en lugar de “cualquiera de ocho ingenieros”.

Un segundo ejemplo: un contratista y el CRM

Un caso más corto muestra la misma maquinaria con riesgo estándar. Un consultor de ventas externo, dado de alta por el sistema de proveedores como persona que no es empleada, necesita trabajar oportunidades en el CRM durante un contrato de tres meses.

Su catálogo solicitable, filtrado por población, muestra solo lo que pueden tener los contratistas: ver datos del pipeline y editar sus propias oportunidades, pero no exportar datos de contactos, que el catálogo marca como solo para empleados. La persona que gestiona el contrato envía la solicitud en nombre del consultor, la justificación remite al documento de alcance del contrato y la fecha de fin se completa con la del contrato en el sistema de proveedores. En este nivel basta con una aprobación de la owner del CRM.

Tres meses después el contrato termina y el acceso vence solo, el mismo día en que el sistema de proveedores cierra el contrato. Una semana antes, la persona responsable recibe un recordatorio preguntando si se va a prorrogar, para que una renovación tardía no deje al consultor sin acceso a mitad de una negociación. Nadie tuvo que acordarse de quitar nada, y cuando corre la siguiente revisión no queda nada que limpiar.

Cómo fallan los programas de solicitud

La mayoría de los programas de solicitud no fallan con ruido. Derivan hacia patrones que en un tablero parecen gobierno y no lo son.

El aprobador sello de goma aprueba cuarenta solicitudes en cuatro minutos. Técnicamente no se saltó nada y de verdad no se revisó nada. Las causas suelen ser estructurales, demasiadas solicitudes de bajo riesgo enviadas a personas, aprobadores que no saben qué revisan, ningún contexto en la pantalla de aprobación, y las soluciones también: automatizar el nivel estándar, decirle a cada aprobador cuál es su revisión y mostrarle lo que el beneficiario ya tiene.

El catálogo ilegible devuelve a la gente a los tickets, al “igual que Sara” o a pedir todo lo que suene razonable. El volumen de solicitudes parece sano mientras el catálogo se esquiva en la práctica.

El permanente por defecto tiene un campo de fecha de fin que viene en “nunca”, así que casi nadie la pone. Hazlo obligatorio por encima del nivel estándar y complétalo con un valor sensato.

El plazo vencido que aprueba, mencionado antes, es lo bastante común como para repetirlo: cualquier flujo que aprueba una solicitud cuando nadie responde ha convertido el silencio en consentimiento.

Y la puerta lateral: los administradores siguen otorgando acceso directamente en las consolas “porque es más rápido”, y el proceso de solicitud solo gobierna lo que pasa por él. La reconciliación contra las solicitudes aprobadas es la única forma confiable de encontrar la puerta lateral, y la respuesta correcta suele ser una conversación sobre por qué la puerta principal es lenta, no solo un recordatorio de la política. Si el camino gobernado tarda tres días y la puerta lateral tres minutos, la gente usará la puerta lateral. Un proceso que automatiza el nivel estándar y resuelve las solicitudes elevadas en un día hábil quita el motivo principal para rodearlo.

Medir si funciona

Los procesos de solicitud producen muchos datos. Las medidas útiles son las que muestran si el proceso es un control de verdad.

El tiempo de las solicitudes, separado por nivel de riesgo, muestra cuánto espera la gente; si las solicitudes estándar tardan días, la puerta lateral está por abrirse. La proporción de solicitudes aprobadas sin ningún cambio, y la tasa de rechazo por aprobador, muestran si los aprobadores dicen que no alguna vez; un aprobador que no rechazó nada en un año no está revisando, y tasas de aprobación cercanas al 100% en los niveles elevados sugieren un sello de goma. El número de solicitudes que llegan a su fecha de fin sin renovarse muestra si las fechas de fin quitan acceso de verdad; cero vencimientos significa que nadie las pone. La cantidad de acceso que la reconciliación encuentra sin ninguna solicitud detrás es el tamaño de la puerta lateral. Y el balance entre verificaciones de conflicto que bloquearon una solicitud y las que se pasaron por alto muestra si la verificación es un control o una sugerencia.

Igual que con las medidas del catálogo, la tendencia importa más que cualquier número suelto. Tiempos de solicitud que bajan con una tasa de rechazo estable y distinta de cero describen un proceso en el que la gente confía y que todavía dice que no cuando corresponde. Tiempos que bajan con una tasa de rechazo que también baja describen un proceso que se está convirtiendo en un trámite.

Cómo se relaciona con los estándares

La solicitud de acceso es uno de los controles de IGA que los estándares nombran de forma más directa:

• NIST SP 800-53 Rev. 5, control AC-2 (Account Management), exige que el acceso lo autoricen aprobadores designados con un uso y una duración previstos, y AC-6 (Least Privilege) explica por qué el acceso solicitado debe ser mínimo y temporal.
• Criterios de SOC 2 (Trust Services Criteria), CC6.2 y CC6.3, esperan que el acceso se autorice antes de otorgarse y se cambie o retire según los roles y la necesidad, algo que los auditores prueban muestreando registros de solicitudes.
• PCI DSS v4.0, Requisito 7, exige que el acceso a los datos de titulares de tarjeta lo apruebe personal autorizado y se limite al mínimo privilegio, con la aprobación documentada.
• ISO/IEC 27001:2022, control del Anexo A 5.18 (Derechos de acceso), pide que los derechos de acceso se otorguen, revisen, cambien y retiren según un proceso definido; el flujo de solicitud es ese proceso hecho concreto.
• El IDPro Body of Knowledge trata el diseño de solicitudes de acceso y de flujos de aprobación como disciplina profesional.

Cerrando el ciclo

El primer artículo de este dominio describió IGA como un ciclo entre la administración y el gobierno. La solicitud de acceso es donde las dos mitades se encuentran en una sola transacción. Una decisión de gobierno, quién aprueba, con qué política, por cuánto tiempo, produce una acción administrativa, aprovisionar por un conector, y la reconciliación comprueba que la acción coincide con la decisión. Todo lo que construyó el primer módulo aparece aquí: el registro de identidad decide quién es el beneficiario, el catálogo define qué se puede pedir y quién es su owner, los niveles de riesgo fijan cuántas aprobaciones hacen falta y los roles del programa deciden quién responde de que el flujo funcione. Las seis semanas de Daniel en el warehouse, hechas así, habrían sido el acceso correcto, aprobado por las personas correctas y desaparecido el día en que terminó el cierre.

Resumen

• Una solicitud de acceso es una petición estructurada y gobernada de un entitlement del catálogo, con beneficiario, entitlement, justificación, duración y solicitante, no un ticket en texto libre ni un “igual que Sara”.
• El catálogo solicitable es solo la parte caso por caso del catálogo gobernado. El birthright le corresponde a JML y a los roles; el acceso privilegiado permanente no debería poder solicitarse.
• Las aprobaciones crecen con el riesgo, y cada aprobador debería revisar algo distinto: la jefatura la necesidad, el owner el encaje, un segundo aprobador la independencia. El silencio nunca aprueba.
• Las verificaciones de conflictos, elegibilidad y redundancia corren antes de que nadie apruebe, y una verificación fallida debe bloquear o enrutar, no solo avisar.
• Las fechas de fin son la mejor defensa contra la acumulación de privilegios; el acceso justo a tiempo es la norma para el trabajo privilegiado.
• Aprobado, aprovisionado y confirmado son estados distintos, y la reconciliación es lo que muestra que el acceso coincide con la decisión y deja ver la puerta lateral.

Tres preguntas para ponerte a prueba

1. Un flujo envía cada solicitud a la jefatura y al owner de la aplicación, sea cual sea el nivel de riesgo. Las solicitudes tardan cuatro días de media y los dos aprueban el 99% de las veces. ¿Qué cambiarías y por qué sumar un tercer aprobador podría empeorar las cosas?
2. Explica la diferencia entre una verificación de conflictos preventiva y una detectiva, y describe un caso de fraude concreto que solo la preventiva habría detenido.
3. La reconciliación encuentra 300 entitlements en un sistema destino sin ninguna solicitud aprobada detrás. Da tres explicaciones distintas para esa diferencia y qué harías con cada una.

Ejercicio práctico

Elige una aplicación que uses en el trabajo o en tus estudios, o el procesador de pagos del ejemplo, y diseña su modelo de solicitud de acceso en una sola página.

1. Enumera cinco entitlements y clasifica cada uno como birthright, solicitable o temporal, con una frase que lo justifique.
2. Para cada entitlement solicitable o temporal, fija el nivel de riesgo, la ruta de aprobación (quién aprueba y qué revisa cada uno) y la duración por defecto.
3. Escribe una regla de conflicto que una verificación preventiva debería aplicar entre dos de tus entitlements, y decide qué pasa cuando falla: ¿bloquear o enviar a quién?
4. Elige tres medidas de este artículo que reportarías cada mes y anota el valor que te haría sospechar que el proceso se convirtió en un sello de goma.