Registo de Eventos e Deteção de Ameaças

O registro em log e a deteção de ameaças permitem que as organizações identifiquem, investiguem e respondam a incidentes de segurança antes que eles se transformem em violações em grande escala. Ao contrário das tradicionais revisões periódicas de logs, os ambientes de nuvem modernos exigem monitoramento contínuo, análise comportamental e correlação centralizada entre camadas de identidade, rede, dados e aplicativos para detetar ataques em vários estágios que exploram provisionamento rápido, recursos efêmeros e arquiteturas distribuídas. As organizações que implementam recursos abrangentes de registro e deteção de ameaças alcançam resposta rápida a incidentes e prontidão forense, enquanto aqueles que negligenciam esses controles enfrentam tempo de permanência prolongado do adversário, escalonamento de privilégios não detetado e incapacidade de reconstruir cronogramas de violação.

Sem recursos abrangentes de registro e deteção de ameaças, as organizações enfrentam ameaças não detetadas operando por longos períodos, evidências forenses incompletas que impedem a reconstrução de incidentes e lacunas de conformidade regulamentar.

Aqui estão os três pilares principais do domínio de segurança Registro em log e deteção de ameaças.

Habilite os recursos de deteção: Antes de responder a ameaças, você deve primeiro implantar sistemas de deteção inteligentes que monitorem continuamente padrões de ataque conhecidos, comportamentos anômalos e indicadores de comprometimento. Os serviços nativos de deteção de ameaças aproveitam a análise comportamental e a inteligência de ameaças para identificar atividades suspeitas que os controles de acesso tradicionais não podem impedir, desde tentativas de injeção de SQL e uploads de malware até abuso de credenciais e exfiltração de dados. Implemente a deteção em todos os tipos de recursos críticos (computação, dados, identidade, rede) para garantir que nenhuma superfície de ataque permaneça sem monitoramento.

Controlos relacionados:

• LT-1: Habilite os recursos de deteção de ameaças
• LT-2: Habilite a deteção de ameaças para gerenciamento de identidade e acesso

Habilite o registro em log abrangente: Implemente o log de auditoria sistemática em todas as camadas de nuvem — logs de recursos (operações de plano de dados), logs de atividades (alterações no plano de gerenciamento), logs de identidade (eventos de autenticação e autorização) e logs de rede (fluxos de tráfego e decisões de firewall). O registo abrangente fornece as evidências forenses necessárias para reconstruir a cronologia dos ataques, definir o perímetro de impacto dos incidentes e apoiar os requisitos de conformidade. Sem trilhas de auditoria completas que abranjam identidade, rede e acesso a dados, os respondentes a incidentes não têm visibilidade para determinar o que foi acessado, por quem, quando e de onde, prolongando o tempo de exposição da violação e aumentando a exposição regulatória.

Controlos relacionados:

• LT-3: Ativar o registo para investigação de segurança
• LT-4: Habilitar o log de rede para investigação de segurança

Centralize e analise: Agregue logs de todas as fontes numa plataforma centralizada de Gestão de Informação e Eventos de Segurança (SIEM) para permitir correlação, análises avançadas e resposta automatizada. A centralização transforma fluxos de log isolados em inteligência acionável contra ameaças, correlacionando eventos em planos de identidade, rede e dados para revelar cadeias de ataque de vários estágios que o monitoramento de fonte única não pode detetar. Estabeleça políticas de retenção disciplinadas alinhadas com os requisitos de conformidade e as necessidades de negócios e garanta uma sincronização de tempo precisa em todos os sistemas para manter a integridade forense e permitir a reconstrução precisa de incidentes.

Controlos relacionados:

• LT-5: Centralize o gerenciamento e a análise de logs de segurança
• LT-6: Configurar a retenção de logs
• LT-7: Usar fontes de sincronização de tempo aprovadas

LT-1: Habilite os recursos de deteção de ameaças

Azure Policy: Consulte definições de políticas incorporadas no Azure: LT-1.

Princípio da segurança

Habilite os recursos de deteção de ameaças em serviços de computação, armazenamento, banco de dados e identidade para identificar padrões de ataque conhecidos, comportamentos anômalos e atividades suspeitas. Use análises comportamentais e inteligência de ameaças para detetar ameaças que os controles de acesso tradicionais não podem evitar.

Risco a mitigar

Os adversários exploram ambientes sem deteção nativa de ameaças para conduzir ataques que permanecem invisíveis para os controles de segurança tradicionais. Sem análise comportamental e monitoramento orientado por inteligência de ameaças:

• Malware não detetado & exploits: Os arquivos mal-intencionados carregados para armazenamento ou tentativas de exploração em bancos de dados continuam sem serem detetados porque as defesas baseadas em assinatura ou na camada de rede perdem cargas úteis sofisticadas.
• Exfiltração silenciosa de dados: Extração de dados em larga escala, padrões de consulta incomuns ou volumes de acesso anômalos escapam da deteção devido à ausência de linhas de base comportamentais e deteção de anomalias de volume.
• Cegueira ao movimento lateral: Os invasores alternam entre recursos (armazenamento para computação para banco de dados) sem disparar alertas porque a correlação entre serviços e os feeds de inteligência sobre ameaças não estão integrados.
• Injeção de SQL & ataques de aplicativos: As tentativas de exploração de banco de dados por meio de consultas maliciosas ou ataques na camada de aplicativo continuam sem monitoramento sem análise de consulta em tempo real e correspondência de padrões de ameaça.
• Tempo de permanência prolongado: Os invasores mantêm o acesso persistente por longos períodos (dias a meses) porque as fases de reconhecimento, preparação e execução não geram alertas, atrasando a resposta a incidentes e aumentando o impacto da violação.
• Opacidade da ameaça interna: Atividades internas maliciosas ou negligentes se misturam com padrões de tráfego legítimos, ausência de análise de comportamento do usuário (UBA) e deteção de anomalias específicas para acesso privilegiado.

A falha na implantação da deteção abrangente de ameaças aumenta o tempo médio de deteção (MTTD) de horas para semanas, amplifica os custos de violação e permite que os adversários estabeleçam uma persistência profunda em toda a sua infraestrutura de nuvem.

MITRE ATT&CK

• Acesso Inicial (TA0001): explora aplicativos voltados para o público (T1190) aproveitando vulnerabilidades não detetadas em aplicativos Web ou APIs para ganhar posição inicial.
• Execução (TA0002): interpretador de comandos e scripts (T1059) executando código malicioso dentro de recursos computacionais ou sem servidor sem disparar alertas comportamentais.
• Persistência (TA0003): manipulação de conta (T1098) modificando entidades de serviço ou criando identidades backdoor não detetadas devido à ausência de monitoramento de anomalias.
• Evasão de Defesa (TA0005): comprometer as defesas (T1562) desativando o registo, agentes de monitoramento ou serviços de segurança para operar em pontos cegos.
• Coleta (TA0009): dados do armazenamento em nuvem (T1530) recolhendo silenciosamente contentores de blob ou armazenamento de objetos sem detectar volume ou padrões.
• Exfiltração (TA0010): exfiltração através de serviços Web (T1567) transmitindo dados através de terminais de API legítimos em volumes ou horários que a análise comportamental sinalizaria.
• Impacto (TA0040): sequestro de recursos (T1496) implantando criptomineradores ou abuso computacional não detetado pela deteção de anomalias de consumo de recursos.

LT-1.1: Habilite a deteção de ameaças para serviços em nuvem

Implante recursos nativos de deteção de ameaças em todos os serviços de nuvem críticos para identificar atividades maliciosas, comportamentos anômalos e padrões de ataque conhecidos por meio de análises comportamentais e inteligência de ameaças. Essa camada fundamental fornece a primeira linha de defesa contra ameaças direcionadas a serviços de computação, armazenamento, banco de dados e gerenciamento de chaves. Implemente as seguintes etapas para estabelecer uma cobertura abrangente de deteção de ameaças:

• Use a deteção de ameaças nativa da nuvem: Implante os recursos de deteção de ameaças de sua plataforma de gerenciamento de postura de segurança na nuvem para serviços de computação, armazenamento, banco de dados e identidade, fornecendo análise comportamental e monitoramento orientado por inteligência de ameaças.

• Habilite uma cobertura de serviço abrangente: Ative a deteção de ameaças para todos os serviços críticos do Azure usando o Microsoft Defender for Cloud, abrangendo máquinas virtuais, contas de armazenamento, bancos de dados, contêineres e instâncias do Cofre de Chaves.

• Analise os recursos de deteção: Familiarize as equipes de segurança com os recursos de deteção disponíveis usando o guia de referência de alertas de segurança do Microsoft Defender for Cloud para entender os tipos de alerta, os níveis de gravidade e os requisitos de resposta.

• Resolva as lacunas de deteção: Para serviços sem capacidade nativa de deteção de ameaças, colete logs da camada de dados e encaminhe para o Microsoft Sentinel para regras de análise personalizadas e deteção de comportamento.

