Share via

Felsöka problem med AWS S3-anslutningsprogram

  • Artikel

Med Amazon Web Services (AWS) S3-anslutningsprogrammet kan du mata in AWS-tjänstloggar som samlats in i AWS S3-bucketar till Microsoft Sentinel. De typer av loggar som vi stöder för närvarande är AWS CloudTrail, VPC Flow Logs och AWS GuardDuty.

Den här artikeln beskriver hur du snabbt identifierar orsaken till problem som uppstår med AWS S3-anslutningsprogrammet så att du kan hitta de steg som krävs för att lösa problemen.

Lär dig hur du ansluter Microsoft Sentinel till Amazon Web Services för att mata in AWS-tjänstloggdata.

Microsoft Sentinel tar inte emot data från Amazon Web Services S3-anslutningsprogrammet eller någon av dess datatyper

Loggarna för AWS S3-anslutningsprogrammet (eller någon av dess datatyper) visas inte på Microsoft Sentinel-arbetsytan på mer än 30 minuter efter att anslutningsappen har anslutits.

Innan du söker efter en orsak och lösning bör du gå igenom följande överväganden:

  • Det kan ta cirka 20–30 minuter från det att anslutningsprogrammet har anslutits tills data matas in på arbetsytan.
  • Anslutningsprogrammets anslutningsstatus anger att det finns en insamlingsregel. Den anger inte att data har matats in. Om statusen för Amazon Web Services S3-anslutningsappen är grön finns det en samlingsregel för en av datatyperna, men fortfarande inga data.

Fastställa orsaken till problemet

I det här avsnittet går vi igenom följande orsaker:

  1. Behörighetsprinciperna för AWS S3-anslutningsprogrammet har inte angetts korrekt.
  2. Data matas inte in i S3-bucketen i AWS.
  3. SQS (Amazon Simple Queue Service) i AWS-molnet tar inte emot meddelanden från S3-bucketen.
  4. Data kan inte läsas från SQS/S3 i AWS-molnet. Med GuardDuty-loggar orsakas problemet av fel KMS-behörigheter.

Orsak 1: AWS S3-anslutningsappens behörighetsprinciper har inte angetts korrekt

Det här problemet orsakas av felaktiga behörigheter i AWS-miljön.

Skapa behörighetsprinciper

Du behöver behörighetsprinciper för att distribuera AWS S3-dataanslutningsprogrammet. Granska de behörigheter som krävs och ange relevanta behörigheter.

Orsak 2: Relevanta data finns inte i S3-bucketen

Relevanta loggar finns inte i S3-bucketen.

Lösning: Sök efter loggar och exportera loggar om det behövs

  1. Öppna S3-bucketen i AWS, sök efter relevant mapp enligt de loggar som krävs och kontrollera om det finns några loggfiler i mappen.
  2. Om data inte finns finns det ett problem med AWS-konfigurationen. I det här fallet måste du konfigurera en AWS-tjänst för att exportera loggar till en S3-bucket.

Orsak 3: S3-data kom inte fram till SQS

Data överfördes inte från S3 till SQS.

Lösning: Kontrollera att data har anlänt och konfigurera händelseaviseringar

  1. Öppna relevant SQS i AWS.
  2. På fliken Monitoring (Övervakning) bör du se trafik i widgeten Number Of Messages Sent (Antal skickade meddelanden). Om det inte finns någon trafik i SQS finns det ett konfigurationsproblem med AWS.
  3. Kontrollera att definitionen för händelseavisering för SQS har rätt datafilter (prefix och suffix).
    1. Om du vill se händelseaviseringar går du till S3-bucketen, väljer fliken Properties (Egenskaper) och letar upp avsnittet Event notifications (Händelseaviseringar).
    2. Om du inte kan se det här avsnittet skapar du det.
    3. Kontrollera att SQS har de relevanta principerna för att hämta data från S3-bucketen. SQS måste innehålla den här principen på fliken Åtkomstprincip .

Orsak 4: SQS läste inte data

SQS läste inte S3-data.

Lösning: Kontrollera att SQS läser data

  1. Öppna relevant SQS i AWS.

  2. På fliken Monitoring (Övervakning) bör du se trafik i widgeten Number Of Messages Deleted (Antal borttagna meddelanden) och Number Of Messages Received (Antal mottagna meddelanden).

  3. En topp med data räcker inte. Vänta tills det finns tillräckligt med data (flera toppar) och leta sedan efter problem.

  4. Om minst en av widgetarna är tom kontrollerar du hälsologgarna genom att köra den här frågan:

    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. Kontrollera att hälsofunktionen är aktiverad:

    SentinelHealth 
| take 20

  6. Om hälsofunktionen inte är aktiverad aktiverar du den.

Data från AWS S3-anslutningsprogrammet (eller någon av dess datatyper) visas i Microsoft Sentinel med en fördröjning på mer än 30 minuter

Det här problemet inträffar vanligtvis när Microsoft inte kan läsa filer i S3-mappen. Microsoft kan inte läsa filerna eftersom de antingen är krypterade eller i fel format. I dessa fall orsakar många återförsök så småningom inmatningsfördröjning.

Fastställa orsaken till problemet

I det här avsnittet går vi igenom följande orsaker:

  • Loggkryptering är inte korrekt konfigurerat
  • Händelsemeddelanden har inte definierats korrekt
  • Hälsofel eller inaktiverad hälsa

Orsak 1: Loggkryptering har inte konfigurerats korrekt

Om loggarna är helt eller delvis krypterade av Key Management Service (KMS) kanske Microsoft Sentinel inte har behörighet för kms att dekryptera filerna.

Lösning: Kontrollera loggkryptering

Kontrollera att Microsoft Sentinel har behörighet för kms att dekryptera filerna. Granska nödvändiga KMS-behörigheter för GuardDuty- och CloudTrail-loggarna.

Orsak 2: Händelsemeddelanden är inte korrekt konfigurerade

När du konfigurerar ett Amazon S3-händelsemeddelande måste du ange vilka händelsetyper som stöds amazon S3 ska skicka meddelandet till. Om en händelsetyp som du inte angav finns i din Amazon S3-bucket skickar Amazon S3 inte meddelandet.

Lösning: Kontrollera att händelsemeddelanden har definierats korrekt

Kontrollera att händelsemeddelandena från S3 till SQS har definierats korrekt genom att kontrollera att:

  • Aviseringen definieras från den specifika mappen som innehåller loggarna och inte från huvudmappen som innehåller bucketen.
  • Meddelandet definieras med suffixet .gz . Exempel:

Orsak 3: Hälsofel eller hälsotillstånd har inaktiverats

Det kan finnas fel i hälsologgarna eller så är hälsofunktionen kanske inte aktiverad.

Lösning: Kontrollera att det inte finns några fel i hälsologgarna och aktivera hälsa

  1. Kontrollera att det inte finns några fel i hälsologgarna genom att köra den här frågan:

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

  2. Kontrollera att hälsofunktionen är aktiverad:

    SentinelHealth 
| take 20

  3. Om hälsofunktionen inte är aktiverad aktiverar du den.

Nästa steg

I den här artikeln har du lärt dig hur du snabbt identifierar orsaker och löser vanliga problem med AWS S3-anslutningsprogrammet.

Vi välkomnar feedback, förslag, begäranden om funktioner, felrapporter eller förbättringar och tillägg. Gå till Microsoft Sentinel GitHub-lagringsplatsen för att skapa ett problem eller en förgrening och ladda upp ett bidrag.