4.7 Gestión de identidades y accesos

Resumen y motivación

Cada solicitud que llega a tus sistemas arrastra una pretensión implícita: tengo permiso para hacer esto. La gestión de identidades y accesos (IAM) es la disciplina de decidir si esa pretensión es verdadera. Responde a dos preguntas distintas que la gente confunde constantemente. La autenticación demuestra quién eres. La autorización decide qué puedes hacer una vez que lo has demostrado. Mantén esas dos ideas separadas en tu cabeza y la mitad de la confusión de este campo desaparece.

Para equipos grandes, la identidad se ha convertido, casi sin que nadie lo anuncie, en el control más importante que posees. El capítulo 4.3 sostiene que la identidad es el nuevo perímetro, y el capítulo 4.1 construye la confianza cero sobre ella: cuando dejas de confiar en la red, lo único que queda por confiar es una identidad verificada y una política explícita. Ese giro significa que un flujo débil de recuperación de contraseña o una cuenta de servicio olvidada ya no es un detalle menor. Es la puerta principal. La mayoría de los incidentes reales no son exploits ingeniosos de vulnerabilidades de seguridad de memoria; son credenciales robadas, permisos excesivamente amplios y cuentas que deberían haberse desactivado hace meses.

Las apuestas se disparan en entornos empresariales y gubernamentales. Una gran corporación gestiona decenas de directorios superpuestos, miles de altas y bajas al mes, y socios que necesitan acceso acotado a un fragmento de tus sistemas. Una agencia pública añade credenciales de tarjeta inteligente, niveles de verificación de identidad reglamentados y auditores que exigirán, por escrito, saber exactamente quién pudo acceder a un registro dado en un día concreto. Este capítulo tiene una postura clara sobre cómo construir una capa de identidad que responda a esas preguntas con rigor, sin acabar frenando a tu gente.

Principios fundamentales

La autenticación y la autorización son problemas distintos. Demostrar la identidad y conceder permisos requieren diseños separados y revisiones separadas.
Una identidad, muchos sistemas. Centraliza cada población de identidades en una única fuente de verdad; la proliferación de directorios es un defecto de seguridad.
Privilegio mínimo por defecto. Parte de cero accesos y añádelos de forma deliberada, tanto para personas como para máquinas.
Toda credencial es temporal. Prioriza credenciales de vida corta y emisión automática frente a secretos de larga duración.
La revocación es tan importante como la concesión. Un acceso que sobrevive a su necesidad es riesgo puro.
Lo resistente al phishing supera a lo memorable. Orienta la autenticación hacia claves de paso y factores respaldados por hardware.
Las máquinas también son identidades. Cargas de trabajo, pipelines y servicios necesitan identidad gestionada, no claves estáticas compartidas.
El acceso es un ciclo de vida, no un evento. Concede, revisa y revoca con periodicidad, y demuestra que lo haces.

Recomendaciones

Separa la autenticación de la autorización y centralízalas ambas

Autentica a través de un proveedor de identidad (IdP), un sistema que verifica la identidad y emite tokens que otros sistemas confían. Luego deja que cada aplicación tome sus propias decisiones de autorización a partir de la identidad y los atributos que el token transporta. Esta separación te permite reforzar la autenticación una sola vez, para todos, mientras mantienes la lógica de permisos granular cerca de los datos que protege. Adopta el acceso único (SSO), donde un solo inicio de sesión concede acceso a múltiples aplicaciones, para que tu gente disponga de un único acceso sólido en lugar de cuarenta débiles. La federación extiende esa misma confianza más allá de los límites organizativos, permitiendo que las identidades de un socio accedan a tus sistemas sin que tengas que gestionar sus contraseñas.

Usa el protocolo moderno para lo que cada uno está hecho

