Teilen über


Problembehandlung für AWS S3-Connectors

Mit dem Amazon Web Services (AWS) S3-Connector können Sie AWS-Dienstprotokolle, die in AWS S3-Buckets gesammelt werden, in Microsoft Sentinel erfassen. Die derzeit unterstützten Protokolltypen sind AWS CloudTrail, VPC Flow Logs und AWS GuardDuty.

In diesem Artikel wird beschrieben, wie Sie die Ursache von Problemen mit dem AWS S3-Connector schnell identifizieren, um die erforderlichen Schritte zum Beheben der Probleme zu ermitteln.

Lesen Sie Verbinden von Microsoft Sentinel mit Amazon Web Services zum Erfassen von AWS-Dienstprotokolldaten.

Microsoft Sentinel empfängt keine Daten vom Amazon Web Services S3-Connector oder von einem seiner Datentypen.

Nach dem Verbinden des Connectors dauert es länger als 30 Minuten, bis die Protokolle für den AWS S3-Connector (oder einen seiner Datentypen) im Microsoft Sentinel-Arbeitsbereich angezeigt werden.

Bedenken Sie Folgendes, bevor Sie nach einer Ursache und Lösung suchen:

  • Nach der Verbindungsherstellung mit dem Connector kann es etwa 20 bis 30 Minuten dauern, bis Daten im Arbeitsbereich erfasst werden.
  • Der Verbindungsstatus des Connectors gibt an, dass eine Sammlungsregel vorhanden ist, aber nicht, dass Daten erfasst wurden. Wenn der Status des Amazon Web Services S3-Connectors grün ist, ist eine Sammlungsregel für einen der Datentypen vorhanden, es liegen aber trotzdem noch keine Daten vor.

Ermitteln der Ursache des Problems

In diesem Abschnitt befassen wir uns mit den folgenden Ursachen:

  1. Die Berechtigungsrichtlinien für den AWS S3-Connector sind nicht korrekt festgelegt.
  2. Die Daten werden nicht im S3-Bucket in AWS erfasst.
  3. Die SQS-Instanz (Amazon Simple Queue Service) in der AWS-Cloud empfängt keine Benachrichtigungen vom S3-Bucket.
  4. Die Daten können nicht aus der SQS-Instanz/S3 in der AWS-Cloud gelesen werden. Bei GuardDuty-Protokollen ist das Problem auf falsche Berechtigungen für den Schlüsselverwaltungsdienst (Key Management Service, KMS) zurückzuführen.

Ursache 1: Die Berechtigungsrichtlinien für den AWS S3-Connector sind nicht korrekt festgelegt.

Dieses Problem wird durch falsche Berechtigungen in der AWS-Umgebung verursacht.

Erstellen von Berechtigungsrichtlinien

Sie benötigen Berechtigungsrichtlinien, um den AWS S3-Datenconnector bereitzustellen. Überprüfen Sie die erforderlichen Berechtigungen, und legen Sie die relevanten Berechtigungen fest.

Ursache 2: Die relevanten Daten sind nicht im S3-Bucket vorhanden.

Die relevanten Protokolle sind nicht im S3-Bucket vorhanden.

Lösung: Suchen nach Protokollen und ggf. Exportieren von Protokollen

  1. Öffnen Sie in AWS den S3-Bucket, suchen Sie nach dem relevanten Ordner für die erforderlichen Protokolle, und überprüfen Sie, ob der Ordner Protokolldateien enthält.
  2. Wenn die Daten nicht vorhanden sind, liegt ein Problem mit der AWS-Konfiguration vor. In diesem Fall müssen Sie einen AWS-Dienst zum Exportieren von Protokollen in einen S3-Bucket konfigurieren.

Ursache 3: Die S3-Daten wurden nicht von der SQS-Instanz empfangen.

Die Daten wurden nicht erfolgreich von S3 an die SQS-Instanz übertragen.

Lösung: Überprüfen, ob die Daten empfangen wurden, und Konfigurieren von Ereignisbenachrichtigungen

  1. Öffnen Sie in AWS die relevante SQS-Instanz.
  2. Auf der Registerkarte Überwachung sollte Datenverkehr im Widget mit der Anzahl gesendeter Nachrichten angezeigt werden. Wenn kein Datenverkehr in der SQS-Instanz vorhanden ist, liegt ein Problem mit der AWS-Konfiguration vor.
  3. Stellen Sie sicher, dass die Ereignisbenachrichtigungsdefinition für die SQS-Instanz die richtigen Datenfilter enthält (Präfix und Suffix).
    1. Wählen Sie zum Anzeigen der Ereignisbenachrichtigungen im S3-Bucket die Registerkarte Eigenschaften aus, und suchen Sie nach dem Abschnitt mit den Ereignisbenachrichtigungen.
    2. Falls dieser Abschnitt nicht angezeigt wird, erstellen Sie ihn.
    3. Stellen Sie sicher, dass die SQS-Instanz über die relevanten Richtlinien verfügt, um die Daten aus dem S3-Bucket abzurufen. Die SQS-Instanz muss diese Richtlinie auf der Registerkarte Zugriffsrichtlinie enthalten.

