Microsoft AZ-400: Seguridad, cumplimiento y DevSecOps — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — 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, el cumplimiento y DevSecOps en las canalizaciones de entrega centradas en Azure exigen desplazar la detección de riesgos a las fases más tempranas posibles, aplicar políticas de forma continua y automatizar la recopilación de evidencias. Las implementaciones eficaces unifican las pruebas de seguridad de aplicaciones (SAST/DAST/SCA), la gobernanza de secretos, el escaneo de infraestructura como código (IaC) y los controles normativos en el ciclo de vida de CI/CD. En Azure DevOps y GitHub, esto significa ejecutar analizadores en cada pull request, condicionar las fusiones (merges) con umbrales de calidad, implementar con identidades de privilegio mínimo que recuperan secretos con límite de tiempo de Azure Key Vault y monitorear continuamente la postura con Microsoft Defender for DevOps y Defender for Cloud. El objetivo no es solo encontrar problemas, sino también evitar que cambios inseguros lleguen a los recursos protegidos, demostrar el cumplimiento a través de pistas de auditoría y mantener una velocidad segura.

Seguridad de desplazamiento a la izquierda (shift-left), mitigaciones del Top 10 de OWASP y fortalecimiento de la canalización

La seguridad de desplazamiento a la izquierda (shift-left) comienza con SAST y SCA en el momento del PR, complementada con el escaneo de secretos y DAST dirigido antes de la promoción a producción. SAST saca a la luz vulnerabilidades a nivel de código, como puntos de inyección, deserializadores no seguros y falta de codificación de salida. Integre SonarQube/SonarCloud o el escaneo de código de GitHub (p. ej., CodeQL) para analizar cada conjunto de cambios; enriquezca los pull requests con problemas vinculados a líneas específicas; y aplique puertas de calidad que fallen la compilación cuando no se cumplan los umbrales de vulnerabilidad o cobertura. Enfoque SAST en las clases del Top 10 de OWASP:

• Inyección: exija el uso de consultas parametrizadas/ORM, valide/normalice las entradas y prohíba la concatenación de cadenas/SQL dinámico. Aplíquelo mediante conjuntos de reglas SAST y pruebas unitarias que aseguren el uso de asistentes de acceso a datos verificados.
• Cross-Site Scripting (XSS): requiera codificación de salida y una Content Security Policy. El análisis de contaminación (taint analysis) de SAST debe rastrear las entradas no confiables hasta los receptores (sinks) (innerHTML, Response.Write).
• Cross-Site Request Forgery (CSRF): aplique tokens antifalsificación y cookies SameSite. Las canalizaciones pueden ejecutar analizadores de framework para asegurar que el middleware y la configuración estén habilitados.
• Deserialización insegura: no permita serializadores binarios/XML no seguros, limite los tipos permitidos y prefiera serializadores JSON configurados con valores predeterminados seguros. Las comprobaciones de SAST y las políticas de dependencias evitan el uso de bibliotecas conocidas como no seguras.

DAST valida las compilaciones en ejecución en un entorno de preproducción (staging). Automatice OWASP ZAP o un equivalente como un trabajo de la canalización posterior a la implementación en un entorno no productivo, utilizando escaneos autenticados y un conjunto de reglas ajustado al perfil de su aplicación. Condicione la promoción a producción a una línea base de vulnerabilidades: bloquee ante nuevos hallazgos de severidad Alta/Crítica y persista las excepciones aceptadas con una fecha de caducidad.

El Análisis de composición de software (SCA) detecta paquetes de terceros vulnerables antes de la fusión. Use Dependabot para generar PRs de actualización de versión y OWASP Dependency-Check para producir SBOMs e informes de CVE en CI. Aplique el cumplimiento de licencias definiendo listas de permitidos/denegados (p. ej., denegar copyleft para productos propietarios) y haciendo que fallen las compilaciones que incluyan licencias no permitidas. El escaneo de secretos debe ejecutarse en cada commit y en CI: adopte el escaneo de secretos de GitHub Advanced Security o integre Gitleaks/Microsoft Security DevOps para detectar credenciales, tokens y claves codificadas; bloquee la fusión cuando se detecte un patrón de secreto y rote las credenciales afectadas.

El fortalecimiento de la canalización no es negociable. Bloquee las protecciones de rama, exija revisiones de PR y aplique comprobaciones de estado para SAST/SCA/DAST. En Azure Pipelines, utilice recursos protegidos, aprobaciones y comprobaciones de entorno, y plantillas requeridas para estandarizar las fases de seguridad. Prefiera tokens de corta duración y de privilegio mínimo; evite por completo las credenciales estáticas con la federación de identidades de carga de trabajo. Restrinja los agentes autohospedados a redes privadas, limite el alcance de sus identidades al mínimo y deshabilite la inyección de scripts aplicando plantillas que no permitan pasos de script arbitrarios para repositorios no confiables.

Secretos, identidades, Azure Key Vault y rotación de certificados

Azure Key Vault es el almacén autoritativo para secretos, claves y certificados. Intégrelo directamente con CI/CD para eliminar los secretos en texto plano:

• Secretos de la canalización: en Azure DevOps, vincule un grupo de variables a un Key Vault usando una conexión de servicio con un alcance limitado solo a los nombres de los secretos requeridos. Los secretos se recuperan en tiempo de ejecución y se enmascaran en los registros. En GitHub Actions, use azure/login con identidad federada para obtener tokens y llamar a Key Vault; evite almacenar secretos de cliente en la configuración del repositorio.
• Acceso con identidad administrada: siempre que sea posible, permita que las cargas de trabajo y los agentes de implementación se autentiquen con Microsoft Entra ID usando una identidad administrada o la federación de identidades de carga de trabajo para que no se almacenen secretos. Limite el acceso a Key Vault usando RBAC o directivas de acceso siguiendo el principio de privilegio mínimo (solo get/list para versiones de secretos específicas; sin permisos de purga/eliminación).
• Rotación de certificados: almacene los certificados TLS/MTLS en Key Vault Certificates con autorrotación a través de CA integradas. Configure los servicios consumidores (App Service, Application Gateway, AKS Ingress a través de CSI Secrets Store) para que hagan referencia a Key Vault, de modo que los certificados renovados se recojan sin necesidad de volver a implementar. Use Event Grid en los eventos certificateNearExpiry de Key Vault para activar un runbook de automatización o una Function que valide los enlaces y precaliente las cachés. Realice un seguimiento del uso de la versión del certificado en los manifiestos de implementación; fije las versiones cuando sea necesario y avance deliberadamente durante las ventanas de mantenimiento.

Fortalezca Key Vault con puntos de conexión privados, reglas de firewall, protección contra purga, eliminación temporal (soft-delete) y registro en Log Analytics o en almacenamiento para auditoría. Deniegue el acceso entre inquilinos a menos que esté explícitamente justificado y rote de forma rutinaria el acceso para las cuentas de emergencia (break-glass).

Dependencias, contenedores, IaC y cumplimiento como código

El escaneo de dependencias debe gestionar tanto los defectos de seguridad como las licencias. Dependabot propone continuamente actualizaciones seguras; utiliza políticas de revisión de dependencias para bloquear los PR que introduzcan versiones vulnerables. OWASP Dependency-Check (o herramientas nativas del ecosistema como npm audit, pip-audit) debe ejecutarse en CI para generar SBOMs (CycloneDX/SPDX) y hacer que la compilación falle cuando se violen los umbrales de severidad o las reglas de licencia. Para una gobernanza de licencias avanzada, combínalo con una plataforma de SCA capaz de aplicar políticas legales y flujos de trabajo de remediación.

La seguridad de las imágenes de contenedor comienza en CI y continúa en el registro y en tiempo de ejecución:

