AZ-305

Deep Dive

D1 · Identidad, Gobernanza y Monitoreo

Diseño de Identidad (Entra ID)

El AZ-305 no pregunta "qué es Entra ID" — pregunta cuándo y cómo diseñar la solución de identidad: cuántos tenants, qué método de autenticación híbrida, cuándo usar B2B vs B2C, y qué tipo de identidad asignar a cada workload. Aquí dominamos esos criterios de decisión.

Diseño de tenants de Entra ID

Interactivo

🏛️Jerarquía de gobernanza Azure — herencia de Policies y RBAC

Policies y RBAC asignados en niveles superiores se heredan hacia abajo. Pasa el cursor sobre un nodo para ver su cadena de herencia completa.

Ancestro (hereda DE aquí)Descendiente (hereda ESTO)
ROOT MGMGMT GROUPSSUBSCRIPTIONSRESOURCE GRPRESOURCESDeny: unapproved regionsRequire tag: CostCenterOwner: ops-team@corp.comIcon-general-11Root MGTenant IDIcon-general-11MG-ProductionProd workloadsIcon-general-11MG-DevelopmentDev/Test workloadsIcon-general-2Sub-Prod-01Pay-As-You-GoIcon-general-2Sub-Prod-02EAIcon-general-2Sub-DevDev/Test pricingIcon-general-7rg-web-prodwesteuropeIcon-general-7rg-data-prodwesteuropeIcon-general-7rg-networkingwesteuropeIcon-general-7rg-dev-sandboxnortheuropeIcon-compute-21VM-web-01Standard_D2s_v3Icon-compute-21SQL DatabaseGeneral PurposeIcon-compute-21VNet-prod10.0.0.0/16Icon-compute-21VM-dev-01Standard_B2s

⬇️ Herencia descendente

RBAC y Policies en Root MG aplican a TODOS los niveles. Un hijo no puede anular lo que el padre impone con un efecto Deny.

🔒 Scope de asignación

Asignar en el nivel más alto posible reduce el overhead de gestión. 1 policy en Root MG = cobertura de todo el tenant.

🏷️ Tags NO heredan auto

A diferencia de RBAC/Policy, tags en un RG NO se propagan a los recursos hijos. Se necesita Azure Policy con efecto modify.

Un tenant de Microsoft Entra ID es el límite de identidad y administración de la organización. La regla de diseño por defecto es un solo tenant por organización — múltiples tenants multiplican la complejidad de licencias, Conditional Access, B2B y administración.

Para el examen: un tenant puede tener múltiples suscripciones, pero cada suscripción confía en exactamente un tenant. Mover una suscripción de tenant rompe RBAC, managed identities y Key Vault access policies.

Cuándo un solo tenant (default)

  • • Una organización con una fuerza laboral unificada
  • • Quieres políticas de Conditional Access y PIM centralizadas
  • • Licencias (P1/P2) aplicadas una sola vez
  • • Colaboración interna sin fricciones de invitados
  • • Separación de ambientes se logra con suscripciones + management groups, no con tenants

Cuándo múltiples tenants (excepción)

  • • Aislamiento regulatorio total (filiales con jurisdicciones legales distintas)
  • • Fusiones y adquisiciones aún no integradas
  • • Tenant de sandbox para probar configuraciones de Entra ID que no se pueden aislar de otra forma
  • • ISVs que necesitan un tenant separado para sus apps multi-cliente

Identidad híbrida — métodos de autenticación

🔐Árbol de decisión — Método de autenticación híbrida

PHS · PTA · ADFS + herramienta de sincronización

Interactivo

Pregunta 1

¿Existe un requisito de seguridad o compliance que prohíba almacenar hashes de contraseña en la nube de Microsoft?

💡 PHS almacena un hash del hash en Entra ID. Si la política lo permite (mayoría de casos) → PHS. Si dicen "la contraseña no puede salir del datacenter ni en forma de hash" → continúa.

Cuando existe Active Directory on-premises, Entra Connect (o Cloud Sync) sincroniza identidades a la nube. La decisión clave del AZ-305 es dónde se valida la contraseña. Tres opciones:

MétodoDónde se validaInfraestructura extraCuándo elegirlo
Password Hash Sync (PHS)En la nube — Entra ID valida el hash sincronizadoNinguna (solo Entra Connect)Default recomendado. Más simple, funciona aunque on-prem esté caído, habilita leaked credential detection.
Pass-through Auth (PTA)On-premises — agentes PTA validan contra los DCs en tiempo real2-3 agentes PTA en servidores on-premPolítica de seguridad prohíbe almacenar hashes en la nube, pero quieres evitar la complejidad de ADFS. Login falla si on-prem cae (mitigar con PHS como respaldo).
Federación (ADFS)On-premises — granja ADFS emite tokensGranja ADFS + WAP + certificados (alta complejidad)Solo si necesitas: smartcards/MFA de terceros on-prem, o requisito de que la autenticación nunca toque la nube. Microsoft lo desaconseja para casos nuevos.

