Mit der Benutzeroberfläche für Feeds arbeiten

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Feeds in der Feed Management UI erstellen, verwalten und Fehler beheben. Außerdem finden Sie hier Anleitungen zum Ändern, Aktivieren und Löschen von Feeds.

Hinweis

Für jeden Datenfeed sind bestimmte Voraussetzungen erforderlich, bevor er in Google Security Operations eingerichtet werden kann. Die Anforderungen für Ihren Feed finden Sie unter Konfiguration nach Quelltyp. Suchen Sie dort nach Ihrer spezifischen Datenquelle.

Unterstützte Komprimierungsformate und Dateigrößen

Für die Aufnahme von Feeds werden die Komprimierungsformate .gz, .tar.gz, .tar und solr.gz unterstützt. In der folgenden Tabelle sind die verschiedenen Dateigrößen aufgeführt, die von der Transformation von Google SecOps-Feeds unterstützt werden:

Vorgang Eingabetyp Empfohlene Größe Erwartete Dauer Max. Größe
Datenmodellierung CSV < 5 GB < 7 Min. 10 GB
Datenmodellierung CSV < 5 GB ~30 Min. 10 GB
Datenmodellierung CSV TBD TBD 2 GB
Datenmodellierung XML / JSON < 1 GB < 10 Min. 2 GB
Datenmodellierung XLS / XLSX < 50 MB ~1 Min. 50 MB
Dateien zusammenführen Beliebig < 1 GB Variiert je nach Anzahl der Dateien 100 GB
Dateien entpacken Nicht-ZIP < 5 GB Variiert je nach Anzahl der Dateien 10 GB (unkomprimiert)
Dateien entpacken Postleitzahl - Variiert je nach Anzahl der Dateien 4 GB (unkomprimiert)

Grenzwerte und Trennzeichen für Logzeilen

Wenn Sie textbasierte Logs (JSON, CSV oder Syslog) erfassen, müssen Ihre Daten die folgenden Erfassungslimits einhalten:

  • Maximale Zeilengröße: Eine einzelne Logzeile darf nicht größer als 4 MB sein. Wenn eine einzelne Zeile dieses Limit überschreitet, schlägt der Feed mit dem Fehler MaxLogLineSize4MBExceeded fehl.
  • Unterstützte Trennzeichen: Sowohl Zeilenvorschub (\n) als auch Zeilenumbruch + Zeilenvorschub (\r\n) werden unterstützt.

Auswirkungen der Änderung des verknüpften Cloud-Projekts auf Datenfeeds

Wenn Sie das Google Cloud -Projekt aktualisieren, das mit Ihrer Google SecOps-Instanz verknüpft ist, werden alle Feeds, die Daten mit den folgenden Connectors aufnehmen, beendet und müssen manuell neu erstellt werden:

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

Bei allen anderen Feeds, die diese Connectors nicht verwenden, wird die Aufnahme ohne Unterbrechung fortgesetzt. Kunden müssen nichts weiter unternehmen.

Erwartungen während der Migration

Bei betroffenen Feeds sind folgende Änderungen zu beobachten:

  • Feedstatus: Für Feeds, die vor der Migration erstellt wurden, werden keine Live-Daten mehr abgerufen. Sie sind schreibgeschützt.
  • Vorhandene Daten: Alle Daten, die vor der Migration bereits in Google SecOps übertragen wurden, werden automatisch aufgenommen. Es gehen keine Daten verloren.
  • Fehlermeldungen: Wenn Sie versuchen, einen älteren Feed zu bearbeiten oder zu löschen, wird die folgende Meldung angezeigt: This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

Erforderliche Maßnahmen für Kunden

Damit die Daten weiterhin aufgenommen werden, müssen Sie Ihre Feeds in der neuen Umgebung manuell neu erstellen. So minimieren Sie Unterbrechungen:

  1. Feeds neu erstellen: Sie müssen neue Feeds erstellen, um die Feeds zu ersetzen, die vor der Migration vorhanden waren.
  2. Maximales Dateialter konfigurieren: Legen Sie beim Einrichten Ihrer neuen Feeds das maximale Dateialter auf etwa 2 Stunden vor dem Start des BYOP-Updates fest. Dieser Puffer sorgt für einen reibungslosen Übergang.

  3. Doppelte Daten verwalten: Je nach ausgewählter Maximales Dateialter kann es zu einer Übertragung doppelter Daten kommen. Technische Details dazu, wie Google SecOps diese redundanten Logs filtert, finden Sie unter Deduplizierung verhindern.

  4. Vorhandene Feeds aufzeichnen und löschen (vor der Migration): Bevor Sie mit der BYOP-Migration beginnen, zeichnen Sie die Konfigurationseinstellungen für alle vorhandenen Feeds auf, die die betroffenen Connectors (z. B. Amazon S3 V2) verwenden, und löschen Sie dann die Feeds. Wenn Sie vor der Migration erstellte Feeds nicht löschen, können sie nicht mehr verwaltet werden und verbleiben als verwaiste Einstellungen in der Google SecOps-Weboberfläche.

Möglichkeiten zum Einrichten von Feeds

Google SecOps-Kunden haben zwei Möglichkeiten, einen Feed in der Plattform einzurichten. Verwenden Sie die Methode, die für Ihre Umgebung am besten geeignet ist:

  • SIEM-Einstellungen > Feeds (Standard)
  • Content Hub > Content-Pakete (Premium)

Feeds konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Ihre Feeds allgemein konfigurieren. Wir beginnen mit dem standardmäßigen Ablauf. Die auf der Seite Feeds aufgeführten Datenfeeds umfassen alle Feeds, die Google für Ihr Konto konfiguriert hat, einschließlich der von Ihnen konfigurierten Feeds.

Feed hinzufügen

So fügen Sie Ihrem Google SecOps-Konto einen Feed hinzu:

  1. Wählen Sie im Google SecOps-Menü SIEM-Einstellungen > Feeds aus.

  2. Klicken Sie auf Neuen Feed hinzufügen.

  3. Klicken Sie auf der nächsten Seite auf Einen einzelnen Feed konfigurieren. Hinweis: Dieser Schritt ist für Kunden, die die eigenständige Google SecOps SIEM-Plattform verwenden, nicht relevant.

  4. Geben Sie einen Feednamen ein.

  5. Wählen Sie in der Liste Quelltyp den Quelltyp für den Import von Daten in Google SecOps aus. Folgende Feed-Quelltypen stehen zur Auswahl:

    • Amazon Data Firehose
    • Amazon S3 (eingestellt)
    • Amazon S3 (V2)
    • Amazon SQS (eingestellt)
    • Amazon SQS (V2)
    • Azure Blob Storage (eingestellt)
    • Azure Blob Storage (V2)
    • Benutzerdefinierte API
    • Cloud Pub/Sub
    • Cloud Storage (eingestellt)
    • Cloud Storage (V2)
    • Cloud Storage-ereignisgesteuert
    • Drittanbieter-API
    • Webhook

    Wichtig:

    • Wenn Sie Feeds für Amazon S3 (eingestellt), Amazon SQS (eingestellt), Azure Blob Storage (eingestellt) und Google Cloud Cloud Storage (eingestellt) verwenden, muss der Verzeichnispfad gültig sein.
    • Wenn Sie Amazon SQS (eingestellt) oder Amazon SQS (V2) verwenden, müssen Sie Google SecOps explizit die Berechtigung zum Löschen von Nachrichten aus der Amazon SQS-Warteschlange erteilen.
    • Wenn Sie Amazon SQS-Feeds (eingestellt) verwenden, achten Sie darauf, dass nur ein Feed Nachrichten aus der Warteschlange verarbeitet. Nachrichten, die von einer anderen Anwendung oder einem anderen Feed gelesen wurden, werden nicht in den aktuellen Feed aufgenommen.
    • Die Verwendung von Amazon SQS (eingestellt) als Feedquelltyp wird nur für Logs in Amazon S3-Buckets unterstützt.

  6. Wählen Sie in der Liste Logtyp den Logtyp aus, der den Logs entspricht, die Sie aufnehmen möchten. Die verfügbaren Protokolle variieren je nach dem Quelltyp, den Sie zuvor ausgewählt haben.

    Wenn Sie Cloud Storage als Quelltyp auswählen, verwenden Sie die Option Dienstkonto abrufen, um ein eindeutiges Dienstkonto zu erhalten. Beispiel für die Einrichtung eines Google Cloud Storage-Feeds

  7. Klicken Sie auf Weiter.

  8. Geben Sie auf dem Tab Eingabeparameter die erforderlichen Parameter an. Die hier angezeigten Optionen variieren je nach Quelle und Protokolltyp, die auf dem Tab Eigenschaften festlegen ausgewählt sind. Bewegen Sie den Mauszeiger auf das Fragezeichensymbol neben den einzelnen Feldern, um weitere Informationen dazu zu erhalten, was Sie angeben müssen.

  9. Optional: Sie können einen Namespace auf dem Tab Eigenschaften festlegen angeben. Weitere Informationen zu Namespaces finden Sie unter Mit Asset-Namespaces arbeiten.

  10. Klicken Sie auf Weiter.

  11. Prüfen Sie die neue Feedkonfiguration auf dem Tab Abschließen.

  12. Klicken Sie auf Senden. Google SecOps führt eine Validierungsprüfung des neuen Feeds durch. Wenn der Feed die Prüfung besteht, wird ein Name für den Feed generiert, er wird an Google SecOps gesendet und Google SecOps versucht, Daten abzurufen.

    Feedanfrage abschließen

Mehrere Feeds für eine Produktfamilie konfigurieren (nur Google SecOps-Kunden)

Sie können mehrere Feeds pro Produktfamilie konfigurieren, basierend auf dem Logtyp.

  • Baseline-Protokolltypen: Als empfohlen gekennzeichnet. Diese Logtypen werden für die Kernfunktionen der Plattform empfohlen.
  • Zusätzliche Logtypen: Als optional gekennzeichnet. Diese Protokolltypen bieten zusätzlichen Kontext.

Um die Einrichtung zu vereinfachen, bietet die Plattform für jede Konfiguration spezifische Einrichtungsanleitungen und vordefinierte Parameter. Für CrowdStrike Falcon können Sie beispielsweise mehrere eindeutige Feeds sowohl für empfohlene als auch für optionale Logtypen erstellen, um eine umfassende Datenabdeckung zu gewährleisten.

Feed für CrowdStrike EDR konfigurieren

So konfigurieren Sie einen Logfeed für CrowdStrike EDR:

  1. Klicken Sie unter Einstellungen > Feeds auf Neuen Feed hinzufügen.
    1. Klicken Sie auf das Produkt CrowdStrike Falcon:
    2. Wählen Sie den Logtyp CrowdStrike EDR aus.
  2. Alternativ können Sie unter Content Hub> Content-Pakete auf das Produkt CrowdStrike Falcon klicken:
    1. Klicken Sie auf Jetzt starten.
    2. Wählen Sie den Logtyp CrowdStrike EDR aus.

  3. Geben Sie Werte für die folgenden Felder an:

    Feld Beschreibung
    Source Type Amazon SQS
    Region Die AWS S3-Region, die dem URI zugeordnet ist.
    Queue Name Der Name der SQS-Warteschlange, aus der gelesen werden soll.
    Account Number Die SQS-Kontonummer.
    Source Deletion Option Gibt an, ob Dateien und Verzeichnisse nach der Übertragung gelöscht werden sollen.
    Queue Access Key ID Ein 20-stelliger alphanumerischer Zugriffsschlüssel für das Konto, z. B. AKIAOSFOODNN7EXAMPLE.
    Queue Secret Access Key Ein 40-stelliger alphanumerischer geheimer Zugriffsschlüssel für das Konto, z. B. wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. Optional: Konfigurieren Sie die folgenden Parameter:

    • Feedname: Der eindeutige Name des Feeds wird automatisch ausgefüllt.
    • Asset-Namespace: Der Namespace, der dem Feed zugeordnet ist.
    • Aufnahme-Labels: Labels, die auf die Ereignisse aus diesem Feed angewendet werden.

  5. Klicken Sie auf Feed erstellen.

Sie können diesen Vorgang wiederholen, um zusätzliche Feeds für denselben Logtyp zu erstellen. Sie können auch Feeds für andere verfügbare Logtypen direkt auf dieser Seite konfigurieren. Rufen Sie nach Abschluss die Seite Feed Management (Feedverwaltung) auf, um eine detaillierte Zusammenfassung aller konfigurierten Protokolltypen zu sehen.

IP-Zulassungsliste

Aktivieren Sie die Zulassungsliste und fügen Sie die Google-IP-Bereiche für alle Logtypen hinzu, in die Daten aus Drittanbieter-APIs aufgenommen werden.

Quelldateien löschen

Mit der Option zum Löschen der Quelle können Sie Feedquellenobjekte (Dateien und Ordner) nach einer erfolgreichen Übertragung aus dem Speicher löschen. Diese Option ist nur für ausgewählte Feedquelltypen verfügbar, darunter Cloud Storage. Diese Feedquellentypen enthalten das Feld SOURCE DELETION OPTION in den Workflows Add new (Neu hinzufügen) und Edit feed (Feed bearbeiten).

Optionen zum Löschen von Quellen

  • Für unterstützte Feedquelltypen, einschließlich Cloud Storage, bietet das Feld SOURCE DELETION OPTION (Option zum Löschen der Quelle) die folgenden Optionen:

    • Dateien nie löschen
    • Übertragene Dateien und leere Verzeichnisse löschen
    • Übertragene Dateien löschen

  • Microsoft Azure Blob Storage (AZURE_BLOBSTORE) unterstützt das Löschen von Quelldateien nicht. Wählen Sie im Feld SOURCE DELETION OPTION (OPTION ZUM LÖSCHEN DER QUELLE) nur die Option Never delete files (Dateien nie löschen) aus.

  • Für die folgenden Feedquellen ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2 und AZURE_BLOBSTORE_V2 bietet das Feld OPTION ZUM LÖSCHEN DER QUELLE zwei Optionen:

    • NIE: Es werden nach Übertragungen niemals Dateien gelöscht.
    • ON_SUCCESS: Löscht alle Dateien und leeren Verzeichnisse nach der Übertragung.

Quellspezifische Einrichtung und Berechtigungen

Für verschiedene Quelltypen sind bestimmte Authentifizierungs- und Netzwerkkonfigurationen erforderlich, um mit Google SecOps zu kommunizieren. In diesem Abschnitt wird beschrieben, wie Sie Berechtigungen konfigurieren und Dienstkonten einrichten. Die beschriebene Einrichtung konzentriert sich auf die Aufnahme in Cloud Storage (Pull-basiert), die Aufnahme in Multi-Cloud (cloudübergreifender Pull) und die Push-basierte Aufnahme (API oder Echtzeit).

Beispiel für die Einrichtung eines Google Cloud Storage-Feeds

  1. Wählen Sie im Google SecOps-Menü Einstellungen und dann Feeds aus.
  2. Klicken Sie auf Neuen Feed hinzufügen.
  3. Klicken Sie auf der nächsten Seite auf Einen einzelnen Feed konfigurieren. Dieser Schritt ist nicht erforderlich, wenn Sie die eigenständige Google SecOps SIEM-Plattform verwenden.
  4. Wählen Sie für Quelltyp die Option Cloud Storage v2 aus.
  5. Wählen Sie den Logtyp aus. Wenn Sie beispielsweise einen Feed für Google Kubernetes Engine-Audit-Logs erstellen möchten, wählen Sie Google Kubernetes Engine-Audit-Logs als Logtyp aus.
  6. Klicken Sie auf Dienstkonto abrufen. Google SecOps stellt ein eindeutiges Dienstkonto bereit, das von Google SecOps zum Erfassen von Daten verwendet wird. Alternativ können Sie dieses Dienstkonto programmatisch über die API abrufen. Weitere Informationen finden Sie unter Dienstkonto abrufen.
  7. Optional: Konfigurieren Sie das Dienstkonto. Weitere Informationen finden Sie unter Zugriff auf das Google SecOps-Dienstkonto gewähren.
  8. Klicken Sie auf Weiter.

  9. Geben Sie basierend auf der von Ihnen erstellten Cloud Storage-Konfiguration Werte für die folgenden Felder an:

    • Storage-Bucket-URI

    • Option zum Löschen der Quelle

    Weitere Informationen zum Einrichten von Cloud Storage-Buckets finden Sie unter Buckets erstellen.

  10. Klicken Sie auf Weiter und dann auf Senden.

Zugriff auf das Google SecOps-Dienstkonto gewähren

  1. Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.

    Buckets aufrufen

  2. Gewähren Sie dem Dienstkonto Zugriff auf die relevanten Cloud Storage-Objekte.

    • So erteilen Sie die Leseberechtigung für eine bestimmte Datei:

      1. Wählen Sie die Datei aus und klicken Sie auf Zugriff bearbeiten.
      2. Klicken Sie auf Hauptkonto hinzufügen.
      3. Geben Sie im Feld Neue Hauptkonten den Namen des Google SecOps-Dienstkontos ein.
      4. Weisen Sie dem Google SecOps-Dienstkonto eine Rolle mit der Leseberechtigung zu. Beispiel: Storage-Objekt-Betrachter (roles/storage.objectViewer). Dies ist nur möglich, wenn Sie den einheitlichen Zugriff auf Bucket-Ebene nicht aktiviert haben.
      5. Klicken Sie auf Speichern.

    • Wenn Sie mehreren Dateien die Leseberechtigung erteilen möchten, gewähren Sie den Zugriff auf Bucket-Ebene so:

      • Für "feedSourceType": "GOOGLE_CLOUD_STORAGE":

        1. Fügen Sie das Google SecOps-Dienstkonto als Hauptkonto zu Ihrem Speicher-Bucket hinzu und weisen Sie ihm die IAM-Rolle Storage-Objekt-Betrachter (roles/storage.objectViewer) zu.
        2. Wenn Sie den Feed so konfigurieren, dass Quelldateien gelöscht werden, müssen Sie das Google SecOps-Dienstkonto als Hauptkonto in Ihrem Bucket hinzufügen und ihm die IAM-Rolle Storage-Objekt-Administrator (roles/storage.objectAdmin) zuweisen.

      • Weisen Sie für "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2" die folgenden Rollen zu:

        1. So weisen Sie diese Rolle zu:

          • Storage-Objekt-Betrachter (roles/storage.objectViewer), wenn die Übertragung in einen anderen Cloud Storage-Bucket erfolgt.

        2. Weisen Sie eine der folgenden Rollen zu, je nachdem, was Sie für die Option zum Löschen der Quelle auswählen. Wenn Sie Bei Erfolg auswählen, weisen Sie die Rolle Autor alter Storage-Buckets zu. Wenn Sie Nie auswählen, weisen Sie die Rolle Storage Legacy Bucket Reader zu:

          • Autor alter Storage-Buckets (roles/storage.legacyBucketWriter), wenn die Berechtigung zum Löschen von Objekten erforderlich ist.
          • Leser alter Storage-Buckets (roles/storage.legacyBucketReader), wenn die Berechtigung zum Löschen von Objekten nicht erforderlich ist.

      • Für "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

        1. Weisen Sie eine der folgenden Rollen zu:

          • Storage-Objekt-Betrachter (roles/storage.objectViewer), wenn die Übertragung in einen anderen Cloud Storage-Bucket erfolgt.
          • Storage-Objekt-Ersteller (roles/storage.objectCreator), wenn die Übertragung in ein Dateisystem erfolgt.

        2. Weisen Sie eine der folgenden Rollen zu:

          • Autor alter Storage-Buckets (roles/storage.legacyBucketWriter), wenn die Berechtigung zum Löschen von Objekten erforderlich ist.
          • Leser alter Storage-Buckets (roles/storage.legacyBucketReader), wenn die Berechtigung zum Löschen von Objekten nicht erforderlich ist.

