Microsoft AZ-500: Seguridad de computación, contenedores y endpoints — 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

Esta sección proporciona una referencia operativa para proteger la computación, los contenedores y los endpoints de Azure en IaaS y PaaS. Se centra en cómo configurar las protecciones, por qué son importantes y cómo aplicarlas de forma coherente con los controles nativos de Azure.

Seguridad de la computación y los endpoints

Las protecciones de la plataforma de VM de Azure y las opciones de cifrado son fundamentales.

Secure Boot, vTPM y Trusted Launch: Trusted Launch refuerza las VM de Gen2 al habilitar UEFI Secure Boot y un TPM virtual (vTPM). Secure Boot previene los bootloaders/rootkits no firmados. El vTPM proporciona un almacén resistente a la manipulación para las claves (por ejemplo, BitLocker) y admite el arranque medido para que la plataforma pueda dar fe de la cadena de arranque del sistema operativo. Operativamente, habilite Trusted Launch en el momento de la implementación y aplíquelo con directivas para garantizar que todas las nuevas VM obtengan comprobaciones de integridad basadas en hardware sin que los administradores necesiten gestionar configuraciones estáticas de BIOS/UEFI.
VM confidenciales: Utilice series de VM confidenciales respaldadas por AMD SEV-SNP o Intel TDX (por ejemplo, DCasv5/DCadsv5) para cifrar la memoria de la VM y proporcionar atestación. Esto protege las cargas de trabajo de un host/hipervisor malicioso y de ataques de canal lateral. Operativamente, seleccione SKUs confidenciales para escenarios de datos en uso altamente sensibles, integre la atestación en su canal de implementación y prefiera discos de SO efímeros cuando necesite reimplementaciones rápidas sin persistencia de datos.
Opciones de cifrado de disco:
- Azure Disk Encryption (ADE): BitLocker (Windows) o DM-Crypt (Linux) dentro del invitado, con claves en Key Vault (BEK/KEK). Útil cuando se necesitan dominios criptográficos basados en el invitado, comprobaciones de cumplimiento dentro del SO o para aprovechar BitLocker vinculado al vTPM. Requiere un agente y operaciones de ciclo de vida para la salud de la extensión.
- Server-Side Encryption (SSE) con claves gestionadas por el cliente (CMK): Cifrado a nivel de almacenamiento para discos gestionados utilizando claves en Key Vault o Managed HSM. Sin agentes en el invitado, cobertura completa de la plataforma (discos, instantáneas, imágenes), sobrecarga operativa mínima. Es la opción predeterminada recomendada para la mayoría de los casos de uso; combínelo con Trusted Launch o VM confidenciales para una defensa en profundidad más sólida.
Microsoft Defender for Servers:
- Plan 1: Microsoft Defender for Endpoint (MDE) para EDR/protección de endpoints en servidores. Elija este plan si ya cuenta con herramientas maduras de gestión de vulnerabilidades y configuración y necesita principalmente EDR.
- Plan 2: Añade evaluación de vulnerabilidades basada en agente o sin agente, acceso a VM justo a tiempo (JIT), controles de aplicación adaptables, fortalecimiento de red adaptable y supervisión de la integridad de los archivos (FIM). Elija este plan si desea una reducción de la exposición impulsada por la plataforma y una gobernanza en acción sin tener que unir múltiples herramientas.
- Protección de endpoints: Despliegue MDE a través de extensiones de VM o Arc para servidores que no son de Azure para estandarizar la telemetría, la protección contra manipulaciones y los playbooks de respuesta en entornos híbridos.
- Evaluación de vulnerabilidades: Utilice la señal de Threat & Vulnerability Management de MDE o el escáner integrado (p. ej., Qualys) para inventariar CVEs, priorizar por explotabilidad y orquestar la aplicación de parches. Operativamente, establezca primero una línea base para los servidores críticos expuestos a Internet; vincule la remediación a las ventanas de cambio.
- Supervisión de la integridad de los archivos: Realice un seguimiento de los cambios en archivos/claves de registro sensibles para detectar manipulaciones sospechosas y cumplir con los requisitos de cumplimiento. Configure rutas de vigilancia con un alcance definido para evitar el ruido y reenvíe las alertas a su SIEM.
Reducción de la exposición con Defender for Cloud:
- Acceso a VM Just-in-Time: Cierra el RDP/SSH de entrada. Los administradores solicitan acceso por tiempo limitado; Defender abre la regla del NSG o de Azure Firewall y registra la actividad. El resultado es una superficie de ataque drásticamente reducida con excepciones auditables.
- Controles de aplicación adaptables: Aprende los procesos normales y crea listas de aplicaciones permitidas (AppLocker en Windows, reglas de auditoría para Linux). Esto bloquea binarios y scripts no aprobados, lo que es particularmente efectivo contra ataques sin archivos o LOLBin.
- Fortalecimiento de red adaptable: Utiliza análisis de tráfico e inteligencia de amenazas para proponer el endurecimiento de las reglas de NSG. Adopte una cadencia de revisión y aplicación para restringir iterativamente la exposición mientras se evitan interrupciones del servicio.
- Guest Configuration: Azure Policy para auditoría/remediación dentro del invitado (Windows y Linux) a través de un agente o Azure Arc. Úselo para aplicar líneas base del SO, políticas de contraseñas y configuraciones alineadas con CIS cuando necesite un estado de configuración demostrable, no solo una postura de la plataforma.

Computación PaaS: App Service y Functions

Los patrones seguros por defecto reducen la superficie de ataque de PaaS.

Azure App Service:
- Autenticación/Autorización: Habilite la autenticación de App Service para delegar la autenticación a Microsoft Entra ID u otros proveedores. Use Easy Auth para flujos estándar de OIDC/OAuth2, y luego exija el inicio de sesión en todas las rutas para eliminar la exposición no autenticada.
- Restricciones de acceso: Permita o deniegue el tráfico por IP/CIDR, etiquetas de servicio o tráfico de red virtual a través de puntos de conexión privados. Mantenga reglas separadas para el endpoint scm y el endpoint de la aplicación para proteger su plano de implementación de forma independiente.
- Puntos de conexión privados: Exponga la aplicación a través de una IP privada en su VNet y, opcionalmente, deshabilite el acceso público. Utilice zonas de DNS privadas y restrinja las dependencias de salida con VNet Integration y un firewall de egreso central.
- Identidades administradas: Prefiera identidades asignadas por el sistema o por el usuario para acceder a Key Vault, Storage y otros servicios. Esto elimina los secretos incrustados y permite la asignación centralizada de roles y la rotación de claves.
Azure Functions:
- Gestión de claves: Las Functions utilizan claves de función, claves de host y la clave maestra. Rote las claves regularmente y almacene las claves consumidas externamente en Key Vault, o reemplace las claves con flujos OAuth adecuados si es factible.
- Integración de red: Use puntos de conexión privados para el acceso de entrada a la Function app y VNet Integration regional para los controles de salida. Restrinja la cuenta de Storage utilizada por las Functions solo a redes seleccionadas y agregue el punto de conexión privado de la Function a las redes permitidas.
- Identidades: Use identidades administradas para la autenticación de servicio a servicio en lugar de claves o cadenas de conexión. Impulse el mínimo privilegio con asignaciones de RBAC de alcance limitado.
- Controles de implementación: Fuerce el uso exclusivo de FTPS, deshabilite la autenticación básica para el sitio scm, restrinja las IP de scm y use Run From Package para garantizar implementaciones inmutables. Integre CI/CD con workload identity federation para eliminar los secretos de larga duración.

Seguridad de Kubernetes y Contenedores

Fortalezca los clústeres y las cadenas de suministro de extremo a extremo.

Identidad y autorización en AKS:
- Integración con Microsoft Entra: Habilite AAD administrado para AKS para autenticar kubectl usando tokens y grupos de Entra. Esto centraliza el ciclo de vida del usuario y el MFA/Acceso Condicional.
- RBAC de Kubernetes: Asigne usuarios/grupos de Entra a roles y role bindings de Kubernetes para un mínimo privilegio a nivel de namespace.
- Azure RBAC para Kubernetes: Use roles integrados (p. ej., Azure Kubernetes Service RBAC Viewer/Admin) cuando desee que Azure RBAC autorice directamente las acciones de la API de Kubernetes. Esto unifica la autorización y la auditoría con el plano de control de Azure.
Redes y privacidad en AKS:
- Políticas de red: Aplique políticas para el tráfico de pod a pod y de pod a servicio con Azure NPM o Calico. Deniegue por defecto y permita explícitamente el egreso requerido; la política como código previene el movimiento lateral.
- Clústeres privados: Haga que el servidor de la API sea privado, accesible solo a través de puntos de conexión privados. Combínelo con Azure Bastion/Private Link y una estrategia de egreso con firewall (NAT Gateway + UDRs) para mantener el plano de administración fuera de internet.
Seguridad de Container Registry (ACR):
- RBAC: Asigne AcrPull a las cargas de trabajo que solo necesitan descargar imágenes y AcrPush a los pipelines de compilación; evite el rol sobreprivilegiado de Propietario (Owner). AcrPull y AcrPush se alinean con el principio de mínimo privilegio.
- Confianza y firma de contenido: Firme las imágenes con cosign y exija la verificación con control de admisión (Gatekeeper + Ratify) antes de que los pods se inicien. Esto protege contra imágenes manipuladas.
- Escaneo de imágenes: Habilite Microsoft Defender for Cloud para escanear ACR al hacer push/importar y de forma programada. Bloquee la implementación de imágenes con CVEs críticos sin parches utilizando políticas de admisión.
- Patrón de cuarentena: Dirija las imágenes nuevas a un repositorio o etiqueta en cuarentena, ejecute escaneos y verificaciones de políticas, y luego promuévalas reetiquetándolas tras la aprobación.
- Acceso privado: Deshabilite el acceso a la red pública y use puntos de conexión privados y reglas de firewall del registro. Vincule AKS a ACR utilizando una asignación de rol a nivel de recurso en lugar de un rol de directorio.

Ejemplo breve para vincular ACR a AKS usando la identidad administrada del clúster:

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

Microsoft Defender for Containers: Despliega un sensor en el plano de datos de AKS, monitorea los registros de auditoría de Kubernetes y las señales en tiempo de ejecución, y los correlaciona con los resultados del escaneo de imágenes. Detecta ejecuciones sospechosas (execs) en pods, criptominería, dashboards expuestos y operaciones de riesgo en el plano de control. Habilite el aprovisionamiento automático y conecte las alertas a su SIEM/SOAR para su clasificación (triage).

Gobernanza, Políticas y Aplicación

Un control consistente requiere políticas en el momento del despliegue y en tiempo de ejecución.

Azure Policy para computación y discos:
- Denegar la creación de VMs sin trusted launch o sin SSE con CMK.
- Forzar el uso de extensiones de VM para la protección de endpoints usando DeployIfNotExists para autoinstalar los agentes requeridos.
- Auditar el cumplimiento de la configuración del sistema operativo invitado; remediar las desviaciones (drift) de forma programada.

Fragmento de política corto para desplegar una extensión de VM requerida si falta:

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

Controles de admisión de Kubernetes:
- El add-on de Azure Policy para AKS utiliza Gatekeeper (OPA) para evaluar las especificaciones de los pods en el momento de la admisión. Aplica reglas como “solo descargar desde ACR”, “no permitir contenedores privilegiados” y “requerir firmas de imagen”.
- Mantener iniciativas separadas para la línea base (indispensables) y reforzadas (para namespaces sensibles) para permitir un fortalecimiento progresivo.

Restricción corta de Gatekeeper para limitar los registros:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

Cadencia operacional:
- Detectar: Usar las recomendaciones de Defender for Cloud y las alertas de las cargas de trabajo como señales de desviación (drift) y amenazas.
- Decidir: Clasificar (triage) por impacto en el negocio y explotabilidad; asignar propietarios a través de etiquetas (tags).
- Aplicar: Convertir las pruebas piloto exitosas en políticas de denegación (deny policies) o restricciones de admisión; medir los intentos bloqueados para detectar shadow IT.

Escenario de Problema Práctico

Adobe Inc. está migrando un microservicio de pagos a Azure. Los requisitos de seguridad exigen cero exposición pública, solo imágenes firmadas y acceso de administrador por tiempo limitado a las VMs heredadas durante la transición.

Hacer que el plano de control de AKS sea privado y bloquear el tráfico de salida (egress).

Justificación: Un servidor de API de AKS privado elimina el plano de gestión de internet. Un NAT Gateway junto con un Azure Firewall con reglas de salida explícitas asegura que las cargas de trabajo solo alcancen los endpoints aprobados (ACR, Key Vault, repositorios de paquetes de Microsoft).

Forzar el uso de imágenes firmadas y restringir los registros.

Justificación: Configurar Gatekeeper con restricciones que solo permitan imágenes de myacr.azurecr.io y requieran firmas cosign validadas por Ratify. Esto evita que se ejecuten imágenes manipuladas o no confiables, cerrando un riesgo importante en la cadena de suministro.

Asegurar ACR con private endpoints y roles de mínimo privilegio.

Justificación: Deshabilitar el acceso de red público y exponer ACR a través de un private endpoint en la VNet de AKS. Otorgar a la identidad administrada de AKS solo el rol AcrPull; otorgar al pipeline de compilación el rol AcrPush. Esto sigue el principio de mínimo privilegio y elimina la dependencia de internet.

Habilitar Defender for Containers y el escaneo de imágenes de ACR.

Justificación: El escaneo continuo de imágenes al subirlas (on push) y la detección de amenazas en tiempo de ejecución proporcionan una cobertura por capas. Las alertas unifican configuraciones incorrectas, vulnerabilidades conocidas y comportamientos sospechosos para una respuesta rápida.

Proteger las herramientas de administración basadas en App Service con autenticación y acceso privado.

Justificación: Usar App Service Authentication con Microsoft Entra ID para requerir MFA y Acceso Condicional. Crear un private endpoint para la aplicación de administración y restringir el acceso scm por separado. Las identidades administradas eliminan los secretos para el acceso a Key Vault.

Usar el acceso Just-in-Time (JIT) a VMs para los hosts heredados durante la transición.

Justificación: JIT cierra los puertos RDP/SSH por defecto y solo los abre bajo solicitudes aprobadas por duraciones limitadas. Esto acota estrictamente las ventanas de exposición mientras se preserva el acceso de emergencia.

Estandarizar las opciones de cifrado: SSE con CMK para discos; Trusted Launch para VMs.

Justificación: SSE con CMK minimiza la carga operativa y centraliza el ciclo de vida de las claves en Key Vault, mientras que Trusted Launch/vTPM añade integridad en el arranque y protección de claves. ADE se reserva solo para casos donde se requiere contractualmente evidencia de un dominio criptográfico basado en el sistema operativo invitado.

Aplicar Azure Policy y controles de admisión como barreras de protección (guardrails).

Justificación: Las iniciativas de Azure Policy fuerzan el uso de trusted launch, extensiones de VM requeridas y deniegan el acceso público a ACR/Function. Las restricciones de Gatekeeper implementan verificaciones de admisión en tiempo de ejecución para AKS. Juntos aseguran que las configuraciones se mantengan en cumplimiento a medida que los equipos iteran.

Validar y operar con una gobernanza continua.

Justificación: Conectar las alertas de Defender for Cloud y MDE al SIEM de Adobe, medir el efecto de las políticas (deny vs. audit) y revisar las excepciones mensualmente. Esto transforma los controles puntuales en un modelo operativo de seguridad duradero.

← Arquitectura de seguridad de red · Todos los dominios · Seguridad de datos →

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