Laboratório de Troubleshooting: Configure access to service endpoints
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que VMs em uma subnet chamada snet-app-prod pararam de acessar um Azure Storage Account após uma janela de manutenção realizada na véspera. O engenheiro responsável confirma que nenhuma alteração foi feita diretamente no Storage Account. Durante a manutenção, foram realizadas as seguintes atividades: atualização do NSG associado à subnet, redimensionamento de duas VMs e migração da subnet para um endereço CIDR menor (10.1.2.0/26, antes era 10.1.2.0/24).
Ao verificar as configurações atuais, o engenheiro observa:
# Saída do comando az network vnet subnet show
{
"addressPrefix": "10.1.2.0/26",
"serviceEndpoints": [],
"networkSecurityGroup": {
"id": "/subscriptions/.../nsg-app-prod"
}
}
O Storage Account está configurado com a seguinte regra de rede:
{
"virtualNetworkRules": [
{
"virtualNetworkResourceId": "/subscriptions/.../snet-app-prod",
"action": "Allow",
"state": "networkSourceDeleted"
}
],
"defaultAction": "Deny"
}
Qual é a causa raiz da falha de acesso?
A) O NSG foi atualizado durante a manutenção e está bloqueando o tráfego de saída para o Storage Account na porta 443.
B) A operação de redimensionamento do CIDR da subnet removeu automaticamente os Service Endpoints configurados, e o Storage Account ainda exige que a subnet autorizada tenha um Service Endpoint ativo.
C) O Storage Account detectou que a subnet de origem foi modificada e entrou em estado de quarentena, exigindo reautorização manual pelo portal do Azure.
D) A regra de rede virtual no Storage Account ficou em estado inválido porque o Resource ID da subnet foi alterado quando o CIDR foi modificado, e o Service Endpoint não existe mais na subnet.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Service Endpoint para Microsoft.Storage foi removido da subnet snet-data-01 durante uma operação de reconfiguração de rede realizada por outro membro da equipe. O Storage Account em questão está configurado com defaultAction: Deny e possui apenas uma regra de rede virtual referenciando snet-data-01. O ambiente é de produção e o Storage Account é utilizado por um processo batch crítico que executa a cada 30 minutos. O próximo ciclo ocorre em 12 minutos.
A equipe possui as permissões necessárias para alterar configurações de subnet e de Storage Account. Não há janela de manutenção aberta. A política interna da empresa exige abertura de change request para alterações em produção, exceto em casos de incidente ativo com impacto confirmado em produção.
Qual é a ação correta a tomar neste momento?
A) Abrir um change request formal antes de qualquer ação, pois a política interna não permite alterações em produção fora de janela, mesmo com impacto iminente.
B) Reabilitar o Service Endpoint para Microsoft.Storage na subnet snet-data-01 imediatamente, registrando a ação como incidente ativo dado o impacto confirmado em produção.
C) Alterar temporariamente o Storage Account para defaultAction: Allow até que o change request seja aprovado, restaurando o Service Endpoint posteriormente.
D) Criar uma nova subnet com o Service Endpoint configurado e atualizar a regra de rede virtual do Storage Account para referenciar a nova subnet antes do próximo ciclo batch.
Cenário 3 — Causa Raiz
Um desenvolvedor relata que uma aplicação hospedada em VMs na subnet snet-backend consegue acessar normalmente o Azure Key Vault e o Azure Service Bus, ambos com Service Endpoints configurados e regras de rede virtual correspondentes. No entanto, a mesma aplicação falha ao tentar acessar um Azure SQL Database que também possui Service Endpoint e regra de rede virtual configurados de forma aparentemente idêntica.
O desenvolvedor informa que o banco de dados foi migrado de brazilsouth para eastus2 há três dias, logo após a última implantação bem-sucedida da aplicação. O time de banco de dados confirma que atualizou o connection string na aplicação com o novo FQDN. O time de rede confirma que o NSG da subnet permite saída na porta 1433 para qualquer destino.
A configuração do Service Endpoint na subnet é:
{
"serviceEndpoints": [
{ "service": "Microsoft.Sql", "locations": ["brazilsouth"] },
{ "service": "Microsoft.KeyVault", "locations": ["*"] },
{ "service": "Microsoft.ServiceBus", "locations": ["*"] }
]
}
Qual é a causa raiz da falha de acesso ao SQL Database?
A) O Azure SQL Database em eastus2 requer que a regra de rede virtual seja recriada após uma migração de região, pois o Resource ID do servidor muda com a migração.
B) O NSG libera apenas saída na porta 1433, mas o Azure SQL Database requer também comunicação na porta 11000-11999 para roteamento de gateway, que está bloqueada.
C) O Service Endpoint para Microsoft.Sql está configurado apenas para a região brazilsouth, não cobrindo a nova localização do banco de dados em eastus2.
D) O connection string foi atualizado mas o cache DNS das VMs ainda resolve o antigo FQDN, redirecionando conexões para o servidor original que não existe mais.
Cenário 4 — Impacto Colateral
Para resolver um problema de acesso, um engenheiro modifica a configuração do Service Endpoint na subnet snet-shared, alterando o campo locations de ["brazilsouth"] para ["*"] no endpoint Microsoft.Storage. A alteração resolve o problema imediatamente e o acesso ao Storage Account na nova região é restabelecido.
Dois dias depois, o time de segurança abre um alerta informando que dados de uma aplicação em snet-shared estão sendo acessados a partir de uma região inesperada e que o modelo de confinamento regional de dados pode ter sido comprometido.
Qual consequência a alteração de locations para "*" causou diretamente?
A) O Storage Account passou a aceitar conexões de qualquer origem na internet, pois o valor * no Service Endpoint remove as restrições de rede virtual configuradas no firewall do serviço.
B) O Service Endpoint passou a rotear tráfego pelo backbone da Microsoft para instâncias do Storage em qualquer região, potencialmente permitindo que a aplicação acesse Storage Accounts em regiões fora da política de residência de dados.
C) O valor * no campo locations desabilita a otimização de roteamento pelo backbone, fazendo o tráfego passar novamente pela internet pública e expondo os dados em trânsito.
D) A alteração para * replicou automaticamente as regras de rede virtual do Storage Account para todas as regiões do Azure, criando pontos de acesso não autorizados em outras geografias.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
Explicação:
A pista decisiva está na saída do comando que mostra "serviceEndpoints": [] e no estado "networkSourceDeleted" na regra do Storage Account. Esses dois sinais juntos confirmam que o Service Endpoint foi removido da subnet e que o Storage Account reconheceu a subnet como uma origem que não existe mais em estado válido.
A operação de redimensionamento de CIDR em uma subnet no Azure exige que a subnet seja reconfigurada, o que pode resultar na remoção de Service Endpoints. Quando o Service Endpoint deixa de existir na subnet, o Storage Account marca a regra de rede virtual correspondente como networkSourceDeleted, estado que efetivamente bloqueia o tráfego mesmo que a regra ainda apareça listada.
A informação sobre o redimensionamento de duas VMs é propositalmente irrelevante e não tem relação com Service Endpoints ou regras de rede. O foco no NSG como distrator é um erro clássico de diagnóstico: o NSG pode bloquear tráfego, mas a saída do subnet show mostrando serviceEndpoints: [] e o estado da regra no Storage Account são evidências suficientes para descartar o NSG como causa raiz antes de investigá-lo.
O distrator mais perigoso é a alternativa A: focar no NSG sem examinar o estado do Service Endpoint levaria o engenheiro a criar regras de NSG desnecessárias enquanto o problema real permanece sem correção.
Gabarito — Cenário 2
Resposta: B
Explicação:
O cenário apresenta restrições claras: impacto confirmado em produção, processo crítico com execução iminente em 12 minutos, e uma política interna que explicitamente excepciona incidentes ativos com impacto confirmado. A combinação dessas informações indica que a exceção à política se aplica e que a ação correta é restaurar o Service Endpoint imediatamente, documentando como incidente.
A alternativa A ignora a exceção explícita da política para incidentes ativos. A alternativa C resolve o sintoma de forma arriscada: alterar defaultAction para Allow expõe o Storage Account a acessos não autorizados de qualquer origem enquanto o change request tramita, o que representa um risco de segurança desproporcional. A alternativa D seria tecnicamente viável em outro contexto, mas criar uma nova subnet e atualizar regras em menos de 12 minutos em produção, sem janela, é mais arriscado e demorado do que a correção direta.
A decisão correta equilibra urgência, impacto e conformidade com a política: a exceção existe exatamente para esse tipo de situação.
Gabarito — Cenário 3
Resposta: C
Explicação:
A configuração da subnet mostra explicitamente que Microsoft.Sql está habilitado apenas para "locations": ["brazilsouth"], enquanto o banco de dados foi migrado para eastus2. Isso significa que o tráfego em direção ao SQL em eastus2 não é coberto pelo Service Endpoint, e portanto não segue o roteamento pelo backbone da Microsoft nem é reconhecido pelo firewall do banco como originado de uma subnet autorizada.
O contraste com Key Vault e Service Bus, que usam "*" e funcionam normalmente, é a pista estrutural que confirma o diagnóstico: o problema não é de NSG, DNS ou regra de rede virtual, mas de cobertura regional do Service Endpoint.
A informação sobre o connection string atualizado é propositalmente incluída para distrair: ela é relevante para problemas de resolução de nome, mas o cenário não apresenta nenhum sintoma compatível com falha de DNS (como timeout de resolução ou erro de host não encontrado). O distrator mais perigoso é a alternativa D, pois problemas de cache DNS são comuns após migrações e o enunciado menciona explicitamente a atualização do connection string, o que poderia levar o leitor a concluir que o cache ainda não foi propagado, ignorando a evidência direta da configuração do Service Endpoint.
Gabarito — Cenário 4
Resposta: B
Explicação:
O campo locations em um Service Endpoint define em quais regiões do Azure o roteamento pelo backbone da Microsoft é ativado para aquele serviço. Ao alterar para "*", o Service Endpoint passa a cobrir todas as regiões, o que significa que a aplicação pode agora rotear tráfego de forma otimizada para Storage Accounts em qualquer região do Azure.
Isso não altera as regras de firewall do Storage Account original, mas permite que a aplicação alcance outros Storage Accounts em outras regiões que também estejam configurados para aceitar a subnet. Em ambientes com políticas de residência de dados, isso pode violar restrições regulatórias ou contratuais que exigem que dados sejam acessados apenas dentro de uma determinada geografia.
A alternativa A é o distrator mais perigoso porque mistura dois conceitos: o locations do Service Endpoint e as regras de firewall do serviço de destino. Esses são controles independentes. O locations: * amplia a cobertura do roteamento pelo backbone, não modifica as regras de acesso do Storage Account. A alternativa C inverte a lógica de funcionamento do campo locations. A alternativa D descreve um comportamento que não existe: Service Endpoints não replicam regras de firewall entre regiões.
Árvore de Troubleshooting: Configure access to service endpoints
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico objetiva |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de ausência de acesso. Responda cada pergunta com base no que é observável diretamente nas configurações do Azure (portal, CLI ou ARM), seguindo o caminho que corresponde ao estado real do ambiente. Cada ramificação elimina uma hipótese e direciona a investigação para a causa mais provável, evitando ações corretivas prematuras antes do diagnóstico estar concluído.