Delen via

Problemen met AWS S3-connector oplossen

  • Artikel

Met de Amazon Web Services (AWS) S3-connector kunt u AWS-servicelogboeken, verzameld in AWS S3-buckets, opnemen in Microsoft Sentinel. De typen logboeken die momenteel worden ondersteund, zijn AWS CloudTrail, VPC-stroomlogboeken en AWS GuardDuty.

In dit artikel wordt beschreven hoe u snel de oorzaak van problemen met de AWS S3-connector kunt identificeren, zodat u de stappen kunt vinden die nodig zijn om de problemen op te lossen.

Meer informatie over het verbinden van Microsoft Sentinel met Amazon Web Services om logboekgegevens van de AWS-service op te nemen.

Microsoft Sentinel ontvangt geen gegevens van de Amazon Web Services S3-connector of een van de gegevenstypen

De logboeken voor de AWS S3-connector (of een van de gegevenstypen) zijn langer dan 30 minuten nadat de connector is verbonden, niet zichtbaar in de Microsoft Sentinel-werkruimte.

Bekijk deze overwegingen voordat u naar een oorzaak en oplossing zoekt:

  • Het kan ongeveer 20 tot 30 minuten duren vanaf het moment dat de connector is verbonden totdat gegevens worden opgenomen in de werkruimte.
  • De verbindingsstatus van de connector geeft aan dat er een verzamelingsregel bestaat; het geeft niet aan of er gegevens zijn opgenomen. Als de status van de Amazon Web Services S3-connector groen is, is er een verzamelingsregel voor een van de gegevenstypen, maar nog steeds geen gegevens.

De oorzaak van het probleem bepalen

In deze sectie worden de volgende oorzaken behandeld:

  1. De AWS S3-connector machtigingen zijn niet juist ingesteld.
  2. De gegevens worden niet opgenomen in de S3-bucket in AWS.
  3. De Amazon Simple Queue Service (SQS) in de AWS-cloud ontvangt geen meldingen van de S3-bucket.
  4. De gegevens kunnen niet worden gelezen vanuit de SQS/S3 in de AWS-cloud. Met GuardDuty-logboeken wordt het probleem veroorzaakt door verkeerde KMS-machtigingen.

Oorzaak 1: Het machtigingenbeleid voor de AWS S3-connector is niet juist ingesteld

Dit probleem wordt veroorzaakt door onjuiste machtigingen in de AWS-omgeving.

Machtigingenbeleid maken

U hebt machtigingenbeleid nodig om de AWS S3-gegevensconnector te implementeren. Controleer de vereiste machtigingen en stel de relevante machtigingen in.

Oorzaak 2: De relevante gegevens bestaan niet in de S3-bucket

De relevante logboeken bestaan niet in de S3-bucket.

Oplossing: Zoeken naar logboeken en logboeken exporteren indien nodig

  1. Open in AWS de S3-bucket, zoek de relevante map op basis van de vereiste logboeken en controleer of er logboekbestanden in de map zijn.
  2. Als de gegevens niet bestaan, is er een probleem met de AWS-configuratie. In dit geval moet u een AWS-service configureren om logboeken te exporteren naar een S3-bucket.

Oorzaak 3: de S3-gegevens zijn niet aangekomen op de SQS

De gegevens zijn niet overgebracht van S3 naar de SQS.

Oplossing: Controleer of de gegevens zijn aangekomen en configureer gebeurtenismeldingen

  1. Open in AWS de relevante SQS.
  2. Op het tabblad Bewaking ziet u het verkeer in de widget Aantal verzonden berichten. Als er geen verkeer in de SQS is, is er een probleem met de AWS-configuratie.
  3. Zorg ervoor dat de definitie van gebeurtenismeldingen voor de SQS de juiste gegevensfilters (voorvoegsel en achtervoegsel) bevat.
    1. Als u de gebeurtenismeldingen wilt zien, selecteert u het tabblad Eigenschappen in de S3-bucket en gaat u naar de sectie Gebeurtenismeldingen.
    2. Als u deze sectie niet ziet, maakt u deze.
    3. Zorg ervoor dat de SQS het relevante beleid heeft om de gegevens op te halen uit de S3-bucket. De SQS moet dit beleid bevatten op het tabblad Toegangsbeleid .

