Microsoft AZ-500: Gestión de identidades y accesos — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Security Engineer Associate AZ-500 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La Gestión de Identidad y Acceso (IAM) en Microsoft Azure se centra en Microsoft Entra ID (anteriormente Azure AD). Gobierna quién puede acceder a qué recursos, bajo qué condiciones y con qué privilegios. Una arquitectura IAM eficaz minimiza los privilegios permanentes, impone el acceso condicional y basado en riesgos, y adopta la autenticación moderna tanto para humanos como para cargas de trabajo, al tiempo que soporta escenarios de colaboración híbridos y externos.

Construcciones y ámbitos de identidad de Microsoft Entra

Tenants, usuarios y grupos
- Un tenant representa el límite de identidad y el tejido de confianza de su organización. Los usuarios pueden ser cuentas de miembro o de invitado (B2B). Utilice grupos de seguridad para la autorización y grupos de Microsoft 365 para las funciones de colaboración; prefiera los grupos dinámicos para reducir la gestión manual de la membresía.
Unidades Administrativas (AUs)
- Las AUs le permiten delegar roles de directorio sobre un subconjunto de usuarios/dispositivos (p. ej., el servicio de asistencia regional solo puede gestionar a los usuarios de Europa). Esto apoya el principio de privilegio mínimo para las tareas de directorio.
Roles de directorio y ámbitos de asignación de roles
- Los roles de directorio (p. ej., Global Administrator, User Administrator) se aplican a los recursos de Microsoft Entra. Limite el ámbito de los roles de directorio a una AU siempre que sea posible para restringir el radio de impacto. El rol de Global Administrator es necesario para configurar inicialmente Privileged Identity Management (PIM).
Ámbitos del control de acceso basado en roles de Azure (Azure RBAC)
- Azure RBAC gobierna el acceso a los recursos de Azure. Asigne roles en el ámbito de grupo de administración, suscripción, grupo de recursos o recurso. La herencia fluye hacia abajo; elija siempre el ámbito más reducido posible para reducir el exceso de privilegios.
Razonamiento operativo
- Separe los roles de directorio (Entra) de Azure RBAC (autorización de recursos). Utilice AUs y ámbitos de RBAC estrictos para limitar el alcance administrativo, reducir las oportunidades de movimiento lateral y simplificar las revisiones de acceso.

Control de acceso con Azure RBAC y privilegio mínimo

Roles integrados y privilegio mínimo
- Prefiera el rol integrado más específico que se ajuste a la tarea. Ejemplo: conceda acceso de solo extracción (pull) de imágenes de contenedor con AcrPull y acceso de carga/envío (push) con AcrPush, en lugar del rol amplio de Contributor. Para Key Vault, conceda el control administrativo a través de RBAC solo a los administradores del almacén, mientras utiliza políticas de acceso granulares para operaciones específicas de objetos como la gestión de certificados.
Herencia de asignación de roles
- Asigne en el ámbito más bajo posible. Las asignaciones a nivel de grupo de administración o suscripción se heredan en cascada; evite derechos amplios y heredados a menos que sea deliberado. Cuando necesite un RBAC coherente entre suscripciones, aplique asignaciones de roles consistentes a través de Azure Blueprints (o alternativas modernas de IaC) en lugar de la asignación manual con PIM.
Asignaciones de denegación (Deny)
- Las asignaciones de denegación bloquean explícitamente acciones independientemente de las asignaciones de permiso (allow) y suelen ser creadas por servicios de Azure como Azure Policy o Blueprints. Utilícelas para imponer barreras de protección (guardrails) no negociables (p. ej., impedir reglas de red pública en recursos sensibles).
Roles personalizados
- Cuando los roles integrados son demasiado amplios, defina roles personalizados solo con las acciones requeridas. Valide mediante pruebas de privilegio mínimo y revisiones de acceso.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

Razonamiento operativo
- La delimitación de ámbitos en RBAC y los roles personalizados reducen los derechos excesivos y la superficie de auditoría. Las asignaciones de denegación codifican restricciones de cumplimiento “duras” que no pueden ser eludidas por concesiones de permiso (“allow”) erróneamente amplias, mejorando la resiliencia de la postura de seguridad.

