Gestión de identidades y accesos: ciclo de vida, MFA y modelos de autorización

Toda decisión de control de acceso que toma un sistema se apoya en dos hechos: quién lo pide y qué puede hacer esa persona o ese programa. La gestión de identidades y accesos (IAM) es la disciplina de mantener correctos ambos hechos, no solo en el momento en que se crea una cuenta, sino a lo largo de ascensos, traslados, contratistas, adquisiciones, servicios dados de baja y la larga cola de cuentas cuyo acceso nadie recuerda haber concedido. Es donde la seguridad falla con más frecuencia sin hacer ruido, porque un permiso obsoleto no genera ningún mensaje de error.

Para un desarrollador, la IAM se traduce en decisiones concretas: qué factores de autenticación admitir, cómo almacenar las credenciales, qué modelo de autorización necesita realmente el dominio, cómo recibir las cuentas de usuario desde el directorio de un cliente y qué hacer con las identidades de máquina, que ya superan en número a las humanas. Los protocolos que transportan la identidad entre sistemas —OAuth 2.0 para el acceso delegado y OpenID Connect para el inicio de sesión federado— se tratan por separado; esta guía trata del modelo que hay debajo de ellos.

El ciclo de vida de la identidad

Las cuentas tienen una vida, que suele describirse en tres etapas: alta, cambio y baja (joiner, mover, leaver).

Alta. Una fuente autorizada —el sistema de RR. HH. para los empleados, un registro de contratos para los proveedores, un flujo de registro para los clientes— crea la identidad. Los accesos se conceden a partir de una base definida para el puesto, no copiando los permisos de un compañero, una costumbre que propaga los privilegios como un rumor.

Cambio. Alguien cambia de equipo, asciende o asume una responsabilidad temporal. El patrón peligroso es la acumulación de privilegios: se conceden los nuevos accesos, nunca se retiran los antiguos y, al cabo de unos años, un empleado veterano puede hacer casi cualquier cosa. Un cambio debe desencadenar la recertificación de todo el conjunto de permisos, no una simple suma.

Baja. La salida debe revocar el acceso en todas partes y con rapidez, incluidas las aplicaciones federadas, las VPN, los buzones compartidos, los tokens de API personales, las consolas en la nube y todo lo que la persona configuró con sus propias credenciales. Aquí es donde la identidad centralizada se amortiza: deshabilitar una sola cuenta del directorio cierra todas las aplicaciones federadas con él, mientras que las cuentas gestionadas localmente sobreviven indefinidamente.

Dos prácticas de apoyo hacen real el ciclo. La revisión de accesos es un ejercicio periódico en el que el responsable de un sistema confirma que cada usuario sigue necesitando sus accesos; funciona cuando el revisor ve los permisos en lenguaje claro y puede revocarlos con un clic, y degenera en un visto bueno automático cuando muestra nombres de grupo en bruto. La segregación de funciones codifica las combinaciones que ninguna persona puede tener a la vez —crear un proveedor y aprobar su pago, por ejemplo— y se comprueba al conceder el acceso en lugar de descubrirse durante una auditoría.

Factores de autenticación

Las pruebas de autenticación se reparten en las tres categorías tradicionales: algo que sabes, algo que tienes y algo que eres. Su solidez real difiere enormemente.

Las passkeys, basadas en WebAuthn y FIDO2, son la respuesta moderna. El registro crea un par de claves en el autenticador; la clave privada nunca sale de él y la relying party guarda la clave pública. Al iniciar sesión, el navegador firma un challenge junto con el origen del sitio solicitante, de modo que una credencial para bank.example.com no produce nada que pueda usar un dominio que lo imite. Esa vinculación al origen es lo que derrota a los proxies de phishing en tiempo real, y por eso las passkeys están sustituyendo a los códigos de un solo uso en lugar de complementarlos. Las passkeys sincronizadas acompañan al usuario entre dispositivos a través del llavero de la plataforma; las claves ligadas al dispositivo, en un token físico, encajan en los roles de alta garantía.

La autenticación adaptativa, o basada en riesgo, ajusta la exigencia al contexto: un dispositivo nuevo, una ubicación inusual o una transferencia elevada activan un refuerzo (step-up), mientras que una sesión conocida no lo hace. Combinada con los claims acr y amr que emite un proveedor de identidad, permite a una aplicación exigir un factor más fuerte para una operación concreta en vez de en cada inicio de sesión.