Oorzaak 4: De SQS heeft de gegevens niet gelezen

De SQS heeft de S3-gegevens niet gelezen.

Oplossing: Controleer of de SQS de gegevens leest

  1. Open in AWS de relevante SQS.

  2. Open de relevante SQS in AWS en ga naar het tabblad Bewaking. U ziet verkeer in de widgets Aantal verwijderde berichten en Aantal ontvangen berichten.

  3. Eén piek aan gegevens is niet voldoende. Wacht tot er voldoende gegevens zijn (verschillende pieken) en controleer vervolgens op problemen.

  4. Als ten minste één van de widgets leeg is, controleert u de statuslogboeken door deze query uit te voeren:

    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. Zorg dat de statusfunctie is ingeschakeld:

    SentinelHealth 
| take 20

  6. Als de statusfunctie niet is ingeschakeld, schakelt u deze in.

Gegevens van de AWS S3-connector (of een van de gegevenstypen) worden weergegeven in Microsoft Sentinel met een vertraging van meer dan 30 minuten

Dit probleem treedt meestal op wanneer Microsoft geen bestanden in de map S3 kan lezen. Microsoft kan de bestanden niet lezen omdat ze zijn versleuteld of de verkeerde indeling hebben. In deze gevallen veroorzaken veel nieuwe pogingen uiteindelijk een opnamevertraging.

De oorzaak van het probleem bepalen

In deze sectie worden de volgende oorzaken behandeld:

  • Logboekversleuteling is niet juist ingesteld
  • Gebeurtenismeldingen zijn niet juist gedefinieerd
  • Statusfouten of status uitgeschakeld

Oorzaak 1: Logboekversleuteling is niet juist ingesteld

Als de logboeken volledig of gedeeltelijk zijn versleuteld door de Key Management Service (KMS), is Microsoft Sentinel mogelijk niet gemachtigd voor deze KMS om de bestanden te ontsleutelen.

Oplossing: Logboekversleuteling controleren

Zorg ervoor dat Microsoft Sentinel gemachtigd is voor deze KMS om de bestanden te ontsleutelen. Controleer de vereiste KMS-machtigingen voor de logboeken GuardDuty en CloudTrail.

Oorzaak 2: Gebeurtenismeldingen zijn niet correct geconfigureerd

Wanneer u een Amazon S3-gebeurtenismelding configureert, moet u opgeven naar welke ondersteunde gebeurtenistypen Amazon S3 de melding moet verzenden. Als er een gebeurtenistype bestaat dat u niet hebt opgegeven in uw Amazon S3-bucket, verzendt Amazon S3 de melding niet.

Oplossing: Controleer of gebeurtenismeldingen correct zijn gedefinieerd

Als u wilt controleren of de gebeurtenismeldingen van S3 naar de SQS correct zijn gedefinieerd, controleert u het volgende:

  • De melding wordt gedefinieerd vanuit de specifieke map die de logboeken bevat en niet vanuit de hoofdmap die de bucket bevat.
  • De melding wordt gedefinieerd met het achtervoegsel .gz . Bijvoorbeeld:

Oorzaak 3: Statusfouten of status uitgeschakeld

Er zijn mogelijk fouten in de statuslogboeken of de statusfunctie is mogelijk niet ingeschakeld.

Oplossing: Controleer of de statuslogboeken geen fouten bevatten en schakel de status in

  1. Controleer of er geen fouten zijn in de statuslogboeken door deze query uit te voeren:

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

  2. Zorg dat de statusfunctie is ingeschakeld:

    SentinelHealth 
| take 20

  3. Als de statusfunctie niet is ingeschakeld, schakelt u deze in.

Volgende stappen

In dit artikel hebt u geleerd hoe u snel oorzaken kunt identificeren en veelvoorkomende problemen met de AWS S3-connector kunt oplossen.

We zijn blij met feedback, suggesties, verzoeken om functies, foutrapporten of verbeteringen en toevoegingen. Ga naar de GitHub-opslagplaats van Microsoft Sentinel om een probleem of fork te maken en een bijdrage te uploaden.