• Otimize a qualidade do alerta: Configure regras de filtragem e análise de alertas para reduzir falsos positivos e extrair alertas de alta qualidade dos dados de log, ajustando a sensibilidade de deteção com base na criticidade da carga de trabalho e na tolerância ao risco.

LT-1.2: Habilite a deteção e a análise avançadas de ameaças

Melhore a deteção básica de ameaças centralizando a telemetria de segurança, implantando plataformas unificadas de deteção e resposta estendidas (XDR) e enriquecendo alertas com inteligência sobre ameaças. Essa camada avançada permite a correlação de ameaças em vários domínios, deteção personalizada para padrões de ataque específicos da organização e alertas ricos em contexto que aceleram a investigação e a resposta. Crie esse recurso de deteção avançada por meio das seguintes etapas:

• Centralize a telemetria de segurança: Agregue alertas e dados de log de plataformas de segurança na nuvem, proteção de pontos finais, sistemas de identidade e serviços de aplicativos no Azure Monitor ou no Microsoft Sentinel para análise e correlação unificadas.

• Implante a plataforma XDR unificada: Habilite o Microsoft Defender XDR para correlacionar a deteção de ameaças no Microsoft 365 Defender (pontos de extremidade, email, colaboração), no Microsoft Defender for Cloud (infraestrutura do Azure) e no Microsoft Entra ID (identidade) com agrupamento de incidentes entre domínios e fluxos de trabalho de investigação automatizados.

• Crie regras de deteção personalizadas: Crie regras de análise personalizadas que correspondam a padrões de ameaça específicos da organização, indicadores de ataque e violações de lógica de negócios que as deteções pré-criadas não podem resolver.

• Enriqueça com informações sobre ameaças: Integre o Microsoft Defender Threat Intelligence para enriquecer alertas com atribuição de agentes de ameaça, reputação de infraestrutura, inteligência de exploração de vulnerabilidades e correlação de indicadores comprometida.

• Indicadores de ameaças de alavancagem: Implemente indicadores de inteligência de ameaças no Microsoft Sentinel para correspondência automatizada de observáveis (endereços IP, domínios, hashes de arquivos, URLs) contra infraestruturas maliciosas conhecidas e campanhas de agentes de ameaças.

Exemplo de implementação

Uma organização global de manufatura permitiu a deteção abrangente de ameaças em 300+ recursos do Azure abrangendo contas de armazenamento, bancos de dados SQL, instâncias do Cosmos DB e sistemas de produção de IoT para reduzir o tempo médio para detetar ataques sofisticados (MTTD).

Desafio: O monitoramento de segurança tradicional dependia de alertas isolados específicos de serviços sem correlação entre armazenamento, bancos de dados, identidade e sistemas de e-mail. A equipe de segurança não tinha visibilidade unificada para detetar ataques em vários estágios, abrangendo campanhas de phishing, comprometimento de credenciais e exfiltração de dados. O tempo médio para detetar ameaças sofisticadas excedeu 30 dias.

Abordagem da solução:

• Deteção abrangente de ameaças na nuvem: Foram habilitados serviços do Microsoft Defender for Cloud em mais de 150 contas de armazenamento, 40 instâncias SQL Database, 12 contas de Cosmos DB e bases de dados PostgreSQL, fornecendo análise comportamental e deteção baseada em inteligência de ameaças para operações no plano de dados.
• Plataforma XDR unificada: Implantou o Microsoft Defender XDR correlacionando a deteção de ameaças no Microsoft 365 Defender (endpoints, email, colaboração), Microsoft Defender for Cloud (infraestrutura do Azure) e Microsoft Entra ID (identidade) com correlação automatizada de incidentes entre domínios.
• Regras de análise personalizadas: Criou regras de análise do Sentinel detetando ataques em vários estágios, incluindo anomalias de acesso ao armazenamento coincidindo com a enumeração de esquema do banco de dados SQL, padrões de extração em massa do Cosmos DB e campanhas de pulverização de credenciais em todos os serviços.
• Enriquecimento de informações sobre ameaças: Inteligência de ameaças integrada do Microsoft Defender para enriquecer alertas com atribuição de agente de ameaça, infraestrutura de ataque conhecida e contexto de exploração de vulnerabilidade.

Resultado: O Defender XDR detetou e continha uma cadeia de ataque de phishing para exfiltração logo após a implantação, com o Threat Intelligence identificando a infraestrutura que corresponde ao APT conhecido visando a propriedade intelectual de fabricação. A correlação automatizada de incidentes entre domínios permitiu que as equipes de segurança investigassem e respondessem rapidamente a ataques em vários estágios que anteriormente permaneciam sem serem detetados por longos períodos.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SI-4(1), SI-4(2), SI-4(5), SI-4(12), SI-4(23), AU-6(1), AU-6(3)
• PCI-DSS v4: 10.6.1, 10.6.2, 10.6.3, 10.8.1, 11.5.1
• Controles CIS v8.1: 8.11, 13.1, 13.2
• NIST CSF v2.0: DE. CM-1, DE. CM-4, DE. CM-7
• ISO 27001:2022: A.8.16, A.5.24
• SOC 2: CC7.2, CC7.3

LT-2: Habilite a deteção de ameaças para gerenciamento de identidade e acesso

Azure Policy: Consulte definições de políticas incorporadas Azure: LT-2.

Princípio da segurança

Monitore eventos de autenticação e autorização para detetar credenciais comprometidas, padrões de entrada anômalos e abuso de conta. Identifique anomalias comportamentais, incluindo falhas de autenticação excessivas, viagens impossíveis, uso preterido da conta e escalonamentos de privilégios não autorizados.

Risco a mitigar

Os ataques baseados em identidade continuam sendo o principal vetor de acesso inicial para violações de nuvem, mas muitas organizações carecem de monitoramento comportamental para detetar abuso de credenciais e padrões de acesso anômalos. Sem deteção de ameaças focada na identidade:

• Credencial compromete cegueira: As credenciais roubadas, vazadas ou forçadas brutas são usadas por longos períodos (semanas a meses) sem deteção porque as anomalias de entrada e a pontuação de risco estão ausentes.
• Viagem impossível sem ser detetada: Autenticações bem-sucedidas de locais geograficamente distantes dentro de prazos impossíveis indicam compartilhamento ou comprometimento de credenciais, mas prosseguem sem monitoramento sem análise de linha de base.
• Exploração de contas desativadas: Contas órfãs, ex-funcionários ou entidades de serviço não utilizadas fornecem pontos de acesso persistentes que os invasores aproveitam para evitar o escrutínio do comportamento dos usuários.
• Silêncio de escalonamento de privilégios: Os atacantes adicionam-se a funções administrativas, criam novas identidades privilegiadas ou modificam associações de grupo sem acionar alertas de auditoria ou deteção de anomalias.
• Sucesso do ataque de pulverização de senhas: Ataques de adivinhação de senhas lentos e discretos evitam limites de bloqueio de conta e escapam à deteção na ausência de análises agregadas de falhas de autenticação em todo o ambiente.
• Técnicas de desvio de MFA: Os adversários exploram protocolos de autenticação herdados, repetição de sessão ou ataques de fadiga MFA que são bem-sucedidos porque comportamentos de entrada arriscados não são sinalizados ou bloqueados.
• Opacidade da ameaça interna: Insiders mal-intencionados com credenciais legítimas exfiltram dados ou abusam do acesso privilegiado enquanto se misturam com padrões normais de atividade ausentes da análise de comportamento do usuário (UBA).

A falha no monitoramento de anomalias de identidade e acesso permite que os invasores operem usando credenciais válidas, ignorando os controles de rede e de ponto final, mantendo perfis de deteção baixos.

MITRE ATT&CK

• Acesso inicial (TA0001): contas válidas (T1078) aproveitando credenciais comprometidas para obter acesso inicial, parecendo uma autenticação legítima.
• Acesso a credenciais (TA0006): força bruta (T1110) realizando ataques de pulverização de senha ou preenchimento de credenciais contra contas de usuário e serviço.
• Acesso a credenciais (TA0006): credenciais não seguras (T1552) coletando credenciais vazadas de bancos de dados públicos de violação ou fontes da dark web.
• Persistência (TA0003): manipulação de contas (T1098) criando contas backdoor, adicionando grupos privilegiados ou modificando métodos de autenticação.
• Escalonamento de privilégios (TA0004): contas válidas (T1078.004) abusando de contas na nuvem para escalar permissões ou assumir funções com privilégios mais altos.
• Evasão de defesa (TA0005): use material de autenticação alternativo (T1550) aproveitando tokens, cookies ou artefatos de sessão para ignorar os requisitos de MFA.
• Movimento Lateral (TA0008): utilizar material de autenticação alternativo (T1550.001), passando tokens ou credenciais de sessão para aceder a recursos adicionais na nuvem.

LT-2.1: Habilitar a deteção e o monitoramento de ameaças do Microsoft Entra ID