Acceso privilegiado, acceso condicional y protección de la identidad

Privileged Identity Management (PIM)
- Elegible vs. activo: las asignaciones elegibles no otorgan permisos permanentes; los usuarios deben activar JIT para volverse activos. Exija aprobación, justificación y MFA en la activación; establezca duraciones limitadas y requiera referencias de tickets para la trazabilidad. Comience por descubrir los roles privilegiados para comprender la exposición actual. Utilice revisiones de acceso periódicas, idealmente con los propietarios de recursos o grupos como revisores, para validar la necesidad continua.
Conditional Access (CA)
- Las asignaciones se dirigen a usuarios/grupos, identidades de cargas de trabajo, aplicaciones en la nube y acciones. Las condiciones incluyen el riesgo de inicio de sesión, la plataforma/estado del dispositivo, las ubicaciones, las aplicaciones cliente y los filtros para dispositivos y aplicaciones. Los controles de concesión pueden requerir MFA, dispositivos compatibles o unidos a Azure AD híbrido, políticas de protección de aplicaciones o términos de uso. Los controles de sesión restringen la frecuencia de inicio de sesión, las sesiones persistentes y las restricciones impuestas por la aplicación (p. ej., solo web para SharePoint). Utilice el modo de solo informe para validar de forma segura el impacto de la política antes de su aplicación. Mantenga exclusiones para las cuentas de emergencia (break-glass) y despliegues por fases para evitar bloqueos.
Identity Protection
- El riesgo de usuario refleja la probabilidad de que una cuenta esté comprometida; el riesgo de inicio de sesión refleja la probabilidad de que una sesión específica sea riesgosa. Configure políticas para requerir una remediación segura:
  - Usuarios con credenciales filtradas: trátelos como riesgo de usuario Alto; fuerce el restablecimiento de la contraseña y bloquee hasta que se remedie.
  - Inicios de sesión desde IPs con actividad sospechosa: trátelos al menos como riesgo de inicio de sesión Medio; solicite un desafío con MFA o bloquee para aplicaciones sensibles.
- Intégrelo con CA para adaptar la confianza en tiempo real. Realice un seguimiento del historial de riesgos y la remediación para medir la eficacia.
Razonamiento operativo
- PIM elimina los privilegios permanentes e impone una activación fuerte y auditable. CA e Identity Protection aplican el principio de confianza cero (zero trust) —verificando cada intento de acceso en función del usuario, dispositivo, sesión y riesgo— reduciendo el éxito del robo de credenciales y la repetición de tokens (token replay).

Identidades híbridas y de carga de trabajo

Opciones de identidad híbrida
- Sincronización de hash de contraseña (PHS): sincroniza los hashes de contraseña con Entra ID. Es simple y resiliente; no aplica las políticas de inicio de sesión locales en el momento de la autenticación.
- Autenticación de paso a través (PTA): valida las contraseñas contra los DC locales a través de conectores ligeros; aplica las políticas de contraseña y las restricciones de cuenta locales en tiempo real, sin AD FS.
- Federación (p. ej., AD FS): traslada la autenticación a un STS local. Úselo solo cuando se requiera para notificaciones complejas o escenarios heredados; introduce más servidores y sobrecarga operativa.
- Inicio de sesión único de conexión directa (Seamless SSO): inicia la sesión de los usuarios en dispositivos unidos a un dominio dentro de la red corporativa con un mínimo de solicitudes.
- Elección operativa: para aplicar las políticas de contraseña y las restricciones de cuenta locales mientras se minimizan los servidores, implemente PTA y Seamless SSO y también habilite PHS para la resiliencia/conmutación por error de escenarios que no dependen de PTA. La federación por sí sola aumenta la complejidad y no cumple el objetivo de “minimizar servidores”.
Autenticación de aplicaciones en Azure SQL desde dispositivos Windows unidos en modo híbrido
- Use la autenticación integrada de Active Directory para minimizar las solicitudes y aprovechar Kerberos/SSO cuando sea aplicable.
Identidades administradas y entidades de servicio
- Las identidades administradas (asignadas por el sistema o por el usuario) son la primera opción para las cargas de trabajo alojadas en Azure porque eliminan los secretos y rotan las credenciales automáticamente. Asigne RBAC de privilegio mínimo a la identidad en el ámbito del recurso.
- Las entidades de servicio respaldan los registros de aplicaciones; use credenciales de certificado en lugar de secretos de cliente y establezca el tiempo de vida más corto posible.
Federación de identidades de carga de trabajo
- Use la federación OIDC para permitir que las identidades de carga de trabajo externas (p. ej., GitHub Actions, Kubernetes) obtengan tokens para aplicaciones de Entra sin almacenar secretos. Defina las notificaciones de emisor, sujeto y audiencia con precisión para restringir quién puede intercambiar tokens.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

