Microsoft AZ-500: Segurança de Dados, Armazenamento e Banco de Dados — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — 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 de dados, armazenamento e bancos de dados do Azure se concentra em minimizar a confiança, isolar os planos de dados, criptografar em todos os lugares e operacionalizar o menor privilégio com caminhos de acesso auditáveis. Esta seção explica como fortalecer o Azure Storage, o Azure SQL e o Azure Cosmos DB, escolher a estratégia correta de identidade e chaves e prevenir a exfiltração de dados. Cada controle descrito é acompanhado da justificativa operacional por trás dele, para que você possa justificar e manter a configuração em produção.

Protegendo Contas de Armazenamento e Acesso a Dados do Azure

Autorização e compartilhamento da conta de armazenamento

• Azure RBAC para Azure Storage: Prefira a autorização baseada no Azure AD (Blob e Queue) por meio de funções integradas, como Storage Blob Data Reader/Contributor. Justificativa: acesso baseado em token, com tempo limitado via Conditional Access, registrado no Entra ID; evita chaves de conta perpétuas e suporta atribuição just-in-time.
• Chaves compartilhadas: As chaves primárias/secundárias da conta concedem direitos completos no plano de dados. Desabilite o uso de chaves no código e rotacione-as com frequência. Justificativa: chaves compartilhadas são segredos do tipo “bearer” (portador) sem vinculação a um usuário ou CA; comprometimento = exposição total dos dados.
• Tipos de SAS:
  • Service SAS: Concede acesso com escopo definido a recursos específicos (blob, file, queue, table) com permissões, IP, protocolo e limites de tempo. Justificativa: menor privilégio preciso para aplicativos que não podem usar tokens do AD.
  • Account SAS: Superfície mais ampla (ex: entre serviços); use com moderação. Justificativa: expande o raio de impacto (blast radius) se vazada.
  • User delegation SAS: Emitida usando o Azure AD e uma chave de delegação de usuário para o Blob. Justificativa: vincula-se à identidade do Azure AD e ao CA; auditabilidade e revogação superiores.
• Políticas de acesso armazenadas: Defina restrições reutilizáveis (expiração, permissões) para SAS em contêineres/compartilhamentos; revogar ou atualizar a política invalida as SAS emitidas sob ela. Justificativa: revogação centralizada sem a necessidade de regenerar tokens incorporados nos clientes.

Exemplo: gerar uma SAS de delegação de usuário para um blob com o Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Segurança do serviço por tipo

• Blob/Queue/Table: Use o Azure AD RBAC onde for suportado (Blob, Queue). Defina AllowBlobPublicAccess como false, exija HTTPS, habilite o versionamento e a exclusão reversível (soft delete). Justificativa: remove caminhos de exposição anônima e permite a recuperabilidade.
• Azure Files: Use o Azure AD Kerberos para SMB com o Entra ID (ou integração com AD DS) e imponha permissões de menor privilégio no nível do compartilhamento/arquivo. Exija criptografia SMB. Justificativa: acesso vinculado à identidade com segurança de transporte sobre SMB; sem chaves compartilhadas no espaço do usuário.
• Serviço de Tabela (Table service): Use SAS com restrições rígidas de IP/tempo e evite a Account SAS. Justificativa: a granularidade no nível do serviço não é tão rica; defina o escopo de forma agressiva.

Isolamento de rede para todos os serviços de armazenamento

• Regras de firewall do armazenamento: Restrinja a intervalos de IP públicos selecionados somente quando o Private Link não for viável. Justificativa: reduz a superfície de ataque, mas ainda atravessa a internet pública.
• Private endpoints: Prefira o Private Link para Blob, Queue, Table e Files. Mapeie zonas de DNS privado para nomes específicos de recursos. Defina o acesso à rede pública como Disabled (Desabilitado). Justificativa: o tráfego permanece no backbone do Azure; a identidade do recurso é validada via DNS privado; mitiga a exfiltração para serviços de aparência semelhante (lookalike).
• Service endpoints e políticas: Se o Private Link não for uma opção, habilite os service endpoints e aplique políticas de service endpoint para restringir a saída (egress) para contas de armazenamento específicas. Justificativa: restringe o tráfego mesmo na saída da rede virtual; limita o risco de enviar dados para contas pertencentes a invasores.

Configurações operacionais a serem padronizadas

• Imponha somente HTTPS, com no mínimo TLS 1.2.
• Desabilite o acesso por chave compartilhada para Blob e Queue se estiver usando AD (depende do suporte do recurso).
• Políticas de imutabilidade em contêineres/compartilhamentos críticos para retenção regulatória e resiliência a ransomware.

Criptografia e Gerenciamento de Chaves

Camadas de criptografia em repouso

• Chaves gerenciadas pelo serviço (SMK): Criptografia padrão do lado do servidor gerenciada pelo Azure. Justificativa: sobrecarga operacional zero; adequado para muitas cargas de trabalho.
• Chaves gerenciadas pelo cliente (CMK): Chaves no Key Vault ou Managed HSM para Storage, SQL e Cosmos DB. Justificativa: fronteira de confiança externalizada, controle do cliente sobre a rotação/revogação e evidência de conformidade (compliance).
• Criptografia de infraestrutura (criptografia dupla): Camada adicional usando chaves separadas. Justificativa: defesa em profundidade caso a criptografia da mídia de armazenamento seja contornada ou uma fronteira criptográfica seja comprometida.

Rotação e operações de chaves

• As SMK são rotacionadas automaticamente; nenhuma ação é necessária.
• As CMK são rotacionadas criando uma nova versão da chave, concedendo permissões de wrap/unwrap e reapontando o recurso para a versão mais recente (ou para a referência de chave sem versão, quando suportado). Justificativa: rotação sem interrupção com alteração auditável.
• Proteja as chaves com a exclusão reversível (soft delete) e a proteção contra limpeza (purge protection) do Key Vault; controle o acesso de administrador via RBAC e o plano de dados via políticas de acesso ou RBAC (para Managed HSM, use RBAC). Justificativa: previne a perda destrutiva de chaves e impõe o menor privilégio.

Exemplo: definir uma CMK para uma conta de armazenamento

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Escopos de criptografia

• Use escopos de criptografia por contêiner no Storage quando diferentes conjuntos de dados exigirem chaves distintas. Justificativa: segmenta o raio de impacto (blast radius) e permite ciclos de vida de chave diferenciados.

Segurança da Plataforma de Banco de Dados: Azure SQL e Azure Cosmos DB

Autenticação e acesso no Azure SQL

• Autenticação do Microsoft Entra: Crie um administrador do Azure AD em nível de servidor; use usuários de banco de dados contidos (CREATE USER FROM EXTERNAL PROVIDER). Justificativa: evita logins/senhas SQL e habilita o Acesso Condicional e o PIM.
• Usuários contidos: A identidade reside no banco de dados, não no master. Justificativa: simplifica a restauração geográfica e o failover sem a necessidade de reprovisionar logins.
• Regras de firewall: Evite regras de IP de cliente muito abrangentes; prefira o Private Link com o acesso à rede pública desabilitado. Se regras de IP forem necessárias, restrinja a endereços exatos e automatize a revisão. Justificativa: diminui a superfície de ataque e reduz a descoberta por meio de endpoints públicos.
• Endpoints privados: Roteie todo o tráfego do plano de dados pela VNet com DNS privado. Justificativa: elimina a exposição e simplifica a prevenção contra exfiltração de dados.
• Padrões de autenticação: Use o modo Active Directory Integrated (para dispositivos ingressados em domínio) ou código interativo/de dispositivo para obter tokens; cargas de trabalho de serviço devem usar identidades gerenciadas. Justificativa: remove senhas e permite o uso de políticas e tempos de vida de tokens.

Recursos de proteção de dados

• Transparent Data Encryption (TDE): Ativado por padrão; criptografa dados/logs/backups. Justificativa: protege a mídia em repouso sem alterações na aplicação. Use o TDE com CMK para controle externalizado.
• Always Encrypted: Criptografia do lado do cliente para colunas sensíveis com chaves no Key Vault. Justificativa: impede que operadores SQL ou o mecanismo de banco de dados vejam o texto simples; use para campos com PII/PCI.
• Dynamic Data Masking (DDM): Ofusca os resultados de consultas para usuários não privilegiados. Justificativa: reduz a exposição casual de dados, mas não é uma barreira de segurança; combine com RBAC.
• Auditoria: Envie para o Log Analytics, Event Hubs ou Storage. Justificativa: cria uma trilha imutável para investigações e conformidade.