Tres estándares hacen el grueso del trabajo, y cada uno tiene su función. OpenID Connect (OIDC) es una capa de identidad construida sobre OAuth 2.0; úsala para responder ¿quién es este usuario en el inicio de sesión web y móvil. OAuth 2.0 es un marco de autorización para acceso delegado; úsalo para permitir que una aplicación llame a una API en nombre de un usuario sin ver jamás su contraseña (capítulo 2.3). Security Assertion Markup Language (SAML) es el estándar de federación XML más antiguo; sigue siendo el caballo de batalla del SSO empresarial hacia aplicaciones de negocio consolidadas. Un error frecuente es recurrir a OAuth para autenticar directamente. OAuth concede acceso a recursos; OIDC se superpone para establecer la identidad. Elige OIDC para nuevos inicios de sesión de usuario, conserva SAML donde tu catálogo empresarial lo exige, y no inventes tu propio formato de token.

Haz que la autenticación sea resistente al phishing

Las contraseñas por sí solas son indefensables a escala. Exige autenticación multifactor (MFA), que combina algo que sabes, algo que tienes y algo que eres, para cada cuenta humana sin excepción. Luego avanza más allá de los factores débiles: los códigos de un solo uso por SMS son vulnerables al phishing y al intercambio de SIM. El destino fuerte son las claves de paso y el estándar subyacente WebAuthn (una API de navegador para autenticación con clave pública), que anclan el inicio de sesión a una clave privada alojada en hardware y al origen real del sitio, de modo que una página falsa no pueda capturar nada que valga la pena robar. Las claves de paso son también sin contraseña, y tus usuarios te lo agradecerán. Trata la recuperación de cuentas y el restablecimiento de contraseña como parte de la superficie de autenticación, porque un atacante que no pueda saltar tu MFA simplemente atacará el flujo de recuperación.

Gestiona el ciclo de alta-movimiento-baja y revoca rápido

La identidad es un ciclo de vida. Un nuevo ingreso necesita el acceso adecuado desde el primer día. Una persona que cambia de puesto necesita el acceso nuevo y, lo crucial es, que se le quite el acceso anterior, o de lo contrario va acumulando poco a poco las llaves de todo el edificio. Una baja debe perder todo acceso con prontitud, idealmente en minutos desde su último día, en todos los sistemas. Impulsa esto desde una fuente autoritativa, normalmente el sistema de recursos humanos, de modo que un cambio de estado allí active automáticamente la provisión y la revocación aguas abajo. Automatízalo. Las listas de desvinculación manual siempre se saltan algo, y la cuenta que se salta es la que aparece en el informe del incidente.

Elige un modelo de autorización y exprésalo como política en código

Otorga permisos por control de acceso basado en roles (RBAC), donde asignas permisos a roles de función y personas a roles, porque es sencillo de razonar y fácil de auditar. Acude al control de acceso basado en atributos (ABAC) cuando necesites decisiones contextuales basadas en atributos como departamento, clasificación de datos, ubicación u hora del día. La mayoría de las organizaciones maduras operan un híbrido: RBAC para las concesiones gruesas, ABAC para las condiciones finas. Sea cual sea tu elección, expresa la autorización como política en código: reglas redactadas en un formato versionado, probable y revisable, en lugar de clics en una consola. La política en código hace que las decisiones de acceso sean auditable, comparables por diferencias y consistentes entre entornos, y te permite probar un cambio de permiso antes de que se despliegue.

Impón el privilegio mínimo con acceso a tiempo justo y PAM

Aplica el principio de privilegio mínimo: cada identidad recibe el acceso mínimo que necesita y nada más. El privilegio permanente es el enemigo, porque un permiso concedido indefinidamente es un permiso disponible para cualquier atacante que caiga en esa cuenta a cualquier hora. Prefiere el acceso a tiempo justo (JIT), donde una persona solicita derechos elevados para una ventana acotada, los obtiene tras una aprobación y los pierde automáticamente cuando la ventana cierra. Para tus cuentas más peligrosas, adopta la gestión de accesos privilegiados (PAM): un sistema que guarda las credenciales administrativas en una bóveda, intermedia y registra sesiones privilegiadas y emite elevación a demanda. El objetivo es cero acceso administrativo permanente, de modo que incluso un portátil completamente comprometido no ofrezca nada durable.

