4.4Identidades, MFA, seguridad (Entra ID)
Lo esencial en 30 segundos
- En la nube, la identidad se convierte en el verdadero perímetro de seguridad: te conectas desde cualquier sitio, y proteger la identidad protege el acceso a todo.
- Entra ID (antes Azure AD) gestiona las identidades de M365; el MFA añade un segundo factor y bloquea el robo de contraseña solo — la medida más rentable.
- El acceso condicional adapta la exigencia al contexto (lugar, dispositivo, riesgo); se protegen en prioridad las cuentas de administrador.
Mini-caso hilado — Sofiane endurece los accesos de la pyme
Sofiane, administrador de sistemas en una pyme de distribución en Argel, realiza una auditoría de las identidades en Entra ID. Comprueba que el MFA no está activado en todas partes y que dos cuentas de administrador están exentas «para ir más rápido». Lo corrige: MFA exigido para todos, en prioridad en las cuentas con privilegios, y luego una regla de acceso condicional sencilla — MFA obligatorio fuera de la oficina. Define también la conducta a seguir en caso de cuenta comprometida: restablecer y revocar las sesiones. Anota el reflejo: proteger las identidades es proteger todo el acceso.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el script y el reto de 48 h de la sección 4.4.
1. La identidad, nuevo perímetro
En la nube ya no hay un «muro» de red alrededor de la empresa: te conectas desde cualquier sitio. El verdadero perímetro pasa a ser la identidad. Entra ID (antes Azure AD) gestiona estas identidades para Microsoft 365. Proteger la identidad es proteger el acceso a todo — de ahí la importancia de ir más allá de la simple contraseña.
2. El MFA, imprescindible
Una contraseña sola se roba (phishing, fuga, reutilización). El MFA (autenticación multifactor) añade un segundo factor: algo que se posee (aplicación de autenticación, código) además de algo que se sabe (contraseña). Aun con la contraseña, un atacante queda bloqueado sin el segundo factor. Es la medida más rentable contra el robo de cuentas.
3. El acceso condicional
Se va más lejos con el acceso condicional: reglas que adaptan la exigencia al contexto («exigir MFA fuera de la oficina», «bloquear inicios de sesión desde países no concernidos», «exigir un dispositivo conforme»). La idea: cuanto más arriesgado es el contexto, más garantías se piden. Se protegen en prioridad las cuentas con privilegios, nunca exentas de las reglas.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una contraseña robada por phishing
Un usuario introduce su contraseña en un sitio falso; Sofiane compara los dos casos:
Sin MFA : el atacante inicia sesion -> cuenta comprometida X
Con MFA : el atacante tiene la contrasena pero no el 2. factor
-> inicio de sesion bloqueado + alerta OK
Lectura : el MFA neutraliza el robo de la contrasena sola.
Leccion : activar el MFA es la medida mas rentable contra la toma de cuentas.
Lectura: el MFA neutraliza el robo de contraseña sola — el atacante no tiene el segundo factor.
Lección: activar el MFA es la medida más rentable contra la toma de cuentas, sobre todo en los admins.
Vocabulario de la sección
- Entra ID
- Servicio de identidad en la nube de Microsoft (antes Azure AD) para M365.
Ejemplo sencillo: Sofiane gestiona las cuentas y el MFA desde Entra ID.
Lo que no es: un servicio de almacenamiento de archivos de equipo.
Reflejo: identidades M365 → Entra ID.
- Identidad
- Cuenta que prueba quién eres; el verdadero perímetro de seguridad en la nube.
Ejemplo sencillo: Proteger la identidad protege el acceso a todo, recuerda Sofiane.
Lo que no es: un cable o un puerto de red, que no autentica a nadie.
Reflejo: conectarse desde cualquier sitio → proteger la identidad.
- MFA
- Autenticación multifactor: contraseña + un segundo factor que se posee.
Ejemplo sencillo: Sofiane exige el MFA para todos, empezando por los admins.
Lo que no es: una contraseña sola, reutilizada y robada con facilidad.
Reflejo: bloquear el robo de contraseña → MFA.
- Acceso condicional
- Reglas que adaptan la exigencia de autenticación al contexto.
Ejemplo sencillo: Sofiane exige el MFA fuera de la oficina.
Lo que no es: una regla única idéntica en toda situación.
Reflejo: riesgo más alto → exigencia reforzada.
- Phishing
- Engaño cuyo fin es robar credenciales mediante un sitio o mensaje falso.
Ejemplo sencillo: Un portal falso imita el inicio de sesión de M365 para robar la contraseña.
Lo que no es: una avería de hardware que corta la conexión.
Reflejo: contraseña reclamada por mensaje → desconfianza.
En la práctica — En la práctica — Reforzar los accesos de un inquilino
- Compruebe que el MFA está activado para todas las cuentas, sobre todo las de administrador, como Sofiane.
- Defina una regla de acceso condicional sencilla (p. ej. MFA fuera de la oficina).
- Identifique las cuentas con privilegios que merecen una protección reforzada.
- Prevea la conducta a seguir en caso de cuenta comprometida (restablecer, revocar sesiones).
Script paso a paso — endurecer los accesos como Sofiane (5 min)
1) Abra Entra ID y liste las cuentas, localizando las cuentas de administrador. 2) Compruebe que el MFA está activado en todas partes — y nunca exento para los admins. 3) Cree una regla de acceso condicional sencilla: MFA obligatorio fuera de la oficina. 4) Anote las cuentas con privilegios y la protección reforzada prevista. 5) Escriba el procedimiento en caso de compromiso: restablecer y revocar las sesiones.
Recordatorio: estos ajustes responden a una política validada por la organización — principio del mínimo privilegio, sin puentear la seguridad.
Modelo copiar-pegar — mi ficha de seguridad de las identidades
Perimetro : la identidad (no la red) — Entra ID gestiona las cuentas M365
MFA : exigido en todas partes, en PRIORIDAD en las cuentas admin
Acc. cond.: adaptar la exigencia al contexto (lugar, dispositivo, riesgo)
Privileg. : minimo privilegio, nunca exencion 'para ir rapido'
Compromiso: restablecer la cuenta + revocar las sesiones
Una contraseña robada
Gracias al MFA, Sofiane bloquea al atacante que solo tiene la contraseña.
Un admin protegido
Sofiane aplica el MFA en prioridad a las cuentas con privilegios, nunca exentas.
Fuera de la oficina
El acceso condicional exige el MFA en cuanto la conexión viene del exterior.
Una alerta tratada
Sofiane reacciona ante un inicio de sesión sospechoso: restablecer y revocar las sesiones.
✓ Buenas prácticas
- Activar el MFA en todas partes, en prioridad en los admins.
- Adaptar la exigencia al contexto (acceso condicional).
- Tratar la identidad como el verdadero perímetro.
✗ Errores frecuentes
- Apoyarse en la sola contraseña.
- Eximir del MFA a las cuentas de admin «por comodidad».
- Ignorar las alertas de inicio de sesión sospechoso.
Puntos clave
- En la nube, la identidad es el verdadero perímetro de seguridad.
- Entra ID gestiona las identidades de M365.
- El MFA bloquea el robo de contraseña sola: la medida más rentable.
- El acceso condicional adapta la exigencia al contexto (lugar, dispositivo, riesgo).
Reto 48 h — aplícalo mañana
Como Sofiane, audite las identidades de un inquilino: compruebe que el MFA está activo en todas partes (admins primero) y escriba una regla de acceso condicional sencilla (p. ej. MFA fuera de la oficina). Precise en una frase la conducta a seguir en caso de cuenta comprometida (restablecer, revocar las sesiones).
- Puedo explicar por qué la identidad es el perímetro de seguridad.
- Sé por qué el MFA bloquea el robo de contraseña.
- Comprendo el acceso condicional y la prioridad a las cuentas de admin.
Preguntas frecuentes
¿De verdad hace falta el MFA si las contraseñas son fuertes?
Sí: incluso una contraseña fuerte se roba por phishing o fuga. El MFA añade una barrera que el atacante no tiene y neutraliza la inmensa mayoría de las tomas de cuenta automatizadas. Es la medida con mejor relación esfuerzo/protección.
¿Por qué proteger sobre todo las cuentas de administrador?
Porque una cuenta de admin comprometida da las llaves de todo el inquilino. Se protegen en prioridad (MFA, acceso condicional, cuentas dedicadas) y nunca se eximen de las reglas «para ir más rápido».
¿Por qué protege el MFA aunque se robe la contraseña?