STS-Zugriff für Amazon S3 und Azure Storage aktivieren

Der STS wird von den folgenden Google Cloud Storage-Feeds verwendet, um Daten aus Amazon S3- und Azure Storage-Blobstores in Google SecOps zu übertragen:

  • Amazon S3 (V2)
  • Amazon SQS (V2)
  • Azure Blob Storage (V2)

STS sendet Datenübertragungsanfragen an die Amazon S3- und Azure-Speicherdienste über eine Reihe definierter STS-IP-Adressbereiche. Diese STS-IP-Adressbereiche werden in der folgenden JSON-Datei veröffentlicht: IP-Bereiche

Wenn Sie diese STS-Feedquelltypen verwenden möchten, müssen Sie möglicherweise die IP-Zugriffsbeschränkungen anpassen, damit STS auf Ihre Amazon S3- und Azure-Speicherdienste zugreifen kann:

  1. Rufen Sie die neuesten IP-Bereiche aus der JSON-Datei ab.

    Wir empfehlen, Daten aus dieser JSON-Datei mindestens wöchentlich zu lesen, um Ihre Sicherheitskonfiguration auf dem neuesten Stand zu halten. Wenn der Datei ein neuer Bereich hinzugefügt wird, wartet das System mindestens sieben Tage, bevor es diesen Bereich für Anfragen von STS verwendet.

    Ein Beispiel für ein Python-Skript, mit dem IP-Bereiche aus einer JSON-Datei abgerufen werden, finden Sie unter IP-Adressen für Standarddomains.

  2. Vergleichen Sie den aktuellen IP-Bereich creationTime mit dem IP-Bereich creationTime, der aus der vorherigen JSON-Datei gelesen wurde. Wenn sie sich unterscheiden, aktualisieren Sie die IP-Zugriffsbeschränkungen in Amazon S3- und Azure Storage-Blobstores.

    • Für Amazon S3

      So aktualisieren Sie die IP-Zugriffsbeschränkungen in Ihrem Amazon S3-Blobstore:

      Wenn in Ihrem AWS-Projekt IP-Einschränkungen für den Zugriff auf den Speicher verwendet werden, müssen Sie die von STS-Workern verwendeten IP-Bereiche der Liste der zulässigen IP-Adressen hinzufügen.

      Wenn Sie diese Bereiche als zulässige IPs hinzufügen möchten, verwenden Sie das Feld Condition in einer bucket policy, wie in der AWS S3-Dokumentation unter Zugriff basierend auf bestimmten IP-Adressen verwalten beschrieben.

    • Für Azure Storage

      So aktualisieren Sie die IP-Zugriffsbeschränkungen in Ihrem Azure Storage-Blobstore:

      Wenn Sie den Zugriff auf Ihre Azure-Ressourcen über eine Azure Storage-Firewall beschränken, müssen Sie die von STS-Workern verwendeten IP-Bereiche der Liste der zulässigen IP-Adressen hinzufügen.

      Wenn Sie diese Bereiche als zulässige IPs hinzufügen möchten, folgen Sie dieser Anleitung: Azure Storage-Firewalls und virtuelle Netzwerke konfigurieren.

Pub/Sub-Push-Feed einrichten

So richten Sie einen Pub/Sub-Push-Feed ein:

  1. Pub/Sub-Push-Feed erstellen
  2. Geben Sie die Endpunkt-URL in einem Pub/Sub-Abo an.

Pub/Sub-Push-Feed erstellen

  1. Wählen Sie im Google SecOps-Menü Einstellungen und dann Feeds aus.
  2. Klicken Sie auf Neu hinzufügen.
  3. Geben Sie im Feld Feedname einen Namen für den Feed ein.
  4. Wählen Sie in der Liste Quelltyp die Option Google Cloud Pub/Sub Push aus.
  5. Wählen Sie den Logtyp aus. Wenn Sie beispielsweise einen Feed für das Open Cybersecurity Schema Framework erstellen möchten, wählen Sie Open Cybersecurity Schema Framework (OCSF) als Log-Typ aus.
  6. Klicken Sie auf Weiter.
  7. Optional: Geben Sie Werte für die folgenden Eingabeparameter an:
    • Trennzeichen für Aufteilung: Das Trennzeichen, das zum Trennen von Logzeilen verwendet wird. Sie können nur \n verwenden.
    • Asset-Namespace: der Asset-Namespace.
    • Aufnahmelabels: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.
  8. Klicken Sie auf Weiter.
  9. Prüfen Sie die neue Feedkonfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
  10. Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld Endpunktinformationen. Sie benötigen diese Endpunkt-URL, um ein Push-Abo in Pub/Sub zu erstellen.
  11. Optional: Klicken Sie auf den Ein/Aus-Button Feed aktiviert, um den Feed zu deaktivieren. Der Feed ist standardmäßig aktiviert.
  12. Klicken Sie auf Fertig.

Endpunkt-URL angeben

Nachdem Sie einen Pub/Sub-Push-Feed erstellt haben, geben Sie die Endpunkt-URL so an:

  1. Erstellen Sie in Pub/Sub ein Push-Abo. Weitere Informationen zum Erstellen eines Push-Abos finden Sie unter Push-Abos erstellen.
  2. Geben Sie die Endpunkt-URL an, die im Google Cloud Pub/Sub-Push-Feed verfügbar ist.
  3. Wählen Sie Authentifizierung aktivieren und ein Dienstkonto aus.
  4. Deaktivieren Sie sowohl die Option Entpacken der Push-Nutzlast als auch Entpacken der Push-Nutzlast, Nachrichtenmetadaten schreiben.

Amazon Data Firehose-Feed einrichten

So richten Sie einen Amazon Data Firehose-Feed ein:

  1. Erstellen Sie einen Amazon Data Firehose-Feed und kopieren Sie die Endpunkt-URL und den geheimen Schlüssel.
  2. Erstellen Sie einen API-Schlüssel, um sich bei Google SecOps zu authentifizieren. Sie können auch Ihren vorhandenen API-Schlüssel verwenden, um sich bei Google SecOps zu authentifizieren.
  3. Endpunkt-URL in Amazon Data Firehose angeben

Amazon Data Firehose-Feed erstellen

  1. Wählen Sie im Google SecOps-Menü Einstellungen und dann Feeds aus.
  2. Klicken Sie auf Neu hinzufügen.
  3. Geben Sie im Feld Feedname einen Namen für den Feed ein.
  4. Wählen Sie in der Liste Quelltyp die Option Amazon Data Firehose aus.
  5. Wählen Sie den Logtyp aus. Wenn Sie beispielsweise einen Feed für das Open Cybersecurity Schema Framework erstellen möchten, wählen Sie Open Cybersecurity Schema Framework (OCSF) als Log-Typ aus.
  6. Klicken Sie auf Weiter.
  7. Optional: Geben Sie Werte für die folgenden Eingabeparameter an:
    • Trennzeichen für Aufteilung: Das Trennzeichen, das zum Trennen von Logzeilen verwendet wird. Sie können nur \n verwenden.
    • Asset-Namespace: der Asset-Namespace.
    • Aufnahmelabels: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.
  8. Klicken Sie auf Weiter.
  9. Prüfen Sie die neue Feedkonfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
  10. Klicken Sie auf Geheimen Schlüssel generieren, um einen geheimen Schlüssel zur Authentifizierung dieses Feeds zu generieren.
  11. Kopieren Sie den geheimen Schlüssel und speichern Sie ihn, da Sie ihn nicht noch einmal aufrufen können. Sie können einen neuen geheimen Schlüssel generieren. Durch die Neugenerierung des geheimen Schlüssels wird der vorherige geheime Schlüssel jedoch ungültig.
  12. Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld Endpoint Information (Endpunktinformationen). Sie benötigen diese Endpunkt-URL, wenn Sie die Zieleinstellungen für Ihren Bereitstellungsstream in Amazon Data Firehose angeben.
  13. Optional: Klicken Sie auf den Ein/Aus-Button Feed aktiviert, um den Feed zu deaktivieren. Der Feed ist standardmäßig aktiviert.
  14. Klicken Sie auf Fertig.