Da identidad real a las máquinas y las cargas de trabajo

Las personas son solo la mitad de tus identidades. Servicios, pipelines, contenedores y funciones se autentican ante algo, y con demasiada frecuencia lo hacen con un secreto de larga duración pegado en un archivo de configuración. Sustituye las claves estáticas por una identidad de carga de trabajo gestionada: credenciales de vida corta emitidas automáticamente a una carga de trabajo en función de dónde se ejecuta y qué es. Usa TLS mutuo (mTLS), donde ambos extremos de una conexión presentan certificados, para la autenticación entre servicios. Guarda los secretos que queden en un gestor de secretos dedicado con rotación, nunca en código fuente ni en imágenes (capítulo 4.2). Las credenciales de carga de trabajo de vida corta y rotación automática eliminan la causa más frecuente de fugas de credenciales en la nube.

Haz de la identidad el plano de control y revisa el acceso de forma continua

En una arquitectura de confianza cero (capítulo 4.1), la identidad es donde se decide y se ejecuta la política, así que invierte ahí en consecuencia. Luego cierra el ciclo con revisiones de acceso, también llamadas recertificación: con periodicidad, el responsable de cada sistema confirma que cada persona y cada máquina con acceso lo sigue necesitando, y revoca lo que no justifica. Alimenta cada evento de autenticación y autorización en una traza de auditoría que responda quién accedió a qué, cuándo y bajo qué política (capítulo 4.6). Las revisiones de acceso son tu defensa contra el desgaste de privilegios, esa acumulación lenta de permisos que ninguno, por separado, pareció razonable, pero que en conjunto hacen una cuenta enormemente poderosa.

Compromisos: ventajas e inconvenientes

Decisión	Ventajas	Inconvenientes
IdP centralizado con SSO	Un solo acceso fuerte, política coherente, auditoría sencilla	Punto único de fallo; una caída bloquea a todos
RBAC	Simple, auditable, conocido	Proliferación de roles; demasiado grueso para necesidades contextuales
ABAC	Granular, contextual, escala con atributos	Más difícil de diseñar, probar y razonar
Claves de paso / WebAuthn	Resistentes al phishing, sin contraseña, sólidas	Los flujos de recuperación y pérdida de dispositivo requieren diseño cuidadoso
Acceso a tiempo justo	Privilegio permanente casi nulo	Fricción; exige vías de aprobación rápidas y fiables
Federación con socios	Sin gestión de contraseñas externas; confianza acotada	La confianza depende de la propia higiene del socio
Claves de servicio de larga duración	Trivialmente fáciles de configurar	Propensas a fugas; primera causa de incidentes de credenciales

La tensión central es seguridad frente a fricción. Cada control que reduce la superficie de ataque (MFA para todos, elevación JIT, credenciales de vida corta) también añade un paso al día de alguien, y la gente elude los controles que le cuestan demasiado. Resuélvelo haciendo del camino seguro el camino fácil: SSO para que la autenticación fuerte sea un toque, claves de paso para que no haya contraseña que teclear, y provisión automática para que el acceso correcto simplemente aparezca. Gasta tu presupuesto de fricción donde el radio de impacto es mayor, en el acceso privilegiado y de producción, y mantén el acceso cotidiano casi sin fricción.

Preguntas para debatir con tu equipo

¿Qué tan rápido puedes revocar todo el acceso de alguien que baja hoy, y cómo lo sabes? La velocidad de revocación es una medida directa de tu madurez en identidad, porque una baja cuyo acceso perdura es una cuenta sin supervisión con permisos reales. En una organización grande con decenas de sistemas desconectados, la respuesta honesta suele ser «no estamos seguros», y el hueco suele estar en las aplicaciones que nunca se integraron con el proveedor de identidad central. Trae una baja reciente real y traza cada sistema al que podía acceder, verificando los registros de cuándo terminó cada acceso. Fija un objetivo, como la revocación completa en una hora desde el cambio de estado en recursos humanos, e instrumenta el proceso para poder demostrarlo en lugar de confiarse. Si algún sistema depende de que alguien recuerde un paso manual, esa es la cuenta que un futuro incidente explotará.
¿Dónde sigues teniendo acceso privilegiado permanente y credenciales estáticas de larga duración, y qué haría falta para eliminarlos? Los derechos administrativos permanentes y las claves de servicio duraderas son los dos activos que un atacante más desea, porque son resistentes y poderosos. Haz un inventario de cada persona con acceso permanente a producción o administración y cada servicio que se autentican con una clave estática, y pregunta con honestidad cuáles de esos podrían migrar a elevación a tiempo justo o identidad de carga de trabajo de vida corta. La consideración contraria es el miedo operativo: los equipos conservan el acceso permanente porque los momentos de emergencia se sienten más seguros con él, así que debes hacer la elevación de emergencia rápida y fiable antes de quitar los derechos permanentes. Lleva la lista al debate y prioriza por radio de impacto, dirigiéndote primero a producción y administración. El estado final a alcanzar es cero acceso administrativo permanente y ninguna clave estática que sobreviva a un solo despliegue.
¿Tienes una identidad autoritativa única por persona y por carga de trabajo, o varias, y qué te está costando la fragmentación? La proliferación de directorios, donde la misma persona existe como cinco cuentas en cinco sistemas con atributos divergentes, es donde nacen los huecos de revocación y los accesos huérfanos. Consolidar en una única fuente de verdad por población de identidades es una de las inversiones de mayor palanca que un equipo grande puede hacer, porque cada control aguas abajo depende de saber que dos registros son la misma persona. Lleva un inventario de tus almacenes de identidad y señala cuáles son autoritativos y cuáles son copias convenientes que nadie gobierna. El compromiso es que la consolidación es una migración grande y sin brillo que compite con el trabajo de funcionalidad por atención. Decide si el coste continuado de la fragmentación, en dolor de auditoría y riesgo de incidente, justifica financiar esa migración ahora en lugar de después del próximo incidente.
¿Tus factores de autenticación más fuertes son genuinamente resistentes al phishing, y qué te impide retirar las contraseñas de una vez por todas? El factor que un atacante no puede capturar por phishing es el que termina con el robo de credenciales como tu vía dominante de intrusión, y las claves de paso ancladas a WebAuthn son la única opción ampliamente implementable que supera ese listón. En una organización grande, el panorama honesto suele ser mixto: claves de paso para algunos, códigos de un solo uso por SMS para otros y una larga cola de aplicaciones heredadas que aún aceptan una sola contraseña. La consideración contraria es real, porque las claves de paso trasladan el problema difícil a la recuperación y la pérdida de dispositivo, y un flujo de recovery torpe se convierte en el nuevo blanco blando al que un atacante simplemente deriva. Lleva las cifras de cobertura por tipo de factor, la lista de aplicaciones que aún retroceden a contraseña y un flujo de recuperación diseñado del que confíes ante un intento de ingeniería social decidido. En entornos empresariales y públicos, vincula el objetivo a cualquier nivel de garantía reglamentado, porque un sistema de alta garantía que aún permite un factor vulnerable al phishing tiene una brecha de cumplimiento además de una de seguridad.
¿Cómo decides qué acceso recibe cada identidad, y puedes comparar, probar y demostrar esa decisión antes de que se despliegue? La distancia entre «alguien clickeó permisos en una consola» y «una política versionada y revisada» es la diferencia entre un modelo de acceso que puedes auditar y uno ante el que solo puedes pedir disculpas. Para un equipo grande, la presión es dejar que cada aplicación cultive sus propias reglas a medida, lo que acaba produciendo proliferación de roles en el lado RBAC y condiciones inenjuiciables en el lado ABAC, hasta que nadie puede decir qué concede exactamente una concesión dada. La consideración contraria es la velocidad de entrega, porque expresar la autorización como política en código añade un paso de revisión que un clic en consola no tiene, y los equipos bajo plazo resentirán la fricción hasta que el primer fallo de auditoría o el primer permiso excesivamente amplio haga el caso por ellos. Trae un cambio de permiso real y traza cómo se propondría, se probaría, se revisaría y se revertiría, además del recuento de roles que tienes y de cuántos nadie puede explicar. En entornos empresariales y públicos, un auditor pedirá ver exactamente quién pudo acceder a un registro y bajo qué regla un día dado, y solo una política comparable y testable responde sin entrar en pánico.
¿Cuándo revocó una revisión de acceso algo concreto y quién es responsable cuando el desgaste de privilegios no se controla? Las revisiones de acceso son el control que combate la acumulación lenta de permisos que ninguno, por separado, pareció razonable, y una revisión que nunca revoca nada es teatro de recertificación que produce papel en lugar de seguridad. En una organización grande, el modo de fallo es el visto bueno mecánico: los responsables recertifican cientos de entradas en una sola sesión, aprobándolo todo porque evaluar cada una de verdad es tedioso y el incentivo de mantener el acceso fluyendo supera al de cortarlo. La consideración contraria es que unas revisiones significativas cuestan tiempo al responsable y a veces rompen el flujo de alguien al desaparecer un acceso del que dependía en silencio, así que debes hacer la revisión orientada a riesgo y selectiva, no una lista indiferenciada. Trae la tasa de revocación del último ciclo, el número medio de autorizaciones por persona y evidencia de quién es responsable de la recertificación de cada sistema. En entornos empresariales y públicos, nombra al funcionario responsable de cada revisión y la cadencia a la que está sujeto, porque el desgaste de privilegios al que nadie es responsable de vigilar es exactamente la condición que auditores y atacantes explotan.

Perspectiva sectorial

Startup. Compra identidad, no la construyas. Un único proveedor de identidad en la nube con SSO, claves de paso obligatorias y desvinculación con un clic otorga a un puñado de ingenieros una postura empresarial por un precio por usuario. Apóyate en la identidad de carga de trabajo integrada del proveedor para que no exista ni una sola clave de nube de larga duración en tu pipeline, y usa OIDC y OAuth 2.0 de catálogo en lugar de inventar un manejo de tokens que no puedes permitirte mantener.

Pyme. Sin especialista en identidad en plantilla, prioriza el SSO y la MFA que ya vienen incluidos en las herramientas que ya pagas, y actívalos en lugar de buscar una plataforma aparte. Trata el ciclo de alta-movimiento-baja como una breve lista de verificación escrita vinculada a quien gestiona contrataciones, y prefiere las claves de paso porque eliminan la carga de recuperación de contraseña que no puedes permitirse a nadie. Evita los accesos compartidos, ya que son el hábito barato que después hace imposible la atribución y la revocación.

Gran empresa. El trabajo es la consolidación y la gobernanza a través de muchos directorios y equipos: un proveedor de identidad autoritativo impulsado por el sistema de recursos humanos, flujos automáticos de alta-movimiento-baja que provisionan al contratar y revocan en minutos tras la baja, RBAC para funciones de puesto con ABAC para el contexto, y gestión de accesos privilegiados con grabación de sesiones. Expresa la autorización como política en código para que los cambios sean comparables y testables, ejecuta revisiones de acceso periódicas que de verdad revocan, y estandariza la interfaz para que las aplicaciones se integren en la identidad central en lugar de que cada una cultive su propio inicio de sesión.

