Una cuenta puede estar “activa” en un directorio y seguir teniendo permisos que ya no corresponden a la persona, sesiones que aún funcionan o grupos heredados cuyo propietario no sabe explicar. El problema no es sólo crear una identidad fuerte: es sostener una decisión de acceso mientras cambian la relación laboral, la función, el dispositivo, el recurso y el riesgo. Este capítulo modela ese problema como un ciclo de estados y evidencia.
En cc‑0047 se separaron workload identity, credencial, secreto, conexión y sesión. Aquí se conserva esa frontera, pero el principal conductor es humano o administrativo: una persona, un contratista y una cuenta de emergencia. Autenticación verifica control de un autenticador; autorización decide una operación sobre un recurso; un entitlement es la asignación concreta de ese permiso a un principal. Tener una cuenta autenticada no implica tener el entitlement, y tenerlo no prueba que la operación concreta sea apropiada en ese contexto.
El ciclo empieza antes de la cuenta
El modelo joiner–mover–leaver no es una secuencia de tickets, sino una cadena de autoridad. En la incorporación, una fuente de verdad —por ejemplo, el sistema de recursos humanos o un contrato validado— afirma una relación. Un propietario del recurso traduce esa relación a entitlements: qué puede hacer la persona, sobre qué recurso, en qué entorno y hasta cuándo. La función de identidad provisiona una cuenta y un autenticador; el receptor de negocio aplica autorización local.
La cuenta sólo debe habilitarse cuando existen sujeto, alcance, propietario y motivo. NIST SP 800‑53 AC‑2 sitúa la gestión de cuentas en un ciclo que incluye creación, habilitación, modificación, revisión, deshabilitación y eliminación. La norma no convierte un directorio en autoridad universal: cada organización debe definir qué cuenta existe, quién la posee y qué sistema aplica la decisión.
Vista adaptada. Toca el diagrama para ampliarlo.
El cambio de función es más difícil que el alta. Si Ana pasa de soporte a ingeniería, quitar un grupo no basta si conserva un entitlement directo, una pertenencia anidada o una sesión abierta. La transición segura tiene dos operaciones relacionadas: retirar lo que pertenecía a la función anterior y conceder lo nuevo bajo una policy explícita. Durante la ventana de cambio, una política puede bloquear la combinación de roles, exigir revisión o mantener sólo el mínimo común. “Mover” no significa acumular permisos para no interrumpir el trabajo.
El desprovisioning debe tratar varios objetos: cuenta, autenticadores, grupos, claves, grants de aplicaciones, sesiones, tokens y accesos en terceros. SP 800‑63‑4B exige conservar un registro de los autenticadores vinculados durante la vida de una identidad y distingue eventos como pérdida, compromiso, expiración y revocación. En una arquitectura concreta, deshabilitar el usuario puede impedir nuevos inicios de sesión, pero no demuestra que un token ya emitido, una sesión cacheada o una conexión persistente hayan terminado. Ésa es una síntesis de lifecycle, no una promesa de una herramienta.
Autoridad, correlación e identidad
En un sistema real no existe una única “identidad” que todos los componentes compartan con el mismo significado. Hay un identificador de persona en HR, un subject del proveedor de identidad, un identificador local de cuenta, uno o más identificadores de aplicación y, en ocasiones, una cuenta técnica que actúa en nombre de la persona. El gobierno debe conservar la correlación entre ellos sin tratarlos como intercambiables. Una coincidencia de nombre no es evidencia suficiente: los nombres se reutilizan, cambian y pueden variar entre dominios.
La autoridad también es contextual. HR puede afirmar que un contrato existe, pero no debería decidir qué tabla de producción puede modificar. El propietario del recurso puede definir un entitlement de lectura, pero no inventar una relación laboral. El proveedor de identidad prueba control de un autenticador, pero el PEP del servicio decide si ese principal puede ejecutar una operación. Dibujar estas fronteras evita un fallo frecuente: propagar un atributo administrativo hasta convertirlo en permiso sin una policy intermedia.
Para correlacionar de forma auditable, Asteria conserva un identificador estable del sujeto, la fuente que lo emitió, la fecha de vigencia y la relación con la cuenta local. Los cambios de identificador se registran como eventos, no como sobrescrituras silenciosas. Si dos cuentas parecen corresponder a la misma persona, el estado es review hasta resolver la ambigüedad. Si una cuenta carece de fuente vigente, se bloquea o se reduce según el riesgo; no se mantiene sólo porque “siempre estuvo ahí”.
Aprovisionar no es autorizar
System for Cross-domain Identity Management (SCIM) define un esquema y un protocolo para transportar recursos de identidad entre dominios (RFC 7643, RFC 7644). Un proveedor puede crear, modificar o desactivar un recurso remoto con SCIM. El receptor sigue siendo responsable de interpretar atributos, resolver grupos y aplicar su policy. department=finance no es por sí mismo permiso para exportar datos; es un dato que una policy puede usar, con fecha, fuente y controles de integridad.
La frontera importa porque los errores de sincronización son estados observables. Un evento de baja puede perderse; una actualización puede llegar tarde; un grupo puede mapearse con semántica distinta. El sistema debe registrar versión o identificador del evento, origen, hora, resultado y error. Si el receptor no confirma la retirada, la decisión correcta es review, degrade o bloqueo según riesgo, no “cumplido” porque el IdP aceptó la solicitud.
La autorización debe ejecutarse cerca del recurso. El Policy Decision Point (PDP) evalúa principal, acción, recurso, tenant, estado y contexto; el Policy Enforcement Point (PEP) aplica la decisión. La cuenta y el grupo son entradas, no sustitutos del PEP. AC‑3 formula esta distinción: el sistema aplica decisiones de control de acceso a operaciones sobre objetos protegidos. En particular, la autenticación resuelta por el proveedor de identidad no concede un permit para cada API.
Entitlement, rol y recurso
Un rol es una agrupación administrable de permisos; un entitlement es la asignación efectiva a un principal. Un recurso es el objeto protegido y una acción es la operación sobre él. db-reader puede ser un rol, pero el permiso que importa es principal=ana, action=select, resource=prod.billing, context=staging-change. Esta expansión obliga a preguntar quién asignó el rol, qué permisos contiene hoy, qué tenant cubre y cuándo expira.
La herencia complica la retirada. Un usuario puede recibir read por grupo directo, grupo anidado, pertenencia de proyecto y regla por atributo. El sistema de gobierno debe explicar la ruta que produce un permiso y poder revocar una ruta sin dejar otra idéntica oculta. El inventario no debe enumerar sólo grupos: debe resolver permisos efectivos o declarar que esa resolución no está disponible. Un resultado “sin uso” obtenido de un único sistema no basta si otros receptores no emiten telemetría.
La separación de funciones aparece en dos formas. La SoD estática prohíbe asignar simultáneamente combinaciones incompatibles, por ejemplo preparar y aprobar el mismo cambio. La SoD dinámica evalúa el contexto de una transacción: una persona podría tener ambos roles para tareas distintas, pero no activar ambas funciones dentro de la misma operación. La segunda exige un PEP capaz de observar operación, recurso y actor; esconder un grupo en la interfaz no aplica SoD.
Privilegio: limitar la operación, no sólo el usuario
Privileged Access Management (PAM) reúne controles para el acceso que puede cambiar configuración, datos, identidades o controles de seguridad. Incluye inventario de cuentas privilegiadas, aprobación, custodia de secretos o credenciales, broker de sesión, grabación y expiración. PAM no es sinónimo de MFA ni de un producto: una bóveda que entrega una contraseña estática sin controlar destino, duración o sesión sólo mueve el riesgo.
Dos principios ayudan a razonar. Just-in-time (JIT) concede un entitlement por una ventana limitada. Just-enough access (JEA) limita acciones y recursos a lo necesario. Ambos reducen exposición temporal o de alcance, pero no prueban que el comando ejecutado fuera correcto. AC‑6 expresa least privilege como limitar privilegios a los mínimos necesarios para tareas autorizadas; la aplicación concreta requiere roles, recursos y operaciones identificables.
Una solicitud PAM debería contener solicitante, recurso, acción, motivo, duración, entorno y referencia del cambio. Una policy puede exigir un aprobador distinto del solicitante; AC‑5 trata esa separación de funciones como una propiedad que debe definirse y hacerse cumplir. La aprobación es una entrada de decisión, no la autorización final: el PEP del recurso vuelve a comprobar estado, acción y contexto.
Vista adaptada. Toca el diagrama para ampliarlo.
En una sesión administrada, el broker entrega acceso al destino sin revelar necesariamente una contraseña reutilizable. Registra inicio, identidad, motivo, comandos o eventos permitidos según el contrato, y revoca al expirar. La grabación no hace lícita una operación; sirve como evidencia para responder qué ocurrió y contrastarlo con el cambio aprobado. Tampoco debe confundirse “sesión registrada” con “sesión segura”: el canal, el host intermediario, el almacenamiento de logs y la protección de la evidencia tienen sus propios supuestos.
El acceso de emergencia, o break-glass, es una excepción necesaria cuando el camino ordinario no está disponible. Debe tener activación explícita, alcance y duración, razón, registro independiente, notificación y revisión posterior. Una cuenta de emergencia permanente con contraseña conocida por varias personas no es una excepción gobernada. Si el flujo no puede registrar quién activó, qué recurso tocó y cuándo terminó, la organización no puede adjudicar el incidente; debe tratar la evidencia como incompleta.
Permanente, JIT y JEA
El acceso permanente puede ser apropiado para una función operativa estable, pero tiene una ventana de exposición igual a la duración del entitlement. JIT reduce esa duración; JEA reduce el conjunto de acciones. Son controles distintos: una sesión de cinco minutos con permisos de administrador global sigue siendo demasiado amplia, y una sesión con sólo restart-service puede ser segura en alcance pero no en duración si se mantiene abierta todo el día.
El diseño debe declarar qué ocurre si el reloj del broker y el del recurso difieren, si se pierde la conexión durante la aprobación o si la sesión supera su TTL. La opción segura depende del contrato: impedir nuevas acciones, terminar la sesión, marcarla para revisión o permitir sólo una operación idempotente. No se debe renovar silenciosamente un grant privilegiado porque el cliente siga conectado. La renovación debe volver a evaluar identidad, policy, recurso y motivo.
Session brokering y grabación
Un broker puede interponerse entre la identidad y el destino, emitir una credencial temporal, abrir un canal o ejecutar comandos permitidos. Cada arquitectura cambia qué observa el broker. Si sólo entrega un secreto al cliente, no puede afirmar qué comando se ejecutó. Si termina el canal y reenvía operaciones, puede registrar más, pero se convierte en una frontera crítica: su reloj, almacenamiento, disponibilidad y aislamiento afectan la decisión.
La grabación de sesión es evidencia con límites. Un vídeo puede mostrar una terminal, pero no prueba por sí solo qué identidad verificó el destino; un log de API puede omitir acciones hechas por una ruta secundaria. Los registros deben tener timestamps confiables, identificadores correlacionables, integridad y retención proporcional. También deben minimizar datos sensibles: no guardar contraseñas, tokens completos ni secretos introducidos en una consola. Si el canal de grabación falla, la policy debe decidir si bloquea, degrada o permite una excepción con revisión; no se debe etiquetar la sesión como “auditada” por defecto.
Gobierno: decidir con datos, no firmar una lista
Una recertificación pide al propietario confirmar que un entitlement sigue siendo necesario. Para que sea una decisión, el expediente debe enlazar sujeto, recurso, acción, entorno, propietario, última actividad relevante, fecha de expiración, fuente de autoridad y policy. Una firma sin esos elementos puede mostrar que alguien hizo clic, pero no que evaluó el acceso.
El gobierno también necesita detectar conflictos de separación de funciones: por ejemplo, la misma identidad que prepara y aprueba un cambio de producción. Un conflicto no implica automáticamente abuso ni vulnerabilidad; indica una condición que la policy debe resolver mediante bloqueo, segundo aprobador, reducción de alcance o excepción documentada. La salida y el motivo son parte de la evidencia.
Vista adaptada. Toca el diagrama para ampliarlo.
Los datos faltantes deben ser estados de primera clase. Si no se conoce el propietario, la fecha de expiración o el sistema receptor, el resultado no es “aprobado por defecto”. Es review o unknown hasta conseguir evidencia. La ausencia de uso tampoco demuestra que el acceso sea innecesario: puede indicar una tarea infrecuente o una telemetría incompleta. Del mismo modo, un log de login prueba un evento de autenticación, no el éxito de una acción administrativa.
Recertificación y métricas
Una campaña de revisión útil mide cobertura y calidad, no sólo porcentaje de clics. Asteria puede medir tiempo desde evento de baja hasta último receptor confirmado, proporción de entitlements con propietario vigente, grants privilegiados sin expiración, conflictos SoD abiertos, sesiones JIT que excedieron TTL, eventos SCIM fallidos y cuentas sin uso pero todavía autorizadas. Cada métrica necesita definición de población, fuente, fecha y sesgo conocido.
Una caída en “cuentas activas” podría significar una baja real o un conector caído. Un aumento de unknown puede reflejar mejor detección, no peor seguridad. El diagnóstico compara eventos de fuente, entrega al receptor, decisión del PEP y evidencia de sesión. La ausencia de un evento no equivale a ausencia de acción. Cuando la telemetría no permite adjudicar, se registra la incertidumbre y se asigna una acción de remediación.
Caso conductor: Asteria cambia y sale
Asteria asigna a Ana el rol de soporte con acceso de lectura a tickets. Al incorporarse, HR es la autoridad de relación laboral, el responsable de soporte es dueño del entitlement y el PEP de tickets aplica ticket:read. El directorio crea la cuenta y el proveedor de autenticación vincula un autenticador. Ningún paso por sí solo concede acceso a producción.
Meses después, Ana se mueve a ingeniería. El workflow marca la transición, retira el entitlement de soporte y solicita deploy:write sobre staging. Para producción, requiere JIT y un aprobador independiente. El detector de SoD encuentra que Ana también figura como aprobadora de cambios. La policy bloquea la combinación; un cambio de registro de dueño o una excepción acotada debe resolverlo. Mantener ambos grupos “por continuidad” sería acumular autoridad sin una decisión.
Ana solicita una sesión de 30 minutos para diagnosticar un despliegue. El PDP valida identidad, entitlement, recurso, motivo y ventana; la aprobación se registra. El broker entrega acceso temporal y el PEP del cluster vuelve a comprobar que la acción sea staging. Al expirar, el broker cierra su sesión, pero Asteria aún debe verificar tokens o conexiones que el receptor pueda mantener. La evidencia mínima contiene identificadores no secretos, policy version, timestamps y decisión, nunca la contraseña ni un token reutilizable.
Finalmente HR registra la salida. El sistema deshabilita la cuenta y revoca autenticadores según el contrato, retira entitlements y envía eventos a los receptores. Un control negativo intenta una nueva operación; otro busca una sesión previamente establecida. Si el segundo todavía funciona, la baja no está completa: hay que localizar el receptor y su mecanismo de cierre. Si no hay telemetría para decidir, el estado es unknown, no “sin acceso”.
Caso extremo a extremo: de incorporación a incidente
Supóngase que una consultora, Bea, entra para operar un sistema de pagos. HR crea la relación con fecha de fin; el propietario de pagos solicita sólo lectura en producción; seguridad exige MFA resistente a phishing; el IdP crea una cuenta correlacionada con un identificador de proveedor. El workflow rechaza la solicitud si no hay fecha de expiración o propietario. SCIM entrega el recurso a la consola, que devuelve una confirmación con versión.
Durante una migración, Bea necesita cambiar una configuración. Solicita JIT de 15 minutos, especifica recurso y ticket, y un segundo operador aprueba. El PDP detecta que Bea aparece como revisora del mismo cambio y activa SoD dinámica: la solicitud queda deny hasta cambiar el aprobador. Una nueva aprobación entrega un grant de staging mediante el broker. El broker registra inicio y fin; el PEP de la consola valida de nuevo el recurso. Una llamada que intenta alcanzar producción devuelve deny, aunque la sesión esté autenticada.
En la salida de Bea, HR envía el evento, el IdP deshabilita la cuenta y SCIM marca el recurso inactivo. La consola confirma la retirada, pero una herramienta de backup no responde. El sistema no declara la baja completa: marca ese receptor unknown, bloquea el camino de backup y abre investigación. Un token de API encontrado en memoria no se interpreta como “cuenta activa”; se revoca según su servicio, se busca uso posterior y se comprueba que las sesiones no puedan renovar. El informe final separa lo observado (login rechazado), lo inferido (un receptor pudo no procesar la baja), el impacto posible y la decisión (bloqueo temporal y retest).
Este caso muestra por qué el gobierno no es un formulario. La autoridad de la relación, el entitlement, la aprobación, la sesión y la retirada pertenecen a momentos y componentes distintos. La evidencia debe permitir reconstruirlos sin convertir una señal aislada en una garantía.
Qué hacer cuando los sistemas discrepan
Los ciclos distribuidos no fallan sólo con una caída total. Pueden entregar eventos fuera de orden, repetirlos o aceptar una actualización sin propagarla. Un evento mover que llega antes que el joiner puede crear una cuenta huérfana; un leaver repetido puede devolver un error “ya eliminado” aunque un receptor conserve un grant. Por eso cada transición necesita un identificador idempotente, una versión de la fuente y una política para eventos tardíos. La idempotencia evita duplicar efectos, pero no resuelve por sí sola una autorización equivocada.
Cuando una fuente y un receptor discrepan, el operador debe separar cuatro preguntas: qué evento afirma la fuente, qué recibió el conector, qué estado materializó el receptor y qué acción permite ahora el PEP. Si sólo se conoce la primera, el estado es unknown. La respuesta puede ser bloquear una ruta de alto impacto, mantener el mínimo común o exigir una revisión humana. No se debe “arreglar” la discrepancia editando directamente el grupo en el receptor sin registrar la fuente y el motivo: esa corrección crea otra autoridad difícil de retirar.
El diagnóstico mejora cuando se conserva una línea temporal correlacionada. Para cada principal se anotan t_source, t_provision, t_policy, t_session y t_revoke, junto con relojes y versiones. Un retardo mediano puede ocultar colas largas: conviene observar percentiles, edad del evento más antiguo, reintentos y proporción de receptores sin confirmación. Las métricas no son un objetivo de cumplimiento aislado; sirven para decidir cuándo un estado provisional deja de ser aceptable.
Límites de la evidencia privilegiada
La evidencia de una sesión administrativa debe permitir responder qué principal actuó, con qué autorización, sobre qué recurso y con qué resultado. Eso no exige conservar todo indiscriminadamente. Un registro de comandos puede contener datos personales, valores de configuración o secretos introducidos accidentalmente. La retención debe definir acceso al propio log, integridad, búsqueda, exportación y destrucción. Si un administrador puede borrar sus propios registros, la separación de funciones está incompleta aunque exista una grabadora.
La correlación entre aprobación y ejecución también tiene límites. El ticket aprobado puede mencionar “reiniciar servicio”, mientras la sesión ejecuta una shell con permisos más amplios; un hash de comando puede cambiar por parámetros; una operación automática puede ejecutarse después de que el grant expire. El PEP debe registrar la decisión efectiva y el receptor, no sólo adjuntar el ticket. Cuando no hay correspondencia, se marca una excepción de control para investigación, no se reescribe el ticket para que parezca coincidente.
En un sistema de alta criticidad, el acceso de emergencia puede necesitar dos canales independientes: uno para activar el grant y otro para alertar al propietario. Esa separación no elimina el riesgo de una cuenta comprometida, pero hace observable el uso. Después del incidente, la revisión debe decidir si el acceso era necesario, si el alcance fue suficiente y si los controles ordinarios deben cambiar. “Se usó break-glass” no es una explicación causal ni una aprobación retroactiva.
Decisiones de diseño que deben quedar explícitas
Antes de automatizar el workflow, Asteria documenta cinco decisiones. Primero, qué fuente tiene autoridad sobre la relación y cómo se resuelven conflictos. Segundo, qué identificador se correlaciona entre HR, IdP, SCIM y recurso. Tercero, qué entitlements son roles administrables y cuáles son grants directos excepcionales. Cuarto, qué receptor confirma revocación y qué ventana de propagación se tolera. Quinto, qué condiciones convierten un dato faltante en bloqueo en vez de revisión.
También documenta las exclusiones. Un permiso de lectura no implica que el dato observado sea apropiado para exportación; JIT no convierte una cuenta en no privilegiada; MFA no sustituye una policy de recurso; SCIM no garantiza que una sesión ya iniciada termine; y un log de broker no demuestra que el destino aplicó el mismo principal. Estas frases evitan que una etiqueta de control se convierta en garantía universal.
Playbook de adjudicación
Ante una alerta de acceso, el analista puede usar una ficha de cinco capas. Primero identifica el principal que el receptor observó y lo correlaciona con la fuente de relación, sin asumir que un nombre visible sea único. Después reconstruye el entitlement efectivo: roles directos, grupos heredados, reglas por atributo, grants temporales y excepciones. En tercer lugar identifica la policy version y el PEP que produjo la decisión. En cuarto lugar reconstruye el lifecycle de sesión, token o conexión. Finalmente clasifica la evidencia como observada, inferida, faltante o contradictoria.
La ficha debe conservar las decisiones negativas. Si una solicitud fue rechazada por conflicto SoD, ese rechazo es un resultado de control, no un fallo que deba ocultarse para mejorar una métrica. Si un receptor no respondió durante el deprovisioning, el estado se mantiene unknown y se aplica la política de contención. Si el acceso se permitió durante una excepción, la revisión posterior debe comprobar alcance y duración, no sólo que exista un ticket. Este lenguaje ayuda a separar una ausencia de datos de una ausencia de riesgo.
La respuesta operativa también debe ser proporcional. Un permiso de lectura sobre documentación interna puede esperar una revisión de propietario; una credencial capaz de cambiar el proveedor de identidad exige bloqueo y comprobación inmediata de sesiones. La severidad se deriva de autoridad, alcance, receptores, duración, capacidad de revocación y evidencia disponible. No se deduce de la etiqueta “admin” sin conocer qué operaciones puede ejecutar realmente.
Cuando se cierra el caso, el informe enlaza causa, decisión y retest. La causa puede ser una fuente de relación desactualizada, un mapeo SCIM ambiguo, una regla SoD incompleta, un broker que no propaga expiración o un receptor sin telemetría suficiente. La corrección debe resolver esa causa y probar el control positivo y negativo: el acceso autorizado sigue funcionando dentro del alcance, y el acceso retirado o fuera de alcance falla en el receptor pertinente. Volver a ejecutar una campaña sin cambiar la causa no es retest.
Transferencia y síntesis
El mismo razonamiento sirve para una cuenta de proveedor, una consola cloud o un administrador de base de datos. Pregunte: ¿qué autoridad afirma la relación?, ¿qué entitlement exacto se concede?, ¿quién lo aplica?, ¿qué reloj y qué cache intervienen?, ¿qué evidencia prueba la retirada? Separe accept/reject/review para identidad y evidencia de permit/deny para la acción. Use degrade/unknown cuando disponibilidad o datos impidan adjudicar.
El ciclo de vida es un contrato entre fuentes de autoridad, sistemas de identidad, policy y receptores. PAM acota operaciones privilegiadas en tiempo, alcance y evidencia; no transforma una aprobación en seguridad total. El gobierno convierte cambios y revisiones en decisiones trazables sólo cuando puede explicar quién, qué, cuándo, bajo qué policy y con qué límites. La propiedad más importante no es que una cuenta exista, sino que cada acceso vigente tenga una razón comprobable y un camino de salida verificable.