Almacenar contraseñas correctamente

Donde las contraseñas siguen existiendo, las reglas son estrictas e innegociables. Nunca las almacenes de forma recuperable. Nunca uses un hash rápido sin más: SHA-256 aplicado a una contraseña está diseñado para ser rápido, que es justo la propiedad que busca un atacante con una tabla robada. Usa un algoritmo de alto consumo de memoria, con sal y ajustable: Argon2id como primera opción, scrypt como segunda, bcrypt cuando lo imponga una limitación del ecosistema y PBKDF2 con un número elevado de iteraciones cuando la normativa exija una función aprobada por el NIST.

// Argon2id con parámetros ajustados para que la verificación cueste unos cientos de milisegundos en tu hardware
Argon2PasswordEncoder encoder = new Argon2PasswordEncoder(
        16,          // longitud de la sal en bytes
        32,          // longitud del hash en bytes
        1,           // paralelismo
        1 << 16,     // coste de memoria de 64 MiB
        3);          // iteraciones

String stored = encoder.encode(submittedPassword);        // incluye el algoritmo, los parámetros y la sal
boolean ok = encoder.matches(submittedPassword, stored);  // comparación en tiempo constante, nunca equals()

La sal es distinta para cada usuario y se guarda junto al hash; impide que una sola tabla precalculada rompa todas las cuentas a la vez. Un pepper —un valor secreto que se guarda fuera de la base de datos, en un gestor de claves— añade protección cuando solo se filtra la base de datos. Codifica el algoritmo y los parámetros en la cadena almacenada para poder subir el coste o migrar de algoritmo más adelante, recalculando el hash de cada contraseña en el siguiente inicio de sesión correcto.

La política importa tanto como la criptografía. Permite frases de contraseña largas y pegar desde un gestor; contrasta las contraseñas candidatas con listas de valores filtrados conocidos; elimina las reglas de composición que empujan hacia Summer2026!; limita la tasa de intentos y bloquea con un retardo creciente en lugar de un umbral fijo que se convierte en palanca de denegación de servicio; y devuelve el mismo mensaje de error exista o no la cuenta. Un generador de contraseñas que se ejecuta íntegramente en el navegador es un buen recurso al que remitir a los usuarios cuando necesitan un valor robusto. Ten en cuenta que un generador de hashes de uso general sirve para sumas de verificación y resúmenes de mensajes, nunca para hashear una contraseña, precisamente porque esos algoritmos son rápidos.

Modelos de autorización

Merece la pena pensar bien el modelo desde el principio, porque adaptarlo después sale caro.

Las listas de control de acceso (ACL) asocian directamente a cada objeto los sujetos autorizados. Así funcionan los permisos del sistema de archivos, como se explica en Usuarios, grupos y permisos en Linux. Son precisas, pero inmanejables a escala: nadie puede responder a «¿a qué tiene acceso este usuario?» sin recorrerlo todo.

El control de acceso basado en roles (RBAC) agrupa los permisos en roles y asigna los roles a los usuarios. Es el caballo de batalla: comprensible, auditable y compatible con todo. Su punto débil es la explosión de roles: los roles se multiplican para codificar excepciones hasta que hay más roles que usuarios, y en ese momento han dejado de ser una abstracción.

El control de acceso basado en atributos (ABAC) evalúa una política sobre atributos del sujeto, el recurso, la acción y el entorno. Expresa un contexto que queda fuera del alcance de los roles, a costa de políticas sobre las que es más difícil razonar y que cuesta más probar.

permit if
    subject.department == resource.owningDepartment
    and subject.clearance >= resource.classification
    and action in {"read", "list"}
    and environment.time within subject.workingHours

El control de acceso basado en relaciones (ReBAC) modela la autorización como un grafo —este usuario es editor de esa carpeta, que contiene ese documento— y responde a las preguntas recorriéndolo. Encaja en productos colaborativos y en recursos jerárquicos donde el permiso fluye por contención, y es el modelo en el que se basan varios servicios de políticas modernos.

En la práctica, los sistemas los combinan: roles de grano grueso o scopes de OAuth en el perímetro, y una comprobación fina por relaciones o atributos en la capa de dominio, donde vive la regla de propiedad. Externalizar la política a un motor —un sidecar o una biblioteca que evalúa reglas declarativas— saca la autorización de la lógica de negocio y la hace testeable, pero solo compensa cuando varios servicios comparten las mismas reglas. Sea cual sea el modelo, el punto de decisión debe estar en el servidor, aplicarse en cada petición y denegar por defecto.