API-Schlüssel für den Amazon Data Firehose-Feed erstellen

So erstellen Sie einen API-Schlüssel für den Amazon Data Firehose-Feed:

  1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf.
  2. Klicken Sie auf Anmeldedaten erstellen und wählen Sie den API-Schlüssel aus.
  3. Schränken Sie den API-Schlüsselzugriff auf die Chronicle API ein.

Endpunkt-URL angeben

Geben Sie in Amazon Data Firehose den HTTPS-Endpunkt und den Zugriffsschlüssel so an:

  1. Hängen Sie den API-Schlüssel an die URL des Feed-Endpunkts an und geben Sie diese URL als HTTP-Endpunkt-URL im folgenden Format an:

      ENDPOINT_URL?key=API_KEY

    Ersetzen Sie Folgendes:

    • ENDPOINT_URL: Die Feed-Endpunkt-URL.
    • API_KEY: Der API-Schlüssel für die Authentifizierung bei Google SecOps.

  2. Geben Sie für den Zugriffsschlüssel den geheimen Schlüssel an, den Sie beim Erstellen des Amazon Data Firehose-Feeds erhalten haben.

HTTPS-Webhook-Feed einrichten

Hinweise:

So richten Sie einen HTTPS-Webhook-Feed ein:

  1. Erstellen Sie einen HTTPS-Webhook-Feed und kopieren Sie die Endpunkt-URL und den geheimen Schlüssel.
  2. Erstellen Sie einen API-Schlüssel, der mit der Endpunkt-URL angegeben wird. Sie können auch Ihren vorhandenen API-Schlüssel zur Authentifizierung bei Google SecOps wiederverwenden.
  3. Endpunkt-URL in der Anwendung angeben

Mehrere Ereignisse in einer einzelnen Webhook-Anfrage senden

Das folgende Codebeispiel zeigt, wie ein einzelner Anfragetext mit mehreren, durch Zeilenumbrüche getrennten JSON-Objekten nach dem curl --location-Element formatiert wird:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

HTTPS-Webhook-Feed erstellen

  1. Wählen Sie im Google SecOps-Menü Einstellungen und dann Feeds aus.
  2. Klicken Sie auf Neu hinzufügen.
  3. Geben Sie im Feld Feedname einen Namen für den Feed ein.
  4. Wählen Sie in der Liste Quelltyp die Option Webhook aus.
  5. Wählen Sie den Logtyp aus. Wenn Sie beispielsweise einen Feed für das Open Cybersecurity Schema Framework erstellen möchten, wählen Sie Open Cybersecurity Schema Framework (OCSF) als Log-Typ aus.
  6. Klicken Sie auf Weiter.
  7. Optional: Geben Sie Werte für die folgenden Eingabeparameter an:
    • Trennzeichen für Aufteilung: Das Trennzeichen, das zum Trennen von Logzeilen verwendet wird. Sie können nur \n verwenden.
    • Asset-Namespace: der Asset-Namespace.
    • Aufnahmelabels: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.
  8. Klicken Sie auf Weiter.
  9. Prüfen Sie die neue Feedkonfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
  10. Klicken Sie auf Geheimen Schlüssel generieren, um einen geheimen Schlüssel zur Authentifizierung dieses Feeds zu generieren.
  11. Kopieren Sie den geheimen Schlüssel und speichern Sie ihn, da Sie ihn nicht noch einmal aufrufen können. Sie können einen neuen geheimen Schlüssel generieren. Durch die Neugenerierung des geheimen Schlüssels wird der vorherige geheime Schlüssel jedoch ungültig.
  12. Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld Endpunktinformationen. Sie müssen diese Endpunkt-URL in Ihrer Clientanwendung angeben.
  13. Optional: Klicken Sie auf den Ein/Aus-Button Feed aktiviert, um den Feed zu deaktivieren. Der Feed ist standardmäßig aktiviert.
  14. Klicken Sie auf Fertig.

API-Schlüssel für den Webhook-Feed erstellen

  1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf.
  2. Klicken Sie auf Anmeldedaten erstellen und wählen Sie anschließend API-Schlüssel aus.
  3. Schränken Sie den API-Schlüsselzugriff auf die Chronicle API ein.

Endpunkt-URL angeben

  1. Geben Sie in Ihrer Clientanwendung den HTTPS-Endpunkt an, der im Webhook-Feed verfügbar ist.

  2. Aktivieren Sie die Authentifizierung, indem Sie den API-Schlüssel und den geheimen Schlüssel als Teil des benutzerdefinierten Headers im folgenden Format angeben:

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    Wir empfehlen, den API-Schlüssel als Header anzugeben, anstatt ihn in der URL anzugeben. Wenn Ihr Webhook-Client keine benutzerdefinierten Header unterstützt, können Sie den API-Schlüssel und den geheimen Schlüssel mit Suchparametern im folgenden Format angeben:

      ENDPOINT_URL?key=API_KEY&secret=SECRET

    Ersetzen Sie Folgendes:

    • ENDPOINT_URL: Die Feed-Endpunkt-URL.
    • API_KEY: Der API-Schlüssel für die Authentifizierung bei Google SecOps.
    • SECRET: der geheime Schlüssel, den Sie zur Authentifizierung des Feeds generiert haben.

Benutzerdefinierten API-Feed einrichten

Mit benutzerdefinierten API-Feeds von Google Security Operations (auch als „Codeless Connectors“ bezeichnet) können Sie Telemetriedaten aus REST APIs von Drittanbietern über ein flexibles, konfigurationsbasiertes Modell aufnehmen. Sie können Datenabrufe konfigurieren, indem Sie Endpunkte, Authentifizierung, Paginierungsstrategien und Statusverwaltung direkt in der Konsole definieren.

Hauptvorteile

  • Integration beschleunigen: Neue Telemetriequellen lassen sich über einen geführten Assistenten in wenigen Minuten einbinden, ohne dass Sie auf Backend-Updates warten müssen.
  • Statusbezogene Prüfpunkte: Sorgen Sie dafür, dass es über alle Abrufzyklen hinweg keine doppelten Daten und keine fehlenden Logs gibt.
  • Fan-out für Eltern und Kinder:Unterstützt zweistufige Ermittlungsworkflows, z. B. das Auflisten von Ressourcen und das Abrufen der zugehörigen Telemetrie.
  • Automatisierte Ausfallsicherheit und Ratenbegrenzung: Verhindert die Drosselung von Anbietern und die Erschöpfung von Kontingenten. Für eine zuverlässige, unterbrechungsfreie Aufnahme werden HTTP 429-Antworten im benutzerdefinierten API-Feed automatisch mit einem exponentiellen Backoff verarbeitet. Anfragen werden mit konfigurierbarer Ratenbegrenzung und Staffelung der Aufgabenverzögerung gesteuert und es werden Sicherheitsvorkehrungen getroffen. Weitere Informationen finden Sie unter Guardrails für Ratenbegrenzung und Drosselung.

