Partilhar via

Resolver problemas do conector do AWS S3

  • Artigo

O conector S3 dos Serviços Web Amazon (AWS) permite-lhe ingerir registos de serviço do AWS, recolhidos em registos do AWS S3, para o Microsoft Sentinel. Os tipos de registos que atualmente suportamos são o CloudTrail do AWS, os Registos do VPC Flow e o AWS GuardDuty.

Este artigo descreve como identificar rapidamente a causa dos problemas que ocorrem com o conector AWS S3 para que possa encontrar os passos necessários para resolver os problemas.

Saiba como ligar o Microsoft Sentinel ao Amazon Web Services para ingerir dados de registo do serviço AWS.

O Microsoft Sentinel não recebe dados do conector amazon Web Services S3 ou de um dos respetivos tipos de dados

Os registos do conector AWS S3 (ou um dos respetivos tipos de dados) não são visíveis na área de trabalho do Microsoft Sentinel durante mais de 30 minutos após a ligação do conector.

Antes de procurar uma causa e uma solução, reveja 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 estado do conector amazon Web Services S3 for verde, existe uma regra de recolha para um dos tipos de dados, mas ainda não existem 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 registo S3 no 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 registos do GuardDuty, o problema é causado por permissões KMS erradas.

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

Este problema é causado por permissões incorretas no ambiente do 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 registo S3

Os registos relevantes não existem no registo S3.

Solução: procure registos e registos de exportação, se necessário

  1. No AWS, abra o registo S3, procure a pasta relevante de acordo com os registos necessários e verifique se existem ficheiros de registo dentro da pasta.
  2. Se os dados não existirem, existe um problema com a configuração do AWS. Neste caso, tem de configurar um serviço AWS para exportar registos para um registo 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. 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 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é existirem dados suficientes (vários picos) e, em seguida, verifique se existem 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 AWS S3 (ou um dos respetivos tipos de dados) são vistos no Microsoft Sentinel com um atraso superior a 30 minutos

Normalmente, este problema ocorre quando a Microsoft não consegue ler ficheiros 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 encriptação de registos não está configurada corretamente
  • As notificações de eventos não estão definidas corretamente
  • Erros de estado de funcionamento ou estado de funcionamento desativado

Causa 1: A encriptação de registos não está configurada corretamente

Se os registos estiverem totalmente ou parcialmente encriptados pelo Key Management Service (KMS), o Microsoft Sentinel poderá não ter permissão para este KMS desencriptar os ficheiros.

Solução: Verificar a encriptação de registos

Certifique-se de que o Microsoft Sentinel tem permissão para este KMS 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

Quando configura uma notificação de evento do Amazon S3, tem de especificar para que tipos de eventos suportados o Amazon S3 deve enviar a notificação. Se existir um tipo de evento que não especificou no seu registo do Amazon S3, o Amazon S3 não envia 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 estado de funcionamento ou estado de funcionamento desativado

Podem existir erros nos registos de estado de funcionamento ou a funcionalidade de estado de funcionamento pode não estar ativada.

Solução: verifique se não existem erros nos registos de estado de funcionamento e ative o estado de funcionamento

  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.

Passos seguintes

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

Congratulamo-nos com comentários, sugestões, pedidos de funcionalidades, relatórios de erros ou melhoramentos e adições. Aceda ao repositório do GitHub do Microsoft Sentinel para criar um problema ou fork e carregar uma contribuição.