Estabeleça uma visibilidade abrangente das atividades de identidade e autenticação habilitando o registro em log de auditoria e o monitoramento de entrada para todos os recursos de identidade. Essa telemetria fundamental permite a deteção de padrões de autenticação suspeitos, alterações não autorizadas na configuração de identidade e possíveis indicadores de comprometimento da conta. Configure os seguintes recursos de monitoramento:

• Habilite o registro de auditoria abrangente: Ative os logs de auditoria do Microsoft Entra para fornecer rastreabilidade completa para todas as alterações feitas nos recursos de identidade, incluindo gerenciamento de usuários e grupos, atribuições de função, registros de aplicativos e modificações de políticas.

• Monitore as atividades de autenticação: Rastreie relatórios de entrada para capturar todos os eventos de autenticação para aplicativos gerenciados e contas de usuário, estabelecendo linhas de base para padrões de acesso normais e identificando anomalias.

• Detete padrões de início de sessão arriscados: Habilite o monitoramento de entradas arriscadas para sinalizar tentativas de autenticação de fontes suspeitas, cenários de viagem impossíveis, locais desconhecidos ou uso de credenciais vazadas indicando possível comprometimento da conta.

• Identifique contas comprometidas: Monitore os usuários sinalizados quanto ao risco para detetar contas que mostrem vários indicadores de risco que exijam investigação e correção imediatas por meio de fluxos de trabalho de revisão automatizados ou manuais.

• Integração com plataformas SIEM: Encaminhe os logs de ID do Microsoft Entra para o Azure Monitor, Microsoft Sentinel ou plataformas SIEM de terceiros para correlação avançada, retenção de longo prazo e análise de deteção de ameaças entre domínios.

LT-2.2: Implementar proteção de identidade e controles baseados em risco

Aprimore o monitoramento de identidade com deteção avançada de riscos, controles de acesso adaptáveis e recursos de investigação alimentados por IA. Essa camada avançada aplica aprendizado de máquina para detetar ataques de identidade sofisticados, automatiza a imposição de autenticação baseada em risco e estende a proteção a ambientes híbridos que unem infraestrutura local e de nuvem. Implemente estes recursos avançados:

• Implante a deteção de risco de identidade: Habilite o Microsoft Entra ID Protection para detetar e corrigir riscos de identidade, incluindo credenciais vazadas, entradas de endereços IP anônimos, fontes vinculadas a malware e ataques de pulverização de senha usando aprendizado de máquina e inteligência de ameaças.

• Implemente controles de acesso baseados em risco: Configure políticas de Proteção de Identidade para impor requisitos de autenticação adaptável por meio do Acesso Condicional do Microsoft Entra, exigindo MFA para entradas de médio risco e bloqueando tentativas de autenticação de alto risco até a correção.

• Monitore as ameaças de identidade da infraestrutura de nuvem: Habilite a proteção de carga de trabalho do Microsoft Defender for Cloud para detetar atividades de identidade suspeitas, incluindo uso de conta preterido, tentativas de autenticação com falha excessivas e comportamentos anômalos da entidade de serviço.

Estenda para ambientes híbridos: Para organizações com Ative Directory local, implante o Microsoft Defender for Identity para monitorar controladores de domínio, detetar ameaças avançadas, identificar identidades comprometidas e investigar ações internas mal-intencionadas que abrangem a infraestrutura híbrida.

Acelere as investigações com IA: Aproveite o Microsoft Security Copilot para reduzir o tempo de investigação por meio de consultas em linguagem natural, análise automatizada de ameaças, fluxos de trabalho de correção guiados e correlação de sinais de identidade alimentada por IA no Microsoft Defender XDR, Sentinel e Entra ID Protection.

Exemplo de implementação

Uma organização de serviços financeiros com 8.000 funcionários implementou a deteção abrangente de ameaças de identidade para combater ataques baseados em credenciais visando aplicativos bancários em nuvem e repositórios de dados de clientes.

Desafio: O monitoramento de autenticação tradicional carecia de análise comportamental para detetar ataques baseados em credenciais, incluindo viagens impossíveis, campanhas de pulverização de senhas e exploração de contas inativas. A equipe de segurança se baseou em revisões manuais de registros, descobrindo comprometimentos somente após incidentes de fraude ou reclamações de clientes. O tempo médio para detetar ataques baseados em identidade excedeu 30 dias.

Abordagem da solução:

• Deteção e proteção de risco de identidade: Implantou a Proteção de ID do Microsoft Entra com políticas de Acesso Condicional baseadas em risco bloqueando entradas de alto risco, exigindo MFA para tentativas de autenticação de médio risco e forçando automaticamente redefinições de senha para deteção de credenciais vazadas.
• Análise SIEM avançada: Criei regras de análise do Sentinel detetando padrões de viagem impossíveis, ataques de pulverização de senha (50+ falhas em 10+ contas de uma única fonte), escalonamento de privilégios fora das janelas de mudança e reativação de conta inativa.
• Monitoramento de ambiente híbrido: Implantou o Defender for Identity em 12 controladores de domínio locais para monitorar sinais do Ative Directory e correlacionar com padrões de autenticação na nuvem para visibilidade completa.
• Investigação baseada em IA: O Microsoft Security Copilot integrado permite consultas de incidentes em linguagem natural, enriquecimento automatizado do contexto de ameaças, fluxos de trabalho de correção guiados e correlação entre domínios entre comprometimento de identidade e acesso a recursos.

Resultado: O Identity Protection sinalizou contas comprometidas logo após a implantação, o Sentinel detetou e conteve ataques de preenchimento de credenciais em poucos minutos e o Security Copilot permitiu que as equipes de segurança investigassem rapidamente ameaças baseadas em identidade usando consultas em linguagem natural. A organização alcançou uma deteção e resposta substancialmente mais rápidas a ataques baseados em identidade que anteriormente permaneciam não detetados por longos períodos.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-2(1), AU-6(1), AU-6(3), IA-4(4), SI-4(1), SI-4(12)
• PCI-DSS v4: 8.2.8, 10.2.1, 10.2.2, 10.6.1
• Controles CIS v8.1: 6.2, 8.5, 8.11
• NIST CSF v2.0: DE. CM-1, PR. AC-4, PR. IP-8
• ISO 27001:2022: A.5.16, A.8.15, A.8.16
• SOC 2: CC6.1, CC7.2, CC7.3

LT-3: Ativar o registo para investigação de segurança

Azure Policy: Veja definições de políticas incorporadas do Azure: LT-3.

Princípio da segurança

Habilite o registro de auditoria em operações de plano de dados, atividades de plano de controle e eventos de identidade para dar suporte à investigação de incidentes, análise forense e validação de conformidade. O registro abrangente fornece a trilha de evidências necessária para reconstruir incidentes de segurança e determinar o escopo da violação.

Risco a mitigar

O registro de auditoria abrangente em todos os níveis de nuvem fornece a base forense para investigação de incidentes, reconstrução de violações e validação de conformidade. Sem registro sistemático de eventos de recursos, atividades e identidades:

• Pontos cegos forenses: Os respondentes a incidentes não podem determinar o que foi acessado, modificado ou eliminado durante uma violação porque as operações no plano de dados ao nível dos recursos, (acesso ao cofre de chaves, consultas de banco de dados, leituras de armazenamento), não são registadas.
• Opacidade do plano de gestão: As alterações de infraestrutura (atribuições de função, modificações de regras de firewall, exclusões de recursos) prosseguem sem trilhas de auditoria, impedindo a atribuição de ações administrativas maliciosas ou negligentes.
• Atribuição impossível: As equipes de segurança não podem identificar qual identidade executou ações suspeitas, de qual endereço IP, em que momento ou usando qual método de autenticação na ausência de logs abrangentes do Microsoft Entra ID.
• Invisibilidade do movimento lateral: Os invasores alternam entre recursos (VM para armazenamento e banco de dados) sem deixar trilhas pesquisáveis porque a correlação de atividades entre serviços não possui dados de auditoria.
• Falha de conformidade: As estruturas regulatórias (PCI-DSS, HIPAA, SOC 2) exigem trilhas de auditoria detalhadas para todos os acessos a dados e ações administrativas — o registro ausente cria lacunas de conformidade demonstráveis e constatações de auditoria.
• Tempo de permanência prolongado: Sem logs abrangentes, as equipes de segurança descobrem violações somente após notificação externa (reclamações de clientes, divulgação regulatória) e não por meio de monitoramento interno, aumentando o tempo médio de permanência de dias para meses.
• Ambiguidade da causa raiz: As revisões pós-incidente não podem determinar o vetor de acesso inicial, o caminho de escalonamento de privilégios ou a sequência de movimento lateral sem trilhas de auditoria completas que abranjam identidade, rede e planos de dados.

O registro inadequado transforma cada incidente de segurança em uma investigação prolongada e de alto custo, com evidências forenses incompletas e escopo incerto.

MITRE ATT&CK