Directorios, aprovisionamiento y federación

Los directorios LDAP siguen siendo el almacén de usuarios de referencia en la mayoría de las grandes organizaciones. Un directorio es un árbol jerárquico de entradas identificadas por nombres distinguidos (DN), con usuarios y grupos como objetos y atributos como uid, mail y memberOf. Históricamente, las aplicaciones se conectaban directamente a LDAP para autenticar; hoy es mejor dejar que el proveedor de identidad hable con el directorio y ofrecer a tu aplicación un inicio de sesión federado, para que las credenciales nunca pasen por tu código.

SCIM (RFC 7644) resuelve la otra mitad: dar de alta las cuentas en una aplicación y, sobre todo, darlas de baja. Es un protocolo REST sobre un esquema de usuario JSON estándar, que un proveedor de identidad usa para crear, actualizar, desactivar y eliminar cuentas a medida que cambia el directorio.

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: app.example.com
Content-Type: application/scim+json
Authorization: Bearer <provisioning token>

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

Admitir SCIM convierte el desaprovisionamiento de un ticket manual en una consecuencia automática de un cambio en el directorio, que es lo más valioso que puede hacer una aplicación de negocio por la postura de seguridad de sus clientes. Poner active a false debe cerrar de inmediato las sesiones y revocar los tokens, no limitarse a ocultar la cuenta de una lista.

Identidades privilegiadas, de máquina y en la nube

Las cuentas de administrador merecen un trato aparte. La gestión de accesos privilegiados (PAM) implica: ningún derecho de administración permanente, elevación solicitada para una tarea y concedida por un tiempo limitado, cuentas separadas para el trabajo de administración, grabación de sesiones cuando el riesgo lo justifique y autenticación respaldada por hardware en cada inicio de sesión privilegiado. Existen credenciales de emergencia (break-glass), selladas, vigiladas y probadas, y su uso genera una alerta automáticamente.

Las identidades de máquina ya superan en número a las humanas. Servicios, jobs, pipelines y contenedores necesitan autenticarse, y la respuesta equivocada es una clave de API compartida en un fichero de configuración. Prefiere una identidad que la plataforma emita para la carga de trabajo en ejecución: un rol de instancia en una cuenta en la nube, un token de service account proyectado en Kubernetes, un certificado de corta duración de una autoridad interna para TLS mutuo. En términos de los servicios básicos de AWS, es la diferencia entre una access key subida a un repositorio y un rol asumido por una instancia en ejecución sin ninguna credencial estática en ningún sitio. Cuando un secreto estático sea inevitable, limítalo a una sola acción, rótalo automáticamente y alerta cuando se use desde un origen inesperado.

Por último, la auditoría. Cada autenticación, cada decisión de autorización sobre un recurso sensible, cada concesión de permisos y cada elevación de privilegios debe generar una entrada de registro con el actor, la acción, el objetivo, el resultado y la hora, escrita en un lugar que el actor no pueda editar. Ese registro es lo que hace que un incidente pase de la especulación a una cronología.

Puntos clave

• La identidad es un ciclo de vida, no un formulario de registro; quien cambia de puesto acumula privilegios y quien se va debe perder el acceso en todas partes y con rapidez.
• Las passkeys basadas en WebAuthn están ligadas al origen y resisten el phishing, y por eso hoy superan a los códigos de un solo uso y a las aprobaciones por push.
• Almacena las contraseñas con Argon2id o una función equivalente de alto consumo de memoria, con sal y parametrizada, y prioriza la longitud y el cribado frente a las reglas de composición y la rotación forzada.
• Elige el modelo de autorización que necesita el dominio —roles para permisos de grano grueso, atributos o relaciones cuando deciden el contexto y la propiedad— y aplícalo en el servidor, siempre.
• Federa la autenticación con el directorio y admite SCIM para que el alta y, sobre todo, la desactivación de cuentas sean automáticas.
• Aplica a las identidades privilegiadas y de máquina el mismo rigor que a las humanas: sin derechos permanentes, sin secretos estáticos donde la plataforma pueda emitirlos de corta duración y con un registro de auditoría que nadie pueda reescribir.