Acceso de AKS a ACR
- Otorgue el rol AcrPull a la identidad administrada del clúster de AKS en el registro de destino utilizando el flujo attach-acr, que automatiza el ámbito correcto y evita asignaciones incorrectas.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

Razonamiento operativo
- PTA+PHS+Seamless SSO aplica controles locales en tiempo real mientras mantiene la resiliencia de la nube. Las identidades administradas y la federación eliminan los secretos estáticos de las canalizaciones y del tiempo de ejecución, cerrando las vías de robo de credenciales de alta frecuencia.

Colaboración externa, métodos de autenticación y acceso a aplicaciones

Identidades externas y colaboración B2B
- Utilice cuentas de invitado B2B con configuraciones de acceso entre inquilinos, términos de uso y CA dirigido a invitados. Restrinja quién puede invitar y prefiera el acceso justo a tiempo (just-in-time) a través de la administración de derechos.
Administración de derechos y paquetes de acceso
- Agrupe grupos, aplicaciones y sitios de SharePoint en paquetes de acceso con políticas que definan quién puede solicitar (incluidos usuarios externos), flujos de aprobación, duraciones de asignación y revisiones de acceso. Para la selección de revisores, utilice los Propietarios del Grupo (Group Owners) para mantener la responsabilidad del negocio en los custodios de los recursos.
Métodos de autenticación y sin contraseña
- Estandarice el uso de métodos robustos: llaves de seguridad FIDO2, Windows Hello for Business e inicio de sesión desde el teléfono con Microsoft Authenticator. Utilice el registro combinado de información de seguridad (SSPR + MFA) y aplique la política de registro de MFA para todos los usuarios. Habilite SSPR con reescritura en el entorno local si es necesario; requiera métodos seguros y limítelos a factores gestionados por la empresa siempre que sea posible. Deshabilite los protocolos de autenticación heredados/básicos y bloquee la MFA débil solo por SMS cuando el riesgo lo justifique.
Microsoft Entra application proxy
- Publique aplicaciones web locales sin necesidad de abrir puertos de entrada en el firewall. Utilice grupos de conectores para alta disponibilidad (HA), preautenticación con Entra ID y aplique capas de CA, cumplimiento de dispositivos e Identity Protection para lograr una confianza cero (zero trust) en aplicaciones heredadas.
Seguridad en el registro de aplicaciones
- Requiera flujos de trabajo de consentimiento del administrador; limite quién puede crear aplicaciones; clasifique los permisos; prefiera los permisos de aplicación solo cuando no se requiera contexto de usuario y limite el alcance de las API al mínimo. Deshabilite la concesión implícita siempre que sea posible, requiera la asignación para las aplicaciones empresariales y prefiera certificados en lugar de secretos con rotación automatizada.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

Razonamiento operativo
- Los paquetes de acceso y el app proxy proporcionan un acceso externo gobernado y auditable. Los métodos robustos y sin contraseña aumentan la resistencia al phishing. Los controles estrictos en el registro de aplicaciones evitan el consentimiento demasiado amplio y reducen la posibilidad de suplantación de identidad de la aplicación.

Escenario de problema práctico