Entra Connect Sync vs Cloud Sync

  • Connect Sync: servidor dedicado on-prem, soporta PHS/PTA/federación, filtros avanzados, device writeback
  • Cloud Sync: agente ligero, configuración en el portal, soporta múltiples bosques AD desconectados, alta disponibilidad con múltiples agentes
  • • Cloud Sync NO soporta: device writeback, Exchange hybrid writeback completo, filtrado por atributo complejo
  • • Pueden coexistir: Connect Sync para el bosque principal, Cloud Sync para bosques adquiridos

Entra Domain Services (cuándo)

Para aplicaciones legacy que requieren Kerberos/NTLM/LDAP y se migran a Azure sin poder reescribirse. Entra DS provee un dominio administrado (sin DCs que gestionar) sincronizado desde Entra ID.

  • • No es extensión de tu AD on-prem — es un dominio nuevo y administrado
  • • Sin trust saliente a tu AD (solo forest trust entrante en SKUs altos)
  • • Alternativa: levantar DCs en VMs de Azure (control total, pero tú los gestionas)
Icon-identity-235

Identidades externas: B2B y B2C

Entra ID B2B (colaboración)

  • Invitados externos (partners, proveedores, consultores) en TU tenant
  • El invitado usa SUS credenciales — su organización gestiona su identidad
  • Aparece como objeto usuario tipo "Guest" en tu directorio
  • Se le aplican tus políticas de Conditional Access y access reviews
  • Escenario típico: dar a un partner acceso a un recurso de Azure o app interna

Entra External ID / B2C (clientes)

  • Tenant SEPARADO para identidades de consumidores de tu app pública
  • Login con email, redes sociales (Google, Facebook) o cuentas locales
  • User journeys personalizables (branding, MFA, registro self-service)
  • Escala a millones de usuarios; los clientes NO ven tu directorio corporativo
  • Escenario típico: app de retail con login social para clientes finales

Regla de oro para el examen

Partners/empleados de otra empresa que colaboran contigo → B2B (mismo tenant, usuarios guest). Clientes/consumidores de tu producto → B2C / External ID (tenant separado, login social). Si la pregunta menciona "social identity providers" o "millones de clientes", la respuesta es B2C.

Identidades de servicio y workload

TipoQuién gestiona credencialesCuándo usarla
Managed Identity (system-assigned)Azure — sin secretos, ciclo de vida atado al recursoDefault para recursos Azure que acceden a otros servicios Azure (VM → Key Vault, App Service → SQL). Se elimina con el recurso.
Managed Identity (user-assigned)Azure — sin secretos, ciclo de vida independienteMúltiples recursos comparten la misma identidad (fleet de VMs, slots de App Service), o pre-aprovisionas permisos antes de crear recursos.
Service PrincipalTú — secreto o certificado que rota manualmenteApps fuera de Azure (CI/CD externo, on-premises) o multi-tenant. Última opción si Managed Identity no es viable.
Workload Identity FederationNadie — federación OIDC sin secretosGitHub Actions, Kubernetes externo u otro IdP que asume un service principal SIN secretos almacenados. Preferido sobre service principal + secreto.

Principio de diseño

Jerarquía de preferencia: Managed Identity > Workload Identity Federation > Service Principal con certificado > Service Principal con secreto. Si el escenario dice "eliminar secretos almacenados" o "sin gestión de credenciales", la respuesta casi siempre es Managed Identity.

Tabla de decisión arquitectónica

El escenario dice...Diseña con...
Mínima infraestructura on-prem, login resiliente aunque caiga el datacenterPassword Hash Sync
Las contraseñas (ni sus hashes) no pueden salir de on-premisesPass-through Authentication (+ PHS como fallback de DR si lo permiten)
MFA con smartcards on-premises / control total del flujo de tokensFederación con ADFS
App legacy con Kerberos/LDAP migrada a Azure, sin gestionar DCsEntra Domain Services
Partners externos acceden a apps internas con sus propias credencialesEntra B2B (guests + access reviews)
App de consumidores con login social a escala de millonesEntra External ID (B2C)
App Service necesita leer secretos de Key Vault sin credencialesManaged Identity (system-assigned)
Pipeline de GitHub Actions despliega a Azure sin secretos guardadosWorkload Identity Federation
Sincronizar varios bosques AD desconectados con agentes ligerosEntra Cloud Sync

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa con AD on-premises migra a Azure. Requisitos: (1) los usuarios deben poder iniciar sesión en apps cloud aunque el datacenter on-premises esté caído, (2) mínima infraestructura adicional, (3) detección de credenciales filtradas. ¿Qué método de autenticación híbrida recomiendas?

Inicia sesión para llevar tu progreso.