Ursache 4: Die SQS-Instanz hat die Daten nicht gelesen.

Die SQS-Instanz hat die S3-Daten nicht erfolgreich gelesen.

Lösung: Überprüfen, ob die SQS-Instanz die Daten liest

  1. Öffnen Sie in AWS die relevante SQS-Instanz.

  2. Auf der Registerkarte Überwachung sollte Datenverkehr in den Widgets mit der Anzahl gelöschter Nachrichten und der Anzahl empfangener Nachrichten zu sehen sein.

  3. Eine einzelne Datenspitze reicht nicht aus. Warten Sie mit der Überprüfung auf Probleme, bis genügend Daten (mehrere Spitzen) vorhanden sind.

  4. Wenn mindestens eines der Widgets leer ist, führen Sie die folgende Abfrage aus, um die Integritätsprotokolle zu überprüfen:

    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. Vergewissern Sie sich, dass das Integritätsfeature aktiviert ist:

    SentinelHealth 
    | take 20
    
  6. Falls das Integritätsfeature nicht aktiviert ist, aktivieren Sie es.

Daten vom AWS S3-Connector (oder von einem seiner Datentypen) werden in Microsoft Sentinel mit einer Verzögerung von mehr als 30 Minuten angezeigt.

Dieses Problem tritt in der Regel auf, wenn Microsoft Dateien im S3-Ordner nicht lesen kann. Microsoft kann die Dateien nicht lesen, da sie entweder verschlüsselt sind oder das falsche Format aufweisen. In diesen Fällen verursachen viele Wiederholungen schließlich eine Verzögerung der Erfassung.

Ermitteln der Ursache des Problems

In diesem Abschnitt befassen wir uns mit den folgenden Ursachen:

  • Die Protokollverschlüsselung ist nicht korrekt eingerichtet.
  • Ereignisbenachrichtigungen sind nicht korrekt definiert.
  • Es liegen Integritätsfehler vor, oder das Integritätsfeature ist deaktiviert.

Ursache 1: Die Protokollverschlüsselung ist nicht korrekt eingerichtet.

Wenn die Protokolle vollständig oder teilweise vom Schlüsselverwaltungsdienst (KMS) verschlüsselt werden, verfügt Microsoft Sentinel möglicherweise nicht über die Berechtigung zum Entschlüsseln der Dateien für diesen KMS.

Lösung: Überprüfen der Protokollverschlüsselung

Stellen Sie sicher, dass Microsoft Sentinel für diesen KMS über die Berechtigung zum Entschlüsseln der Dateien verfügt. Überprüfen Sie die erforderlichen KMS-Berechtigungen für die GuardDuty- und CloudTrail-Protokolle.

Ursache 2: Ereignisbenachrichtigungen sind nicht korrekt konfiguriert.

Wenn Sie eine Amazon S3-Ereignisbenachrichtigung konfigurieren, müssen Sie angeben, an welche unterstützten Ereignistypen Amazon S3 die Benachrichtigung senden soll. Wenn ein Ereignistyp, den Sie nicht angegeben haben, in Ihrem Amazon S3-Bucket vorhanden ist, sendet Amazon S3 die Benachrichtigung nicht.

Lösung: Überprüfen, ob Ereignisbenachrichtigungen korrekt definiert sind

Überprüfen Sie Folgendes, um sicherzustellen, dass die Ereignisbenachrichtigungen von S3 an die SQS-Instanz korrekt definiert sind:

  • Die Benachrichtigung ist über den Ordner definiert, der die Protokolle enthält, und nicht über den Hauptordner, der den Bucket enthält.
  • Die Benachrichtigung ist mit dem Suffix .gz definiert. Beispiel:

Ursache 3: Es liegen Integritätsfehler vor, oder das Integritätsfeature ist deaktiviert.

Möglicherweise liegen Fehler in den Integritätsprotokollen vor, oder das Integritätsfeature ist nicht aktiviert.

Lösung: Überprüfen, ob Fehler in den Integritätsprotokollen vorliegen, und Aktivieren des Integritätsfeatures

  1. Führen Sie die folgende Abfrage aus, um sicherzustellen, dass keine Fehler in den Integritätsprotokollen vorhanden sind:

    SentinelHealth
    | where TimeGenerated between (ago(startTime)..ago(endTime))
    | where SentinelResourceKind  == "AmazonWebServicesS3"
    | where Status != "Success"
    | distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description
    
  2. Vergewissern Sie sich, dass das Integritätsfeature aktiviert ist:

    SentinelHealth 
    | take 20
    
  3. Falls das Integritätsfeature nicht aktiviert ist, aktivieren Sie es.

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie häufige Probleme mit dem AWS S3-Connector schnell identifizieren und beheben können.

Wir freuen uns über Feedback, Vorschläge, Featureanfragen, Fehlerberichte oder Verbesserungen und Ergänzungen. Besuchen Sie das Microsoft Sentinel-GitHub-Repository, um ein Problem zu melden oder einen Beitrag zu forken und hochzuladen.