Sector público. Las reglas de contratación, la transparencia y la rendición de cuentas ante la ciudadanía guían el diseño. Ancla la autenticación a credenciales de hardware como tarjetas PIV o CAC, establece niveles de garantía de identidad según la norma NIST SP 800-63 de modo que los sistemas de mayor riesgo exijan factores de mayor garantía, y conserva registros de auditoría inmutables que respondan exactamente quién accedió a qué y cuándo. Publica en lenguaje claro el tratamiento de la identidad ciudadana, separa los pilas de identidad del cliente y de la fuerza laboral, y asegúrate de que cada acción privilegiada sobre un sistema sensible sea intermediada y registrada para los auditores que lo pedirán.

Ejemplos

Startup. Una startup de veinte personas no puede cubrir un equipo de identidad, así que lo compra. Cada empleado inicia sesión a través de un único proveedor de identidad en la nube con SSO hacia el correo, el repositorio de código, la consola de nube y la aplicación interna, y las claves de paso son obligatorias, de modo que no hay contraseñas que robar. La desvinculación es un clic: desactivar a la persona en el proveedor de identidad corta el acceso en todas partes a la vez. Para su propio producto, usan OIDC para el inicio de sesión del usuario y OAuth 2.0 para que las integraciones llamen a su API con tokens acotados. La autenticación entre servicios y la nube usa la identidad de carga de trabajo integrada del proveedor, de modo que no hay ni una sola clave de nube de larga duración en el pipeline. Todo esto cuesta una cuota modesta por usuario y les compra una postura de identidad más sólida que la que muchas grandes empresas operan.

Gran empresa. Un banco transnacional lleva una década acumulando cuatro directorios y cientos de aplicaciones, algunas federadas por SAML, otras con sus propios logins locales. Financia un programa de consolidación: un proveedor de identidad autoritativo, impulsado por el sistema de recursos humanos, con flujos automáticos de alta-movimiento-baja que provisionan al contratar y revocan en minutos tras la terminación. El RBAC cubre las funciones de puesto estándar, mientras que el ABAC impone reglas de residencia de datos y nivel de autorización para el acceso transfronterizo. Los administradores no tienen acceso permanente a producción; solicitan elevación a tiempo justo a través de un sistema PAM que registra cada sesión. Las revisiones trimestrales de acceso obligan a los responsables de cada sistema a recertificar o revocar, y cada decisión se expresa como política en código para que los auditores puedan comparar exactamente qué cambió y cuándo.

Sector público. Una agencia federal emite tarjetas inteligentes PIV, y su equivalente militar, la tarjeta CAC, a su personal, de modo que la autenticación está anclada a una credencial de hardware en lugar de a una contraseña. Su programa de identidad sigue el enfoque FICAM y establece niveles de garantía de identidad según la guía NIST SP 800-63, de modo que los sistemas de mayor riesgo exigen credenciales de mayor garantía. Los servicios orientados al ciudadano usan un pilar de identidad del cliente separado, a un nivel de garantía menor, con MFA sólido. Las revisiones de acceso y los registros de auditoría inmutables alimentan directamente la evidencia de autorización continua de la agencia (capítulo 4.6), y cada acción privilegiada sobre un sistema clasificado es intermediada y registrada.

Justificación empresarial: motivaciones, retorno y coste total

El retorno de la inversión en identidad se obtiene al sacar tu vector de intrusión dominante de la zona de peligro. Las credenciales robadas y las cuentas con permisos excesivos impulsan una gran parte de los incidentes reales, y cada uno arrastra una cola pesada: respuesta a incidentes, multas regulatorias, notificación de brecha y daño reputacional duradero. La MFA resistente al phishing por sí sola elimina la vía de intrusión más común, y la desvinculación automatizada cierra el hueco de la cuenta huérfana que convierte una baja rutinaria en una exposición. Estas son algunas de las reducciones de riesgo más económicas por cada euro invertido.

