Microsoft AZ-400: Segurança, Conformidade e DevSecOps — Guia de estudos

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

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A segurança, a conformidade e o DevSecOps em pipelines de entrega focados no Azure exigem o deslocamento da detecção de riscos para os estágios mais iniciais possíveis, a imposição contínua de políticas e a automação da coleta de evidências. Implementações eficazes unificam testes de segurança de aplicações (SAST/DAST/SCA), governança de segredos, varredura de infraestrutura como código (IaC) e controles regulatórios no ciclo de vida de CI/CD. No Azure DevOps e no GitHub, isso significa executar analisadores em cada pull request, condicionar merges a limiares de qualidade, implantar com identidades de privilégio mínimo que recuperam segredos com tempo de vida limitado do Azure Key Vault e monitorar continuamente a postura com o Microsoft Defender for DevOps e o Defender for Cloud. O objetivo não é apenas encontrar problemas, mas impedir que alterações inseguras alcancem recursos protegidos, comprovar a conformidade por meio de trilhas de auditoria e sustentar uma velocidade segura.

Segurança “shift-left”, mitigações do OWASP Top 10 e endurecimento de pipelines

A segurança “shift-left” (deslocada para a esquerda) começa com SAST e SCA no momento do PR, complementada por varredura de segredos e DAST direcionado antes da promoção para o próximo ambiente. O SAST expõe vulnerabilidades no nível do código, como pontos de injeção, desserializadores inseguros e codificação de saída ausente. Integre o SonarQube/SonarCloud ou o GitHub code scanning (ex: CodeQL) para analisar cada conjunto de alterações; anote os pull requests com problemas vinculados a linhas específicas; e imponha “quality gates” (portões de qualidade) que falhem o build quando os limiares de vulnerabilidade ou cobertura não forem atendidos. Foque o SAST nas classes do OWASP Top 10:

Injeção: exija o uso de consultas parametrizadas/ORM, valide/normalize a entrada e proíba a concatenação de strings/SQL dinâmico. Imponha isso por meio de conjuntos de regras SAST e testes unitários que garantam o uso de auxiliares de acesso a dados verificados.
Cross-Site Scripting (XSS): exija codificação de saída e uma Content Security Policy. A análise de “taint” (contaminação) do SAST deve rastrear entradas não confiáveis até os “sinks” (pontos de saída) (innerHTML, Response.Write).
Cross-Site Request Forgery (CSRF): imponha tokens antifalsificação e cookies SameSite. Os pipelines podem executar analisadores de framework para garantir que o middleware/configurações estejam ativados.
Desserialização Insegura: não permita serializadores binários/XML inseguros, limite os tipos permitidos e prefira serializadores JSON configurados com padrões seguros. As verificações SAST e as políticas de dependência impedem o uso de bibliotecas conhecidamente inseguras.

O DAST valida builds em execução em um ambiente de “staging” (homologação). Automatize o OWASP ZAP ou equivalente como uma tarefa de pipeline pós-implantação em um ambiente de não produção, usando varreduras autenticadas e um conjunto de regras ajustado ao perfil da sua aplicação. Condicione a promoção a uma linha de base de vulnerabilidades: bloqueie com base em novas descobertas de criticidade Alta/Crítica e persista as exceções aceitas com uma data de expiração.

A Análise de Composição de Software (SCA) detecta pacotes de terceiros vulneráveis antes do merge. Use o Dependabot para criar PRs de atualização de versão e o OWASP Dependency-Check para produzir SBOMs e relatórios de CVEs em CI. Imponha a conformidade de licenças definindo listas de permissão/negação (ex: negar “copyleft” para produtos proprietários) e falhando builds que incluam licenças não permitidas. A varredura de segredos deve ser executada no commit e em CI: adote o “secret scanning” do GitHub Advanced Security ou integre o Gitleaks/Microsoft Security DevOps para capturar credenciais, tokens e chaves “hardcoded” (embutidos no código); bloqueie o merge quando um padrão de segredo for detectado e rotacione as credenciais afetadas.

O endurecimento do pipeline (“pipeline hardening”) é inegociável. Bloqueie as proteções de branch, exija revisões de PR e imponha verificações de status para SAST/SCA/DAST. No Azure Pipelines, use recursos protegidos, aprovações e verificações de ambiente e templates obrigatórios para padronizar os estágios de segurança. Prefira tokens de curta duração e com privilégio mínimo; evite credenciais estáticas completamente com a federação de identidade de carga de trabalho (“workload identity federation”). Restrinja agentes auto-hospedados (“self-hosted”) a redes privadas, defina o escopo de suas identidades minimamente e desabilite a injeção de script impondo templates que não permitam etapas de script arbitrárias para repositórios não confiáveis.

Segredos, identidades, Azure Key Vault e rotação de certificados

O Azure Key Vault é o repositório autoritativo para segredos, chaves e certificados. Integre-o diretamente com CI/CD para eliminar segredos em texto plano:

Segredos do pipeline: no Azure DevOps, vincule um grupo de variáveis a um Key Vault usando uma conexão de serviço com escopo apenas para os nomes de segredos necessários. Os segredos são recuperados em tempo de execução e mascarados nos logs. No GitHub Actions, use azure/login com identidade federada para obter tokens e chamar o Key Vault; evite armazenar segredos de cliente nas configurações do repositório.
Acesso por identidade gerenciada: sempre que possível, permita que cargas de trabalho e agentes de implantação se autentiquem com o Microsoft Entra ID usando identidade gerenciada ou federação de identidade de carga de trabalho para que nenhum segredo seja armazenado. Defina o escopo do acesso ao Key Vault usando RBAC ou políticas de acesso seguindo o princípio do privilégio mínimo (apenas get/list para versões específicas de segredos; sem purge/delete).
Rotação de certificados: armazene certificados TLS/MTLS no Key Vault Certificates com rotação automática por meio de CAs integradas. Configure os serviços consumidores (App Service, Application Gateway, AKS Ingress via CSI Secrets Store) para referenciar o Key Vault para que os certificados renovados sejam utilizados sem uma nova implantação. Use o Event Grid em eventos certificateNearExpiry do Key Vault para acionar um runbook de automação ou uma Function que valide os “bindings” e aqueça os caches. Rastreie o uso da versão do certificado nos manifestos de implantação; fixe as versões quando necessário e avance-as deliberadamente durante as janelas de manutenção.

Endureça o Key Vault com “private endpoints”, regras de firewall, proteção contra exclusão definitiva (“purge protection”), exclusão reversível (“soft-delete”) e registro de logs no Log Analytics ou em um armazenamento para auditoria. Negue o acesso entre “tenants”, a menos que explicitamente justificado, e rotacione rotineiramente o acesso para contas de emergência (“break-glass”).

Dependências, contêineres, IaC e conformidade como código

A varredura de dependências deve lidar tanto com falhas de segurança quanto com licenciamento. O Dependabot propõe continuamente atualizações seguras; use políticas de revisão de dependência para bloquear PRs que introduzem versões vulneráveis. O OWASP Dependency-Check (ou ferramentas nativas do ecossistema como npm audit, pip-audit) deve ser executado no CI para gerar SBOMs (CycloneDX/SPDX) e falhar o build quando os limites de severidade ou as regras de licença forem violados. Para uma governança de licenças avançada, utilize em conjunto com uma plataforma de SCA capaz de aplicar políticas legais e fluxos de trabalho de remediação.

A segurança de imagens de contêiner começa no CI e continua no registro e no tempo de execução:

Trivy: execute como uma etapa do pipeline para escanear Dockerfiles e imagens construídas em busca de CVEs de SO/pacotes e configurações incorretas; interrompa o build em caso de achados Críticos/Altos. Imponha o uso de imagens base mínimas e contêineres sem root.
Varredura de vulnerabilidades do Azure Container Registry: habilite o Microsoft Defender for Containers para escanear imagens no push/importação e de forma agendada. Exponha os achados no Defender for Cloud, exporte para itens de trabalho e aplique portões de implantação que bloqueiem imagens com problemas Críticos/Altos não resolvidos.
Defender for Containers: estenda a proteção para AKS/ECS/Kubernetes com detecção de ameaças em tempo de execução, verificações no estilo kube-bench e controle de admissão. Use políticas para permitir o pull apenas de ACRs confiáveis assinados com Notation/ACR content trust e verifique as assinaturas no CI e na admissão do cluster.

A segurança de IaC garante que os recursos de nuvem sejam provisionados de forma segura por padrão:

Checkov e tfsec: escaneie manifestos do Terraform e Kubernetes em busca de configurações inseguras (armazenamento público, security groups abertos, falta de criptografia). Interrompa os builds com base em limites de severidade; estabeleça uma linha de base para a dívida existente a fim de focar em recursos novos/alterados.
Linting de ARM/Bicep: habilite o linter do Bicep (bicepconfig.json) e o ARM Template Tool Kit (arm-ttk) para aplicar regras de marcação (tagging), endpoints somente HTTPS, chaves gerenciadas pelo cliente e configurações de diagnóstico. Combine com implantações what-if para detectar desvios (drift) antes de aplicar.

A Conformidade como Código (Compliance as Code) usa o Azure Policy e o Defender for Cloud para aplicar e relatar controles continuamente:

