Laboratório de Troubleshooting: Implement virtual network flow logs
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança configurou VNet flow logs para monitorar tráfego em uma VNet de produção chamada vnet-prod-eastus. O recurso foi habilitado há três dias via Portal do Azure. A equipe espera visualizar os logs no workspace do Log Analytics law-security-prod, mas ao executar consultas KQL, nenhum dado é retornado para o período desde a ativação.
O administrador verifica as configurações e obtém a seguinte saída via CLI:
az network watcher flow-log show \
--location eastus \
--name flowlog-vnet-prod
{
"enabled": true,
"flowAnalyticsConfiguration": {
"networkWatcherFlowAnalyticsConfiguration": {
"enabled": true,
"trafficAnalyticsInterval": 60,
"workspaceId": "law-security-prod",
"workspaceRegion": "eastus",
"workspaceResourceId": "/subscriptions/.../workspaces/law-security-prod"
}
},
"retentionPolicy": {
"days": 30,
"enabled": true
},
"storageId": "/subscriptions/.../storageAccounts/stflowlogsprod",
"targetResourceId": "/subscriptions/.../virtualNetworks/vnet-prod-eastus",
"version": 2
}
O administrador confirma que a conta de armazenamento stflowlogsprod está acessível e que o workspace law-security-prod está ativo. O Network Watcher está habilitado na região eastus. A equipe também menciona que o nome do workspace foi alterado de law-monitor-prod para law-security-prod há cinco dias, dois dias antes da ativação dos flow logs.
Ao verificar o workspace no Portal, o administrador observa que a solução Traffic Analytics aparece como instalada e ativa. Uma consulta direta à tabela NTANetAnalytics retorna zero linhas.
Qual é a causa raiz da ausência de dados no workspace?
A) O Traffic Analytics está configurado com intervalo de 60 minutos, o que atrasa excessivamente a ingestão e os dados ainda não apareceram no workspace.
B) O campo workspaceId na configuração do flow log contém o nome do workspace em vez do GUID do workspace, causando falha silenciosa no envio para o Log Analytics.
C) O VNet flow log versão 2 não é compatível com Traffic Analytics e requer downgrade para versão 1 para enviar dados ao Log Analytics.
D) A conta de armazenamento stflowlogsprod está na mesma região que o workspace, o que impede o Traffic Analytics de processar os dados coletados.
Cenário 2 — Impacto Colateral
A equipe de operações de uma empresa decidiu reduzir custos de armazenamento e alterou a política de retenção dos VNet flow logs de 90 dias para 7 dias na conta de armazenamento stflowlogs-corp. A alteração foi aplicada com sucesso e confirmada via Portal. O tráfego de rede continua sendo registrado normalmente e os arquivos de log continuam chegando ao storage container.
Qual consequência secundária essa alteração pode causar?
A) Os arquivos de log com mais de 7 dias serão excluídos automaticamente da conta de armazenamento, tornando investigações forenses de incidentes ocorridos antes desse período impossíveis sem backup externo.
B) O Traffic Analytics deixará de processar dados novos porque depende de um buffer mínimo de retenção de 30 dias para calcular tendências de tráfego.
C) O Network Watcher desabilitará automaticamente o flow log após detectar que a retenção configurada é inferior ao mínimo exigido de 30 dias.
D) A redução da retenção causará falha na ingestão de novos logs no workspace do Log Analytics porque o conector entre storage e Log Analytics requer retenção mínima de 30 dias para funcionar.
Cenário 3 — Decisão de Ação
A equipe de segurança de uma empresa identificou a causa raiz de um problema: o VNet flow log da VNet vnet-hr-westeurope está enviando dados para a conta de armazenamento errada, stflowlogs-dev, em vez de stflowlogs-prod. Isso ocorre porque um script de provisionamento aplicou a configuração incorreta durante o último deployment.
O ambiente tem as seguintes restrições:
- A VNet vnet-hr-westeurope processa dados de RH e está em produção ativa
- Dados de flow log dos últimos 14 dias estão armazenados em stflowlogs-dev, que é acessível
- A política de segurança da empresa exige que dados de produção nunca permaneçam em contas de armazenamento de desenvolvimento por mais de 24 horas
- Uma auditoria de conformidade começa em 2 horas e exige que os flow logs estejam corretamente configurados e acessíveis no ambiente de produção
- Alterar a configuração de um flow log existente não interrompe a coleta de dados em andamento
Qual é a ação correta a tomar agora?
A) Desabilitar o flow log, aguardar a conclusão da auditoria e recriar a configuração apontando para stflowlogs-prod após a auditoria.
B) Atualizar imediatamente a configuração do flow log para apontar para stflowlogs-prod e iniciar o processo de migração dos dados existentes de stflowlogs-dev para stflowlogs-prod antes da auditoria.
C) Manter a configuração atual durante a auditoria para não arriscar interrupção, e corrigir o apontamento para stflowlogs-prod após a conclusão da auditoria.
D) Excluir o flow log atual e recriar um novo apontando para stflowlogs-prod, aceitando a perda dos 14 dias de dados históricos como necessária para conformidade imediata.
Cenário 4 — Causa Raiz
Um administrador habilitou VNet flow logs para a VNet vnet-spoke-centralus e configurou o envio para a conta de armazenamento stflowlogs-central. Após 48 horas, ele verifica o container de destino e encontra arquivos sendo gravados normalmente. No entanto, ao tentar acessar os arquivos via Portal do Azure Storage Explorer, recebe o seguinte erro:
AuthorizationPermissionMismatch
This request is not authorized to perform this operation using this permission.
RequestId: 8fa2c3d1-0011-004f-6a2b-9c3def000000
O administrador confirma que sua conta possui a role Storage Blob Data Reader atribuída diretamente à conta de armazenamento. Ele também confirma que os arquivos existem no container insights-logs-flowlogflowevent e que o container tem acesso público desabilitado.
Informações adicionais: a conta de armazenamento usa Azure Data Lake Storage Gen2 com namespace hierárquico habilitado. O administrador acessou sem problemas outras contas de armazenamento do tipo blob padrão com a mesma role atribuída. A conta de armazenamento foi criada há 6 meses e os flow logs foram habilitados há 2 dias.
Qual é a causa raiz do erro de autorização?
A) A role Storage Blob Data Reader não é suficiente para acessar dados em contas com namespace hierárquico; é necessário também a permissão de execução nos diretórios pai via ACL.
B) O acesso público desabilitado no container impede qualquer acesso via Storage Explorer, independentemente das roles atribuídas ao usuário.
C) A role Storage Blob Data Reader não tem permissão para acessar o container insights-logs-flowlogflowevent porque ele é criado automaticamente pelo sistema e requer a role Storage Account Contributor para leitura.
D) O erro ocorre porque os arquivos de flow log ficam em quarentena por 72 horas após a criação antes de ficarem acessíveis para leitura por usuários não privilegiados.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O campo workspaceId na configuração de Traffic Analytics deve conter o GUID do workspace do Log Analytics, não o nome legível. A saída da CLI mostra "workspaceId": "law-security-prod", que é um nome, não um identificador único. Quando esse campo recebe um nome em vez do GUID, a configuração é aceita sem erro explícito, mas o envio de dados falha silenciosamente porque o serviço não consegue resolver o destino correto.
A pista crítica no enunciado é que o workspace foi renomeado recentemente. Em um workflow correto, o GUID do workspace não muda com a renomeação, mas o nome sim. Se a configuração tivesse sido copiada de um ambiente anterior usando o nome antigo, seria inválida. A saída da CLI confirma o uso do nome no lugar do GUID.
A informação irrelevante é a renomeação do workspace de law-monitor-prod para law-security-prod. Ela foi incluída para induzir o leitor a suspeitar de incompatibilidade de nome, quando o problema real é o tipo de identificador usado no campo.
O distrator mais perigoso é a alternativa A. O intervalo de 60 minutos é válido e esperado para Traffic Analytics, mas três dias de espera eliminam completamente essa hipótese. Agir com base nela levaria o administrador a aguardar indefinidamente sem corrigir a configuração real.
Gabarito — Cenário 2
Resposta: A
A redução da retenção para 7 dias ativa a política de ciclo de vida da conta de armazenamento para excluir automaticamente os blobs com mais de 7 dias. Como os flow logs são armazenados como arquivos em blob storage, qualquer dado anterior a esse período será removido sem possibilidade de recuperação direta. Isso compromete investigações forenses de incidentes que ocorreram antes da janela de 7 dias.
As alternativas B, C e D representam comportamentos que não existem na plataforma. O Traffic Analytics não tem requisito mínimo de retenção para processar dados novos. O Network Watcher não desabilita flow logs automaticamente com base na retenção configurada. E o conector entre storage e Log Analytics não tem dependência da política de retenção do storage para funcionar.
O impacto colateral real é operacional e de conformidade: investigações de segurança que dependem de logs históricos ficam comprometidas silenciosamente, sem qualquer alerta do sistema.
Gabarito — Cenário 3
Resposta: B
O enunciado estabelece duas restrições simultâneas que precisam ser satisfeitas: a política de segurança exige que dados de produção saiam da conta de desenvolvimento em menos de 24 horas, e a auditoria começa em 2 horas. A alternativa B é a única que satisfaz ambas: corrige o apontamento imediatamente (respeitando a restrição de não interrupção da coleta) e inicia a migração dos dados existentes para a conta correta antes da auditoria.
A alternativa A desabilita o flow log, o que interrompe a coleta desnecessariamente e viola a continuidade durante a auditoria.
A alternativa C é o distrator mais perigoso: mantém os dados de produção em um ambiente de desenvolvimento durante a auditoria, violando diretamente a política de segurança e expondo a empresa a não conformidade documentada.
A alternativa D sacrifica 14 dias de histórico sem necessidade, pois a migração dos dados é viável e o enunciado não menciona qualquer impedimento técnico para ela.
Gabarito — Cenário 4
Resposta: A
Em contas de armazenamento com Azure Data Lake Storage Gen2 e namespace hierárquico habilitado, o modelo de controle de acesso combina RBAC com ACLs (Access Control Lists) no nível de diretório e arquivo. A role Storage Blob Data Reader concede permissão de leitura no nível do plano de dados via RBAC, mas em contas com namespace hierárquico, o acesso a um arquivo dentro de uma estrutura de diretórios também requer permissão de execução em cada diretório pai na hierarquia. Sem essa ACL de execução nos diretórios pai, o acesso ao arquivo é negado com o erro AuthorizationPermissionMismatch.
A pista crítica é que o administrador acessa sem problemas outras contas de armazenamento padrão com a mesma role. Isso elimina a hipótese de role insuficiente de forma genérica e aponta para uma diferença específica da conta, que é o namespace hierárquico.
A informação irrelevante é que a conta foi criada há 6 meses. Esse dado induz a pensar em alguma configuração legada, mas a causa está no modelo de permissões do ADLS Gen2, independente da idade da conta.
O distrator mais perigoso é a alternativa C. Atribuir Storage Account Contributor para resolver o problema seria um erro grave de segurança: essa role concede permissões no plano de gerenciamento, muito além do necessário, e não resolve o problema de ACL nos diretórios do namespace hierárquico.
Árvore de Troubleshooting: Implement virtual network flow logs
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: pergunta diagnóstica objetiva com resposta verificável
- Vermelho: causa identificada e confirmada
- Verde: ação recomendada ou resolução a executar
- Laranja: validação ou verificação intermediária antes de prosseguir
Como percorrer a árvore diante de um problema real: parta sempre do nó raiz, que representa o sintoma observado. Responda cada pergunta azul com base no que é diretamente verificável no ambiente, seja via Portal do Azure, CLI ou consulta KQL. Siga o ramo correspondente à sua resposta. Ao atingir um nó laranja, execute a verificação descrita antes de continuar. Ao atingir um nó vermelho, a causa está confirmada. Ao atingir um nó verde, execute a ação indicada e retorne ao nó de validação mais próximo para confirmar que o problema foi resolvido.