AZ-900

Deep Dive

Practicar ahora
D3 · Gestión, seguridad y cumplimiento

Identidad y acceso con Microsoft Entra ID

Autenticación, autorización, RBAC y Zero Trust. El dominio de identidad representa ~25% del AZ-900. La clave es distinguir autenticación de autorización y elegir el control correcto para cada escenario.

Pilares de identidad

Toda arquitectura de seguridad descansa sobre tres pilares. El AZ-900 evalúa que distinguas cuál herramienta corresponde a cada pilar.

01

Autenticación (AuthN)

¿Eres quién dices ser?

Proceso de verificar la identidad. El sistema comprueba credenciales antes de otorgar cualquier acceso.

En Azure

Entra ID verifica usuario + contraseña. Si hay MFA, solicita segundo factor (app, SMS, biométrico).

Trampa de examen

AuthN responde "¿quién eres?". NO responde qué puedes hacer. Eso es AuthZ.

02

Autorización (AuthZ)

¿Qué puedes hacer?

Proceso de determinar qué recursos o acciones están permitidos para una identidad ya autenticada.

En Azure

RBAC define qué puede hacer el usuario: Owner puede borrar. Reader solo puede ver. Contributor puede crear.

Trampa de examen

AuthZ ocurre DESPUÉS de AuthN. No se puede autorizar a alguien sin haberlo autenticado primero.

03

Auditoría

¿Quién hizo qué y cuándo?

Registro inmutable de todas las acciones. Permite forense, compliance y detección de anomalías.

En Azure

Azure Activity Log + Entra ID Sign-in Logs. Retención 90 días por defecto. Enviar a Log Analytics para más.

Trampa de examen

Auditoría ≠ alertas. Auditoría registra el pasado. Alertas notifican en tiempo real. Son complementarios.

Icon-identity-227

Microsoft Entra ID — directorio central de identidades

Antes llamado Azure Active Directory (Azure AD). Es el servicio de identidad en la nube de Microsoft. Toda cuenta de Azure, Microsoft 365 u Office 365 usa Entra ID como directorio subyacente.

Funciones principales

Directorio central

Almacena todas las identidades: usuarios, grupos, service principals, managed identities.

Single Sign-On (SSO)

Un login para múltiples apps. Inicia sesión una vez → accede a Teams, Azure Portal, Salesforce, GitHub sin volver a autenticar.

Multi-Factor Auth (MFA)

Segundo factor obligatorio para cuentas privilegiadas. Reduce 99.9% el riesgo de compromiso por contraseña robada.

B2B (Business-to-Business)

Invitar usuarios externos (socios, auditores) con su cuenta de empresa. Sin crear cuentas adicionales.

B2C (Business-to-Consumer)

Permitir que clientes se registren con Google/Facebook/email propio. Tu app, sus cuentas.

Tipos de identidad en Entra ID

Usuario

Persona real. Cuenta de empleado, admin, invitado B2B.

Grupo

Colección de usuarios. Asignas permisos al grupo, no individualmente.

Service Principal

Identidad para una aplicación. Como un "usuario" para tu app o script.

Managed Identity

Service Principal automático gestionado por Azure. Sin contraseñas ni rotación manual.

Entra ID ≠ Active Directory clásico

Entra ID es un directorio cloud basado en HTTP/HTTPS (OAuth, OIDC, SAML). Active Directory Domain Services (AD DS) es on-premises usando LDAP/Kerberos. Son productos diferentes, no la misma cosa en la nube.

RBAC — Control de Acceso Basado en Roles

RBAC es el sistema de autorización de Azure. En lugar de dar permisos individuales a cada persona, asignas roles. Cada rol = conjunto de permisos predefinidos o personalizados.

RolPuede crear/modificarPuede borrarPuede asignar rolesCaso de uso típico
OwnerAdmin de la suscripción, lider técnico
ContributorDesarrolladores de producción
ReaderAuditores, stakeholders, soporte L1
User Access AdministratorGestionar permisos sin tocar recursos
Custom RoleConfigurableConfigurableConfigurableDBA solo con acceso a SQL, DevOps sin billing

Asignación de roles — 3 componentes

Security Principal

¿A quién se asigna? Usuario, grupo, service principal o managed identity.

Role Definition

¿Qué puede hacer? Colección de permisos (actions, notActions). Ej: "Microsoft.Compute/virtualMachines/read".

Scope

¿Sobre qué recursos? Management Group → Subscription → Resource Group → Recurso individual.

Herencia: los roles se heredan hacia abajo. Asignar Contributor en una Subscription → el usuario es Contributor en todos los RGs y recursos de esa Subscription.

Icon-identity-233

Acceso Condicional y Zero Trust

Acceso Condicional

Políticas que evalúan señales (usuario, ubicación, dispositivo, app, riesgo) y aplican controles. Si X → entonces Y.

SIUsuario está en red corporativaAcceso sin MFA
SIUsuario desde IP desconocidaExigir MFA
SIDispositivo no administradoBloquear acceso a datos sensibles
SIRiesgo de inicio de sesión = altoForzar cambio de contraseña
SIAdmin accediendo a Azure PortalSiempre exigir MFA + dispositivo compliant

Zero Trust — el modelo moderno

Principio: "nunca confíes, siempre verifica". No existe perímetro de red de confianza. Cada acceso se verifica, independientemente de si viene de dentro o fuera de la red corporativa.

Verificar explícitamente

Autenticar y autorizar siempre, basado en todos los datos disponibles.

Acceso mínimo privilegiado

Least privilege: solo los permisos necesarios, por el tiempo necesario.

Asumir brecha

Diseñar como si el atacante ya estuviera dentro. Segmentar, cifrar, monitorear.

MFA y métodos de autenticación

Los 3 factores de autenticación

🧠

Algo que SABES

  • Contraseña
  • PIN
  • Pregunta de seguridad
📱

Algo que TIENES

  • App Authenticator (código TOTP)
  • SMS con código
  • Llave de seguridad física (FIDO2)
👁️

Algo que ERES

  • Huella dactilar
  • Reconocimiento facial
  • Iris

MFA = mínimo 2 factores de categorías distintas. Contraseña + PIN no es MFA (ambos son "algo que sabes"). Contraseña + app authenticator sí es MFA.

Estadísticas de seguridad (Microsoft, 2023)

  • MFA bloquea el 99.9% de los ataques de compromiso de cuentas basados en contraseña.
  • El 81% de las brechas de seguridad involucran credenciales débiles o robadas.
  • Una cuenta sin MFA con contraseña filtrada tarda en promedio 10 segundos en ser comprometida.

AD DS clásico vs Microsoft Entra ID

Pregunta frecuente en el examen: cuándo usar cada uno.

DimensiónAD DS (on-premises)Microsoft Entra ID (cloud)
Dónde viveServidores propios (Domain Controllers)Cloud de Microsoft (global)
ProtocoloLDAP, Kerberos, NTLMHTTP/HTTPS, OAuth 2.0, OIDC, SAML 2.0
DispositivosPCs Windows unidas al dominioCualquier dispositivo, cualquier OS, cualquier lugar
Apps soportadasApps corporativas legacy (Kerberos)Apps modernas, SaaS, API (Google, Salesforce, GitHub)
MFA nativoNo (requiere extensión)Sí, integrado
Acceso condicionalNoSí (Conditional Access policies)
EscaladoManual (agregar DCs)Automático, global
MantenimientoTu equipo: parches, HA, backup de ADMicrosoft (99.99% SLA)
Caso de uso idealApps legacy on-premises, GPOs, join de PCs corp.Identidades cloud, SaaS, trabajo remoto, apps modernas

Escenario híbrido — lo más común

Muchas empresas tienen AD DS on-premises Y Entra ID en la nube. Las unen con Entra Connect (sincronización de identidades). El usuario se autentica con su cuenta corporativa tanto en PCs del dominio como en Teams, Azure Portal y Salesforce.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

¿Qué protocolos usa Microsoft Entra ID para autenticación y autorización modernas?