Laboratório de Troubleshooting: Configure service endpoint policies
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs em uma sub-rede chamada snet-app-prod pararam de acessar uma conta de armazenamento chamada storagecontosoapp após uma janela de manutenção na última sexta-feira. A VNet está na região eastus2. O time de infraestrutura confirma que nenhuma regra de NSG foi alterada durante a manutenção. O service endpoint para Microsoft.Storage permanece habilitado na sub-rede.
Durante a investigação, um engenheiro executa o seguinte comando e obtém a saída abaixo:
az network vnet subnet show \
--resource-group rg-prod \
--vnet-name vnet-prod \
--name snet-app-prod \
--query "{endpoints:serviceEndpoints, policies:serviceEndpointPolicies}"
{
"endpoints": [
{
"provisioningState": "Succeeded",
"service": "Microsoft.Storage",
"locations": ["eastus2", "eastus"]
}
],
"policies": [
{
"id": "/subscriptions/aaaa-bbbb/resourceGroups/rg-network/providers/Microsoft.Network/serviceEndpointPolicies/policy-storage-prod"
}
]
}
Em seguida, o engenheiro inspeciona a policy e encontra:
{
"serviceEndpointPolicyDefinitions": [
{
"service": "Microsoft.Storage",
"serviceResources": [
"/subscriptions/aaaa-bbbb/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/storagecontosobackup"
]
}
]
}
O time também menciona que, durante a manutenção, foi criada uma nova conta de armazenamento para backup e que a política de acesso da conta storagecontosoapp não foi modificada.
Qual é a causa raiz da falha de acesso à conta storagecontosoapp?
A) O service endpoint na sub-rede não está configurado para a região correta, pois eastus2 e eastus são tratadas separadamente
B) A service endpoint policy associada à sub-rede lista apenas a conta de backup storagecontosobackup, excluindo a conta storagecontosoapp
C) A policy foi criada no resource group rg-network, diferente do resource group rg-prod onde a sub-rede está, causando incompatibilidade de escopo
D) A política de acesso da conta storagecontosoapp foi revogada durante a criação da nova conta de backup, bloqueando o tráfego
Cenário 2 — Decisão de Ação
A causa de uma falha de conectividade foi identificada: uma service endpoint policy em produção foi atualizada incorretamente por um operador e agora referencia apenas um resource group de desenvolvimento, bloqueando o acesso de todas as sub-redes de produção às contas de armazenamento corretas. Há 14 aplicações críticas afetadas. O ambiente de produção não pode ser desligado. A equipe de segurança exige que qualquer alteração na policy passe por aprovação formal antes de ser aplicada, mas existe um processo de emergência que permite alterações imediatas com registro posterior.
Qual é a ação correta a tomar neste momento?
A) Remover a associação entre a service endpoint policy e todas as sub-redes de produção imediatamente, restaurando acesso irrestrito temporariamente enquanto a correção formal é preparada
B) Acionar o processo de emergência, corrigir os serviceResources da policy para referenciar os resource groups de produção corretos e registrar a alteração após a aplicação
C) Criar uma nova service endpoint policy com a configuração correta e aguardar aprovação formal antes de associá-la às sub-redes, mantendo a policy incorreta no lugar
D) Reverter a policy para a versão anterior via Azure Resource Manager exportando o template antes da alteração incorreta e reimplantando via pipeline de CI/CD
Cenário 3 — Causa Raiz
Um desenvolvedor relata que uma aplicação em uma sub-rede snet-analytics consegue acessar normalmente o Azure Blob Storage, mas não consegue acessar um Azure Data Lake Storage Gen2 chamado dlscontosoanalytics na mesma assinatura. Ambas as contas estão na região westus2, mesma região da VNet. O desenvolvedor menciona que o Data Lake foi criado há três semanas e que antes dessa data tudo funcionava normalmente. Ele também menciona que a equipe de redes adicionou uma service endpoint policy à sub-rede há quatro semanas como parte de um projeto de hardening.
A sub-rede tem o seguinte estado:
az network vnet subnet show \
--resource-group rg-analytics \
--vnet-name vnet-analytics \
--name snet-analytics \
--query "serviceEndpointPolicies"
[
{
"id": "/subscriptions/cccc-dddd/resourceGroups/rg-network/providers/Microsoft.Network/serviceEndpointPolicies/policy-hardening-v1"
}
]
A inspeção da policy revela:
{
"serviceEndpointPolicyDefinitions": [
{
"service": "Microsoft.Storage",
"serviceResources": [
"/subscriptions/cccc-dddd/resourceGroups/rg-analytics/providers/Microsoft.Storage/storageAccounts/blobcontosoanalytics"
]
}
]
}
O desenvolvedor acredita que o problema começou quando o Data Lake foi criado, e que talvez o tipo de serviço Microsoft.Storage não cubra o Data Lake Storage Gen2.
Qual é a causa raiz do problema?
A) O tipo de serviço Microsoft.Storage não cobre o Azure Data Lake Storage Gen2, sendo necessário um tipo separado na policy
B) A service endpoint policy foi adicionada há quatro semanas e está bloqueando todo o tráfego de armazenamento, inclusive o Blob Storage, contradizendo o relato do desenvolvedor
C) A policy lista explicitamente apenas a conta blobcontosoanalytics, e o Data Lake Storage Gen2 dlscontosoanalytics é uma conta de armazenamento distinta não incluída na lista de permissões
D) O Data Lake Storage Gen2 requer que o service endpoint seja habilitado especificamente para Microsoft.DataLake, e não para Microsoft.Storage
Cenário 4 — Impacto Colateral
Uma equipe identifica que uma service endpoint policy em uma sub-rede está mais restritiva do que o necessário. Para resolver rapidamente, um administrador remove a associação da policy da sub-rede via portal do Azure. O acesso às contas de armazenamento é imediatamente restaurado para todas as aplicações na sub-rede.
Qual consequência secundária essa ação pode causar?
A) O service endpoint para Microsoft.Storage é automaticamente desabilitado da sub-rede quando a policy é desassociada, interrompendo novamente o tráfego após alguns minutos
B) A sub-rede passa a ter acesso irrestrito a qualquer conta de armazenamento do Azure via service endpoint, incluindo contas de outras organizações e outros tenants
C) Todas as outras service endpoint policies associadas a outras sub-redes na mesma VNet são automaticamente desassociadas como efeito cascata
D) A remoção da policy invalida as rotas do service endpoint na tabela de rotas efetivas da sub-rede, forçando o tráfego de armazenamento a sair pela internet
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída da inspeção da policy deixa claro que serviceResources contém apenas a conta storagecontosobackup, criada durante a manutenção. Como a service endpoint policy funciona como uma allowlist explícita, qualquer conta não listada é bloqueada automaticamente. A conta storagecontosoapp, que era o destino original do tráfego, não está na lista e por isso o acesso foi negado.
A pista decisiva no enunciado é a sequência temporal: a policy foi atualizada durante a manutenção para incluir a nova conta de backup, mas a conta original não foi mantida na lista. Isso é um erro operacional clássico de substituição em vez de adição.
A informação irrelevante no cenário é a menção de que a política de acesso da conta storagecontosoapp não foi modificada. Essa informação leva o leitor a descartar esse vetor, mas o foco correto está na policy de service endpoint, não na política de acesso da conta em si.
O distrator C explora um equívoco comum: a localização do recurso de policy em um resource group diferente da sub-rede não causa incompatibilidade. A policy é associada à sub-rede por ID de recurso, independentemente do resource group onde está criada. O distrator mais perigoso é D, pois direciona o diagnóstico para a conta de armazenamento em vez de para a policy de rede, o que levaria a uma investigação completamente equivocada.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta restrições explícitas: produção não pode ser desligada, a segurança exige aprovação formal, mas existe um processo de emergência para situações críticas. Com 14 aplicações afetadas, a situação se qualifica como emergência. A ação correta é usar o processo disponível para isso: corrigir a policy imediatamente e registrar a alteração posteriormente.
O distrator A é tecnicamente válido como medida de contingência, mas viola o princípio de segurança ao remover completamente a política de controle de acesso, expondo as sub-redes de produção a acesso irrestrito ao armazenamento. É uma ação mais drástica do que o necessário.
O distrator C respeita o processo formal, mas ignora a urgência da situação e o fato de que um processo de emergência existe exatamente para esse tipo de caso. Manter a policy incorreta no lugar enquanto se aguarda aprovação prolonga o impacto desnecessariamente.
O distrator D seria válido se um template anterior existisse e estivesse acessível, mas introduz latência operacional desnecessária via pipeline quando a correção direta nos serviceResources é mais rápida e igualmente eficaz.
Gabarito — Cenário 3
Resposta: C
O Azure Data Lake Storage Gen2 é implementado sobre o Azure Blob Storage e é tratado pelo Azure como uma conta de armazenamento comum do tipo Microsoft.Storage. Portanto, o tipo de serviço da policy já cobriria o Data Lake, tornando a hipótese do desenvolvedor incorreta.
O problema real está na estrutura da policy: ela lista apenas a conta blobcontosoanalytics em serviceResources. Quando o Data Lake dlscontosoanalytics foi criado três semanas atrás, ninguém atualizou a policy para incluí-lo. Como a policy funciona como allowlist, o tráfego para o Data Lake é bloqueado, enquanto o tráfego para o Blob Storage listado continua funcionando normalmente.
A informação irrelevante é a crença do desenvolvedor de que Microsoft.Storage não cobre o Data Lake Storage Gen2. Esse raciocínio é plausível para quem não conhece a implementação interna, mas leva ao distrator A, que seria o erro de diagnóstico mais comum e mais perigoso: se a equipe agir com base nessa hipótese, tentará adicionar um tipo de serviço inexistente e não resolverá o problema real.
O distrator B pode ser eliminado pelo próprio relato do desenvolvedor, que confirma que o Blob Storage ainda funciona. Se a policy bloqueasse tudo, ambos estariam inacessíveis.
Gabarito — Cenário 4
Resposta: B
Quando uma service endpoint policy é desassociada de uma sub-rede, o service endpoint em si permanece habilitado. O que muda é que a restrição de destino é removida. Sem a policy, o tráfego da sub-rede via service endpoint pode alcançar qualquer conta de armazenamento do Azure, incluindo contas de outros tenants e outras organizações. Esse é exatamente o risco que as service endpoint policies foram criadas para mitigar.
O distrator A representa um equívoco sobre o acoplamento entre service endpoints e policies. São recursos independentes: remover a policy não afeta o service endpoint. O distrator C descreve um comportamento de efeito cascata que não existe na plataforma; policies são associadas individualmente a cada sub-rede. O distrator D também está incorreto: as rotas do service endpoint são determinadas pelo service endpoint habilitado na sub-rede, não pela policy associada a ela.
O impacto colateral correto é o mais silencioso e perigoso: nenhuma mensagem de erro, nenhuma interrupção de serviço, mas uma janela de exposição significativa enquanto a correção não é reaplicada.
Árvore de Troubleshooting: Configure service endpoint policies
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial ou falha reportada |
| Azul | Pergunta diagnóstica objetiva |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo a falha observada. A cada nó de decisão, verifique o estado atual do ambiente antes de avançar, nunca assuma a resposta. Siga o caminho que corresponde ao que você observou, sem pular níveis. Quando atingir um nó vermelho, você identificou a causa raiz. O nó verde imediatamente ligado a ele indica a ação correta. Se chegar ao nó laranja de validação sem resolução, o problema está fora do escopo das service endpoint policies e exige investigação em outra camada da rede.