Cibersegurança e segurança da informação

Investigação de incidentes de segurança no Azure: Sentinel, Entra e Defender

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de incidentes de segurança no Azure na área de Cloud Security e IR

Resposta rápida

A investigação de incidentes de segurança no Azure exige a conexão de Identity, Audit Logs, API actions, recursos, regiões e sessões. Comece por preservar as evidências e construir uma linha do tempo, e só depois implemente uma contenção documentada.

A investigação na nuvem exige a conexão de identidades, Control Plane, recursos, chaves, sessões e serviços de segurança. Como a atividade está distribuída por serviços e regiões, a linha do tempo e a compreensão das permissões são cruciais. Este artigo centra-se na investigação de incidentes de segurança no Azure e destina-se a analistas de SOC e Cloud. O objetivo é fornecer uma metodologia que possa ser aplicada na prática, numa entrevista profissional e num ambiente de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. Microsoft Sentinel, Entra sign-ins, Activity Log podem apontar numa direção, mas o seu significado depende da hora, do ativo, do utilizador e da atividade esperada. Portanto, construiremos a investigação em torno de uma questão de investigação, das evidências necessárias e de um critério claro para a conclusão.

O cenário prático no artigo é: um cenário de alteração de permissões e de recurso anómalo. Todos os exemplos são dados de laboratório ou descrições de processos. No que diz respeito a Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Definição do Tenant/Subscription scope

O processo de investigação de incidentes de segurança no Azure é construído por etapas com pontos de paragem. Defina um objetivo, Scope, fontes, ações permitidas, evidências necessárias, funções e critério de conclusão. Em ambientes de ataque, adicione Stop conditions e um canal de emergência.

Cada etapa deve ter um Output claro: um mapa de ativos, linha do tempo, Finding, Rule, Playbook ou relatório. A transição para a próxima etapa ocorre apenas quando o Output é suficiente e fiável; isso evita trabalho aleatório ou expansão do Scope sem aprovação.

Entra e Identity

O tópico 'Entra e Identity' é uma parte central do trabalho na investigação de incidentes de segurança no Azure. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de ferramentas sem entender o objetivo.

Na prática, registe Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Activity logs e Resources

O tópico 'Activity logs e Resources' é uma parte central do trabalho na investigação de incidentes de segurança no Azure. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de ferramentas sem entender o objetivo.

Defender e Sentinel

O tópico 'Defender e Sentinel' é uma parte central do trabalho na investigação de incidentes de segurança no Azure. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de ferramentas sem entender o objetivo.

Containment, Recovery e Review

A resposta à investigação de incidentes de segurança no Azure deve reduzir o risco sem apagar as evidências que ainda são necessárias. Comece com uma ação reversível e focada, confirme a propriedade e a autoridade, e documente o tempo, a execução e o resultado.

A correção a longo prazo trata da raiz do problema: permissões, configuração, Validation, Telemetry, processo ou formação. Após a implementação, realize um Retest e monitorize os sinais de recorrência, em vez de se contentar em fechar o Ticket.

Pontos de verificação únicos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, managed identity. A lista não é uma Checklist automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

Microsoft Sentinel: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Entra sign-ins: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Activity Log: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Defender for Cloud: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
resource changes: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
managed identity: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.

Quando um dos focos não está disponível, documente a lacuna e escolha uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload estiver encriptado, use Metadata, volume, frequência e contexto TLS/DNS.

Processo de trabalho recomendado

Defina um Scope e uma única questão de trabalho sobre a investigação de incidentes de segurança no Azure.
Registe as fontes de dados e as evidências necessárias: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Execute o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma linha do tempo ou tabela de comparação e separe o facto da interpretação.
Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário prático

O cenário escolhido é um cenário de alteração de permissões e de recurso anómalo. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, defina dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que um analista ou outro revisor possa auditar: uma captura de ecrã ou Export da evidência, uma linha do tempo curta, uma suposição inicial, evidência de verificação, limitação e recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que fazer	Resultado
Preparação	Defina Scope, tempo e objetivo. Registe que campos ou evidências de Microsoft Sentinel, Entra sign-ins, Activity Log deverão aparecer.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada com a investigação de incidentes de segurança no Azure, sem informações reais ou impacto num sistema de produção.	Evento/Request/Flow controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a possível explicação legítima.	Conclusão provisória
Conclusão	Escolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist prático

Verifique e documente: Principal e session.
Verifique e documente: API action.
Verifique e documente: Resource e region.
Verifique e documente: Source IP e user agent.
Verifique e documente: Audit event ID.
Verifique e documente: GuardDuty/Defender/SCC finding.
Indique Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina proprietário e próxima ação com prazo.

Erros comuns

Focar-se apenas numa área.
Rodar uma chave antes de preservar a linha do tempo.
Não verificar AssumeRole ou Token.
Ignorar o Control Plane.
Não mapear permissões eficazes.
Concluir que a localização geográfica prova um ataque.

Resumo e CTA

A investigação de incidentes de segurança no Azure: Sentinel, Entra e Defender é um tópico que combina conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, preserve o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No percurso Cybersecurity & AI da HPI, estes princípios são praticados através de sistemas, logs e laboratórios. O passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

A investigação de incidentes de segurança no Azure por si só prova um ataque ou vulnerabilidade?

Não. Fornece um sinal ou uma descoberta que precisa de contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando alguns dados estão em falta?

Documente a falta, verifique uma fonte alternativa e reduza o nível de confiança. Não complete campos por suposição nem apresente Desconhecido como válido.

Quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente Retention, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem colocar em risco um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina Scope, Stop conditions e backup antes de iniciar o trabalho.