• Evasão de Defesa (TA0005): prejudicar defesas (T1562.008) desativando ou modificando configurações de log para operar dentro de pontos cegos de monitoramento.
• Evasão de Defesa (TA0005): remoção de indicadores (T1070) excluindo ou manipulando logs para remover evidências de atividade maliciosa.
• Descoberta (TA0007): descoberta de infraestrutura em nuvem (T1580) enumerando recursos, permissões e configurações para mapear o ambiente.
• Coleção (TA0009): dados do armazenamento em nuvem (T1530) acessando dados confidenciais sem registro de logs do plano de dados para rastrear leituras, downloads ou transferências.
• Exfiltração (TA0010): exfiltração através de serviço Web (T1567) extraindo dados através de APIs na nuvem onde o registo de transações está desativado ou incompleto.

LT-3.1: Habilitar a infraestrutura e o registro de identidades

Estabeleça a trilha de auditoria fundamental capturando todas as operações do plano de gerenciamento e eventos de identidade em seu ambiente de nuvem. Essa camada fornece visibilidade sobre quem está fazendo alterações na infraestrutura, quando essas alterações ocorrem e como as identidades estão sendo usadas — essenciais para detetar modificações não autorizadas, abuso de privilégios e violações de conformidade. Habilite estes recursos principais de registro:

• Habilite os registros de atividades para operações do plano de gerenciamento: Ative os Logs de Atividade do Azure para todas as assinaturas para capturar operações do plano de gerenciamento, incluindo criação, modificação, exclusão de recursos (operações PUT, POST, DELETE), atribuições de função, alterações de política e ações administrativas.

• Centralize a coleta do log de atividades: Configure as configurações de diagnóstico no nível do grupo de gerenciamento ou da assinatura para rotear os Logs de Atividades para o espaço de trabalho centralizado do Log Analytics para retenção de longo prazo, análise de correlação e relatórios de conformidade.

• Aplique uma cobertura de registro consistente: Implante a Política do Azure para impor configurações de diagnóstico em todas as assinaturas, garantindo uma coleta consistente do Log de Atividades e evitando desvios de configuração à medida que novas assinaturas são criadas.

• Capturar eventos de autenticação: Habilite os logs de entrada do Microsoft Entra para capturar todos os eventos de autenticação de usuário e entidade de serviço, incluindo eventos de entrada interativos, eventos de entrada não interativos, eventos de entrada de entidade de serviço e autenticações de identidades geridas.

• Acompanhe as alterações de identidade: Habilite os logs de auditoria do Microsoft Entra para controlar todas as alterações feitas na ID do Microsoft Entra, incluindo gerenciamento de usuários/grupos, atribuições de função, registros de aplicativos, modificações na política de acesso condicional e alterações na unidade administrativa.

• Prolongue a retenção dos registos de identidade: Configure as definições de diagnóstico do Microsoft Entra para encaminhar os registos de início de sessão e auditoria para o espaço de trabalho do Log Analytics ou para o Hub de Eventos, permitindo uma retenção prolongada além do período padrão de 30 dias do centro de administração do Microsoft Entra.

• Monitore a infraestrutura de identidade híbrida: Para ambientes híbridos, integre os logs de integridade do Microsoft Entra Connect para monitorar eventos de sincronização, falhas de autenticação e integridade da integração do Ative Directory local.

• Correlacione com os eventos de rede: Ative os registos de infraestrutura de rede conforme descrito no LT-4 (registos de fluxo NSG, registos do Firewall do Azure, diagnóstico do Gateway VPN, registos do Gateway de Aplicações) para fornecer contexto de rede em investigações de segurança, correlacionando eventos de identidade e do plano de controlo com padrões de tráfego de rede.

LT-3.2: Active o registo da plataforma e do serviço de dados

Estenda a cobertura de auditoria para operações de plano de dados onde dados comerciais confidenciais residem e são acessados. Os logs de serviço da plataforma capturam os detalhes "o que foi acessado" e "por quem" essenciais para investigar violações de dados, ameaças internas e violações de conformidade, abrangendo armazenamento, bancos de dados, gerenciamento de segredos, contêineres e plataformas NoSQL. Configure o registo do plano de dados a seguir:

• Habilite logs de plano de dados no nível de recurso: Ative os logs de recursos do Azure para operações de plano de dados realizadas nos serviços do Azure, incluindo operações de leitura, gravação e exclusão em dados e configurações em todos os serviços da plataforma.

• Operações de armazenamento de logs: Ativar os logs de diagnóstico do Armazenamento do Azure para capturar todas as operações de armazenamento de blobs, ficheiros, filas e tabelas, incluindo eventos StorageRead, StorageWrite, StorageDelete, juntamente com a identidade do chamador, IP de origem e latência das operações para investigações forenses.

• Atividades de auditoria da base de dados: Configure a auditoria do Banco de Dados SQL do Azure para registrar todas as consultas de banco de dados, alterações de esquema, concessões de permissão, tentativas de autenticação e operações administrativas — roteie logs de auditoria para o espaço de trabalho ou conta de armazenamento do Log Analytics para monitoramento de conformidade e segurança.

• Monitore o acesso a segredos: Habilite os logs de diagnóstico do Cofre de Chaves do Azure para capturar todas as operações de acesso a chaves, segredos e certificados, incluindo recuperação, rotação, exclusão e alterações de permissão com contexto de auditoria completo para rastreamento de ativos confidenciais.

• Acompanhe as operações NoSQL: Configure os logs de diagnóstico do Azure Cosmos DB para capturar operações de plano de dados, desempenho de consulta, padrões de acesso à chave de partição e eventos de limitação de recursos para investigação de segurança e desempenho.

• Abranja plataformas de dados adicionais: Habilite o log de diagnóstico para outros serviços de dados, incluindo o Azure Data Lake Storage, o Azure Synapse Analytics, o Banco de Dados do Azure para PostgreSQL/MySQL e o Cache do Azure para Redis, capturando acesso a dados e operações administrativas.

0- Registe o plano de controlo do Kubernetes: Habilite o diagnóstico do Azure Kubernetes Service (AKS) para capturar registos do plano de controlo, incluindo registos do kube-apiserver (todas as solicitações de API), kube-audit (trilha de auditoria de segurança), kube-controller-manager, kube-scheduler e registos do cluster-autoscaler.

• Monitorar o tempo de execução do contêiner: Configure o Container Insights para coletar métricas, logs e dados de desempenho no nível de contêiner de clusters AKS, Instâncias de Contêiner do Azure e clusters Kubernetes habilitados para Azure Arc, incluindo eventos do ciclo de vida do pod e utilização de recursos.

• Rastreie imagens de contentores: Ative o diagnóstico do Registo de Contentores do Azure para registar operações de envio e puxar de imagens, acesso ao repositório, eventos de autenticação, invocações de webhook e resultados de verificação de vulnerabilidades.

• Automatize a ativação de logs da plataforma: Use o Microsoft Defender for Cloud para habilitar e configurar automaticamente logs de recursos para os serviços do Azure suportados nas várias assinaturas, reduzindo a sobrecarga de configuração manual.

• Imponha uma cobertura consistente: Implante a Política do Azure para impor configurações de diagnóstico para serviços de dados, garantindo uma coleta de log consistente, evitando desvios de configuração e corrigindo recursos não compatíveis automaticamente.

LT-3.3: Habilitar o registro em log de aplicativos e cargas de trabalho

Conclua sua cobertura de auditoria capturando atividades da camada de aplicativo, operações de carga de trabalho personalizadas e execução de lógica de negócios. Os logs de aplicativos fornecem a visibilidade mais profunda sobre como os usuários interagem com seus sistemas, quais dados corporativos eles acessam e quais ataques na camada de aplicativos são tentados — essenciais para detetar ameaças internas, abuso de aplicativos e ataques sofisticados que ignoram os controles de infraestrutura. Implemente o registro abrangente de aplicativos:

• Registrar atividades do aplicativo Web: Habilite o diagnóstico do Serviço de Aplicativo do Azure para capturar logs de aplicativos, logs do servidor Web (logs do IIS/HTTP.sys), mensagens de erro detalhadas, rastreamento de solicitação com falha e logs de implantação para aplicativos Web e APIs.

• Monitore as operações do gateway de API: Configure o diagnóstico do Gerenciamento de API do Azure para registrar solicitações de API, respostas, falhas de autenticação, violações de limite de taxa, detalhes de execução de política, erros de serviço de back-end e eventos de gerenciamento de assinatura.

• Acompanhe a execução da função sem servidor: Habilite o monitoramento do Azure Functions com a integração do Application Insights para capturar execuções de funções, dependências, exceções, métricas de desempenho e eventos de segurança personalizados, incluindo decisões de autorização e auditorias de operações confidenciais.

• Registre fluxos de trabalho do processo de negócios: Para os Aplicativos Lógicos do Azure, habilite o diagnóstico para registrar execuções de fluxo de trabalho, eventos de disparo, resultados de ações e falhas de integração dando suporte a investigações de segurança de processos de negócios.

• Implante agentes de monitoramento de VM: Implante o Agente do Azure Monitor em máquinas virtuais Windows e Linux para coletar Logs de Eventos de Segurança, Syslog, contadores de desempenho e arquivos de log personalizados.

• Colete eventos de segurança do Windows: Configure a coleta do Log de Eventos do Windows para eventos relevantes à segurança, incluindo tentativas de autenticação (ID de Evento 4624, 4625), escalonamento de privilégios (4672, 4673), gerenciamento de contas (4720, 4726, 4738) e alterações na política de auditoria (4719).

• Reúna logs do sistema Linux: Configure a coleção Linux Syslog para logs de autenticação (/var/log/auth.log, /var/log/secure), logs do sistema (/var/log/syslog, /var/log/messages) e logs de segurança específicos do aplicativo.

• Monitore a proteção de endpoints: Habilite o monitoramento antimalware para máquinas virtuais do Windows para registrar eventos de deteção de malware, resultados de verificação, atualizações de assinatura e violações de política.

• Implemente o registro em log estruturado: Implemente o log estruturado de aplicativos com contexto de segurança, incluindo identidade do usuário, endereço IP de origem, ID da solicitação, tipo de operação, rótulos de classificação de dados, decisões de autorização e identificadores de transações comerciais para dar suporte à correlação e à análise forense.

• Habilite a telemetria APM: Habilite o Application Insights ou soluções equivalentes de monitoramento de desempenho de aplicativos (APM) para coletar telemetria, exceções, eventos de segurança personalizados, rastreamento distribuído para microsserviços e rastreamento de dependência.

• Registrar eventos de segurança do aplicativo: Configure o log de eventos de segurança da camada de aplicativo, incluindo tentativas de autenticação, falhas de autorização, falhas de validação de entrada, escalonamentos de privilégios, acesso a dados confidenciais e violações de segurança da lógica de negócios.

• Monitore ataques a aplicativos da Web: Para aplicativos Web e APIs, registre cabeçalhos de segurança HTTP, violações de política de segurança de conteúdo, imposição de política CORS e eventos de gerenciamento de sessão para detetar ataques na camada de aplicativo.

• Capturar tentativas de ataque da Camada 7: Ative o registo de logs para gateways de API e firewalls de aplicações web para capturar ataques, incluindo tentativas de injeção de SQL, cross-site scripting (XSS), tentativas de execução de código remoto, inclusão de ficheiros locais, ataques de entidade externa XML (XXE) e padrões de abuso de lógica de negócios.

• Rastreie o abuso da API: Configure o registro em log para imposição de limitação de taxa, falhas de autenticação, deteção de bots e padrões de abuso de API que ofereçam suporte à deteção de ameaças e resposta a incidentes.

Exemplo de implementação

Um provedor de SaaS de saúde permitiu o registro abrangente de três camadas (infraestrutura/identidade, plataforma/serviços de dados, aplicativo/carga de trabalho) para atender aos requisitos de auditoria da HIPAA e dar suporte a investigações de segurança para sistemas de registro de saúde eletrônico (EHR) que atendem 200+ clientes hospitalares.

Desafio: O registro fragmentado em serviços isolados impediu a correlação de ataques em vários estágios. A equipe de segurança não tinha trilhas de auditoria completas para conformidade com a HIPAA e não conseguia reconstruir cronogramas de incidentes abrangendo alterações na infraestrutura, acesso a dados e abuso de aplicativos. O tempo médio para investigar incidentes excedeu 2 semanas devido à agregação manual de logs em 120+ serviços.

Abordagem da solução:

• Infraestrutura e registo de identidades: Configuramos logs de atividade centralizados e logs de identidade do Microsoft Entra (inícios de sessão, auditoria) ao nível do grupo de gestão abrangendo 5 assinaturas, capturando 1,5 milhão de eventos diários de autenticação e 50 mil operações de gestão com retenção de 2 anos para fins de conformidade.
• Registo da plataforma e do serviço de dados: Logs de diagnóstico habilitados para mais de 120 contas de armazenamento em nuvem, 12 bases de dados SQL, 15 Key Vaults, instâncias do Cosmos DB e clusters AKS (kube-audit, Container Insights) capturando operações do plano de dados, desempenho de consultas e eventos de segurança de containers gerando mais de 2 milhões de eventos de auditoria diários.
• Registro de aplicativos e carga de trabalho: Implantou o Azure Monitor Agent em 150 VMs, habilitou o diagnóstico do Serviço de Aplicativo para 8 aplicativos Web, configurou o log de Gerenciamento de API para 3 APIs de integração de assistência médica e implementou o Application Insights para rastreamento distribuído com registro de contexto de segurança estruturado.
• Correlação centralizada: Implantou regras de análise do Microsoft Sentinel correlacionando eventos em todas as três camadas com políticas de retenção hierárquicas (2 anos regulado pela HIPAA, 1 ano operacional, desempenho de 90 dias) e controles de acesso do Azure RBAC.

Resultado: A correlação de logs entre camadas permitiu a deteção rápida de ataques sofisticados em vários estágios, abrangendo atribuições de função, acesso ao Cofre de Chaves e exfiltração de armazenamento. A organização alcançou conformidade completa com a trilha de auditoria HIPAA e reduziu substancialmente o tempo de investigação de incidentes por meio da análise centralizada de logs em toda a infraestrutura, plataforma e camadas de aplicativos.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-6(3), AU-12(1), SI-4(2)
• PCI-DSS v4: 10.2.1, 10.2.2, 10.3.1, 10.3.2, 10.3.3
• Controles CIS v8.1: 8.2, 8.3, 8.5, 8.12
• NIST CSF v2.0: DE. AE-3, DE. CM-1, DE. CM-6, PR. PT-1
• ISO 27001:2022: A.8.15, A.8.16, A.8.17
• SOC 2: CC4.1, CC7.2, CC7.3

LT-4: Habilitar o log de rede para investigação de segurança

Azure Policy: Veja definições de políticas incorporadas no Azure: LT-4.

Princípio da segurança

Ative o log de tráfego de rede, incluindo logs de fluxo, logs de decisões do firewall, eventos de firewall de aplicações web e consultas DNS para apoiar a investigação de incidentes e a detecção de ameaças. Os logs de rede fornecem evidências forenses para movimento lateral, comunicações de comando e controle, exfiltração de dados e violações de políticas.

Risco a mitigar

Os logs de tráfego de rede fornecem evidências forenses críticas para investigar movimento lateral, exfiltração de dados, comunicações de comando e controle e ataques na camada de aplicativo. Sem uma solução abrangente para registos de rede:

• Cegueira de movimento lateral: Os invasores deslocam-se entre sub-redes, entre VMs ou de recursos de computação para serviços de dados sem deixar evidências de fluxo de rede, impedindo a identificação de anomalias no tráfego leste-oeste.
• Opacidade do caminho de exfiltração: Transferências de dados em larga escala para destinos externos, padrões de saída incomuns ou tunelamento de DNS prosseguem sem serem detetados na ausência de logs de fluxo e análise de tráfego de firewall.
• Ataques de camada de aplicação invisíveis: Tentativas de injeção de SQL, uploads de web shell, abuso de API ou desvio de deteção de manipulação de protocolo quando os logs de WAF, os logs de gateway de aplicação e a inspeção de camada 7 são desabilitados.
• Comunicações C2 não detetadas: Beaconing de comando e controlo, padrões de retorno de chamada ou protocolos tunelados evitam a deteção na ausência de logs de consulta DNS e linhas de base de conexão de rede.
• Invisibilidade da violação da política: O tráfego que viola a segmentação da rede, acessa portas/protocolos não autorizados ou ignora as regras de firewall continua sem monitoramento, erodindo os limites de confiança zero.
• Lacunas de conformidade: As normas regulamentares (PCI-DSS 10.8, NIST AU-12) exigem o registo e monitorização da atividade da rede — registos ausentes criam resultados de auditoria e riscos de certificação.
• Falha na reconstrução do incidente: A perícia forense pós-violação não pode determinar o IP de origem do invasor, caminhos de movimento lateral ou rotas de exfiltração de dados sem fluxo de rede abrangente e logs de decisão de firewall.

MITRE ATT&CK

• Command & Control (TA0011): protocolo de camada de aplicação (T1071) usando HTTP/HTTPS ou outros protocolos padrão para misturar tráfego C2 com comunicações legítimas.
• Command & Control (TA0011): DNS (T1071.004) aproveitando consultas DNS para canais C2 ou túneis de exfiltração de dados.
• Movimento Lateral (TA0008): serviços remotos (T1021) movendo-se entre sistemas usando RDP, SSH ou protocolos de gerenciamento em nuvem.
• Exfiltração (TA0010): exfiltração através do canal C2 (T1041) transmitindo dados roubados através de ligações de comando e controlo estabelecidas.
• Exfiltração (TA0010): exfiltração através de protocolo alternativo (T1048) utilizando portas ou protocolos não padrão para evitar o monitoramento de saída.
• Defense Evasion (TA0005): tunelamento de protocolo (T1572) encapsulando tráfego malicioso dentro de protocolos legítimos (DNS, HTTPS) para contornar a inspeção.

LT-4.1: Habilite o registro e o monitoramento de segurança de rede

Capture telemetria de tráfego de rede abrangente para detetar movimento lateral, exfiltração de dados, comunicações de comando e controle e ataques na camada de aplicativo. Os logs de rede fornecem a trilha de evidências de como os invasores se movem entre sistemas, quais destinos externos eles contatam e quais técnicas de ataque eles empregam — essenciais para investigar violações sofisticadas de vários estágios. Habilite os seguintes recursos de log de rede:

• Captura de logs de fluxo de rede: Ative os logs de fluxo do grupo de segurança de rede (NSG) para capturar informações sobre o tráfego IP que passa através dos NSGs, incluindo IPs de origem/destino, portas, protocolos e decisões de permitir/negar, essenciais para a deteção de movimentos laterais.

• Monitore as atividades do firewall:Habilite os logs e métricas do Firewall do Azure para monitorar a atividade do firewall, o processamento de regras, os acessos de inteligência de ameaças e os logs de proxy DNS para monitoramento centralizado de saída e deteção de ameaças.

• Registre ataques na camada de aplicativo: Habilite os logs do Web Application Firewall (WAF) para capturar tentativas de ataque na camada de aplicativo, incluindo injeção de SQL, scripts entre sites e violações do OWASP Top 10 com detalhes de solicitação e decisões de bloqueio.

• Coletar dados de consulta DNS: Colete logs de consulta DNS para ajudar a correlacionar dados de rede e detetar ataques baseados em DNS, incluindo tunelamento, domínios DGA e comunicações de comando e controle.

• Implante um monitoramento abrangente: Use as soluções de monitoramento de rede do Azure no Azure Monitor para visibilidade de rede abrangente e correlação de log centralizada.

• Habilite a análise de tráfego: Envie logs de fluxo para o espaço de trabalho do Azure Monitor Log Analytics e use a Análise de Tráfego para fornecer informações sobre padrões de tráfego de rede, ameaças à segurança, consumo de largura de banda e violações de políticas.

Exemplo de implementação

Desafio: Uma plataforma global de comércio eletrônico necessária para detetar movimentos laterais, exfiltração de dados e ataques na camada de aplicativos em toda a infraestrutura de várias regiões, protegendo o processamento de pagamentos e os sistemas de dados dos clientes.

Abordagem da solução: Habilitou o log de rede abrangente implantando logs de fluxo NSG com Análise de Tráfego em 200+ grupos de segurança de rede, configurou logs de diagnóstico do Firewall do Azure e WAF em pontos de saída centralizados e gateways de aplicativos, implementou análises de DNS para deteção de C2 e integrou todos os logs de rede com o SIEM para correlação com sinais de identidade e atividade de recursos.

Resultado: A Análise de Tráfego identificou violações de políticas (portas de gerenciamento expostas), logs WAF detetaram e bloquearam campanhas de injeção de SQL e a análise de DNS sinalizou padrões DGA permitindo um rápido isolamento de VMs. O registro em log de rede permitiu a deteção de padrões de movimento lateral e tentativas de exfiltração de dados que teriam permanecido invisíveis sem uma análise abrangente de fluxo e log de firewall.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-12(1), SI-4(2), SI-4(4), SI-4(5), SI-4(12)
• PCI-DSS v4: 10.2.1, 10.2.2, 10.3.1, 10.3.2, 11.4.1, 11.4.2
• Controles CIS v8.1: 8.2, 8.5, 8.6, 8.11, 13.6
• NIST CSF v2.0: DE. AE-3, DE. CM-1, DE. CM-4, DE. CM-6, DE. CM-7
• ISO 27001:2022: A.8.15, A.8.16
• SOC 2: CC7.2

LT-5: Centralize o gerenciamento e a análise de logs de segurança

Azure Policy: Veja definições de políticas incorporadas no Azure: LT-5.

Princípio da segurança

Centralize os logs de segurança de todos os serviços de nuvem, sistemas de identidade e infraestrutura de rede em uma plataforma unificada para correlação e análise. A agregação centralizada permite a deteção de ataques em vários estágios, abrangendo vários serviços que fontes de log isoladas não podem revelar.

Risco a mitigar

Logs distribuídos armazenados em diferentes serviços e regiões evitam a correlação de ataques em vários estágios e atrasam a deteção de incidentes. Sem agregação centralizada de logs e recursos SIEM:

• Invisibilidade de ataques em vários estágios: Cadeias de eliminação sofisticadas que abrangem identidade (ID do Microsoft Entra), rede (fluxos NSG) e dados (acesso ao armazenamento) permanecem não detetadas porque silos de log isolados impedem a correlação entre serviços e a reconstrução da linha do tempo.
• Fadiga de alerta e ruído: As equipas de segurança que se afogam em alertas não correlacionados de dezenas de serviços individuais perdem padrões críticos — incidentes de alta prioridade enterrados em milhares de falsos positivos sem contextualização e priorização.
• Deteção tardia: A agregação e análise manual de logs estende o tempo médio de deteção (MTTD) de minutos para dias — os atacantes completam ciclos completos de ataque (reconhecimento → execução → exfiltração) antes que os defensores correlacionem evidências.
• Caça incompleta a ameaças: Os analistas de segurança não podem executar consultas proativas de caça a ameaças abrangendo vários serviços, intervalos de tempo e indicadores de ataque quando os logs permanecem espalhados por interfaces específicas do serviço.
• Falhas na auditoria de conformidade: Os requisitos normativos exigem monitoramento e emissão de relatórios de segurança centralizados — logs distribuídos criam lacunas demonstráveis na maturidade das operações de segurança e na prontidão da auditoria.
• Resposta ineficiente a incidentes: As equipes de RI desperdiçam horas críticas alternando manualmente entre o Portal do Azure, o Log Analytics, logs específicos do serviço e ferramentas de terceiros em vez de fluxos de trabalho de investigação unificados.
• Perda de retenção e governança: Políticas de retenção inconsistentes entre serviços resultam em evidências forenses críticas expirando antes da conclusão das investigações, e a falta de controles de acesso centralizados expõe logs confidenciais a visualização não autorizada.

Na ausência de SIEM/SOAR centralizado, as organizações operam reativamente com visibilidade fragmentada, tempos de resposta prolongados e incapacidade de detetar ataques coordenados.

MITRE ATT&CK

• Evasão de defesa (TA0005): prejudica a defesa (T1562) explorando a fragmentação de log para evitar a deteção baseada em correlação entre limites de serviço.
• Descoberta (TA0007): descoberta de infraestrutura em nuvem (T1580) enumerando sistematicamente recursos em vários serviços — padrões visíveis apenas por meio de análise centralizada.
• Movimento Lateral (TA0008): utilizar material de autenticação alternativo (T1550) pivotando entre serviços usando tokens ou credenciais — movimento rastreável apenas por meio de correlação de registos entre serviços.
• Coleta (TA0009): dados em estágio (T1074.002) agregando dados de várias fontes antes da exfiltração — padrões de estágio detectáveis através de uma análise de anomalias em múltiplos serviços.
• Exfiltração (TA0010): exfiltração automatizada (T1020) usando extração distribuída em vários serviços para evitar limites de volume de serviço individuais — detetável apenas por meio de análise agregada.

LT-5.1: Implementar agregação centralizada de logs

Transforme logs fragmentados espalhados por serviços em visibilidade unificada roteando toda a telemetria de segurança para uma plataforma central. A agregação de logs fornece a base para a correlação entre serviços, permitindo a deteção de padrões de ataque que ultrapassam os limites da infraestrutura — desde o comprometimento inicial, passando pelo movimento lateral até a exfiltração de dados. Estabeleça uma coleta centralizada de logs:

• Agrupar registos centralmente: Integre os registos de atividade do Azure num workspace centralizado do Log Analytics juntamente com os registos de diagnóstico de recursos de todos os serviços para permitir a correlação entre recursos e fluxos de trabalho de investigação unificados.

• Consultar logs agregados: Use o Azure Monitor com consultas KQL para executar análises em logs agregados de serviços do Azure, dispositivos de extremidade, recursos de rede e outros sistemas de segurança para deteção e investigação de padrões.

• Configure o alerta: Crie regras de alerta usando os logs agregados de várias fontes para detetar ameaças à segurança e problemas operacionais por meio da lógica de correlação que abrange várias fontes de log.

• Estabeleça governança de dados: Defina a propriedade dos dados, implemente controles de acesso baseados em função aos logs, especifique locais de armazenamento para requisitos de conformidade e defina políticas de retenção equilibrando as necessidades de investigação com as obrigações regulatórias e de custo.

LT-5.2: Implantar recursos SIEM e SOAR

Eleve a agregação de logs em operações de segurança proativas implantando o gerenciamento de informações e eventos de segurança (SIEM) com recursos de resposta automatizada. O SIEM transforma logs brutos em inteligência acionável por meio de regras de correlação, análise de ameaças e fluxos de trabalho automatizados de incidentes, permitindo que as equipes de segurança detetem e respondam a ameaças na velocidade da máquina, em vez do ritmo manual da investigação. Construa sua plataforma SIEM/SOAR:

• Implante a plataforma SIEM:Onboard Microsoft Sentinel para fornecer recursos de gerenciamento de eventos de informações de segurança (SIEM) e resposta automatizada de orquestração de segurança (SOAR) para análise de segurança centralizada e resposta a incidentes.

• Conecte fontes de dados: Conecte fontes de dados ao Microsoft Sentinel, incluindo serviços do Azure, Microsoft 365, soluções de segurança de terceiros e sistemas locais para estabelecer visibilidade de segurança abrangente.

• Configure regras de análise: Crie regras de deteção no Sentinel para identificar ameaças e criar automaticamente incidentes com base em eventos de segurança correlacionados que abrangem várias fontes de log e períodos de tempo.

• Automatize as ações de resposta: Implemente playbooks de resposta automatizados usando Aplicativos Lógicos para orquestrar ações de resposta a incidentes, incluindo fluxos de trabalho de contenção, notificação e correção.

• Habilite painéis de monitoramento: Implante pastas de trabalho e painéis do Sentinel para monitoramento de segurança, caça a ameaças, relatórios de conformidade e visibilidade da postura de segurança em nível executivo.

• Integre a análise baseada em IA: Habilite a integração do Microsoft Security Copilot com o Sentinel para fornecer investigação de incidentes alimentada por IA, caça a ameaças e recomendações de resposta guiada usando consultas em linguagem natural em logs de segurança centralizados.

Exemplo de implementação

Desafio: Uma companhia de seguros multinacional precisava de capacidades unificadas de deteção e investigação de ameaças em 12 subscrições do Azure, 500+ recursos e 4 regiões geográficas que processam informações pessoais e dados de reclamações dos tomadores de seguros.

Abordagem da solução: Espaço de trabalho do Log Analytics centralizado, implementado com configurações de diagnóstico a nível de grupo de gestão, encaminhando todos os logs de atividades do Azure, telemetria de identidade e logs de recursos críticos (Armazenamento, SQL, Cofre de Chaves, Firewall). Habilitado o Microsoft Sentinel SIEM com conectores de dados para Defender for Cloud, Entra ID Protection, Microsoft 365 Defender e Defender Threat Intelligence. Regras de análise configuradas para ameaças específicas de seguros (exportação de sinistros em massa, anomalias de acesso privilegiado, ataques em vários estágios), playbooks de resposta automatizada para fluxos de trabalho de contenção e Copiloto de segurança integrado para recursos de investigação em linguagem natural. Estabeleci pastas de trabalho de conformidade mapeando os requisitos HIPAA, PCI-DSS e SOC 2 para a telemetria do Sentinel.

Resultado: O Sentinel detetou campanhas de preenchimento de credenciais por meio de correlação entre assinaturas e identificou movimentos laterais entre regiões geográficas em poucos minutos. O Security Copilot permitiu que analistas de nível 1 conduzissem investigações sofisticadas usando consultas em linguagem natural sem exigir conhecimentos avançados de linguagem de consulta. O SIEM centralizado reduziu substancialmente o tempo médio para detetar e investigar incidentes de segurança em toda a infraestrutura global.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-6(3), AU-6(5), AU-7(1), AU-12(1), SI-4(1), SI-4(2), SI-4(5), SI-4(12)
• PCI-DSS v4: 10.4.1, 10.4.2, 10.4.3, 10.7.1, 10.7.2, 10.7.3
• Controles CIS v8.1: 8.9, 8.11, 13.1, 13.3, 13.4, 17.1
• NIST CSF v2.0: DE.AE-2, DE.AE-3, DE.CM-1, DE.CM-4, DE.CM-6, DE.CM-7, RS.AN-1
• ISO 27001:2022: A.8.15, A.8.16, A.5.25
• SOC 2: CC7.2, CC7.3

LT-6: Configurar a retenção de armazenamento de log

Azure Policy: Veja definições de políticas incorporadas no Azure: LT-6.

Princípio da segurança

Configure períodos de retenção de logs alinhados com requisitos normativos, mandatos de conformidade e cronogramas de investigação. Equilibre os requisitos de preservação de provas forenses com os custos de armazenamento por meio de estratégias de retenção hierárquica.

Risco a mitigar

Políticas de retenção de logs insuficientes ou inconsistentes destroem evidências forenses antes que as investigações sejam concluídas e criam lacunas de conformidade. Sem retenção disciplinada alinhada com os requisitos regulamentares e operacionais:

• Expiração da evidência: Os dados forenses críticos (logs de autenticação, padrões de acesso, fluxos de rede) expiram antes que as equipes de segurança descubram violações — o tempo médio de permanência de 200+ dias significa que os logs devem persistir por tempo suficiente para investigar o comprometimento histórico.
• Violações de conformidade: Os mandatos regulatórios (PCI-DSS 10.7: 1 ano, GDPR: varia de acordo com a jurisdição, HIPAA: 6 anos) exigem períodos de retenção específicos — retenção inadequada cria descobertas de auditoria, falhas de certificação e penalidades regulatórias.
• Reconstrução incompleta de incidentes: A correlação histórica de indicadores em prazos de violação estendidos torna-se impossível quando os logs expiram prematuramente, impedindo a análise completa da cadeia de destruição e a determinação da causa raiz.
• Lacunas de deteção legal: Litígios, investigações regulatórias e auditorias internas exigem a produção de logs de segurança históricos — logs ausentes criam exposição legal e incapacidade de defender práticas organizacionais.
• Cegueira da análise de padrões: Modelos de aprendizado de máquina e linhas de base comportamentais exigem dados históricos de treinamento — a retenção curta impede a deteção de ataques de queima lenta, padrões sazonais ou análise de tendências de longo prazo.
• Derrapagens de custos: A falta de estratégia de hierarquização de retenção (armazenamento quente versus frio) leva à retenção dispendiosa do Log Analytics para necessidades de arquivamento de longo prazo melhor atendidas pelo Armazenamento do Azure — inflando os custos operacionais desnecessariamente.
• Desvio da política de retenção: A retenção inconsistente entre serviços (90 dias para logs de atividades, 30 dias para logs de recursos, indefinida para alguns serviços) cria pontos cegos investigativos e cobertura forense imprevisível.

A retenção inadequada transforma violações de longa duração em incidentes não investigados, ao mesmo tempo em que cria exposição regulatória e legal.

MITRE ATT&CK

• Evasão de Defesa (TA0005): os atacantes que utilizam a remoção de indicadores (T1070) aproveitam-se de janelas de retenção curtas para garantir que as evidências expirem naturalmente sem necessitar da eliminação ativa de logs.
• Persistência (TA0003): manipulação de contas (T1098) que estabelece um acesso a longo prazo por porta dos fundos, com confiança de que as provas iniciais da intrusão envelhecerão antes da deteção.

LT-6.1: Implementar estratégia de retenção de logs

Equilibre as necessidades de preservação forense com os custos de armazenamento implementando estratégias de retenção hierárquica alinhadas às determinações normativas e aos prazos de investigação. Diferentes tipos de log exigem diferentes períodos de retenção — armazenamento ativo para investigações ativas, armazenamento ativo para histórico recente e arquivamento frio para conformidade de longo prazo — otimizando a capacidade de investigação e os custos operacionais. Configure a seguinte estratégia de retenção:

• Encaminhe os logs para o armazenamento apropriado: Crie configurações de diagnóstico para rotear os Logs de Atividade do Azure e outros logs de recursos para locais de armazenamento apropriados com base nos requisitos de retenção, mandatos de conformidade e cronogramas de investigação equilibrando os custos de armazenamento quente versus frio.

• Configure a retenção de curto a médio prazo: Use o espaço de trabalho do Azure Monitor Log Analytics para retenção de logs de até 1 a 2 anos para investigação ativa, caça a ameaças e análise operacional com recursos de consulta KQL.

• Implemente armazenamento de longo prazo: Use o Armazenamento do Azure, o Data Explorer ou o Data Lake para armazenamento de longo prazo e arquivamento para além de 1-2 anos, para atender aos requisitos de conformidade (PCI-DSS, SEC 17a-4, HIPAA) com redução significativa de custos por meio de níveis de armazenamento frio/arquivado.

• Encaminhar logs externamente: Use os Hubs de Eventos do Azure para encaminhar logs para SIEM externo, data lake ou sistemas de segurança de terceiros fora do Azure quando necessário para visibilidade em várias nuvens ou integrações herdadas.

• Configure a retenção da conta de armazenamento: Configure políticas de retenção para logs da conta Azure Storage com base nos requisitos de conformidade, implementando o gerenciamento do ciclo de vida para transições automáticas de camada e eliminação.

• Planejar a retenção de logs do Sentinel: Implemente uma estratégia de armazenamento de longo prazo para logs do Microsoft Sentinel, já que o Sentinel usa o espaço de trabalho do Log Analytics como back-end, exigindo configuração de arquivamento explícita para retenção estendida além dos limites do espaço de trabalho.

• Arquivar alertas de segurança: Configure a exportação contínua para alertas e recomendações do Microsoft Defender for Cloud para atender aos requisitos de retenção, uma vez que os dados do Defender for Cloud têm retenção limitada no portal nativo.

Exemplo de implementação

Desafio: Uma organização de serviços financeiros regulamentada precisava atender a vários requisitos de retenção (PCI-DSS: 1 ano, SEC 17a-4: 7 anos) enquanto gerenciava 80 TB de dados de log de segurança anuais de forma econômica.

Abordagem da solução: Implementou a estratégia de retenção de logs hierárquicos configurando o espaço de trabalho do Log Analytics com retenção padrão de 1 ano e substituições no nível da tabela (logs de identidade: 2 anos, fluxos de rede: 90 dias), exportando todos os logs para contas de Armazenamento do Azure com políticas de gerenciamento de ciclo de vida (hot→cool em 90 dias, cool→archive em 1 ano) e configurando o armazenamento imutável (WORM) em contas críticas de conformidade. Implantou a Política do Azure impondo configurações de diagnóstico e consistência de configuração de retenção, criou pacotes de consultas do Log Analytics para relatórios de conformidade automatizados e estabeleceu um processo de retenção legal para preservação de dados forenses durante incidentes ativos.

Resultado: Obtive conformidade completa com a trilha de auditoria para os requisitos de PCI-DSS e SEC 17a-4 e, ao mesmo tempo, reduzi substancialmente os custos de armazenamento de logs por meio da estratégia de armazenamento hierárquico. Investigou com sucesso incidentes históricos de segurança usando logs arquivados além dos recursos de retenção anteriores e simplificou auditorias de conformidade trimestrais por meio de consultas automatizadas de coleta de evidências e verificação de retenção.

Nível de criticidade

Deveria ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-11(1), SI-12
• PCI-DSS v4: 10.5.1, 10.7.1, 10.7.2, 10.7.3
• Controles CIS v8.1: 8.3, 8.10
• NIST CSF v2.0: PR. PT-1, DE. CM-1
• ISO 27001:2022: A.8.15
• SOC 2: CC7.2

LT-7: Usar fontes de sincronização de tempo aprovadas

Princípio da segurança

Sincronize todos os sistemas com fontes de tempo autorizadas para manter carimbos de data/hora precisos nos logs de segurança. A sincronização de tempo consistente permite uma correlação de log confiável, reconstrução da linha do tempo do incidente e análise forense.

Risco a mitigar

O tempo preciso e sincronizado em todos os sistemas é fundamental para a correlação de registros, análise forense e reconstrução da linha do tempo de incidentes. Sem sincronização de tempo consistente:

• Corrupção na linha do tempo forense: A reconstrução de incidentes torna-se impossível quando logs de diferentes fontes mostram carimbos de data/hora conflitantes — os investigadores não podem determinar a sequência de ataque ou correlacionar eventos entre sistemas (logs de VM mostrando ataque às 10h00, logs de firewall mostrando o mesmo evento às 9h45).
• Falha de correlação SIEM: A análise de segurança e as regras de correlação falham quando o desvio de tempo faz com que os eventos cheguem fora de ordem — deteções perdidas, pois a lógica da regra espera sequências de eventos cronológicas.
• Oportunidades de desvio de autenticação: Os mecanismos de autenticação baseados no tempo (tíquetes Kerberos, tokens JWT, códigos OTP) tornam-se exploráveis quando a distorção do relógio permite ataques de repetição ou estende as janelas de validade do token.
• Falhas na auditoria de conformidade: As estruturas regulatórias (PCI-DSS 10.4, SOC 2, HIPAA) exigem sincronização de tempo precisa para integridade da trilha de auditoria — o desvio de tempo cria descobertas de auditoria e questiona a confiabilidade das evidências.
• Alertas falsos positivos/negativos: A deteção de anomalias e a análise comportamental geram alertas incorretos quando o desvio de tempo faz com que atividades normais apareçam fora das janelas de tempo esperadas ou padrões suspeitos pareçam benignos.
• Erros de validação do certificado: As verificações de validade do certificado SSL/TLS falham ou são bem-sucedidas incorretamente quando os relógios do sistema se desviam das janelas NotBefore/NotAfter do certificado, causando interrupções de serviço ou desvio de segurança.
• Erros de retenção de log: As políticas de retenção baseadas na avaliação de carimbo de data/hora (excluir logs com mais de 365 dias) são executadas incorretamente devido a desvio temporal — excluindo evidências prematuramente ou retendo logs além dos limites da política.

As falhas de sincronização de tempo minam a integridade probatória de todo o registro e monitoramento de segurança, tornando a análise forense inconclusiva e não confiável.

MITRE ATT&CK

• Evasão de Defesa (TA0005): remoção de indicadores (T1070) manipulando carimbos de data/hora para ocultar atividades maliciosas dentro de janelas de tempo legítimas ou para fazer com que as provas pareçam estar fora do escopo da investigação.

LT-7.1: Configurar a sincronização de tempo segura

Garanta registos de data e hora precisos e consistentes em todos os sistemas para permitir uma correlação confiável de logs e a reconstrução cronológica de incidentes. A sincronização de tempo é fundamental para a integridade forense — mesmo pequenos desvios de relógio podem corromper cronogramas de investigação, causar falhas de correlação SIEM e criar descobertas de auditoria de conformidade. Configure todos os sistemas para usar fontes de tempo confiáveis e monitorar desvios continuamente. Implemente estas práticas de sincronização de tempo:

• Configure a sincronização de tempo do Windows: Use os servidores NTP padrão da Microsoft para sincronização de tempo nos recursos de computação do Windows no Azure utilizando as fontes de tempo de host do Azure por meio de serviços de integração de virtualização, a menos que requisitos específicos determinem o contrário.

• Configure a sincronização de tempo do Linux: Configure a sincronização de tempo nos recursos de computação Linux do Azure usando chrony ou ntpd com fontes NTP fornecidas pelo Azure ou servidores NTP externos apropriados.

• Servidores NTP personalizados seguros: Se estiver implantando servidores NTP (Network Time Protocol) personalizados, proteja a porta de serviço UDP 123 e implemente controles de acesso restringindo consultas de serviço de tempo apenas para clientes autorizados.

• Valide formatos de carimbo de data/hora: Verifique se todos os logs gerados pelos recursos do Azure incluem carimbos de data/hora com informações de fuso horário (de preferência UTC) por padrão para habilitar a reconstrução inequívoca da linha do tempo em implantações globais.

• Monitore o desvio de tempo: Implemente o monitoramento contínuo do desvio de tempo entre sistemas e configure alertas para problemas significativos de sincronização (>5 segundos) que possam afetar a correlação de logs, a análise forense e os mecanismos de autenticação baseados em tempo.

Exemplo de implementação

Desafio: Uma organização global de retalho precisava garantir a integridade forense das linhas de tempo em toda a infraestrutura híbrida (sistemas de ponto de venda locais, back-end do Azure Cloud POS, processamento de pagamentos) abrangendo 2.500 lojas para conformidade com PCI-DSS e investigação de fraude.

Abordagem da solução: Foi configurada uma sincronização abrangente de tempo ao verificar a sincronização automática de NTP dos serviços PaaS do Azure, ao configurar as VMs do Azure (Windows/Linux) para utilizarem as fontes de tempo dos hosts do Azure, e ao implementar alertas do Azure Monitor para desvio de tempo superior a >5 segundos. Implantou consultas do Log Analytics detectando anomalias nos carimbos de data/hora em fontes de log correlacionadas e runbooks de correção automatizados forçando a ressincronização do tempo nas VMs afetadas. Estabeleceram-se auditorias trimestrais de sincronização de tempo que validam a configuração NTP e a consistência da marca temporal nos logs de aplicativos, de identidade e de rede.

Resultado: Alcançou a conformidade com os requisitos de sincronização de tempo PCI-DSS e correlacionou com sucesso investigações de fraude em fontes de log híbridas com precisão consistente de carimbo de data/hora, permitindo uma reconstrução precisa de incidentes. O monitoramento e a correção automatizados de desvio de tempo eliminaram alertas de segurança falsos positivos causados por eventos fora de ordem e garantiram a integridade da linha do tempo forense em toda a infraestrutura distribuída globalmente.

Nível de criticidade

Deveria ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: AU-8(1), AU-8(2)
• PCI-DSS v4: 10.6.1, 10.6.2, 10.6.3
• Controles CIS v8.1: 8.4
• NIST CSF v2.0: DE. CM-1, PR. PT-1
• ISO 27001:2022: A.8.15
• SOC 2: CC7.2