Exemplo: habilitar auditoria em nível de servidor para o Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Vulnerability Assessment (VA): Cria baselines e verifica o esquema/configuração; exporta para o storage; integra com portões de DevSecOps. Justificativa: higiene contínua e detecção de desvios com orientação clara para remediação.
• Threat Detection: Detecta injeção de SQL, logins anômalos, login de localizações desconhecidas, privilégios abusivos. Justificativa: detecção gerenciada com baixa sobrecarga operacional; complementa os controles de rede.
• Resposta a alertas: Roteie para Logic Apps, e-mail, SIEM. Crie playbooks para triagem, suspensão de usuário, revogação de token e restrição do firewall. Justificativa: a resposta codificada reduz o tempo médio de contenção (MTTC).

Segurança do Azure Cosmos DB

• Chaves e tokens: As chaves primárias/secundárias são de alto privilégio; rotacione-as regularmente. Prefira o RBAC do Azure AD para operações no plano de dados com funções como Cosmos DB Built-in Data Contributor/Reader. Justificativa: acesso vinculado à identidade com Acesso Condicional (CA) e auditoria.
• Controles de rede: Lista de permissões (allow list) no firewall de IP para contingência; Endpoints Privados como o caminho padrão; desabilite o acesso público se for viável. Justificativa: controle de caminho garantido e validação de endpoint.
• Criptografia: Em repouso por padrão; habilite CMK para controle adicional. Justificativa: atende a requisitos externos de criptografia e à separação de funções.
• Logs de diagnóstico e métricas: Habilite DataPlaneRequests, ControlPlaneRequests e categorias específicas da API (por exemplo, MongoRequests). Justificativa: observabilidade de ponta a ponta para padrões de acesso, throttling e solicitações anômalas.

Controles de Monitoramento, Classificação e Exfiltração

Segredos e strings de conexão apoiados pelo Key Vault

• Use identidades gerenciadas para recuperar segredos/chaves em tempo de execução; nunca armazene segredos no código ou em configurações. Justificativa: elimina a proliferação de credenciais e a necessidade de rotação de segredos nas aplicações.
• Referência do Key Vault no App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Prefira tokens de acesso do Azure AD para SQL em vez de strings de conexão baseadas em segredos, quando possível. Justificativa: políticas e revogação mais robustas.

Proteção da informação e classificação de dados

• Rótulos de sensibilidade do Microsoft Purview Information Protection: Aplique rótulos com criptografia e direitos de uso para documentos e e-mails; integre com a rotulagem automática. Justificativa: proteção persistente que ultrapassa os limites do armazenamento.
• SQL Information Protection (Azure SQL): Use a descoberta e classificação de dados nativa, recomende rótulos em colunas e exporte para o Purview. Justificativa: governança centralizada e política consistente em todo o patrimônio de dados.

Controles de exfiltração de dados e padrões de acesso seguro

• Priorize o Private Link: Para Storage, SQL e Cosmos DB. Desabilite os endpoints públicos. Justificativa: impede o acesso pela internet pública e força a origem do tráfego em VNets aprovadas.
• Filtragem de egresso: Use o Azure Firewall com tags de FQDN e regras DNAT que permitam apenas os endpoints do Azure necessários; adicione políticas de endpoint de serviço onde o Private Link for impraticável. Justificativa: a lista de permissões de saída (allow-listing) bloqueia o vazamento de dados para endpoints controlados por invasores.
• Regras de instância de recurso: Para o firewall do Storage, permita o acesso apenas de instâncias de recursos confiáveis específicas (por exemplo, um workspace do Synapse). Justificativa: vincula o acesso a produtores/consumidores conhecidos, não apenas a redes.
• Fortalecimento de SAS (Hardening): Use SAS de delegação de usuário sempre que possível, limite a HTTPS, restrinja IPs, use permissões mínimas e os menores tempos de vida; vincule a políticas de acesso armazenadas para permitir a revogação. Justificativa: reduz o uso indevido de tokens e simplifica a invalidação de emergência.
• AKS e endpoints de serviço: Se depender de endpoints de serviço, use o Azure CNI para que os pods obtenham IPs da VNet e herdem o acesso do endpoint. Justificativa: conecta o tráfego de contêineres aos controles nativos da VNet; caso contrário, os endpoints não se aplicam ao tráfego de pods com NAT.
• Logging e análise: Habilite os logs de diagnóstico do Storage, SQL e Cosmos DB para o Log Analytics; crie alertas para volume de dados anômalo, picos na emissão de SAS e erros 403 frequentes. Justificativa: detecção precoce de tentativas de exfiltração.

Cenário de Problema Prático

O Spotify precisa impedir a exfiltração de dados de sub-redes de desenvolvedores e de cargas de trabalho do AKS para endpoints de Storage e SQL não autorizados, ao mesmo tempo em que permite que pipelines de CI/CD executem testes de integração.

1. Desabilite o acesso à rede pública e crie Private Endpoints para todas as contas de Storage e servidores Azure SQL de produção. Justificativa: Força todos os fluxos do plano de dados a passarem pelo Private Link, eliminando o ingresso/egresso público e permitindo a aplicação rigorosa da origem via VNets e DNS privado.

2. Configure zonas de DNS privado com registros A mapeando os FQDNs dos recursos de armazenamento e banco de dados para os IPs dos private endpoints; vincule todas as VNets necessárias. Justificativa: Impede o vazamento de DNS para endpoints públicos e garante que os clientes resolvam para os recursos privados pretendidos.

3. Nos firewalls do Storage, adicione regras de instância de recurso apenas para as identidades do cluster AKS de produção e do scale set dos agentes de build; defina a ação padrão como negar (deny). Justificativa: Mesmo dentro da mesma VNet, apenas identidades de recursos aprovadas podem acessar a conta, impedindo o movimento lateral e a exfiltração a partir de cargas de trabalho não confiáveis.

4. Imponha o uso do Azure CNI no AKS e habilite endpoints de serviço com políticas de endpoint de serviço para permitir que os namespaces de desenvolvimento acessem apenas uma conta de armazenamento dedicada de não produção. Justificativa: Os pods de desenvolvimento obtêm IPs da VNet para que as políticas de rede se apliquem; as políticas de endpoint restringem qualquer tráfego não privado estritamente às contas autorizadas.

5. Substitua as chaves compartilhadas por RBAC do Azure AD para Blob e Queue no código da aplicação; onde o compartilhamento for inevitável para testes, emita SAS de delegação de usuário com políticas de acesso armazenadas e expiração de 1 hora. Justificativa: Tokens vinculados à identidade são auditáveis e revogáveis; SAS de curta duração minimiza o risco se um token for exposto nos logs de build.

6. Habilite o Defender for SQL com detecção de ameaças e Avaliação de Vulnerabilidades (Vulnerability Assessment); encaminhe alertas e logs de auditoria do SQL para um workspace central do Log Analytics com Logic Apps automatizados para triagem (desabilitar usuário, revogar sessões, adicionar negação temporária no firewall). Justificativa: As detecções gerenciadas aceleram a contenção de injeção de SQL e acessos anômalos, enquanto os playbooks padronizam e agilizam a resposta.

7. Use o Key Vault para a CMK (Chave Gerenciada pelo Cliente) que protege o TDE e os escopos de criptografia do Storage; habilite a exclusão reversível (soft delete) e a proteção contra limpeza (purge protection); rotacione as chaves trimestralmente e atualize as referências dos recursos para a versão mais recente da chave. Justificativa: O controle criptográfico externalizado com rotação segura atende aos requisitos de conformidade e reduz o risco de erro operacional.

8. Classifique colunas sensíveis no Azure SQL com o SQL Information Protection e integre ao Microsoft Purview; aplique rótulos de sensibilidade do MIP para exportações subsequentes. Justificativa: A rotulagem persistente acompanha as extrações de dados, limitando o uso indevido e permitindo que ferramentas de DLP apliquem controles em diferentes ferramentas e dispositivos.

9. Bloqueie o tráfego de egresso com o Azure Firewall para permitir apenas os serviços do Azure necessários para build/teste, usando tags de FQDN para Storage e SQL e negando tráfego de saída HTTP(S) com curingas (wildcard). Justificativa: O modelo de segurança positivo garante que o tráfego possa alcançar apenas endpoints aprovados, impedindo que os dados saiam para domínios de invasores.

Esta sequência impede o acesso público, restringe quem e o que pode acessar os dados, vincula o acesso a identidades em vez de segredos e operacionaliza o monitoramento e a resposta rápida — tudo isso enquanto preserva a velocidade do desenvolvedor por meio de exceções com escopo e tempo definidos.

← Segurança de Computação · Todos os domínios · Gerenciamento de Chaves →

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

Navegar Microsoft →