Solucionar problemas do conector do AWS S3

  • Artigo

O conector da AWS (Amazon Web Services) S3 permite que você ingira logs de serviço da AWS, coletados em buckets da AWS S3, no Microsoft Sentinel. Atualmente, os tipos de logs compatíveis são AWS CloudTrail, Logs de Fluxo do VPC e AWS GuardDuty.

Este artigo descreve como identificar rapidamente a causa dos problemas que ocorrem com o conector AWS S3 para que você possa encontrar as etapas necessárias para resolver os problemas.

Saiba como conectar o Microsoft Sentinel à Amazon Web Services para ingerir dados de log do serviço da AWS.

O Microsoft Sentinel não recebeu dados do conector Amazon Web Services S3 nem de um dos tipos de dados dele

Os logs do conector AWS S3 (ou de um dos tipos de dados dele) não ficam visíveis no workspace do Microsoft Sentinel por mais de 30 minutos após o conector ser conectado.

Antes de pesquisar uma causa e uma solução, examine estas considerações:

  • Pode levar cerca de 20 a 30 minutos a partir do momento em que o conector é conectado até que os dados sejam ingeridos no workspace.
  • O status de conexão do conector indica que existe uma regra de coleção. Ele não indica que os dados foram ingeridos. Se o status do conector Amazon Web Services S3 estiver verde, isso significará que há uma regra de coleta para um dos tipos de dados, mas ainda não há dados.

Determinar a causa do problema

Nesta seção, abordaremos estas causas:

  1. As políticas de permissões do conector AWS S3 não foram definidas corretamente.
  2. Os dados não são ingeridos no bucket S3 na AWS.
  3. O SQS (Serviço de Fila Simples da Amazon) na nuvem da AWS não recebe notificações do bucket do S3.
  4. Os dados não podem ser lidos do SQS/S3 na nuvem da AWS. Com os logs do GuardDuty, o problema geralmente é causado por permissões incorretas do KMS.

Causa 1: as políticas de permissões do conector AWS S3 não foram definidas corretamente

Esse problema é causado por permissões incorretas no ambiente da AWS.

Criar políticas de permissões

Você precisa ter políticas de permissões para implantar o conector de dados AWS S3. Examine as permissões necessárias e defina as permissões relevantes.

Causa 2: os dados relevantes não existem no bucket S3

Os logs relevantes não existem no bucket S3.

Solução: pesquisar logs e exportá-los, se necessário

  1. Na AWS, abra o bucket S3, procure a pasta relevante de acordo com os logs necessários e verifique se há arquivos de log dentro da pasta.
  2. Se os dados não existirem, o problema estará na configuração da AWS. Nesse caso, você precisa configurar um serviço AWS para exportar logs para um bucket S3.

Causa 3: os dados S3 não chegaram ao SQS

Os dados não foram transferidos com êxito do S3 para o SQS.

Solução: verifique se os dados chegaram e configure as notificações de eventos

  1. Na AWS, abra o SQS relevante.
  2. Na guia Monitoramento, você verá o tráfego no widget Número de Mensagens Enviadas. Se não houver tráfego no SQS, o problema estará na configuração da AWS.
  3. Verifique se a definição de notificações de evento para o SQS inclui os filtros de dados corretos (prefixo e sufixo).
    1. Para ver as notificações de evento, no bucket S3, selecione a guia Propriedades e localize a seção Notificações de eventos.
    2. Se você não conseguir ver esta seção, crie-a.
    3. Verifique se o SQS tem as políticas relevantes para obter os dados do bucket S3. O SQS precisará conter essa política na guia Política de acesso.

Causa 4: o SQS não leu os dados

O SQS não leu com êxito os dados do S3.

Solução: verifique se o SQS lê os dados

  1. Na AWS, abra o SQS relevante.

  2. Na guia Monitoramento, você verá o tráfego nos widgets Número de Mensagens Excluídas e Número de Mensagens Recebidas.

  3. Um pico de dados não é suficiente. Aguarde até que haja dados suficientes (vários picos) e verifique se há problemas.

  4. Se pelo menos um dos widgets estiver vazio, verifique os logs de integridade executando esta consulta:

    SentinelHealth 
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
| extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
| extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
| project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties

  5. Verifique se o recurso de integridade está habilitado:

    SentinelHealth 
| take 20

  6. Se o recurso de integridade não estiver habilitado, habilite-o.

Os dados do conector AWS S3 (ou de um dos tipos de dados dele) são vistos no Microsoft Sentinel com um atraso de mais de 30 minutos

Esse problema geralmente acontece quando a Microsoft não consegue ler arquivos na pasta S3. A Microsoft não pode ler os arquivos porque eles estão criptografados ou no formato errado. Nesses casos, muitas novas tentativas acabam causando um atraso na ingestão.

Determinar a causa do problema

Nesta seção, abordaremos estas causas:

  • A criptografia de log não está configurada corretamente
  • As notificações de evento não estão definidas corretamente
  • Erros de integridade ou integridade desabilitada

Causa 1: a criptografia de log não está configurada corretamente

Se os logs estiverem total ou parcialmente criptografados pelo KMS (Serviço de Gerenciamento de Chaves), o Microsoft Sentinel poderá não ter permissão para esse KMS descriptografar os arquivos.

Solução: verifique a criptografia de log

Verifique se o Microsoft Sentinel tem permissão nesse KMS para descriptografar os arquivos. Examine as permissões do KMS necessárias para os logs do GuardDuty e do CloudTrail.

Causa 2: as notificações de evento não estão configuradas corretamente

Ao configurar uma notificação de evento do Amazon S3, você deverá especificar para quais tipos de evento com suporte o Amazon S3 deverá enviar a notificação. Se um tipo de evento que você não especificou existir no bucket do Amazon S3, o Amazon S3 não enviará a notificação.

Solução: verifique se as notificações de evento estão definidas corretamente

Para verificar se as notificações de evento do S3 para o SQS estão definidas corretamente, verifique se:

  • A notificação é definida da pasta específica que inclui os logs e não da pasta principal que contém o bucket.
  • A notificação é definida com o sufixo .gz. Por exemplo:

Causa 3: erros de integridade ou integridade desabilitada

Pode haver erros nos logs de integridade ou o recurso de integridade pode não estar habilitado.

Solução: verifique se não há erros nos logs de integridade e habilite a integridade

  1. Verifique se não há erros nos logs de integridade executando esta consulta:

    SentinelHealth
| where TimeGenerated between (ago(startTime)..ago(endTime))
| where SentinelResourceKind  == "AmazonWebServicesS3"
| where Status != "Success"
| distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description

  2. Verifique se o recurso de integridade está habilitado:

    SentinelHealth 
| take 20

  3. Se o recurso de integridade não estiver habilitado, habilite-o.

Próximas etapas

Neste artigo, você aprendeu a identificar rapidamente causas e resolver problemas comuns com o conector AWS S3.

Mande comentários, sugestões, solicitações de recursos, relatórios de bugs ou melhorias e adições. Acesse o Repositório do GitHub do Microsoft Sentinel para criar um problema ou um fork e carregar uma contribuição.