Atribua iniciativas do Azure Policy alinhadas com CIS, NIST, ISO 27001 ou baselines internos; selecione efeitos como Deny para barreiras de proteção críticas (ex: IPs públicos em bancos de dados), DeployIfNotExists para diagnósticos e Audit para observabilidade. Armazene as definições de política como artefatos versionados, teste com pipelines de política como código e promova via pull requests.
Use os painéis de conformidade regulatória do Defender for Cloud para visualizar a conformidade dos controles entre assinaturas e grupos de gerenciamento. Integre com o Azure Monitor e exporte evidências para o Log Analytics ou Event Hubs para ingestão em um SIEM.
Mantenha trilhas de auditoria: Azure Activity Logs para eventos e atribuições de políticas, Resource Graph para consultas de conformidade, logs de auditoria do Azure DevOps/GitHub para alterações em repositórios e pipelines, e evidências de release capturadas automaticamente como artefatos de execução do pipeline.

SonarQube/SonarCloud, segurança de pipeline e Microsoft Defender for DevOps

O SonarQube/SonarCloud fornece quality gates aplicáveis que alinham a qualidade da engenharia com a segurança. Adote o “Clean as You Code” definindo gates para o código novo: cobertura de código mínima em linhas novas/alteradas (por exemplo, 80%+), zero novas vulnerabilidades Críticas ou code smells bloqueadores e baixa duplicação. A falha no gate deve causar a falha do pipeline. Publique a cobertura de frameworks de teste (JaCoCo, Cobertura, VSTest) e ajuste os perfis de qualidade por linguagem para incluir security hotspots e regras alinhadas ao OWASP. Monitore as taxas de dívida técnica e os tempos de remediação; relate as tendências para impulsionar a responsabilidade da equipe.

A segurança de pipeline depende de conexões de serviço com menor privilégio, recursos protegidos e mascaramento abrangente de segredos:

As conexões de serviço devem usar federação de identidade de carga de trabalho ou identidades gerenciadas com escopos restritos (assinatura/grupo de recursos, ACR específico ou Key Vault). Habilite aprovações e verificações nas conexões de serviço e ambientes para que os proprietários precisem autorizar o uso. Limite as permissões de “Uso” a pipelines confiáveis; desabilite a opção “Conceder permissão de acesso a todos os pipelines”.
Recursos protegidos no Azure DevOps protegem conexões de serviço, grupos de variáveis, arquivos seguros e ambientes. Exija verificações como aprovadores, janelas de horário comercial, resultados de consulta do Azure Monitor e motores de política REST externos. Trate-os como gates antes das implantações e como pré-condições para leituras sensíveis (por exemplo, recuperar segredos de produção).
O mascaramento de segredos deve ser aplicado em todos os logs; restrinja a expansão de variáveis em scripts; evite exibir segredos (echoing); e prefira APIs com escopo de system.accessToken em vez de armazenar PATs. Verifique periodicamente os logs do pipeline em busca de vazamentos acidentais de segredos e rotacione-os ao serem detectados.

O Microsoft Defender for DevOps unifica a postura de segurança de repositórios e pipelines no GitHub e no Azure DevOps. Conecte organizações/projetos ao Defender for Cloud para ingerir sinais de risco de código, segredos, IaC e dependências e apresentar recomendações consolidadas. Ele correlaciona os achados aos proprietários, suporta fluxos de trabalho de supressão com expiração e mede a adoção de proteções de branch, revisores obrigatórios e verificações de status. Combine o Defender for DevOps com a tarefa/ação Microsoft Security DevOps para orquestrar múltiplos analisadores (por exemplo, Semgrep, Trivy, tfsec, Gitleaks, Bandit) em uma única etapa e publicar o SARIF para a verificação de código (code scanning). Use o Defender for Cloud para criar iniciativas de governança que monitorem e apliquem as melhores práticas de DevOps (por exemplo, verificação de segredos habilitada, contagem de revisores obrigatórios ≥ 2, merges por não administradores desabilitados), elevando a higiene do repositório a um controle auditável.

Cenário de Problema Prático

O Spotify precisa padronizar a entrega segura para uma nova pilha de microsserviços hospedada no AKS, abrangendo .NET e Node.js, com repositórios no GitHub Enterprise Cloud e implantações através de pipelines YAML multiestágio do Azure DevOps. O desafio é impedir dependências vulneráveis e infraestrutura mal configurada antes do merge, eliminar credenciais estáticas e bloquear a promoção de imagens com CVEs críticos, ao mesmo tempo em que se produz evidências de conformidade auditáveis.

Aplicar varredura de SAST/SCA e segredos no momento do PR

