IAAA - Identification Authentication Authorization Accountability

Definición

Marco básico de gestión de identidades y acceso que cubre cómo un usuario se identifica, demuestra su identidad, recibe permisos y es responsabilizado por sus acciones.

Contexto

• Responde a preguntas clave: quién es el usuario, cómo prueba su identidad, qué puede hacer y cómo auditar sus acciones.
• Sustenta prácticas como MFA, control de acceso y registro/auditoría para proteger confidencialidad, integridad y disponibilidad.
• En el OWASP Top 10 (2025), varias categorías se explican directamente como fallos de IAAA (según el RAW):
  • Autorización → Broken Access Control (OWASP Top 10 2025 - A01)
  • Autenticación → Authentication Failures (OWASP Top 10 2025 - A07)
  • Rendición de cuentas (logging/alerting) → Security Logging and Monitoring Failures (OWASP Top 10 2025 - A09)

Desarrollo (MIT-style)

Introducción y objetivos

• Preguntas resueltas: identificación única, prueba de identidad, evitar suplantaciones, conceder y aplicar acceso, y rastrear acciones.
• Objetivos de aprendizaje: identificación, autenticación, autorización, responsabilidad, modelos de control de acceso, SSO.

Modelo IAAA (visión general)

• Identificación: el usuario declara quién es (email, usuario, número).
• Autenticación: demuestra que es quien dice ser.
• Autorización: qué acciones/recursos puede usar.
• Responsabilidad: registro y auditoría para atribuir acciones.

Identificación

• Reclamar identidad con identificadores únicos: email, usuario (tanderson, neo), teléfono, pasaporte, NID.
• Importancia: sin identidad única, no se puede aplicar autenticación/roles.

Autenticación (factores)

• Diferente de identificación: verifica la identidad reclamada.
• Factores principales:
  1. Algo que sabes: contraseña, frase de contraseña, PIN/patrón.
     
  2. Algo que tienes: teléfono/SIM para OTP, llaves de seguridad hardware (YubiKey, Titan, Nitrokey, Thetis), tarjetas.
     
  3. Algo que eres: biometría (huella, rostro, retina, voz).
     
• Otros menos usados: ubicación, comportamiento.
• Ejemplos: login TryHackMe con usuario/email + contraseña; móvil con PIN/patrón/biometría.

Autenticación multifactor (MFA)

• Uso de ≥2 factores diferentes (p.ej., tarjeta + PIN en cajero, llave + PIN en caja fuerte).
• 2FA es un caso de MFA con dos factores.
• Beneficio: si un factor se compromete (contraseña), el atacante aún necesita el segundo.
• Ejemplos prácticos:
  • OTP por app TOTP (30 s) + contraseña.
  • WebAuthn/FIDO2 (llave hardware) + PIN/biometría.
  • SMS es el más débil; úsalo solo como último recurso.

Buenas prácticas de autenticación

• Política de contraseñas: longitud mínima (12–14+), prohibir reuse, bloquear diccionario, no rotar sin causa salvo compromiso; almacenamiento con hash fuerte y sal (Argon2/ bcrypt/ scrypt).
• SSO/Federación: reduce fatiga de contraseñas y mejora control central (SAML/OIDC); requerir MFA en el IdP.
• Reseteos: verificación fuera de banda fuerte; caducidad de tokens de reset; registros de cambios.
• Sesiones: expiración e invalidación tras logout, cookies HttpOnly/Secure/SameSite.

Autorización y control de acceso

• Autorización: define permisos (qué recursos/acciones).
• Control de acceso: aplica la política (mecanismos físicos o lógicos).
• Ejemplos:
  • Gimnasio: suscriptor autorizado a usar equipo, no a llevárselo.
  • Hotel: llave/tarjeta abre solo la habitación asignada.
  • Empresa: ventas accede a docs de ventas, no a RRHH/finanzas.
  • Email: usuario lee su buzón, no el de otros.
• Patrones comunes: RBAC (roles), ABAC (atributos/claims), SoD (segregación de funciones), principio de mínimo privilegio y just-in-time access para tareas elevadas.

Privilegios (PIM vs PAM)

• PIM (Privileged Identity Management): traduce el rol del usuario en la organización a un rol de acceso en el sistema (identidad privilegiada).
• PAM (Privileged Access Management): gestiona el uso de privilegios (credenciales, sesiones, auditoría, aprobación/JIT) y ayuda a reducir superficie de ataque.
• Principio guía: mínimo privilegio (solo lo estrictamente necesario para la función). Relacionado: IAM Checklist.

Responsabilidad, registro y auditoría

• Responsabilidad = atribuir acciones a identidades autenticadas.
• Requiere logging centralizado e integridad de logs para auditorías.
• Ejemplos: banco registra transacciones de cajeros; alertas por accesos fallidos repetidos o patrones anómalos.
• Prácticas de logging:
  • Registrar autenticaciones, cambios de credenciales, elevación de privilegios, accesos a datos sensibles, cambios de configuración/política.
  • Enviar a SIEM central; sincronizar tiempo; proteger integridad (WORM/retención).
  • Alertas por anomalías (geovelocidad, múltiples fallos, MFA bypass, sesiones desde TOR/VPN inusual).

Ejemplos

• Inicio de sesión único (SSO): identidad declarada una vez, autenticación federada y autorización delegada; exige logs para responsabilidad.
• Preguntas de práctica del RAW (se pueden mapear): factores (1-sabes, 2-tienes, 3-eres, 4-2FA); autorización=definir, control de acceso=aplicar.

Pitfalls / Errores comunes

• Usar solo contraseñas débiles sin MFA.
• Confundir autenticación con autorización (otorgar acceso tras “conocer el email”).
• No centralizar ni proteger logs, perdiendo trazabilidad y no repudio.
• Permisos excesivos por rol (sin mínimo privilegio) o falta de segregación de funciones.
• No validar unicidad de identificadores, creando colisiones de identidad.
• Depender de SMS/voz sin controles anti-swap; reuso de tokens de sesión sin invalidar; no revisar accesos privilegiados periódicamente.

Diagrama

flowchart LR
ID[Identificación] --> AU[Autenticación]
AU --> AZ[Autorización]
AZ --> AC[Rendición de cuentas (logs)]
AC -->|auditoría| Feedback[Mejora de controles]

Referencias

1. TryHackMe — Security Principles (origen del contenido)
2. Pending validation