Fundamentos de la seguridad de identidades
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 7 → 8
ActualizaciónDos secciones nuevas: cómo funcionan la fatiga de MFA y los códigos retransmitidos y por qué las passkeys resisten ambos, y qué hace privilegiada a una cuenta, con una comparación entre el privilegio permanente y el acceso just-in-time.
3 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 17 a 21 minutos.
En el centro de toda decisión de acceso hay dos preguntas:
1. **Autenticación (AuthN)**: *¿Quién es usted?* El sistema verifica que la persona o el servicio controla realmente la cuenta.
2. **Autorización (AuthZ)**: *¿Qué puede hacer?* Una vez probada la identidad, las políticas, los roles y los permisos deciden qué aplicaciones, datos y acciones están permitidos.
Un usuario puede estar perfectamente autenticado y aun así no tener autorización para abrir el sistema de nóminas. Mantenga ambos pasos separados en su razonamiento.
::diagram isf-authn-authz
### Autenticación multifactor
MFA combina factores de categorías distintas para que un único secreto robado no sea suficiente:
- **Algo que sabe**: una contraseña, un PIN, una pregunta de seguridad.
- **Algo que tiene**: un teléfono que recibe notificaciones push, una app autenticadora que genera códigos TOTP, una llave de seguridad FIDO2.
- **Algo que es**: una huella o un reconocimiento facial, normalmente para desbloquear un dispositivo o una passkey.
No todos los factores son igual de robustos. Los códigos por SMS o correo pueden interceptarse o robarse mediante phishing. Las aprobaciones push pueden explotarse con ataques de "fatiga de MFA". Las **passkeys (FIDO2/WebAuthn)** están vinculadas al sitio real y resisten el phishing; por eso muchas organizaciones las consideran el factor preferido.
### Dos ataques al segundo factor, y por qué las passkeys resisten
**Fatiga de MFA.** El atacante ya tiene la contraseña, por ejemplo de una página de phishing. Cada intento de inicio de sesión envía una notificación push al teléfono de la víctima. El atacante lo repite, a menudo de madrugada, hasta que el usuario, cansado, pulsa Approve solo para que pare. Técnicamente no se rompió nada: se desgastó al usuario.
**Códigos retransmitidos.** Una página de inicio de sesión falsa pide la contraseña y el código de un solo uso, y pasa ambos al sitio real en segundos. Funciona igual con códigos por SMS, por correo electrónico y de aplicación autenticadora, porque un código vale allí donde se escriba.
Una **passkey** cierra las dos brechas. Es un par de claves: la clave privada nunca sale del dispositivo del usuario, y el dispositivo solo responde al desafío de inicio de sesión para la dirección del sitio web (el origen) en el que se registró la passkey. Un sitio de apariencia similar tiene otra dirección, así que no recibe nada que pueda reutilizar. No hay notificación que aprobar por reflejo ni código que retransmitir. Una passkey es además **sin contraseña**: el usuario la desbloquea con la huella, el rostro o el PIN del dispositivo, y no se escribe ni se guarda ninguna contraseña en el servidor.
| Factor | Una contraseña robada no basta | Resiste una página de inicio de sesión falsa |
| --- | --- | --- |
| Código por SMS o correo electrónico | Sí | No, el código se puede retransmitir |
| Código de aplicación autenticadora | Sí | No, el código se puede retransmitir |
| Aprobación push | Sí | No, y las notificaciones repetidas pueden desgastar al usuario |
| Passkey (FIDO2/WebAuthn) | Sí | Sí, está vinculada al sitio real |
> Consejo: Pregunte si un factor resiste el phishing, no solo si MFA está "activado".
El texto solo cambió en otros idiomas.
La seguridad de identidades suele dividirse en tres disciplinas. Se solapan, y los programas maduros las gestionan de forma conjunta.
- **IAM (gestión de identidades y accesos)** controla el acceso diario: inicio de sesión único, MFA, directorios, ciclo de vida de usuarios y políticas de acceso. Su objetivo es que las personas adecuadas lleguen a las aplicaciones adecuadas con la menor fricción posible.
- **PAM (gestión de accesos privilegiados)** protege el pequeño grupo de cuentas que más daño pueden causar: administradores de dominio, root, propietarios de bases de datos y administradores de la nube. Sus controles típicos son una bóveda de credenciales, la rotación de contraseñas, las sesiones aprobadas y la grabación de sesiones.
- **IGA (gobierno y administración de identidades)** se pregunta si ese acceso *debería* existir. Incluye solicitudes y aprobaciones de acceso, revisiones periódicas (certificaciones), segregación de funciones y evidencias para auditoría.
Una forma sencilla de recordarlo: IAM abre la puerta, PAM vigila la cámara acorazada e IGA revisa periódicamente la lista de invitados.
En la suite de Monofor, **Monosign** reúne la gestión de accesos y el gobierno en una sola plataforma, **Monopam** se centra en el acceso privilegiado y **Monosync** sincroniza los datos de identidad entre orígenes y destinos. Los usuarios de Monopam y Monosync suelen iniciar sesión a través de Monosign, que actúa así como identidad central.
::diagram isf-iam-pam-iga
### Qué hace privilegiada a una cuenta
Una cuenta es privilegiada por **lo que puede cambiar**, no por quién la usa. Un administrador de dominio es el ejemplo evidente. Una cuenta de servicio que una herramienta de copias de seguridad usa con derechos de administrador en todos los servidores es igual de poderosa, y es más fácil pasarla por alto: nadie inicia sesión con ella, su contraseña rara vez cambia y nadie se siente responsable de ella. Cuando liste las cuentas privilegiadas con un cliente, pregunte por los dos tipos: las que usan las personas y las que usan las máquinas.
### Privilegio permanente y acceso just-in-time
El **privilegio permanente (standing privilege)** significa que el acceso poderoso está ahí todo el tiempo, se use o no. Cada hora que existe es una hora en la que un atacante puede usarlo. El **acceso just-in-time** elimina eso: la persona pide el acceso cuando una tarea lo necesita, se concede para una ventana de tiempo limitada y termina por sí solo después.
Ejemplo: una administradora de bases de datos necesita acceso a producción para un cambio de esquema el jueves por la tarde.
| | Privilegio permanente | Acceso just-in-time |
| --- | --- | --- |
| Cuándo tiene el acceso | Todo el año | El jueves de 20:00 a 22:00 |
| Quién lo decidió | Quien lo configuró hace tiempo | Un compañero que aprobó esta solicitud |
| Qué encuentra un atacante el viernes | Una cuenta de administrador que funciona | Nada que pueda usar |
> Consejo: Empiece por la cobertura de IAM, después proteja las cuentas privilegiadas y luego añada gobierno. Una carencia en cualquiera de los tres se convierte en una vía de ataque.