El coste total de propiedad es real, pero acotado. Incluye la licencia del proveedor de identidad, una plataforma de PAM y gestión de secretos, el esfuerzo de integración de cada aplicación en la identidad central y el trabajo continuado de las revisiones de acceso. El coste más grande es organizativo: consolidar directorios y adaptar el SSO a aplicaciones heredadas es un trabajo lento, sin brillo, que compite con las funcionalidades. Pésalo frente a la alternativa. La identidad fragmentada gasta el mismo dinero eternamente en forma de desvinculación manual, apuros de auditoría y peticiones de recuperación de contraseña al servicio de mesa, más el coste eventual del incidente que la fragmentación hace probable. Cuando presentes el caso ante la dirección, enmarca la identidad como el plano de control de la confianza cero: la consolidación y la automatización son una inversión puntual que reduce tanto el riesgo de incidente como el coste recurrente de auditorías, desvinculaciones y soporte de accesos.

Antipatrones y errores frecuentes

Cuentas huérfanas. Acceso que sobrevive a la persona o al propósito, sobre todo cuentas de servicio sin supervisión y contratistas olvidados.
Administración permanente en todas partes. Acceso privilegiado siempre activo en lugar de elevación a tiempo justo, dando a cualquier cuenta de administrador comprometida poder durable.
Claves estáticas de larga duración. Credenciales de servicio pegadas en la configuración o en el CI que nunca expiran y eventualmente se filtran.
Proliferación de directorios. La misma persona como muchas cuentas sin gobernanza, de modo que ningún cambio se propaga por completo.
Cuentas compartidas. Credenciales usadas por varias personas, que destruyen la atribución y hacen imposible la revocación.
SMS como factor fuerte. Tratar los códigos de un solo uso vulnerables al phishing y al intercambio de SIM como MFA suficiente.
Explosión de roles. Tantos roles RBAC estrechos que el modelo se vuelve inauditable y nadie sabe qué concede un rol.
Desvinculación como lista manual. Pasos de baja humana que inevitablemente se saltan la cuenta que importa.
OAuth usado para autenticar. Tratar un token de acceso como prueba de identidad en lugar de usar OIDC.
Teatro de recertificación. Revisiones de acceso aprobadas sin que nadie evalúe de verdad la necesidad.

Modelo de madurez

Nivel 1, Iniciación: Cada aplicación tiene su propio login. Contraseñas sin MFA consistente. La provisión y la desvinculación son manuales, reactivas y lentas; las cuentas huérfanas se acumulan. Las credenciales de servicio son claves estáticas de larga duración. No hay revisiones de acceso; los permisos se conceden y nunca se revisan.
Nivel 2, Desarrollo: El SSO cubre las aplicaciones principales a través de un proveedor de identidad central, pero la cobertura es irregular entre equipos. La MFA es obligatoria para la mayoría de los accesos humanos. Existe un RBAC básico. El ciclo de alta-movimiento-baja está parcialmente automatizado desde el sistema de recursos humanos. Algunas cuentas privilegiadas están en bóveda. Las revisiones de acceso ocurren de vez en cuando y de forma inconsistente.
Nivel 3, Estandarización: Un proveedor de identidad consolidado es autoritativo para la fuerza laboral, con provisión automatizada y revocación rápida impuesta en toda la organización. La MFA resistente al phishing es estándar y documentada. El RBAC junto con el ABAC se expresa como política en código. La gestión de accesos privilegiados con grabación de sesiones está en marcha. La identidad de carga de trabajo reemplaza la mayoría de las claves estáticas. Las revisiones de acceso periódicas están impuestas y auditadas según una política escrita que todos los equipos siguen.
Nivel 4, Gestión: El programa de identidad se mide contra líneas base y se controla con datos. Seguirás el tiempo de revocación desde el cambio de estado en recursos humanos hasta la revocación completa, la cobertura de MFA y claves de paso por población, el número de cuentas con acceso privilegiado permanente, la cantidad de claves estáticas de larga duración aún en uso, el recuento de cuentas huérfanas y la tasa de revocación en las revisiones de acceso. Las métricas llevan objetivos, como revocación completa en una hora y cero nuevas concesiones de administración permanente, y la superación de un umbral dispara una investigación en lugar de una encogida de hombros. Los cambios de autorización se prueban en el pipeline y cada sí o no sobre una concesión de acceso se rige por evidencia, no por hábito.
Nivel 5, Orquestación: La identidad es el plano de control de la confianza cero en mejora continua, integrado con la seguridad, el riesgo y la planificación de alta-movimiento-baja en toda la organización. Las claves de paso son el valor predeterminado y las contraseñas están en proceso de retiro. El privilegio permanente es cero mediante elevación a tiempo justo, y todas las cargas de trabajo usan credenciales de vida corta y rotación automática con mTLS. La autorización es íntegramente política en código. Las revisiones de acceso son continuas y orientadas al riesgo, la revocación es casi instantánea, y cada decisión produce evidencia de auditoría automáticamente. El modelo se adapta a medida que las señales de riesgo cambian, tensando o relajando el acceso dinámicamente en lugar de en una cadencia fija.