Escolha o SonarCloud para SAST multilíngue com decoração de PR e quality gates; defina a cobertura de código novo ≥ 80% e zero novas vulnerabilidades Críticas. O Dependabot é habilitado para criar PRs automáticos de atualizações seguras, e a revisão de dependências do GitHub (dependency review) bloqueia PRs que introduzem CVEs conhecidos. A verificação de segredos do GitHub Advanced Security, juntamente com o Gitleaks em CI, garante uma defesa em profundidade contra a exposição de credenciais.

Adicionar DAST autenticado antes da promoção

Use o OWASP ZAP em um estágio do pipeline direcionado ao ambiente de homologação (staging) com contas de teste pré-configuradas. Uma verificação de lançamento (release check) bloqueia a produção se novos problemas de criticidade Alta/Crítica aparecerem. O ZAP é escolhido por sua cobertura alinhada ao OWASP e fácil automação de CI.

Proteger identidades e segredos com o Key Vault e a federação de identidade de carga de trabalho

Substitua os segredos de cliente da entidade de serviço (service principal) pela federação de identidade de carga de trabalho do Microsoft Entra para as conexões de serviço, removendo os segredos armazenados. Os pipelines recuperam segredos de tempo de execução e credenciais de banco de dados do Azure Key Vault por meio de permissões de menor privilégio (get/list). Isso elimina credenciais de longa duração e centraliza a rotação.

Implementar automação de certificados

Armazene certificados de ingresso (ingress) e mTLS no Key Vault com rotação automática. O AKS busca os certificados através do driver CSI da Secrets Store para evitar a cópia de segredos para o Kubernetes. O Event Grid aciona uma Function para verificar os bindings após a renovação. Este design minimiza o tempo de inatividade e o erro humano na rotação.

Fortalecer contêineres e registros

Execute o Trivy em CI para escanear Dockerfiles e imagens construídas; falhe em caso de criticidade Alta/Crítica. Envie apenas imagens limpas para o ACR. Habilite o Defender for Containers para escanear o ACR no push e periodicamente, expondo os achados para o Defender for Cloud. Verificações de lançamento baseadas em políticas bloqueiam a implantação de imagens com CVEs de criticidade Alta/Crítica não resolvidos. O Trivy fornece feedback rápido; o Defender adiciona garantia contínua e nativa do registro.

Escanear IaC e fazer lint de Bicep/ARM

Use o Checkov e o tfsec para escanear charts do Terraform e do Helm; imponha controles de tagueamento, criptografia e rede. O linter do Bicep e o ARM TTK são executados em CI para templates nativos do Azure. Verificações com falha bloqueiam merges; baselines limitam o ruído a recursos novos/alterados. Essas ferramentas são escolhidas por sua ampla cobertura de regras e forte suporte ao Azure.

Codificar conformidade e evidências

Atribua iniciativas do Azure Policy para baselines da empresa e do CIS Azure; aplique Deny em guardrails críticos e DeployIfNotExists para diagnósticos. Envie os resultados para os painéis regulatórios do Defender for Cloud. Exporte os Logs de Atividade e as recomendações do Defender para o Log Analytics para obter evidências imutáveis. A política fornece aplicação contínua; os painéis oferecem visualizações prontas para auditoria.

Restringir pipelines e recursos protegidos

Restrinja as conexões de serviço a assinaturas/grupos de recursos com escopo definido; exija aprovações de ambiente e verificações de consulta do Azure Monitor para produção. Proteja grupos de variáveis e arquivos seguros; mascare todos os segredos. Fortaleça os agentes auto-hospedados (self-hosted) com rede privada. Esses recursos reduzem o raio de alcance (blast radius) e garantem a intervenção humana para ações de alto risco.

Consolidar a postura com o Microsoft Defender for DevOps

Conecte a organização do GitHub e o projeto do Azure DevOps ao Defender for Cloud para agregar achados de código, segredos e IaC e monitorar a adoção de proteções de repositório. Use a ação/tarefa Microsoft Security DevOps para orquestrar Semgrep, Trivy, tfsec e Gitleaks com publicação SARIF, garantindo uma varredura padronizada entre os serviços. Isso centraliza o gerenciamento de riscos e os fluxos de trabalho de remediação.

Cada ferramenta/recurso é selecionado para a detecção mais precoce possível, imposição automática e auditabilidade: SonarCloud e ZAP atuam como gates para riscos de código e de tempo de execução; Dependabot e Trivy aceleram atualizações seguras; Key Vault e a federação de identidade removem segredos estáticos; Checkov/tfsec e Azure Policy previnem drift; recursos protegidos e aprovações controlam o raio de alcance; Defender for DevOps e Defender for Cloud entregam um gerenciamento de postura unificado e acionável.

← Gerenciamento de Lançamentos e Estratégias de Implantação · Todos os domínios · Estratégia de Testes e Engenharia de Qualidade →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →