Laboratório de Troubleshooting: Configure service endpoints for Azure platform as a service (PaaS)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma aplicação hospedada em uma VM dentro da sub-rede snet-app (VNet vnet-prod, região East US) passou a receber erros ao tentar gravar arquivos em um Azure Storage Account. O ambiente estava funcionando corretamente até ontem à tarde.
O administrador verifica o Storage Account e encontra a seguinte configuração:
Networking > Firewalls and virtual networks
Public network access: Enabled from selected virtual networks and IP addresses
Virtual networks:
vnet-prod / snet-app Status: Succeeded
Firewall:
(nenhum IP adicionado)
Default action: Deny
Exceptions:
Allow trusted Microsoft services: Enabled
O service endpoint para Microsoft.Storage está listado como provisionado na sub-rede snet-app. A VM tem IP privado 10.1.1.10 e IP público associado 20.50.80.100. O NSG da sub-rede tem as seguintes regras de saída:
Priority Name Port Protocol Source Destination Action
100 Allow-HTTPS-Internet 443 TCP VirtualNetwork Internet Allow
200 Allow-Storage-Tag 443 TCP VirtualNetwork Storage Allow
65000 AllowVnetOutbound * * VirtualNetwork VirtualNetwork Allow
65001 AllowInternetOutbound * * * Internet Allow
65500 DenyAllOutbound * * * * Deny
O time de segurança informa que realizou ontem uma rotação das chaves de acesso do Storage Account. O administrador de rede informa que não houve nenhuma alteração nas configurações de VNet ou sub-rede.
Qual é a causa raiz da falha de acesso?
A) O service endpoint foi desabilitado inadvertidamente durante a rotação de chaves, pois esse processo reinicia as configurações de rede do Storage Account.
B) A aplicação está utilizando uma chave de acesso que foi invalidada pela rotação, fazendo com que as requisições sejam rejeitadas com erro de autenticação, não de rede.
C) A regra de NSG com prioridade 100 está interceptando o tráfego antes da regra específica da Service Tag Storage, redirecionando-o incorretamente para a internet.
D) O IP público da VM (20.50.80.100) não está listado no firewall do Storage Account, e o tráfego está sendo roteado pelo caminho público após a rotação de chaves.
Cenário 2 — Causa Raiz
Um administrador recebe o seguinte alerta: uma aplicação em produção hospedada em VMs na sub-rede snet-backend (VNet vnet-hub) não consegue mais acessar um Azure Key Vault. O Key Vault está configurado para aceitar conexões somente via service endpoint.
O administrador executa o seguinte comando para verificar o estado do endpoint:
az network vnet subnet show \
--resource-group rg-network \
--vnet-name vnet-hub \
--name snet-backend \
--query "serviceEndpoints"
Saída:
[
{
"locations": ["eastus"],
"provisioningState": "Succeeded",
"service": "Microsoft.KeyVault"
}
]
O administrador então verifica as regras de rede do Key Vault:
az keyvault network-rule list --name kv-prod-001 --resource-group rg-app
Saída:
{
"bypass": "AzureServices",
"defaultAction": "Deny",
"ipRules": [],
"virtualNetworkRules": [
{
"id": "/subscriptions/xxx/resourceGroups/rg-network/providers/Microsoft.Network/virtualNetworks/vnet-hub/subnets/snet-backend",
"ignoreMissingVnetServiceEndpoint": false
}
]
}
O time de infraestrutura informa que, há dois dias, a sub-rede snet-backend foi excluída e recriada com o mesmo nome e range de endereços para resolver um problema de configuração de NAT Gateway. O Service Level Agreement (SLA) do Key Vault é de 99,9% e não houve incidentes registrados no Azure Status.
Qual é a causa raiz da falha?
A) O NAT Gateway associado à sub-rede está interceptando o tráfego destinado ao Key Vault e alterando o IP de origem, fazendo com que o endpoint deixe de funcionar.
B) O service endpoint para Microsoft.KeyVault foi perdido quando a sub-rede foi recriada e, apesar de reaprovisionado com sucesso, o registro do recurso de sub-rede no Key Vault ainda aponta para o ID da sub-rede antiga, que não existe mais.
C) O campo ignoreMissingVnetServiceEndpoint: false está bloqueando o acesso porque o service endpoint está em estado de reprovisionamento após a recriação da sub-rede.
D) O bypass AzureServices configurado no Key Vault está em conflito com a regra de VNet, causando rejeição das conexões originadas de serviços internos da Azure.
Cenário 3 — Decisão de Ação
A causa do problema foi identificada: o Azure SQL Database de um ambiente de produção está aceitando conexões de qualquer endereço IP público porque o service endpoint foi habilitado na sub-rede snet-api, mas nenhuma regra de rede foi criada no SQL Database para restringir o acesso. O Default action continua como Allow.
O contexto operacional é o seguinte:
- A aplicação está em produção ativa com aproximadamente 800 usuários simultâneos
- Qualquer interrupção de conectividade ao banco de dados derruba a aplicação completamente
- O time de segurança exige que o acesso público seja bloqueado ainda hoje
- O administrador tem permissão para modificar as regras de firewall do SQL Database
- Não há janela de manutenção programada para as próximas 6 horas
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente o Default action do SQL Database para Deny, pois o service endpoint já garante que a sub-rede snet-api continuará com acesso e nenhuma aplicação será impactada.
B) Adicionar primeiro a regra de VNet para snet-api no firewall do SQL Database, validar que a aplicação mantém conectividade e somente então alterar o Default action para Deny.
C) Habilitar o Private Endpoint no SQL Database antes de qualquer alteração, pois o service endpoint não oferece segurança suficiente para ambientes de produção com esse perfil de acesso.
D) Aguardar a janela de manutenção das próximas 6 horas para realizar as alterações, pois modificar regras de firewall de banco de dados em produção sem janela programada viola boas práticas de ITIL.
Cenário 4 — Sequência de Diagnóstico
Uma VM na sub-rede snet-data não consegue acessar um Azure Storage Account. O service endpoint para Microsoft.Storage deveria estar habilitado. Um administrador precisa investigar o problema.
Os passos disponíveis para diagnóstico são:
[P1] Verificar se o Storage Account tem Default action configurado como Deny
e se a sub-rede snet-data está listada nas regras de VNet permitidas
[P2] Verificar se o service endpoint Microsoft.Storage está provisionado
com sucesso na sub-rede snet-data via az network vnet subnet show
[P3] Revisar as regras de saída do NSG associado à snet-data para confirmar
que o tráfego na porta 443 para a Service Tag Storage está permitido
[P4] Testar a conectividade a partir da VM usando curl ou Test-NetConnection
para confirmar se o problema é de rede ou de autenticação
[P5] Verificar os logs de diagnóstico do Storage Account (StorageBlobLogs)
para identificar se as requisições chegam ao serviço e com qual erro
Qual sequência representa a ordem correta de diagnóstico progressivo?
A) P4 → P2 → P1 → P3 → P5
B) P2 → P1 → P3 → P4 → P5
C) P1 → P3 → P2 → P5 → P4
D) P3 → P2 → P4 → P1 → P5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é a informação de que o time de segurança realizou uma rotação das chaves de acesso do Storage Account no dia anterior, exatamente quando o problema começou. A configuração de rede (service endpoint, regras de VNet, NSG) está intacta e correta, o que elimina qualquer causa de rede como hipótese principal.
A rotação de chaves invalida a chave anterior imediatamente. Se a aplicação ainda usa a chave antiga em sua configuração (string de conexão, variável de ambiente ou Azure Key Vault desatualizado), todas as requisições serão rejeitadas com erro de autenticação (403 AuthenticationFailed), não com erro de conectividade de rede. Esse sintoma é frequentemente confundido com falha de rede porque o efeito prático (acesso negado) parece idêntico.
A informação sobre o IP público da VM (20.50.80.100) é deliberadamente irrelevante: com o service endpoint ativo e a sub-rede listada corretamente nas regras de VNet, o roteamento é feito pelo backbone da Microsoft independentemente do IP público. A alternativa A inventa um comportamento inexistente (rotação de chaves não afeta configurações de rede). A alternativa C é incorreta porque a regra de prioridade 100 (Allow-HTTPS-Internet) e a regra 200 (Allow-Storage-Tag) não conflitam; o tráfego para o Storage via service endpoint corresponde à tag Storage, não ao destino genérico Internet. A alternativa D retoma o IP público como causa, ignorando que o endpoint está funcionando.
O distrator mais perigoso é a alternativa D, pois leva o administrador a adicionar um IP público no firewall do Storage Account como solução, o que agravaria a postura de segurança sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A causa raiz está na combinação de dois fatos declarados no enunciado: a sub-rede foi excluída e recriada há dois dias, e o campo ignoreMissingVnetServiceEndpoint está definido como false.
Quando uma sub-rede é recriada, ela recebe um novo Resource ID interno, mesmo que o nome e o range de endereços sejam idênticos. A regra de VNet no Key Vault referencia o Resource ID da sub-rede original, que não existe mais. Com ignoreMissingVnetServiceEndpoint: false, o Key Vault trata essa referência inválida como ausência de permissão e rejeita as conexões.
A saída do comando az keyvault network-rule list confirma isso: o campo id na virtualNetworkRules aponta para o caminho do recurso, e embora o nome seja o mesmo, o ID subjacente mudou. A solução é remover a regra antiga e adicionar novamente a sub-rede snet-backend recriada.
A informação sobre o SLA do Key Vault e a ausência de incidentes no Azure Status é deliberadamente irrelevante: serve para desviar o raciocínio para uma falha de serviço da Microsoft, quando a causa é local. A alternativa A é incorreta porque o NAT Gateway altera o IP de origem de tráfego de saída para a internet, mas o tráfego via service endpoint não passa pelo NAT Gateway. A alternativa C interpreta erroneamente o campo ignoreMissingVnetServiceEndpoint, que controla o comportamento quando o endpoint está ausente, não quando está em reprovisionamento. A alternativa D descreve um conflito inexistente entre bypass e regras de VNet.
Gabarito — Cenário 3
Resposta: B
A restrição crítica do cenário é a produção ativa com 800 usuários simultâneos e ausência de janela de manutenção. Alterar o Default action para Deny antes de confirmar que a regra de VNet está corretamente aplicada e funcional interromperia imediatamente toda a conectividade da aplicação ao banco de dados.
A sequência correta é: adicionar a regra de VNet para snet-api, validar que a aplicação continua operando normalmente com essa regra ativa e, somente após confirmação, alterar o Default action para Deny. Essa abordagem garante zero downtime para os usuários e atende à exigência de segurança do time ainda dentro do prazo.
A alternativa A comete o erro de assumir que o service endpoint garante automaticamente o acesso após o Deny, sem considerar que qualquer problema de propagação ou configuração durante a transição derrubaria a aplicação. A alternativa C é uma solução tecnicamente válida em outro contexto, mas introduz complexidade e tempo de implementação incompatíveis com a urgência e a ausência de janela. A alternativa D é o distrator mais perigoso em termos organizacionais: a exigência de segurança é para hoje, e aguardar 6 horas com o banco de dados exposto publicamente viola o requisito declarado explicitamente no cenário.
Gabarito — Cenário 4
Resposta: B
A sequência correta é P2 → P1 → P3 → P4 → P5, seguindo a lógica de diagnóstico progressivo do mais simples e fundamental para o mais específico e custoso.
O raciocínio correto é:
- P2 primeiro: verificar se o service endpoint existe e está com
provisioningState: Succeededé o pré-requisito de tudo. Se o endpoint não estiver provisionado, as demais verificações são irrelevantes. - P1 em seguida: confirmado o endpoint, verificar se o Storage Account tem a sub-rede listada e o
Default actionconfigurado corretamente. Essa é a causa mais comum de rejeição após o endpoint estar ativo. - P3 depois: com endpoint e regras de Storage corretos, investigar o NSG, que pode estar bloqueando o tráfego de saída para a Service Tag
Storage. - P4 na sequência: com as configurações validadas, testar conectividade real a partir da VM para confirmar se o problema persiste e se é de rede ou de autenticação.
- P5 por último: consultar logs de diagnóstico é a etapa mais demorada e deve ser usada para confirmar a hipótese já formada ou investigar causas que as etapas anteriores não revelaram.
A alternativa A começa pelo teste de conectividade, o que pode gerar informação útil, mas não orienta o diagnóstico sem antes conhecer o estado das configurações. A alternativa C começa pelo Storage Account antes de verificar se o endpoint sequer existe. A alternativa D começa pelo NSG, que é relevante mas não é o ponto de partida correto de uma investigação estruturada.
Árvore de Troubleshooting: Configure service endpoints for Azure platform as a service (PaaS)
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Diante de um problema real, comece pelo nó raiz (sintoma de falha de acesso ao serviço PaaS) e responda cada pergunta de diagnóstico com base no que você observa no ambiente. Siga o caminho correspondente à resposta obtida, percorrendo os níveis até chegar a um nó vermelho (causa identificada) e, em seguida, ao nó verde correspondente (ação a tomar). Nós laranja indicam pontos onde uma verificação adicional, como consultar logs ou executar um comando, é necessária antes de avançar. A árvore cobre os caminhos mais comuns de falha e pode ser percorrida em qualquer ordem de cima para baixo, nunca pulando níveis sem confirmar o estado real do ambiente.