Ideas para el debate

¿Qué haría falta para alcanzar el acceso administrativo permanente cero, y qué vía de emergencia haría que fuera seguro?
¿Dónde merece la pena la complejidad del ABAC en tu entorno frente a quedarse con un RBAC simple?
¿Con qué agilidad debes retirar las contraseñas a favor de las claves de paso, y qué flujo de recuperación las sustituye?
¿Qué aplicaciones siguen fuera de tu proveedor de identidad central y qué las mantiene ahí?
¿Cómo concedes acceso acotado a socios y clientes sin heredar su higiene de seguridad?
¿Qué métrica individual capta mejor tu velocidad de revocación, y la estás midiendo hoy?

Conclusiones clave

La autenticación demuestra quién eres; la autorización decide qué puedes hacer. Diseña y revísalas por separado.
Centraliza en un único proveedor de identidad con SSO; la proliferación de directorios es un defecto de seguridad, no una comodidad.
Automatiza el ciclo de alta-movimiento-baja y haz que la revocación sea rápida y demostrable.
Usa OIDC para el inicio de sesión del usuario, OAuth 2.0 para el acceso delegado a APIs y SAML donde el catálogo empresarial lo exige; no uses OAuth como autenticación.
Orienta la autenticación hacia claves de paso resistentes al phishing y WebAuthn; exige MFA en todas partes y trata los factores débiles como transición.
Impón el privilegio mínimo con acceso a tiempo justo y gestión de accesos privilegiados; apunta a cero derechos administrativos permanentes.
Da identidad real a las máquinas con credenciales de carga de trabajo de vida corta y mTLS; elimina las claves estáticas de larga duración.
Haz de la identidad el plano de control de la confianza cero (capítulo 4.1) y cierra el ciclo con revisiones de acceso continuas y evidencia de auditoría (capítulo 4.6).

Referencias y lectura complementaria

National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (niveles de garantía de identidad, autenticación y federación)
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, familias AC (Access Control) e IA (Identification and Authentication)
The OAuth 2.0 Authorisation Framework, IETF RFC 6749, y la OAuth 2.0 Security Best Current Practice
OpenID Connect Core 1.0 specification, OpenID Foundation
Security Assertion Markup Language (SAML) 2.0 specification, OASIS
Web Authentication (WebAuthn) Level 2, W3C Recommendation, y especificaciones FIDO2 / FIDO Alliance de claves de paso
Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
Documentación de Open Policy Agent (OPA), Cloud Native Computing Foundation (política en código para autorización)