Laboratório de Troubleshooting: Choose when to use a service endpoint
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relatou que uma aplicação em produção parou de gravar logs em um Azure Storage Account após uma mudança de infraestrutura realizada na véspera. A aplicação roda em VMs dentro da subnet snet-app (10.0.2.0/24) da VNet vnet-prod, localizada em East US.
O engenheiro responsável pela mudança confirma que habilitou o Service Endpoint Microsoft.Storage na subnet e atualizou o firewall do Storage Account conforme o registro abaixo:
Storage Account: stlogsprod001
Firewall and virtual networks:
Allow access from: Selected networks
Virtual Networks:
- vnet-prod / snet-app [STATUS: Provisioning]
Firewall (IP Rules): nenhuma regra
Exceptions: Allow trusted Microsoft services: ON
O engenheiro também menciona que o NSG da subnet foi atualizado horas antes para bloquear tráfego de saída na porta 445, como parte de uma política de segurança para desabilitar SMB. A aplicação usa o SDK do Azure para gravar blobs via HTTPS na porta 443.
Qual é a causa raiz da falha de gravação?
A) O NSG está bloqueando a porta 445, o que impede a comunicação com o Storage Account mesmo via SDK.
B) A entrada da VNet no firewall do Storage Account ainda está em estado de provisionamento e ainda não entrou em vigor.
C) O Service Endpoint Microsoft.Storage não cobre operações de gravação de blob, apenas leitura.
D) A exceção "Allow trusted Microsoft services" está sobrescrevendo a regra de VNet e causando conflito de roteamento.
Cenário 2 — Decisão de Ação
A causa de um incidente em produção foi identificada: o Service Endpoint Microsoft.Sql estava habilitado na subnet errada. A aplicação reside na subnet snet-api, mas o endpoint foi habilitado em snet-mgmt. O firewall do Azure SQL Server está configurado para aceitar apenas snet-mgmt, o que faz com que todas as conexões da aplicação sejam rejeitadas com erro 40615.
O ambiente tem as seguintes restrições no momento:
- São 14h de uma sexta-feira e há um congelamento de mudanças ativo até segunda-feira
- A aplicação está fora do ar para os usuários finais
- O time de segurança precisa aprovar qualquer alteração em NSGs e Service Endpoints
- O time de DBA tem acesso ao portal e pode modificar o firewall do SQL Server sem aprovação de segurança, pois isso está dentro do escopo de permissões deles
- Habilitar o Service Endpoint na subnet correta exigiria aprovação do time de segurança
Qual é a ação correta a tomar neste momento?
A) Solicitar aprovação emergencial ao time de segurança para habilitar o Service Endpoint em snet-api e atualizar o firewall do SQL Server.
B) Pedir ao time de DBA que adicione o IP público das VMs da snet-api como regra de firewall temporária no SQL Server, restaurando o acesso enquanto a correção definitiva aguarda aprovação.
C) Mover as VMs da aplicação para snet-mgmt temporariamente, já que o endpoint está habilitado nessa subnet.
D) Remover a restrição de VNet do firewall do SQL Server e abrir para "All networks" temporariamente, para restaurar o acesso com o menor número de aprovações possível.
Cenário 3 — Causa Raiz
Um analista está investigando por que uma VM em snet-backend (10.1.1.0/24) da VNet vnet-hub não consegue acessar um Azure Key Vault. Ao executar o comando abaixo, ele observa o seguinte:
$ curl -I https://kv-producao.vault.azure.net/
curl: (6) Could not resolve host: kv-producao.vault.azure.net
O analista verifica a configuração da VNet e encontra:
VNet: vnet-hub (10.1.0.0/16) -- East US
Subnet: snet-backend (10.1.1.0/24)
Service Endpoints: Microsoft.KeyVault
DNS Servers: 10.1.0.4 (servidor DNS interno)
Key Vault: kv-producao
Firewall:
Allow access from: Selected networks
Virtual Networks:
- vnet-hub / snet-backend [STATUS: Succeeded]
Public network access: Enabled
O analista nota também que a VNet tem peering configurado com vnet-spoke, e que essa VNet spoke não tem Service Endpoints habilitados. Ele suspeita que o problema esteja relacionado ao peering.
Qual é a causa raiz do erro observado?
A) O Service Endpoint não está funcionando corretamente porque a VNet tem peering ativo, o que cria conflito de roteamento.
B) O servidor DNS interno na VNet não está conseguindo resolver o hostname do Key Vault, impedindo a conexão antes mesmo de o tráfego ser roteado.
C) O Key Vault está com Public network access: Enabled, o que desativa o suporte a Service Endpoints.
D) O Service Endpoint Microsoft.KeyVault foi habilitado na subnet, mas o status Succeeded no firewall do Key Vault indica que a configuração foi sobrescrita por uma política de rede.
Cenário 4 — Sequência de Diagnóstico
Uma equipe recebeu o seguinte relato: "A aplicação em produção retorna erro 403 ao tentar acessar o Azure Storage Account. O problema começou após uma reorganização de subnets realizada durante a janela de manutenção de ontem à noite."
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se o Service Endpoint
Microsoft.Storageestá habilitado na subnet atual da aplicação - Confirmar se a aplicação está de fato rodando na subnet que se supõe que ela esteja
- Verificar quais VNets e subnets estão autorizadas no firewall do Storage Account
- Testar a conectividade da aplicação com o Storage Account usando o SDK e coletar o erro exato
- Verificar se houve alteração no NSG da subnet que possa estar bloqueando saída na porta 443
Qual sequência de diagnóstico é a mais adequada para este cenário?
A) 4 → 2 → 3 → 1 → 5
B) 1 → 3 → 2 → 5 → 4
C) 5 → 1 → 4 → 3 → 2
D) 2 → 4 → 3 → 1 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está visível no enunciado: o status da entrada de VNet no firewall do Storage Account é Provisioning, não Succeeded. Enquanto o provisionamento não é concluído, a regra ainda não está ativa e o Storage Account continua rejeitando conexões originadas daquela subnet, mesmo que o Service Endpoint já esteja habilitado do lado da VNet. As duas configurações precisam estar sincronizadas e ativas para que o acesso funcione.
A informação sobre o bloqueio da porta 445 é a armadilha de distração do cenário. A aplicação usa HTTPS na porta 443 para operações de blob via SDK, portanto o bloqueio de SMB é completamente irrelevante para o sintoma. O leitor que focou nessa informação provavelmente escolheu A, cometendo o erro clássico de associar o detalhe mais visível ao problema, sem verificar o estado real da configuração de rede.
Escolher A seria perigoso em produção: o engenheiro removeria uma política de segurança legítima sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A restrição central do cenário é o congelamento de mudanças combinado com a exigência de aprovação do time de segurança para alterações em Service Endpoints. A correção definitiva (habilitar o endpoint na subnet correta) está bloqueada por processo. Contudo, o enunciado informa explicitamente que o time de DBA pode modificar o firewall do SQL Server dentro do próprio escopo de permissões, sem aprovação adicional.
Adicionar o IP público das VMs como regra temporária no firewall do SQL Server é a única ação que restaura o serviço sem violar as restrições do ambiente. É uma solução de contorno controlada, dentro das permissões disponíveis, que não expõe o banco desnecessariamente.
A alternativa D é a mais perigosa: abrir o SQL Server para "All networks" expõe o banco de dados à internet pública, viola políticas de segurança e vai muito além do necessário para restaurar o acesso de uma única aplicação.
A alternativa C é tecnicamente incorreta: mover VMs entre subnets em produção durante um congelamento é uma mudança de infraestrutura de maior risco e impacto do que o problema original.
Gabarito — Cenário 3
Resposta: B
O erro Could not resolve host ocorre na camada de DNS, antes de qualquer tentativa de conexão TCP ou roteamento via Service Endpoint. Isso significa que o problema não está na configuração do Service Endpoint nem no firewall do Key Vault: o tráfego nunca chegou a ser roteado porque a resolução de nome falhou antes.
O servidor DNS interno (10.1.0.4) é o responsável pela resolução na VNet. Se esse servidor não tem um forwarder configurado corretamente para nomes públicos do Azure (como *.vault.azure.net), a resolução falha. Service Endpoints não alteram a resolução DNS; eles apenas influenciam o caminho do tráfego após a resolução ser bem-sucedida.
A suspeita do analista sobre o peering é a informação irrelevante do cenário. O peering com vnet-spoke não tem relação com a falha de DNS da snet-backend. O analista foi induzido a buscar uma causa complexa quando o erro já indicava claramente onde a falha estava.
A alternativa C é um distrator comum: Public network access: Enabled não desativa Service Endpoints; as duas configurações coexistem normalmente.
Gabarito — Cenário 4
Resposta: A
A sequência 4 → 2 → 3 → 1 → 5 representa o raciocínio diagnóstico correto para um erro 403 após reorganização de subnets.
O primeiro passo (4) é confirmar o sintoma real com precisão: coletar o erro exato da aplicação garante que estamos diagnosticando o problema correto antes de qualquer investigação. Em seguida (2), verificar onde a aplicação está realmente rodando é essencial, pois a reorganização de subnets pode ter movido recursos de forma inesperada. Com a subnet real confirmada, o passo seguinte (3) é verificar o firewall do Storage Account para saber quais subnets estão autorizadas. Então (1) confirma se o Service Endpoint está habilitado na subnet atual. Por último (5), o NSG é investigado como hipótese secundária, pois um erro 403 do Storage Account indica rejeição pela camada de autorização de rede, não bloqueio silencioso de porta.
A sequência B começa pelos controles de rede antes de confirmar onde a aplicação está, o que pode levar a investigar a subnet errada. A sequência D tem uma lógica aceitável, mas postergar a coleta do erro exato (passo 4) para depois de verificar a subnet atual é menos eficiente do que a sequência A, porque sem o erro confirmado qualquer achado posterior pode ser interpretado de forma imprecisa.
Árvore de Troubleshooting: Choose when to use a service endpoint
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão a verificar) |
| Laranja | Validação ou verificaçã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 identificando o tipo de sintoma observado: erro de autorização (403) ou falha de resolução de nome. A partir daí, responda cada pergunta de diagnóstico com base no que pode ser verificado diretamente no portal ou via CLI, avançando pelo caminho correspondente até chegar à causa ou à ação corretiva. Evite pular níveis: cada ramificação elimina uma classe de hipóteses antes de avançar para a próxima.