Adobe Inc. necesita conceder a un proveedor externo acceso administrativo temporal a un subconjunto de recursos de Azure y publicar una aplicación web heredada interna para el proveedor, aplicando una autenticación robusta y el principio de privilegio permanente cero.

Definir el alcance y modelar el acceso

Cree un grupo de recursos rg-vendor-ops y mueva únicamente los recursos necesarios a él. Asigne los roles mínimos de Azure RBAC (p. ej., Contributor en rg-vendor-ops; Reader en un grupo de recursos de diagnóstico).
Justificación: Limitar el alcance previene el movimiento lateral. La herencia de roles se confina a rg-vendor-ops, conteniendo el radio de impacto.

Gobernar la identidad y la activación con PIM

Haga que los administradores del proveedor sean elegibles, no permanentes, para los roles requeridos; exija aprobación, ID de ticket, MFA en la activación y limite la activación a 4 horas. Comience ejecutando la función de PIM “Descubrir roles con privilegios” (Discover privileged roles) para establecer una línea base de las asignaciones existentes.
Justificación: Las asignaciones elegibles eliminan el privilegio permanente. La aprobación y la MFA imponen un acceso JIT alineado con las ventanas de soporte y proporcionan un control auditable.

Aplicar políticas de acceso condicional y de riesgo

Cree una política de CA dirigida al grupo del proveedor y al portal de Azure y las API de ARM, que requiera MFA, un dispositivo compatible/unido a un entorno híbrido y que bloquee el acceso desde ubicaciones de riesgo. Habilítela primero en modo de solo informe (report-only); luego, aplíquela. Configure Identity Protection: bloquee el riesgo de usuario Alto (credenciales filtradas) hasta el restablecimiento de la contraseña; requiera MFA para el riesgo de inicio de sesión Medio (IP sospechosa).
Justificación: El CA vincula el acceso a la confianza del dispositivo y al riesgo en tiempo real. El modo de solo informe previene interrupciones durante la implementación. Las políticas de riesgo remedian automáticamente las sesiones y cuentas comprometidas.

Publicar la aplicación heredada con Microsoft Entra application proxy

Despliegue dos conectores en subredes separadas expuestas al proveedor para alta disponibilidad (HA). Configure la preautenticación con Entra ID, requiera la asignación a la aplicación empresarial y aplique la misma política de CA. Utilice paquetes de acceso para conceder a los usuarios del proveedor acceso con límite de tiempo tanto a la aplicación empresarial como a los roles del grupo de recursos; establezca a los Propietarios del Grupo (Group Owners) como revisores.
Justificación: El app proxy elimina la exposición de entrada y centraliza la autenticación. La administración de derechos estandariza la incorporación y desvinculación (onboarding/offboarding) y garantiza revisiones periódicas por parte de los propietarios de los recursos.

Proteger las credenciales de la carga de trabajo y de la aplicación

Reemplace cualquier secreto de cliente por credenciales de certificado para las entidades de servicio (service principals); para CI/CD, utilice la federación de identidades de carga de trabajo en lugar de almacenar secretos. Para las cargas de trabajo de AKS que necesiten imágenes, adjunte el ACR al clúster para conceder el rol AcrPull a la identidad administrada.
Justificación: Eliminar secretos estáticos cierra un vector de ataque común; la federación y las identidades administradas proporcionan un acceso con privilegios mínimos y rotación automática.

Proteger las cuentas de emergencia (break-glass) y monitorizar

Excluya dos cuentas de emergencia de las políticas de CA, pero protéjalas con contraseñas largas y aleatorias almacenadas fuera de línea. Habilite revisiones de acceso trimestrales y exporte los registros de PIM y CA a un espacio de trabajo de Log Analytics con alertas sobre activaciones anómalas.
Justificación: Las cuentas de emergencia previenen el bloqueo del inquilino a la vez que son operacionalmente seguras. La monitorización continua detecta el uso indebido rápidamente, manteniendo el cumplimiento y la preparación para la respuesta a incidentes.

Todos los dominios · Arquitectura de seguridad de red →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →