Partilhar via

Solução de problemas do conector do AWS S3

  • Artigo

O conector S3 da Amazon Web Services (AWS) permite que você ingira logs de serviço da AWS, coletados em buckets do AWS S3, para o Microsoft Sentinel. Os tipos de logs aos quais oferecemos suporte atualmente são o AWS CloudTrail, o VPC Flow Logs e o AWS GuardDuty.

Este artigo descreve como identificar rapidamente a causa dos problemas que ocorrem com o conector do 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 de serviços da AWS.

O Microsoft Sentinel não recebe dados do conector S3 da Amazon Web Services ou de um de seus tipos de dados

Os logs do conector do AWS S3 (ou de um de seus tipos de dados) não ficam visíveis no espaço de trabalho do Microsoft Sentinel por mais de 30 minutos após a conexão do conector.

Antes de procurar uma causa e solução, analise estas considerações:

  • Pode demorar cerca de 20 a 30 minutos a partir do momento em que o conector é ligado até que os dados sejam ingeridos na área de trabalho.
  • O estado da ligação do conector indica que existe uma regra de recolha, não indica que os dados foram ingeridos. Se o status do conector do Amazon Web Services S3 estiver verde, há uma regra de coleta para um dos tipos de dados, mas ainda não há dados.

Determinar a causa do problema

Nesta secção, abordamos estas causas:

  1. As políticas de permissões do conector AWS S3 não estão definidas corretamente.
  2. Os dados não são ingeridos no bucket do S3 na AWS.
  3. O Amazon Simple Queue Service (SQS) na cloud do AWS não recebe notificações do registo do S3.
  4. Os dados não podem ser lidos a partir do SQS/S3 na cloud do AWS. Com os logs do GuardDuty, o problema é causado por permissões KMS erradas.

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

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

Criar políticas de permissões

Precisa de políticas de permissões para implementar o conector de dados AWS S3. Reveja as permissões necessárias e defina as permissões relevantes.

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

Os logs relevantes não existem no bucket do S3.

Solução: pesquise logs e exporte logs, se necessário

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

Causa 3: Os dados do 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. No AWS, abra o SQS relevante.
  2. No separador Monitorização, deverá ver o tráfego no widget Número de Mensagens Enviadas. Se não houver tráfego no SQS, existe um problema de configuração do AWS.
  3. Confirme se a definição de notificações de eventos para o SQS inclui os filtros de dados corretos (prefixo e sufixo).
    1. Para ver as notificações de eventos, no registo do S3, selecione o separador Propriedades e localize a secção Notificações de eventos.
    2. Se não conseguir ver esta secção, crie-a.
    3. Confirme se o SQS tem as políticas relevantes para obter os dados do registo do S3. O SQS tem de conter esta política no separador 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. No AWS, abra o SQS relevante.

  2. No separador Monitorização, deverá ver o tráfego nos widgets Número de Mensagens Eliminadas e Número de Mensagens Recebidas.

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

  4. Se, pelo menos, um dos widgets estiver vazio, verifique os registos de estado de funcionamento ao executar 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 a funcionalidade de estado de funcionamento está ativada:

    SentinelHealth 
| take 20

  6. Se a funcionalidade de estado de funcionamento não estiver ativada, ative-a.

Os dados do conector do AWS S3 (ou de um de seus tipos de dados) 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 consegue ler os ficheiros porque estão encriptados ou no formato errado. Nestes casos, muitas repetições causam eventualmente um atraso na ingestão.

Determinar a causa do problema

Nesta secção, abordamos estas causas:

  • A criptografia de log não está configurada corretamente
  • As notificações de eventos não estão definidas corretamente
  • Erros de saúde ou integridade desativada

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

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

Solução: Verifique a criptografia de log

Certifique-se de que o Microsoft Sentinel tem permissão para este KMS para desencriptar os ficheiros. Veja as permissões necessárias do KMS para os registos GuardDuty e CloudTrail.

Causa 2: As notificações de eventos não estão configuradas corretamente

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

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

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

  • A notificação está definida na pasta específica que inclui os registos e não na pasta principal que contém o registo.
  • A notificação é definida com o sufixo .gz . Por exemplo:

Causa 3: Erros de saúde ou integridade desativada

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 existem erros nos registos de estado de funcionamento ao executar 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 a funcionalidade de estado de funcionamento está ativada:

    SentinelHealth 
| take 20

  3. Se a funcionalidade de estado de funcionamento não estiver ativada, ative-a.

    Veja mais informações sobre os seguintes itens usados no exemplo anterior, na documentação do Kusto:

    Para obter mais informações sobre o KQL, consulte Visão geral da Kusto Query Language (KQL).

    Outros recursos:

Próximos passos

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

Agradecemos feedbacks, sugestões, pedidos de funcionalidades, relatórios de bugs ou melhorias e adições. Vá para o repositório GitHub do Microsoft Sentinel para criar um problema ou bifurcação e carregar uma contribuição.