• Trivy: ejecútalo como un paso del pipeline para escanear Dockerfiles e imágenes compiladas en busca de CVEs y configuraciones incorrectas de SO/paquetes; interrumpe la compilación ante hallazgos Críticos/Altos. Aplica el uso de imágenes base mínimas y contenedores sin privilegios de root (rootless).
• Escaneo de vulnerabilidades de Azure Container Registry: habilita Microsoft Defender for Containers para escanear imágenes al subirlas/importarlas (on push/import) y de forma programada. Muestra los hallazgos en Defender for Cloud, expórtalos a elementos de trabajo y aplica puertas de despliegue (deployment gates) que bloqueen imágenes con problemas Críticos/Altos sin resolver.
• Defender for Containers: extiende la protección a AKS/ECS/Kubernetes con detección de amenazas en tiempo de ejecución, comprobaciones al estilo kube-bench y control de admisión. Usa políticas para obtener imágenes (pull) solo desde ACRs de confianza firmados con Notation/ACR content trust y verifica las firmas en CI y en la admisión al clúster.

La seguridad de IaC (Infraestructura como Código) garantiza que los recursos en la nube se aprovisionen de forma segura por defecto:

• Checkov y tfsec: escanea manifiestos de Terraform y Kubernetes en busca de configuraciones inseguras (almacenamiento público, grupos de seguridad abiertos, falta de cifrado). Haz que las compilaciones fallen según los umbrales de severidad; establece una línea base de la deuda existente para centrarse en los recursos nuevos o modificados.
• Linting de ARM/Bicep: habilita el linter de Bicep (bicepconfig.json) y el ARM Template Tool Kit (arm-ttk) para aplicar reglas de etiquetado, puntos de conexión solo HTTPS, claves gestionadas por el cliente y configuraciones de diagnóstico. Combínalo con despliegues hipotéticos (what-if) para detectar desviaciones (drift) antes de aplicar los cambios.

El Cumplimiento como Código (Compliance as Code) utiliza Azure Policy y Defender for Cloud para aplicar y reportar controles de forma continua:

• Asigna iniciativas de Azure Policy alineadas con CIS, NIST, ISO 27001 o líneas base internas; selecciona efectos como Deny para barreras de protección críticas (p. ej., IPs públicas en bases de datos), DeployIfNotExists para diagnósticos y Audit para observabilidad. Almacena las definiciones de políticas como artefactos versionados, pruébalas con pipelines de política como código y promuévelas mediante pull requests.
• Utiliza los paneles de cumplimiento normativo de Defender for Cloud para visualizar la conformidad de los controles en todas las suscripciones y grupos de administración. Intégralo con Azure Monitor y exporta la evidencia a Log Analytics o Event Hubs para su ingesta en un SIEM.
• Mantén pistas de auditoría: Azure Activity Logs para eventos y asignaciones de políticas, Resource Graph para consultas de cumplimiento, registros de auditoría de Azure DevOps/GitHub para cambios en repositorios y pipelines, y evidencia de lanzamiento capturada automáticamente como artefactos de ejecución del pipeline.

SonarQube/SonarCloud, seguridad de las canalizaciones y Microsoft Defender for DevOps

SonarQube/SonarCloud proporciona puertas de calidad (quality gates) ejecutables que alinean la calidad de la ingeniería con la seguridad. Adopte el principio «Clean as You Code» estableciendo puertas sobre el código nuevo: cobertura de código mínima en líneas nuevas/modificadas (p. ej., 80 %+), cero nuevas vulnerabilidades críticas o code smells bloqueantes, y baja duplicación. Fallar la puerta de calidad debe hacer que la canalización falle. Publique la cobertura desde los frameworks de pruebas (JaCoCo, Cobertura, VSTest) y ajuste los perfiles de calidad por lenguaje para incluir puntos críticos de seguridad (security hotspots) y reglas alineadas con OWASP. Realice un seguimiento de las tasas de deuda técnica y los tiempos de remediación; informe las tendencias para impulsar la responsabilidad del equipo.

La seguridad de las canalizaciones depende de conexiones de servicio con privilegio mínimo, recursos protegidos y un enmascaramiento de secretos completo:

• Las conexiones de servicio deben usar la federación de identidades de carga de trabajo o identidades administradas con ámbitos restringidos (suscripción/grupo de recursos, un ACR específico o un Key Vault). Habilite aprobaciones y comprobaciones en las conexiones de servicio y los entornos para que los propietarios deban autorizar su uso. Limite los permisos de «Uso» a las canalizaciones de confianza; deshabilite la opción «Conceder permiso de acceso a todas las canalizaciones».
• Los recursos protegidos en Azure DevOps resguardan las conexiones de servicio, los grupos de variables, los archivos seguros y los entornos. Requieren comprobaciones como aprobadores, ventanas de horario comercial, resultados de consultas de Azure Monitor y motores de políticas REST externos. Trátelos como puertas antes de los despliegues y como condiciones previas para lecturas sensibles (p. ej., recuperar secretos de producción).
• El enmascaramiento de secretos debe aplicarse en todos los registros; restrinja la expansión de variables en los scripts; evite imprimir secretos en la salida (echoing); y prefiera las API con ámbito system.accessToken en lugar de almacenar PATs. Escanee periódicamente los registros de las canalizaciones en busca de fugas accidentales de secretos y rótelos al detectarlos.

Microsoft Defender for DevOps unifica la postura de seguridad de los repositorios y las canalizaciones en GitHub y Azure DevOps. Conecte organizaciones/proyectos a Defender for Cloud para ingerir señales de riesgo de código, secretos, IaC y dependencias, y presentar recomendaciones consolidadas. Correlaciona los hallazgos con los propietarios, admite flujos de trabajo de supresión con vencimiento y mide la adopción de protecciones de rama, revisores requeridos y comprobaciones de estado. Combine Defender for DevOps con la tarea/acción Microsoft Security DevOps para orquestar múltiples analizadores (p. ej., Semgrep, Trivy, tfsec, Gitleaks, Bandit) en un solo paso y publicar los resultados en formato SARIF en el escaneo de código. Use Defender for Cloud para crear iniciativas de gobernanza que rastreen y apliquen las mejores prácticas de DevOps (p. ej., escaneo de secretos habilitado, número de revisiones requeridas ≥ 2, fusiones de no administradores deshabilitadas), elevando la higiene del repositorio a un control auditable.

Escenario de problema práctico

Spotify necesita estandarizar la entrega segura para una nueva pila de microservicios alojada en AKS que abarca .NET y Node.js, con repositorios en GitHub Enterprise Cloud y despliegues a través de canalizaciones YAML multietapa de Azure DevOps. El desafío es detener las dependencias vulnerables y la infraestructura mal configurada antes de la fusión (merge), eliminar las credenciales estáticas y bloquear la promoción de imágenes con CVE críticos, mientras se produce evidencia de cumplimiento auditable.

1. Aplicar escaneo SAST/SCA y de secretos en el momento del PR

• Elegir SonarCloud para SAST multilingüe con decoración de PR y puertas de calidad; establecer una cobertura de código nuevo ≥ 80 % y cero vulnerabilidades críticas nuevas. Se habilita Dependabot para crear PR automáticos de actualizaciones seguras y la revisión de dependencias de GitHub (dependency review) bloquea los PR que introducen CVE conocidos. El escaneo de secretos de GitHub Advanced Security, junto con Gitleaks en CI, garantiza una defensa en profundidad contra la exposición de credenciales.

2. Añadir DAST autenticado antes de la promoción

• Usar OWASP ZAP en una etapa de la canalización que apunte al entorno de staging con cuentas de prueba preconfiguradas. Una comprobación de lanzamiento bloquea la producción si aparecen nuevos problemas altos/críticos. Se elige ZAP por su cobertura alineada con OWASP y su fácil automatización en CI.

3. Asegurar identidades y secretos con Key Vault y la federación de identidades de carga de trabajo