Vorbereitung

Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind, bevor Sie einen benutzerdefinierten API-Feed erstellen:

  • Berechtigungen:Zum Erstellen oder Ändern von Feeds benötigen Sie die Rolle „Chronicle API Admin“ (roles/chronicle.admin) oder „Chronicle API Editor“ (roles/chronicle.editor).
  • Anforderungen an Drittanbieter-APIs:
    • Eine gültige API-Basis-URL (muss https:// verwenden).
    • API-Anmeldedaten (API-Schlüssel, Basisauthentifizierungsanmeldedaten oder OAuth 2.0-Client-ID/geheimer Clientschlüssel)
    • Vendor API-Dokumentation mit Details zu Endpunktpfaden, Anfrageparametern, JSON-Antwortstrukturen und Ratenbeschränkungen.
  • Secret Manager-Zugriff:Anmeldedaten werden verschlüsselt und sicher in Secret Manager verwaltet. Die Dienstidentität, die den Connector ausführt, interagiert automatisch mit Secret Manager (roles/secretmanager.secretAccessor und roles/secretmanager.admin).

Benutzerdefinierten API-Feed konfigurieren

So konfigurieren Sie einen benutzerdefinierten API-Feed:

  1. Rufen Sie die SIEM-Einstellungen > Feeds auf.
  2. Klicken Sie auf Neuen Feed hinzufügen.
  3. Klicken Sie auf Einzelnen Feed konfigurieren.
  4. Geben Sie im Feld Feedname einen eindeutigen aussagekräftigen Namen ein, z. B. 1Password-Audit-Events.
  5. Wählen Sie in der Liste Quelltyp die Option Benutzerdefinierte API aus.
  6. Wählen Sie in der Liste Logtyp den Ziel-Google SecOps-Logtyp aus.
  7. Klicken Sie auf Weiter.

  8. Konfigurieren Sie unter Allgemeine Einstellungen Folgendes:

    • Basis-URL:Geben Sie den primären Host ein, z. B. https://events.1password.com. Er muss mit https:// beginnen. Hängen Sie keine Unterpfade oder abschließenden Schrägstriche an.

    • Abfragehäufigkeit:Geben Sie an, wie oft die Plattform die API nach neuer Telemetrie abfragt (in Minuten). Unterstützter Bereich: 5 bis 2.880 Minuten (Standard: 15 Minuten). Bei Standard-APIs (sequenziell) sind 10 bis 15 Minuten üblich. Bei Listen- und Detail-Feeds (über- und untergeordnet) werden 30 bis 60 Minuten empfohlen, damit alle Fan-Out-Aufgaben ohne Überschneidungen ausgeführt werden können.

  9. Wählen Sie unter Authentifizierung eine der unterstützten Authentifizierungsmethoden aus und konfigurieren Sie die erforderlichen Felder:

    • Basisauthentifizierung:Geben Sie den Nutzernamen (Identität des API-Kontos) und den Schlüssel (das geheime Passwort oder Token) ein.
    • OAuth 2.0-Clientanmeldedaten:Authentifizieren Sie sich mit dem OAuth 2.0-Grant-Typ „Clientanmeldedaten“. Google SecOps fordert automatisch Bearer-Zugriffstokens an, speichert sie im Cache und aktualisiert sie vor jedem Erfassungszyklus. Geben Sie den OAuth-Token-Endpunkt (z. B. https://auth.vendor.com/oauth/token), die OAuth-Client-ID und das OAuth-Client-Secret ein.
    • API-Schlüssel-Anfrageheader:Authentifizierung mit benutzerdefinierten API-Schlüsseln, die in Anfrageheader eingefügt werden (das gängigste REST-Muster für Unternehmen). Geben Sie den Namen des Headers ein, z. B. Authorization oder X-API-Key, und den Headerwert, z. B. Bearer <SECRET_TOKEN> oder <SECRET_KEY>.
    • API-Schlüssel-Suchparameter:Authentifizierung mit benutzerdefinierten API-Schlüsseln, die in URL-Suchparameter eingefügt werden. Geben Sie den Namen des Abfrageparameters ein, z. B. api_key, und den Wert des Abfrageparameters, z. B. <SECRET_KEY>.

  10. Wählen Sie das Connectormodell aus, das von Ihrer benutzerdefinierten API verwendet wird:

    • Standard-API (sequenziell): Ein linearer Abfrageablauf, bei dem jede Abfrage direkt auf dem Status der vorherigen Abfrage aufbaut. Bei diesem Modell wird beim nächsten Abruf ein Cursor, ein Token oder ein Zeitstempel verwendet, der aus dem vorherigen Abruf extrahiert wurde, um nur neue Daten abzurufen. Wählen Sie diese Karte aus, wenn der Anbieter einen Endpunkt bereitstellt, der Telemetrie-Ereignisdatensätze direkt zurückgibt (z. B. 1Password, Okta, SentinelOne, GitHub oder Slack).
    • Liste und Details (über-/untergeordnet): Ein zweistufiger Ablauf. Der Feed führt einen ersten Aufruf (übergeordnet) aus, um eine Liste von Ressourcen oder Objekten abzurufen, z. B. eine Liste von Nutzer-IDs oder Zonen. Aus dem Feed werden dann automatisch abhängige Folgeaufrufe (untergeordnete Elemente) generiert, um detaillierte Telemetriedaten für jede einzelne identifizierte Ressource abzurufen. Wählen Sie diese Karte aus, wenn für die Anbieter-API ein zweistufiges Ermittlungsmuster erforderlich ist: Zuerst wird ein Endpunkt aufgerufen, um eine dynamische Liste von Einheiten (z. B. Zonen, Konten, Projekte, Geräte) abzurufen, und dann werden Detailanfragen pro Einheit ausgeführt, um Telemetriedaten abzurufen (z. B. Cloudflare, AWS CloudWatch oder Tenable).

  11. Wenn Sie Standard-API (sequenziell) ausgewählt haben, gehen Sie so vor:

    1. Konfigurieren Sie unter API-Endpunkt die folgenden Parameter, um die technische Route und die Ratenabstimmung für die Anfrage zu definieren:
      • Endpunktpfad:Die spezifische API-Route, die an die Basis-URL angehängt wird (z. B. /api/v1/auditevents). Dadurch wird die genaue Telemetrieressource definiert, die abgefragt werden soll.
      • HTTP-Methode:Wählen Sie GET aus, um Daten mithilfe von URL-Suchparametern abzurufen, oder POST, um eine Suchnutzlast oder einen Filterkörper zu senden.
    2. Anfragetext:Geben Sie für POST-Anfragen die JSON-Daten-Nutzlast an. Sie können dynamische Prüfpunktvariablen wie {"limit": 100, "start_time": "{{.last_timestamp}}"} einbetten.
    3. Maximale Anfragen pro Minute:Geben Sie die maximale Anzahl der Anfragen ein, die pro Minute gesendet werden sollen. Dies ist eine clientseitige Ratenbegrenzung, um die API-Ratenbegrenzungen des Anbieters einzuhalten (Standard: 5 RPM = 1 Anfrage alle 12 Sekunden). Diese Einstellung verhindert, dass das Kontingent bei der mehrseitigen Paginierung erschöpft wird.
    4. Optional: Konfigurieren Sie unter Benutzerdefinierte Header den Header-Namen und den Wert und klicken Sie dann auf Hinzufügen, um spezielle HTTP-Header zu definieren, die von der Ziel-API benötigt werden (z. B. Content-Type: application/json, Accept: application/json).
    5. Optional: Konfigurieren Sie unter Abfrageparameter den Schlüssel und den Wert und klicken Sie dann auf Hinzufügen, um zusätzliche Filter oder Optionen anzugeben, die an den URL-Suchstring angehängt werden (z. B. count=1000, status=active), oder um dynamische Vorlagenvariablen zu binden (z. B. start={{.last_run_time}}).
    6. Wählen Sie unter Paginierungsstrategie den Paginierungsmechanismus aus, der für die Verarbeitung von mehrseitigen Ergebnismengen durch die Drittanbieter-API erforderlich ist, und konfigurieren Sie dann die erforderlichen Felder:
      • Keine:Daten in einer einzelnen Anfrage ohne Paging abrufen.
      • Token-Paginierung:Verwenden Sie Tokens (benutzerdefinierte Schlüssel), um die nächste Seite abzurufen. Geben Sie den JSON-Pfad für das Token für die nächste Seite (z. B. meta.next_cursor) und den Namen des Abfrageparameters für die Token-Paginierung (z. B. cursor) ein.
      • Link-Paginierung:Folgen Sie den in der Antwort angegebenen URLs, um weitere Daten zu erhalten. Geben Sie den JSON-Pfad für den Link zur nächsten Seite ein, z. B. links.next oder @odata.nextLink.
      • Offset-Paginierung:Überspringen Sie eine bestimmte Anzahl von Datensätzen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein, z. B. offset.
      • Seitenzahlnummerierung:Gehen Sie zur nächsten fortlaufenden Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitenzahl ein, z. B. page.

    7. Konfigurieren Sie unter Checkpointing die Einstellungen, mit denen sich der Connector zwischen wiederkehrenden Abfragezyklen merken kann, wo er aufgehört hat:

      • Strategie:Wählen Sie eine der folgenden Strategien aus und konfigurieren Sie die erforderlichen Felder:
        • Keine:Alle verfügbaren Daten abrufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
        • Letzter Zeitstempel:Der Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert ein (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Umfragen als {{.last_run_time}} verwiesen wird).
        • Letzter Datensatz:Verfolgen Sie die höchste Datensatz-ID, um nur neue Datensätze abzurufen. Geben Sie den JSON-Pfad des Prüfpunkts ein (z. B. id oder event_id) und die Prüfpunktvariable (z. B. last_id, auf die als {{.last_id}} verwiesen wird).
        • Iterator-Token:Verwenden Sie persistente Fortsetzungstokens, die von der API bereitgestellt werden. Geben Sie den JSON-Pfad für den Prüfpunktwert und die Prüfpunktvariable ein (z. B. iterator_token, auf die als {{.iterator_token}} verwiesen wird).

    8. Geben Sie unter Antwortzuordnung Regeln an, die der Plattform mitteilen, wie Logs gefunden und extrahiert werden sollen:

      • JSON-Pfad für Zieldaten:Geben Sie den genauen Pfad in der API-Antwortnutzlast ein, in dem sich die Liste der Ziel-Logeinträge befindet. Geben Sie für in Objekte eingeschlossene Arrays (z. B. {"items": [...]}) items ein. Lassen Sie dieses Feld vollständig leer ([]), wenn APIs ein JSON-Root-Array direkt zurückgeben (z. B. [{...}, {...}]).

  12. Wenn Sie Liste und Details (über-/untergeordnet) ausgewählt haben, gehen Sie so vor:

    1. Übergeordnete Anfrage (Discovery): Konfigurieren Sie den Endpunkt, der eine Liste von Elementen zurückgibt:
      1. Konfigurieren Sie unter API-Endpunkt die folgenden Parameter, um die technische Route und die Ratenabstimmung für die Anfrage zu definieren:
        • Endpunktpfad:Die spezifische API-Route, die an die Basis-URL angehängt wird (z. B. /api/v1/auditevents). Damit wird die genaue Telemetrieressource definiert, die abgefragt werden soll.
        • HTTP-Methode:Wählen Sie GET aus, um Daten mithilfe von URL-Suchparametern abzurufen, oder POST, um eine Suchnutzlast oder einen Filterkörper zu senden.
        • Anfragetext:Geben Sie für POST-Anfragen die JSON-Daten-Nutzlast an. Sie können dynamische Prüfpunktvariablen wie {"limit": 100, "start_time": "{{.last_timestamp}}"} einbetten.
      2. Maximale Anfragen pro Minute:Geben Sie die maximale Anzahl der Anfragen ein, die pro Minute gesendet werden sollen. Dies ist eine clientseitige Ratenbegrenzung, um die API-Ratenbegrenzungen des Anbieters einzuhalten (Standard: 5 RPM = 1 Anfrage alle 12 Sekunden). Diese Einstellung verhindert, dass das Kontingent bei der mehrseitigen Paginierung erschöpft wird.
      3. Optional: Konfigurieren Sie unter Benutzerdefinierte Header den Header-Namen und den Wert und klicken Sie dann auf Hinzufügen, um spezielle HTTP-Header zu definieren, die von der Ziel-API benötigt werden (z. B. Content-Type: application/json, Accept: application/json).
      4. Optional: Konfigurieren Sie unter Abfrageparameter den Schlüssel und den Wert und klicken Sie dann auf Hinzufügen, um zusätzliche Filter oder Optionen anzugeben, die an den URL-Suchstring angehängt werden (z. B. count=1000, status=active), oder um dynamische Vorlagenvariablen zu binden (z. B. start={{.last_run_time}}).
      5. Wählen Sie unter Paginierungsstrategie den Paginierungsmechanismus aus, der für die Verarbeitung von mehrseitigen Ergebnismengen durch die Drittanbieter-API erforderlich ist, und konfigurieren Sie dann die erforderlichen Felder:
        • Keine:Daten in einer einzelnen Anfrage ohne Paging abrufen.
        • Token-Paginierung:Verwenden Sie Tokens (benutzerdefinierte Schlüssel), um die nächste Seite abzurufen. Geben Sie den JSON-Pfad für das Token für die nächste Seite (z. B. meta.next_cursor) und den Namen des Abfrageparameters für die Token-Paginierung (z. B. cursor) ein.
        • Link-Paginierung:Folgen Sie den in der Antwort angegebenen URLs, um weitere Daten zu erhalten. Geben Sie den JSON-Pfad für den Link zur nächsten Seite ein, z. B. links.next oder @odata.nextLink.
        • Offset-Paginierung:Überspringen Sie eine bestimmte Anzahl von Datensätzen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein, z. B. offset.
        • Seitenzahlnummerierung:Gehen Sie zur nächsten fortlaufenden Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitenzahl ein, z. B. page.
      6. Konfigurieren Sie unter Checkpointing die Einstellungen, mit denen sich der Connector zwischen wiederkehrenden Abfragezyklen merken kann, wo er aufgehört hat:
        • Strategie:Wählen Sie eine der folgenden Strategien aus und konfigurieren Sie die erforderlichen Felder:
          • Keine:Alle verfügbaren Daten abrufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
          • Letzter Zeitstempel:Der Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert ein (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Umfragen als {{.last_run_time}} verwiesen wird).
          • Letzter Datensatz:Verfolgen Sie die höchste Datensatz-ID, um nur neue Datensätze abzurufen. Geben Sie den JSON-Pfad des Prüfpunkts ein (z. B. id oder event_id) und die Prüfpunktvariable (z. B. last_id, auf die als {{.last_id}} verwiesen wird).
          • Iterator-Token:Verwenden Sie persistente Fortsetzungstokens, die von der API bereitgestellt werden. Geben Sie den JSON-Pfad für den Prüfpunktwert und die Prüfpunktvariable ein (z. B. iterator_token, auf die als {{.iterator_token}} verwiesen wird).
    2. Datenextraktion (die Brücke): Konfigurieren Sie Folgendes:
      • JSON-Pfad für Artikel-ID:Das spezifische Feld in der übergeordneten Antwort, das eine einzelne Entität eindeutig identifiziert (z. B. id oder zone_id). Der Connector extrahiert diese ID aus jedem Element im übergeordneten Array.
      • Name der Vorlagenvariablen:Geben Sie einen benutzerdefinierten Variablennamen für die extrahierte ID an, z. B. zone_id. In der Benutzeroberfläche wird ein dynamisches Symbol angezeigt: Verwenden Sie {{.zone_id}} in der untergeordneten Anfrage unten.
    3. Untergeordnete Anfrage (Detail): Konfigurieren Sie den Endpunkt, der detaillierte Logs für jedes Element zurückgibt:
      1. Konfigurieren Sie unter API-Endpunkt die folgenden Parameter, um die technische Route und die Ratenabstimmung für die Anfrage zu definieren:
        • Endpunktpfad:Die spezifische API-Route, die an die Basis-URL angehängt wird (z. B. /client/v4/zones/{{.zone_id}}/logs/received). Damit wird die genaue Telemetrieressource definiert, die abgefragt werden soll.
        • HTTP-Methode:Wählen Sie GET aus, um Daten mithilfe von URL-Suchparametern abzurufen, oder POST, um eine Suchnutzlast oder einen Filterkörper zu senden.
        • Anfragetext:Geben Sie für POST-Anfragen die JSON-Daten-Nutzlast an. Sie können dynamische Prüfpunktvariablen wie {"limit": 100, "start_time": "{{.last_timestamp}}"} einbetten.
      2. Maximale Anfragen pro Minute:Geben Sie die maximale Anzahl der Anfragen ein, die pro Minute gesendet werden sollen. Dies ist eine clientseitige Ratenbegrenzung, um die API-Ratenbegrenzungen des Anbieters einzuhalten (Standard: 5 RPM = 1 Anfrage alle 12 Sekunden). Diese Einstellung verhindert, dass das Kontingent bei der mehrseitigen Paginierung erschöpft wird.
      3. Optional: Konfigurieren Sie unter Benutzerdefinierte Header den Header-Namen und den Wert und klicken Sie dann auf Hinzufügen, um spezielle HTTP-Header zu definieren, die von der Ziel-API benötigt werden (z. B. Content-Type: application/json, Accept: application/json).
      4. Optional: Konfigurieren Sie unter Abfrageparameter den Schlüssel und den Wert und klicken Sie dann auf Hinzufügen, um zusätzliche Filter oder Optionen anzugeben, die an den URL-Suchstring angehängt werden (z. B. count=1000, status=active), oder um dynamische Vorlagenvariablen zu binden (z. B. start={{.last_run_time}}).
      5. Wählen Sie unter Paginierungsstrategie den Paginierungsmechanismus aus, der für die Verarbeitung von mehrseitigen Ergebnismengen durch die Drittanbieter-API erforderlich ist, und konfigurieren Sie dann die erforderlichen Felder:
        • Keine:Daten in einer einzelnen Anfrage ohne Paging abrufen.
        • Token-Paginierung:Verwenden Sie Tokens (benutzerdefinierte Schlüssel), um die nächste Seite abzurufen. Geben Sie den JSON-Pfad für das Token für die nächste Seite (z. B. meta.next_cursor) und den Namen des Abfrageparameters für die Token-Paginierung (z. B. cursor) ein.
        • Link-Paginierung:Folgen Sie den in der Antwort angegebenen URLs, um weitere Daten zu erhalten. Geben Sie den JSON-Pfad für den Link zur nächsten Seite ein, z. B. links.next oder @odata.nextLink.
        • Offset-Paginierung:Überspringen Sie eine bestimmte Anzahl von Datensätzen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein, z. B. offset.
        • Seitenzahlnummerierung:Gehen Sie zur nächsten fortlaufenden Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitenzahl ein, z. B. page.
      6. Konfigurieren Sie unter Checkpointing die Einstellungen, mit denen sich der Connector zwischen wiederkehrenden Abfragezyklen merken kann, wo er aufgehört hat:
        • Strategie:Wählen Sie eine der folgenden Strategien aus und konfigurieren Sie die erforderlichen Felder:
          • Keine:Alle verfügbaren Daten abrufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
          • Letzter Zeitstempel:Der Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert ein (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Umfragen als {{.last_run_time}} verwiesen wird).

  13. Konfigurieren Sie die folgenden Einstellungen unter Planung und Labels:

    • Abfragehäufigkeit:Wählen Sie ein Standardintervall aus, z. B. 5m oder 1h.
    • Namespace:Optionales Organisations-Tag.
    • Aufnahme-Labels:Schlüssel/Wert-Paare für die rollenbasierte Zugriffssteuerung für Daten.

  14. Klicken Sie auf Senden. Google SecOps führt eine automatische Überprüfung der Anmeldedaten und Endpunkte durch. Wenn die Validierung erfolgreich ist, beginnt das Polling des Feeds.

Beispielkonfiguration 1: 1Password-Audit-Ereignisse (Standard-API-Modell (sequenziell))

Die folgende deklarative JSON-Konfiguration veranschaulicht ein Standard API (Sequential)-Modell mit cursorbasiertem Checkpointing für 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

Konkrete Beispielkonfiguration 2: Cloudflare-Zonen-Telemetrie (Listen- und Detailmodell (über- und untergeordnet))

Die folgende deklarative JSON-Konfiguration zeigt ein List & Detail (Parent-Child)-Fan-Out-Modell für Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

Best Practices für benutzerdefinierte APIs

  • Empfehlungen zur Abfragehäufigkeit:
    • Mit moderaten Abfrageintervallen beginnen: Legen Sie das anfängliche Abfrageintervall für Endpunkte mit hohem Volumen auf 15 oder 30 Minuten fest, um das Verhalten des API-Kontingents des Anbieters zu beobachten, bevor Sie es auf 5 Minuten senken.
    • Für hohes Fan-out-Volumen optimieren: Wenn in Parent-Child (List & Detail)-Feeds Dutzende oder Hunderte von Ressourcen erkannt werden, empfiehlt Google dringend, die Polling frequency auf 30 bis 60 Minuten festzulegen, damit alle Child-Aufgaben mit Pacing abgeschlossen werden können, bevor der nächste Erkennungszyklus beginnt.
  • Aufnahmepfade validieren: Verwenden Sie die Anbieterdokumentation oder API-Testtools, um den genauen JSON-Feldnamen für Zeitstempel zu bestätigen, bevor Sie die Statusprüfung konfigurieren.
  • Multi-Child-APIs aufschlüsseln: Wenn für eine Drittanbieter-API das Abrufen von Benachrichtigungen und Audit-Logs für eine einzelne Nutzerliste erforderlich ist, erstellen Sie zwei separate Single-Child-Feeds (einen für Benachrichtigungen und einen für Audit-Logs), um eine optimale Isolation zu gewährleisten.

Schutzmaßnahmen für Ratenbegrenzung und Drosselung

Damit Kundenfeedkonfigurationen nicht die Kontingente von Drittanbietern überlasten oder Systemressourcen monopolisieren, werden für den Feedtyp „Benutzerdefinierte API“ die folgenden automatischen Schutzmaßnahmen implementiert:

  • Konfigurierbare Anfrageratenbegrenzung: Ausgehende HTTP-Anfragen werden automatisch so gesteuert, dass die Ratenbegrenzungen des Anbieters nicht überschritten werden. Die standardmäßige Pacing-Rate beträgt 5 Anfragen pro Minute (1 Anfrage alle 12 Sekunden). Sie können diesen Wert für jeden Endpunkt über das Feld Maximale Anzahl von Anfragen pro Minute in den Endpunkteinstellungen an die veröffentlichten API-Kontingente Ihres Anbieters anpassen.
  • Obergrenze für untergeordnete Anfragen:Bei Parent-Child (List & Detail)-Feeds können pro Abrufzyklus bis zu 500 untergeordnete Anfragen gesendet werden.
  • Fan-out-Tiefe auf einer Ebene:Der Connector erzwingt eine maximale Fan-out-Tiefe von einer Ebene (übergeordnetes Element ermitteln → untergeordnete Details). Verschachtelte abhängige Anfragen (Enkelaufrufe) werden nicht unterstützt.
  • Obergrenze für die Größe der Antwortnutzlast:Die maximal zulässige HTTP-Antwortgröße für eine einzelne Anfrage oder Seite beträgt 50 MB. Wenn eine nicht paginierte API eine Antwort zurückgibt, die 50 MB überschreitet, schlägt der Abruf mit einem Fehler vom Typ „resource exhausted“ fehl. Um dies zu verhindern, konfigurieren Sie immer Paginierungsabfrageparameter (z. B. limit oder page_size), um Datensätze in kleineren Batches abzurufen.
  • Automatischer HTTP 429-Backoff:Wenn eine API eines Drittanbieters mit HTTP 429 (Zu viele Anfragen) antwortet, erfasst Google SecOps automatisch den Status und leitet einen exponentiellen Backoff-Zeitraum ein. Die Ausführung von Aufgaben wird pausiert, bis das Kontingent des Anbieters wieder aufgefüllt ist.

Einschränkungen für benutzerdefinierte APIs

Beachten Sie bei der Planung Ihrer Aufnahmepfade, dass der Feedtyp „Benutzerdefinierte API“ die folgenden Einschränkungen hat:

  • Strikte JSON-Unterstützung:Es werden nur JSON API-Antworten unterstützt. Andere Formate wie XML, CSV, Parquet und Avro werden nicht unterstützt.
  • Keine dynamische Anforderungssignierung:APIs, für die dynamische kryptografische Signaturen pro Anfrage erforderlich sind, werden nicht unterstützt (z. B. AWS SigV4, Akamai oder Oracle OCI).
  • Keine mehrstufige Authentifizierung:APIs, für die ein anfänglicher programmatischer Anmeldeaufruf erforderlich ist, um Anmeldedaten gegen ein temporäres Sitzungstoken einzutauschen (z. B. Saviynt), bevor Daten abgerufen werden, werden nicht unterstützt.
  • Keine WebSockets oder Push-Aufnahme:Benutzerdefinierte API-Feeds unterstützen das standardmäßige HTTPS-Pull-Polling. Persistente Streamingverbindungen (WebSockets) und eingehende Webhooks werden nicht unterstützt.
  • Kein gegenseitiges TLS (mTLS): Die Authentifizierung muss auf API-Schlüsseln, der Basisauthentifizierung oder Standardanmeldedaten des OAuth 2.0-Clients basieren. Clientseitige Zertifikats-Handshakes werden nicht unterstützt.

Fehlerbehebung bei benutzerdefinierten API-Feeds

Verwenden Sie die folgenden Abfragen, um Fehler für benutzerdefinierte API-Feeds im Cloud Logging Logs Explorer zu untersuchen:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

Ersetzen Sie FEED_ID durch Ihre Feed-ID.

Wenn Sie speziell nach fehlgeschlagenen HTTP-Anfragen filtern möchten, verwenden Sie die folgende Abfrage:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

Ersetzen Sie FEED_ID durch Ihre Feed-ID.

Häufige Fehlerarten und Lösungen

Symptom / Fehler Ursache Lösung / Abhilfe
HTTP 401 Unauthorized / HTTP 403 Forbidden Abgelaufener oder ungültiger API-Schlüssel, abgelaufenes oder ungültiges Passwort oder abgelaufene oder ungültige OAuth-Anmeldedaten. Bearbeiten Sie den Feed, geben Sie gültige Anmeldedaten noch einmal ein und klicken Sie auf Senden.
HTTP 404 Nicht gefunden Falsche Basis-URL oder Endpunktpfadvorlage. Endpunkt in der API-Dokumentation des Anbieters prüfen. Die Basis-URL muss korrekt enden und der Endpunktpfad mit „/“ beginnen.
HTTP 429 „Too Many Requests“ Die Ratenbegrenzungen der Anbieter-API wurden überschritten. Erhöhen Sie die Polling-Häufigkeit oder verringern Sie den Parameter limit in den Abfrageparametern.
JSON-Extraktionsfehler (items_path leer) Der Pfad der Antwortkonfiguration stimmt nicht überein. Prüfen Sie die Struktur der API-Antwortnutzlast und aktualisieren Sie den JSON-Pfad der Zieldaten.
Doppelte Datenaufnahme Ungültiger Zeitstempel für die Statuskonfiguration oder ungültiger Pfad für den ID-Extractor. Prüfen Sie den Feldnamen des Logdatensatzes für den Zeitstempel und aktualisieren Sie den Extraktorpfad.

Feeds verwalten

Nachdem Sie Ihre Datenfeeds konfiguriert haben, können Sie mit den Verwaltungstools den Status der Aufnahme überwachen, vorhandene Parameter ändern und den Feed-Lebenszyklus verwalten. In diesem Abschnitt wird beschrieben, wie Sie Feedstatus interpretieren und wichtige Wartungsaufgaben ausführen, um die kontinuierliche Datensichtbarkeit zu gewährleisten.

Auf der Seite Feeds finden Sie verschiedene Tools, mit denen Sie Ihre Liste der konfigurierten Feeds verwalten und organisieren können:

  • Suchen: Über die Suchleiste können Sie nach einem Feed anhand des Feednamens, der Feed-ID oder des Quelltyps suchen.

  • Filtern: Klicken Sie auf das Filtersymbol, um die Liste anhand bestimmter Feedattribute einzugrenzen.

  • CSV-Datei herunterladen: Klicken Sie auf Als CSV-Datei herunterladen, um die aktuelle Liste der Feeds in eine CSV-Datei zu exportieren.

  • Seitennummerierung: Mit den Steuerelementen für die Seitennummerierung können Sie:

    • Ändern Sie die Anzahl der Zeilen pro Seite.

    • Mit den Seitentabs und Pfeilen können Sie durch mehrere Seiten mit Feeds navigieren.

  • Letzte Aktualisierung: Hier sehen Sie den Zeitstempel der letzten Aktualisierung der Feedliste.

Konfigurierte Feeds ansehen

Auf der Seite Feeds werden alle von Ihnen konfigurierten Feeds angezeigt.

  1. Rufen Sie die SIEM-Einstellungen > Feeds auf. Auf der Hauptseite werden alle konfigurierten Feeds angezeigt.
  2. Bewegen Sie den Mauszeiger auf die einzelnen Zeilen, um das Menü  more_vert Mehr aufzurufen.
  3. Im Menü können Sie Feeddetails aufrufen, den Feed bearbeiten, deaktivieren oder löschen.

Feedstatus überwachen

Sie können den Status des Feeds auf der Seite Feeds im Blick behalten. Die Feeds können die folgenden Status haben:

  • Aktiv: Der Feed ist konfiguriert und bereit, Daten in Ihr Google SecOps-Konto aufzunehmen.
  • InProgress: Google SecOps versucht, Daten vom konfigurierten Drittanbieter abzurufen.
  • Abgeschlossen: Daten wurden erfolgreich über diesen Feed abgerufen.
  • Archiviert: Deaktivierter Feed.

  • Fehler: Beim Abrufen von Daten für den Feed ist ein Fehler aufgetreten. Wahrscheinlich liegt ein Konfigurationsproblem vor. Klicken Sie auf die Frage, um den Konfigurationsfehler aufzurufen. Nachdem Sie den Fehler behoben und den Feed noch einmal eingereicht haben, kehren Sie zur Seite Feeds zurück, um zu prüfen, ob der Feed jetzt funktioniert.

Vorhandene Feeds bearbeiten

Auf der Seite Feeds können Sie einen vorhandenen Feed bearbeiten:

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf das Dreipunkt-Menü  more_vert.

  2. Klicken Sie auf Feed bearbeiten. Sie können die Eingabeparameter für den Feed jetzt ändern und ihn noch einmal an Google SecOps senden. Google SecOps versucht dann, den aktualisierten Feed zu verwenden.

Feeds aktivieren (fortsetzen) und deaktivieren (pausieren)

Wenn Sie einen Feed deaktivieren, werden keine neuen Daten mehr aus dieser Quelle in Google SecOps aufgenommen. Wenn Sie die Datenaufnahme sofort beenden möchten, müssen Sie den Feed löschen. Bestehende aktive oder gedrosselte Übertragungen werden fortgesetzt, bis sie abgeschlossen sind. Wenn Sie den Feed wieder aktivieren, kann Google SecOps Daten abrufen, die während der Deaktivierung des Feeds nicht erfasst wurden. Diese Funktion wird als „Backfill-Fähigkeit“ bezeichnet.

In der Spalte Status sind aktivierte Feeds mit Aktiv, In Bearbeitung, Abgeschlossen oder Fehlgeschlagen gekennzeichnet. Deaktivierte Felder sind mit Archiviert gekennzeichnet. Eine Beschreibung finden Sie unter Feedstatus im Blick behalten.

Auf der Seite Feeds können Sie vorhandene Feeds aktivieren (fortsetzen) oder deaktivieren (pausieren):

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf das Dreipunkt-Menü  more_vert.

  2. Optional: Klicken Sie auf den Schalter Feed aktiviert, um den Feed zu aktivieren.

  3. Optional: Klicken Sie auf den Ein/Aus-Schalter Feed deaktivieren, um den Feed zu deaktivieren. Der Feed ist jetzt mit Archiviert gekennzeichnet.

Datenwiederherstellung beim Reaktivieren von Feeds (Backfill-Fähigkeit)

Ob Google SecOps Daten nachträglich einfügen kann, hängt davon ab, ob Ihr Feed pull-basiert (unterstützt) oder push-basiert (nicht unterstützt) ist.

Pull-basierte Feeds

Über diese Feeds ruft Google SecOps Daten aus externen Quellen ab. Zu den Pull-Feeds gehören:

  • Cloud Storage-Buckets wie Amazon S3, Google Cloud Storage und Azure Blob Storage
  • SFTP-Server

  • Drittanbieter-APIs wie Microsoft 365, Okta und Proofpoint

    Wenn Sie Pull-basierte Feeds wieder aktivieren, kann Google SecOps Daten abrufen, die generiert wurden, als der Feed deaktiviert war.

Push-basierte Feeds

Mit diesen Feeds werden Daten von externen Systemen an Google SecOps „übertragen“. Push-Feeds umfassen:

  • HTTPS-Webhooks
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • Direkte API-/Agent-Aufnahmen, z. B. Bindplane

Google SecOps kann den Backfill von Daten aus Push-basierten Feeds nicht automatisch starten. Wenn der Feed deaktiviert ist und Ihr System Daten überträgt, sendet Google SecOps entweder einen HTTP 403 Forbidden-Fehler oder einen generischen 4xx-Fehler.

Wenn Ihr System die Daten nicht speichert und den Sendevorgang an Google SecOps nicht wiederholt, gehen die Daten verloren. Wenn Ihr System außerdem so eingestellt ist, dass Daten bei einem Fehler verworfen oder der Puffer geleert wird, gehen die Daten für den entsprechenden Zeitraum dauerhaft verloren. Um Datenverlust zu vermeiden, sollten Sie Ihr System so konfigurieren, dass Daten gepuffert und noch einmal gesendet werden, sobald ein Feed wieder aktiviert wird. Google SecOps kann die fehlenden Daten dann aufnehmen, wenn der Feed fortgesetzt wird.

Überlegungen zum Backfill

  • Einschränkungen des Quellsystems:Die Menge an Verlaufsdaten, die Google SecOps aus Pull-basierten Feeds nachladen kann, wird dadurch begrenzt, wie lange das Quellsystem die Daten speichert und was seine API zulässt. Einige APIs bieten beispielsweise nur Zugriff auf Daten der letzten sieben Tage.
  • Google SecOps-Puffer:Für die automatische Wiederherstellung werden Daten für Pull-basierte Feeds im internen Puffer von Google SecOps bis zu 90 Tage lang gespeichert. Danach werden sie gelöscht.
  • Mandanteneinschränkungen:Bei nicht zahlenden Mandanten, z. B. bei Proof-of-Concept-Mandanten, kann es Einschränkungen beim Backfilling älterer Daten geben.
  • Aufnahmekontingente:Damit die Echtzeit-Datenaufnahme nicht beeinträchtigt wird, werden Backfill-Daten mit einer niedrigeren Priorität als Live-Daten verarbeitet. Der pullbasierte Daten-Backfill ist ebenfalls ratenbeschränkt, in der Regel auf ein Drittel (33%) des Burst-Limits Ihres Mandanten pro Protokolltyp. So wird sichergestellt, dass wichtige Push-basierte Feeds wie EDR-Agents nicht negativ beeinträchtigt werden.
  • Dynamische Ratenbegrenzung:Wenn beim Backfill das gesamte verfügbare Pull-Kontingent aufgebraucht wird, wird die Aufnahme für den Rest des Fünf-Minuten-Intervalls pausiert und automatisch fortgesetzt, wenn das Intervall neu beginnt.
  • Cloud-Speicher:Mit den Feedeinstellungen können Sie das Backfilling steuern, z. B. mit Filtern für neue oder aktualisierte Dateien oder mit Datumsbereichsfiltern wie „Maximales Dateialter“.
  • Große Backlogs:Wenn ein großer Backlog aus einem Pull-basierten Feed beim Reaktivieren Probleme verursacht, können Sie sich an den Google-Support wenden, um den Backlog zu löschen. Das bedeutet, dass im Feed nur noch neue Daten aufgenommen werden und die fehlenden Daten nicht nachgetragen werden.
  • Deaktivierte Feeds bearbeiten:Alle Konfigurationsänderungen, die an einem Feed vorgenommen werden, während er deaktiviert ist, werden angewendet, sobald der Feed wieder aktiviert wird.

Feeds löschen

Auf der Seite Feeds können Sie auch einen vorhandenen Feed löschen:

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf das Dreipunkt-Menü  more_vert.

  2. Klicken Sie auf Feed löschen. Das Fenster FEED LÖSCHEN wird geöffnet. Wenn Sie den Feed endgültig löschen möchten, klicken Sie auf Ja, löschen.

Bei benutzerdefinierten API-Feeds wird ein Dialogfeld mit einem optionalen Kästchen angezeigt: Ausstehende Backlog-Daten löschen:

  • Nicht aktiviert (Standard): Die Feedkonfiguration und die Anmeldedaten werden gelöscht, aber in der Warteschlange befindliche Backlog-Daten können bis zur Aufnahme verarbeitet werden.
  • Aktiviert:Die Feedkonfiguration, die Anmeldedaten und alle ausstehenden Backlog-Daten werden endgültig entfernt.

Aufnahmerate steuern

Wenn die Datenaufnahmerate für einen Mandanten einen bestimmten Schwellenwert erreicht, schränkt Google Security Operations die Aufnahmerate für neue Datenfeeds ein, um zu verhindern, dass sich eine Quelle mit einer hohen Aufnahmerate auf die Aufnahmerate einer anderen Datenquelle auswirkt. In diesem Fall kommt es zu einer Verzögerung, aber es gehen keine Daten verloren. Der Schwellenwert wird durch das Erfassungsvolumen und den Nutzungsverlauf des Mandanten bestimmt.

Sie können eine Erhöhung des Ratenlimits anfordern, indem Sie sich an Cloud Customer Care wenden.

Fehlerbehebung bei fehlgeschlagenen Feeds

Auf der Seite Feeds können Sie Details wie Quellentyp, Logtyp, Feed-ID und Status der vorhandenen Feeds aufrufen:

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf das Dreipunkt-Menü  more_vert.

  2. Klicken Sie auf Feed ansehen. Ein Dialogfeld mit den Feeddetails wird angezeigt. Bei einem fehlgeschlagenen Feed finden Sie Fehlerdetails unter Details > Status.

Bei einem fehlgeschlagenen Feed enthalten die Details die Ursache des Fehlers und Schritte zur Behebung.

In der Tabelle Quell- und Erfassungsfehler finden Sie Fehlermeldungen, die beim Arbeiten mit Datenfeeds auftreten können.

Für eine detaillierte Analyse und Fehlerbehebung von Feedaktivitäten können Sie Logs in Cloud Logging ansehen. Weitere Informationen finden Sie unter Feedaktivität mit Cloud Logging analysieren.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten