Microsoft AZ-500: Seguridad de aplicaciones y DevSecOps — 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 seguridad de aplicaciones y DevSecOps en Azure se centran en prevenir el uso indebido de identidades, proteger el ingreso (ingress) y las API, desplazar la seguridad a la izquierda (shift left) en los pipelines, asegurar los secretos en reposo y en tránsito, y aplicar una gobernanza de lanzamientos robusta. Los diseños eficaces eliminan los secretos de larga duración, utilizan el mínimo privilegio, validan a cada llamador e institucionalizan la detección y remediación continuas en el código, las dependencias, la infraestructura y el tiempo de ejecución.

Identidad segura de la aplicación, protección del ingreso y de la API

La seguridad de la identidad de la aplicación en Microsoft Entra ID (Azure AD) comienza con un registro de aplicación (app registration) bien definido y el flujo OAuth 2.0 correcto:

Los permisos delegados se aplican cuando un usuario ha iniciado sesión y el consentimiento puede restringirse únicamente a aplicaciones de editores verificados o a ámbitos (scopes) aprobados por el administrador. Los permisos de aplicación (solo de aplicación) siempre requieren el consentimiento del administrador porque autorizan demonios o servicios en segundo plano que actúan sin un usuario.
Aplique el principio de mínimo privilegio concediendo solo los ámbitos (scopes) o roles de aplicación mínimos necesarios y exigiendo la revisión del administrador para las solicitudes de consentimiento. Deshabilite el consentimiento del usuario final o permítalo solo para editores verificados de bajo riesgo para reducir el phishing de consentimiento.
Prefiera las credenciales de certificado o las identidades federadas en lugar de los secretos de cliente. Los certificados ofrecen una mayor garantía y una rotación predecible. Configure tiempos de vida cortos y automatice la rotación. Bloquee los flujos de cliente público a menos que sea necesario.
Para los servicios de Azure, utilice identidades administradas (managed identities) en lugar de secretos de aplicación. Asigne roles del plano de datos como Key Vault Secrets User o Storage Blob Data Reader, y restrinja el acceso a la red utilizando Private Endpoints cuando sea aplicable.

Application Gateway WAF v2 y Azure Front Door WAF protegen el ingreso público contra las amenazas del Top 10 de OWASP:

Habilite el último Core Rule Set de OWASP administrado por Microsoft y ejecútelo en modo de prevención (Prevention mode) después de ajustarlo. Utilice la puntuación de anomalías (anomaly scoring) inicialmente para reducir los falsos positivos durante el aprendizaje.
Configure reglas personalizadas para geofencing, bloqueos por reputación de IP, aplicación de encabezados y límites de tamaño de solicitud. Para Front Door, añada reglas de límite de velocidad (rate-limit) por IP de cliente para mitigar el credential stuffing y los ataques DoS básicos de capa 7.
Termine TLS con conjuntos de cifrado (cipher suites) y políticas robustas; utilice TLS de extremo a extremo (end-to-end) hasta el origen. Para escenarios que requieran mTLS, configure la validación de certificados de cliente en los listeners de Application Gateway.
Asocie las políticas de WAF a los listeners/rutas con precisión; utilice exclusiones de reglas solo cuando comprenda completamente el falso positivo. Transmita los registros del WAF a Log Analytics para la ingeniería de detección y la respuesta a incidentes.

API Management (APIM) aplica una postura de seguridad multicapa:

Valide los tokens OAuth en el gateway con comprobaciones estrictas de emisor (issuer), audiencia (audience) y ámbito (scope). Exija HTTPS en todas partes y aplique mTLS cuando el límite de confianza del cliente lo requiera.
Combine las claves de suscripción con OAuth para una defensa en profundidad y para limitar la identidad (throttling). Utilice claves de suscripción a nivel de producto para segmentar a los consumidores y rotar las claves sin afectar a otros.
Aplique límites de velocidad (rate limiting) y cuotas con granularidad por consumidor, por ámbito o por suscripción. Utilice el filtrado de IP para incluir en la lista blanca (allowlist) las redes de socios cuando sea apropiado.
Proteja los servicios de backend utilizando TLS mutuo o identidades administradas. Almacene los secretos como valores con nombre (Named Values) respaldados por referencias de Key Vault para evitar el texto plano en la configuración.

Ejemplo de política de APIM para la aplicación de ámbitos JWT y la limitación de velocidad (throttling):

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Fortalecimiento del pipeline de DevSecOps y Defender for DevOps

Azure DevOps y GitHub Actions deben autenticarse en Azure sin secretos de larga duración:

Utilice la federación de identidades de carga de trabajo (OIDC) para las conexiones de servicio (service connections). Cree un registro de aplicación/entidad de servicio (app registration/service principal) en Entra ID, y luego añada una credencial federada que vincule el repositorio, la rama y el flujo de trabajo/entorno a la identidad. Esto genera tokens de corta duración sin secretos almacenados y permite definir el ámbito de mínimo privilegio a través de Azure RBAC.
Asegure los permisos del pipeline: exija aprobaciones para usar las conexiones de servicio, restrinja el pipeline a ramas protegidas y deshabilite “Permitir que los scripts accedan al token de OAuth” a menos que sea necesario. Utilice grupos de variables y secretos con enmascaramiento; no permita el eco de secretos a través de comandos de registro. En GitHub, prefiera los secretos de entorno y organización sobre los secretos de repositorio para un control centralizado y utilice la configuración para “prevenir secretos en los registros” en los ejecutores alojados (hosted runners) cuando sea aplicable.
Aplique reglas de protección de entorno: revisores requeridos, comprobaciones (p. ej., tickets de gestión de cambios, aprobación de pruebas) y aprobaciones basadas en tiempo.

Crear una credencial federada con la CLI de Azure (ejemplo de GitHub OIDC):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps se integra con Azure Repos y GitHub para exponer:

Hallazgos de seguridad en el código (SAST) en lenguajes comunes; las anotaciones en las pull requests resaltan nuevos problemas para prevenir regresiones.
Riesgo en las dependencias (SCA) utilizando inteligencia de vulnerabilidades para bibliotecas de código abierto (OSS) con guías de remediación y versiones corregidas.
Detección de exposición de secretos y rotaciones recomendadas para tokens/claves filtrados.
Configuraciones incorrectas de infraestructura como código (Infrastructure-as-Code) en ARM/Bicep/Terraform (p. ej., almacenamiento público, NSGs permisivos) con gobernanza basada en políticas y seguimiento de desviaciones (drift tracking). Los hallazgos se consolidan en Defender for Cloud con el contexto del repositorio y del pipeline para su priorización. Bloquee los lanzamientos (gate releases) basándose en umbrales de severidad para detener despliegues inseguros.

Gestión de secretos e integración con la plataforma

Key Vault proporciona una gestión centralizada de secretos, claves y certificados con controles exhaustivos:

Aplicar la protección contra purga y la eliminación temporal (soft delete) para prevenir la pérdida destructiva. Preferir RBAC sobre las directivas de acceso para una autorización unificada; habilitar Private Endpoints y deshabilitar el acceso desde la red pública siempre que sea posible; habilitar el registro en un área de trabajo segura.
App Service y Functions utilizan referencias de Key Vault en la configuración de la aplicación con identidades administradas; los secretos se rotan de forma transparente sin necesidad de volver a implementar.
AKS recupera los secretos en tiempo de ejecución a través del Secrets Store CSI Driver con el proveedor de Azure Key Vault, autenticado mediante Azure AD Workload Identity (recomendado). Evite colocar secretos en texto plano en los objetos Secret de Kubernetes.

Ejemplo de referencia de Key Vault en App Service:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

SecretProviderClass de AKS (abreviado):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Las canalizaciones (pipelines) deben obtener los secretos en tiempo de ejecución del trabajo:

Azure DevOps: tarea de Key Vault con una conexión de servicio respaldada por una identidad administrada; restrinja la descarga de secretos al menor número de fases posible.
GitHub Actions: azure/login para OIDC y azure/keyvault para extraer solo los nombres requeridos.

SDLC seguro, contenedores, registro y lanzamientos

Las prácticas de SDLC seguro reducen el riesgo antes del despliegue:

El modelado de amenazas en una fase temprana con STRIDE o un equivalente garantiza que la autenticación, la autorización y los flujos de datos se validen explícitamente. Actualice los modelos a medida que evoluciona la arquitectura.
SAST se ejecuta en cada PR; interrumpa las compilaciones por problemas de alta gravedad con una propiedad clara. DAST se ejecuta después del despliegue en un slot o entorno de staging con datos de prueba seguros.
SCA supervisa continuamente los paquetes; exige versiones fijas y el cumplimiento de licencias.
Revisión de código rigurosa con políticas de rama: revisores requeridos, elementos de trabajo vinculados, validación de compilación y commits firmados.

La seguridad de las imágenes de contenedor es fundamental para la integridad de la cadena de suministro:

Genere y almacene SBOMs (SPDX o CycloneDX) durante las compilaciones, publíquelos junto con las imágenes como artefactos OCI para la trazabilidad.
Escanee las imágenes antes del push y en reposo en los registros usando el escaneo de contenedores de Defender for Cloud; bloquee la promoción en caso de hallazgos críticos.
Firme imágenes y atestaciones usando Notary v2/artefactos OCI con cosign. Haga cumplir la verificación de firmas en la admisión (p. ej., Gatekeeper/OPA o AKS Policy para Kubernetes).
Controles de registro en Azure Container Registry (ACR): deshabilite el usuario administrador, restrinja la red mediante Private Endpoints, habilite claves administradas por el cliente, use tokens con ámbito de repositorio para un acceso detallado y aplique patrones de retención y cuarentena. Otorgue solo AcrPull a los runtimes y AcrPush a la CI. Para AKS, adjunte el ACR con el comando compatible para crear la asignación correcta en lugar de la configuración manual de roles.
Si los contenedores deben usar endpoints de servicio de VNet desde un host de VM, instale un complemento CNI compatible para que el tráfico por contenedor se origine desde la subred.

El registro de aplicaciones no debe filtrar secretos ni PII:

Configure Application Insights para ocultar o descartar campos sensibles con Telemetry Processors; evite registrar encabezados, tokens o payloads sin procesar que contengan secretos o PII. Limite los campos de datos a las necesidades del negocio y habilite el muestreo para reducir la exposición.
Dirija los diagnósticos a un espacio de trabajo de Log Analytics dedicado con un RBAC estricto (Log Analytics Reader como mínimo privilegio) y almacenamiento inmutable al exportar a Storage (bloqueos de retención basados en tiempo).
Proteja los endpoints de ingesta y consulta de telemetría con Private Link donde esté disponible. Almacene las cadenas de conexión de instrumentación en Key Vault y rótelas regularmente.

Las prácticas de lanzamiento seguro imponen una promoción controlada:

Las puertas de aprobación en Azure DevOps Environments o GitHub Environments requieren revisores designados, la superación de controles de calidad y tickets de cambio. Automatice las ventanas de retención para despliegues de alto riesgo.
Aplique el mínimo privilegio a las conexiones de servicio y a los agentes; delimite el ámbito a grupos de recursos o suscripciones por entorno. Use identidades administradas con roles de ámbito reducido.
Segregación de entornos entre desarrollo (Dev), pruebas (Test) y producción (Prod) con suscripciones, VNets, Key Vaults y ACRs separados; no permita el movimiento lateral entre entornos y use diferentes secretos/claves en cada entorno.

Escenario de problema práctico

Fabrikam, Inc. va a publicar una API SaaS multi-inquilino en internet. Requisitos: bloquear los ataques del Top 10 de OWASP, validar los scopes de OAuth por operación, evitar secretos en los repositorios, limitar a los clientes abusivos y garantizar que solo se ejecuten imágenes de contenedor firmadas en producción.

Fronting y WAF

Despliegue Azure Front Door Standard con una política de WAF usando el último conjunto de reglas administradas de OWASP en modo de prevención (Prevention), además de reglas personalizadas de limitación de velocidad (rate-limit) y bloqueo geográfico. Justificación: la aplicación centralizada en el borde global reduce la superficie de ataque y absorbe los ataques de L7 antes de que lleguen al origen.

Política de API Gateway

Coloque Azure API Management detrás de Front Door; implemente validate-jwt con comprobaciones de emisor/audiencia/scope por operación y claves de suscripción a nivel de producto con cuotas. Justificación: APIM proporciona una aplicación consciente de la identidad y aislamiento de inquilinos; las claves junto con OAuth ofrecen una defensa por capas y una limitación precisa.

Identidad y consentimiento

Registre las aplicaciones SPA y daemon en Entra ID con scopes delegados para flujos de usuario y roles de aplicación para el daemon; restrinja el consentimiento del usuario a editores verificados y requiera el consentimiento del administrador para los permisos de la aplicación. Use credenciales de certificado para el daemon. Justificación: elimina los secretos débiles, impone el mínimo privilegio y reduce la exposición al phishing de consentimiento.

DevSecOps con OIDC

Configure GitHub Actions para usar la federación OIDC con una entidad de servicio de Azure con ámbito a una suscripción de no producción para la compilación y a una entidad de servicio con ámbito de producción para el lanzamiento, cada una con roles mínimos (AcrPush para la compilación, Contributor limitado a un RG de producción para el lanzamiento). Justificación: sin secretos almacenados; el radio de impacto se minimiza por entorno.

Cadena de suministro de contenedores

Compile imágenes a través de ACR Tasks, genere SBOMs (CycloneDX) y firme imágenes con cosign; almacene las atestaciones como artefactos OCI. Configure la admisión de AKS con una política para requerir firmas válidas. Justificación: la procedencia y la integridad son verificables en el momento del despliegue, bloqueando imágenes manipuladas.

Controles de registro y runtime

Deshabilite el usuario administrador de ACR, habilite Private Endpoint, asigne AcrPull a la identidad kubelet de AKS a través del flujo attach-acr compatible y habilite el escaneo de imágenes de Defender for Cloud. Justificación: el fortalecimiento de la red y la identidad elimina las puertas traseras por defecto; el escaneo detecta CVEs conocidos antes del tiempo de ejecución.

Secretos y configuración

Use Key Vault con Private Endpoint y RBAC; App Service y Functions consumen referencias de Key Vault, y AKS usa Secret Store CSI con Workload Identity. Justificación: los secretos nunca residen en los repositorios ni en las configuraciones de la aplicación; la rotación es centralizada y auditable.

Gobernanza de lanzamientos

Proteja la rama main de GitHub con revisiones y comprobaciones requeridas; exija aprobaciones de entorno y la superación de puertas de seguridad (sin hallazgos críticos de SAST/SCA/IaC) antes del despliegue en producción. Justificación: asegura que solo avancen las compilaciones validadas y seguras; la supervisión humana se mantiene para los cambios de alto riesgo.

Higiene de la observabilidad

Configure Application Insights para ocultar PII con Telemetry Processors personalizados y dirija los diagnósticos de WAF/APIM a un espacio de trabajo de Log Analytics protegido con acceso de Reader de mínimo privilegio. Justificación: conserva el valor forense sin exponer datos sensibles; el acceso es auditable y restringido.

← Microsoft Sentinel y operaciones de seguridad · Todos los dominios · Seguridad híbrida y multinube →

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