• Reemplazar los secretos de cliente de la entidad de servicio (service principal) con la federación de identidades de carga de trabajo de Microsoft Entra para las conexiones de servicio, eliminando los secretos almacenados. Las canalizaciones recuperan secretos en tiempo de ejecución y credenciales de base de datos desde Azure Key Vault mediante permisos de get/list de privilegio mínimo. Esto elimina las credenciales de larga duración y centraliza la rotación.

4. Implementar la automatización de certificados

• Almacenar los certificados de ingress y mTLS en Key Vault con rotación automática. AKS extrae los certificados a través del driver CSI de Secrets Store para evitar copiar secretos en Kubernetes. Event Grid desencadena una Function para verificar los enlaces después de la renovación. Este diseño minimiza el tiempo de inactividad y el error humano en la rotación.

5. Fortalecer contenedores y registros

• Ejecutar Trivy en CI para escanear Dockerfiles e imágenes construidas; fallar en caso de criticidad alta/crítica. Enviar solo imágenes limpias a ACR. Habilitar Defender for Containers para escanear ACR en cada push y periódicamente, mostrando los hallazgos en Defender for Cloud. Las comprobaciones de lanzamiento respaldadas por políticas bloquean el despliegue de imágenes con CVE altos/críticos sin resolver. Trivy proporciona retroalimentación rápida; Defender añade una garantía continua y nativa del registro.

6. Escanear IaC y hacer linting de Bicep/ARM

• Usar Checkov y tfsec para escanear Terraform y gráficos de Helm; aplicar el etiquetado, el cifrado y los controles de red. El linter de Bicep y el ARM TTK se ejecutan en CI para las plantillas nativas de Azure. Las comprobaciones que fallan bloquean las fusiones; las líneas base limitan el ruido a los recursos nuevos/modificados. Estas herramientas se eligen por su amplia cobertura de reglas y su sólido soporte para Azure.

7. Codificar el cumplimiento y la evidencia

• Asignar iniciativas de Azure Policy para CIS Azure y las líneas base de la empresa; aplicar Deny en las barreras de protección críticas y DeployIfNotExists para los diagnósticos. Enviar los resultados a los paneles de control regulatorios de Defender for Cloud. Exportar los registros de actividad (Activity Logs) y las recomendaciones de Defender a Log Analytics para obtener evidencia inmutable. Policy proporciona una aplicación continua; los paneles de control ofrecen vistas listas para auditoría.

8. Restringir las canalizaciones y los recursos protegidos

• Restringir las conexiones de servicio a suscripciones/grupos de recursos con ámbito definido; requerir aprobaciones de entorno y comprobaciones de consultas de Azure Monitor para producción. Proteger los grupos de variables y los archivos seguros; enmascarar todos los secretos. Fortalecer los agentes autohospedados con redes privadas. Estas características reducen el radio de impacto y garantizan la intervención humana para acciones de alto riesgo.

9. Consolidar la postura con Microsoft Defender for DevOps

• Conectar la organización de GitHub y el proyecto de Azure DevOps a Defender for Cloud para agregar los hallazgos de código, secretos e IaC y rastrear la adopción de protecciones de repositorio. Usar la acción/tarea Microsoft Security DevOps para orquestar Semgrep, Trivy, tfsec y Gitleaks con publicación SARIF, asegurando un escaneo estandarizado en todos los servicios. Esto centraliza la gestión de riesgos y los flujos de trabajo de remediación.

Cada herramienta/característica se selecciona para la detección más temprana posible, la aplicación automática y la auditabilidad: SonarCloud y ZAP actúan como puerta para los riesgos del código y en tiempo de ejecución; Dependabot y Trivy aceleran las actualizaciones seguras; Key Vault y la federación de identidades eliminan los secretos estáticos; Checkov/tfsec y Azure Policy previenen la deriva de configuración (drift); los recursos protegidos y las aprobaciones controlan el radio de impacto; Defender for DevOps y Defender for Cloud ofrecen una gestión de la postura unificada y accionable.

← Gestión de lanzamientos y estrategias de despliegue · Todos los dominios · Estrategia de pruebas e ingeniería de calidad →

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

Explorar Microsoft →