Mit der Feed-Benutzeroberfläche arbeiten

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Feeds in der Feedverwaltungsoberfläche erstellen, Fehler beheben und verwalten. 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)

Limits 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 Protokollzeile 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, in die Daten über die folgenden Connectors aufgenommen werden, 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, erfolgt die Aufnahme ohne Unterbrechung. Kunden müssen nichts weiter unternehmen.

Erwartungen während der Migration

Bei betroffenen Feeds werden Sie die folgenden Änderungen feststellen:

  • Feedstatus: Bei 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 an 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 Maximalen 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. Wählen Sie die Methode aus, die am besten zu Ihrer Umgebung passt:

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

Zulassungsliste für IP-Adressen einrichten

Wenn Google SecOps Daten aus S3, SQS, Azure und Drittanbieter-APIs abruft, stellt die Google-Infrastruktur eine ausgehende Verbindung zum Bucket des Kunden oder zur Drittanbieter-API her.

Wenn Sie eingehenden Traffic für Ihre Storage-Buckets oder Firewalls zulassen möchten, müssen Sie die Zulassungsliste entsprechend dem Feedtyp konfigurieren, wie in der folgenden Liste beschrieben:

Da sich die IP-Bereiche von Google-Diensten dynamisch ändern, empfiehlt Google, die Firewall so zu konfigurieren, dass die Feeds regelmäßig wie folgt abgerufen und geparst werden:

  • V2-Feeds (S3_V2, SQS_V2, Azure_Blobstore_V2): Die Datenübertragung wird ausschließlich von Storage Transfer Service-Workern ausgeführt. Sie müssen ipranges.json nur regelmäßig abrufen und parsen.
  • Legacy-Feeds (S3, SQS, Azure_Blobstore, Azure Event Hub) und Drittanbieter-APIs: Diese Verbindungen stammen aus der Google-Infrastruktur. Sie müssen goog.json und cloud.json nur regelmäßig abrufen und parsen.

Feeds konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Ihre Feeds allgemein konfigurieren, beginnend mit dem Standardverfahren. Die auf der Seite Feeds aufgeführten Datenfeeds enthalten 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 Feedquellentypen 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)
    • Ereignisgesteuert in Cloud Storage
    • Drittanbieter-API
    • Webhook

    Wichtig:

    • Wenn Sie Amazon S3- (eingestellt), Amazon SQS- (eingestellt), Azure Blob Storage- (eingestellt) und Google Cloud Cloud Storage-Feeds (eingestellt) verwenden, achten Sie darauf, dass Sie einen gültigen Verzeichnispfad haben.
    • 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 werden, 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 Logs variieren je nach dem zuvor ausgewählten Quelltyp.

    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 für jedes Feld, um weitere Informationen zu den erforderlichen Angaben zu erhalten.

  9. Optional: Sie können auf dem Tab Attribute festlegen einen Namespace 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: Mit Empfohlen gekennzeichnet. Diese Logtypen werden für die Kernfunktionen der Plattform empfohlen.
  • Zusätzliche Protokolltypen: Als optional gekennzeichnet. Diese Logtypen 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 unter den empfohlenen als auch unter den optionalen Logtypen erstellen, um eine ausreichende 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 mit dem URI verknüpft 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 alphanumerischer Secret-Zugriffsschlüssel mit 40 Zeichen für das Konto, z. B. wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. Optional: Konfigurieren Sie die folgenden Parameter:

    • Feedname: Vorausgefüllter eindeutiger Name für den Feed.
    • Asset-Namespace: Namespace, der mit dem Feed verknüpft ist.
    • Aufnahmelabels: 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 Feeds für andere verfügbare Logtypen auch direkt auf dieser Seite konfigurieren. Wenn Sie fertig sind, rufen Sie die Seite Feedverwaltung auf, um eine detaillierte Zusammenfassung aller konfigurierten Logtypen zu sehen.

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 OPTION ZUM LÖSCHEN DER QUELLE in den Workflows Neu hinzufügen und Feed bearbeiten.

Optionen zum Löschen von Quellen

  • Für unterstützte Feed-Quelltypen, 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 nie Dateien nach Übertragungen 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 mehreren Clouds (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 aus und klicken Sie dann auf Feeds.
  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 Cloud Storage v2 als Quelltyp 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. Siehe 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 von Quellen

    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 gewähren 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 die Leseberechtigung für mehrere Dateien 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 Storage-Bucket hinzu und weisen Sie ihm die IAM-Rolle Storage-Objekt-Betrachter (roles/storage.objectViewer) zu.
        2. Wenn Sie den Feed so konfigurieren, dass Quell-Dateien gelöscht werden, müssen Sie das Google SecOps-Dienstkonto als Hauptkonto für Ihren Bucket hinzufügen und ihm die IAM-Rolle Storage Object Admin (roles/storage.objectAdmin) zuweisen.

      • Gewähren Sie für "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2" die folgenden Rollen:

        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 von Legacy-Storage-Buckets zu. Wenn Sie Nie auswählen, weisen Sie die Rolle Storage Legacy Bucket Reader zu:

          • Autor von Legacy-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 von Legacy-Storage-Buckets (roles/storage.legacyBucketWriter), wenn die Berechtigung zum Löschen von Objekten erforderlich ist.
          • Leser von Legacy-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 von Amazon S3- und Azure Storage-Blobstores an 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 diese unterschiedlich sind, 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 Ihr AWS-Projekt IP-Einschränkungen für den Zugriff auf den Speicher verwendet, 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 IP-Adressen 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: Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.

Pub/Sub-Push-Feed einrichten

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

  1. Erstellen Sie einen Pub/Sub-Push-Feed.
  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 aus und klicken Sie dann auf Feeds.
  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 Logtyp 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.
    • Labels für Datenaufnahme: 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 dann 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 zur Authentifizierung bei Google SecOps wiederverwenden.
  3. Geben Sie die Endpunkt-URL in Amazon Data Firehose an.

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 Logtyp 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.
    • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.
  8. Klicken Sie auf Weiter.
  9. Prüfen Sie die neue Nachrichten-Feed-Konfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
  10. Klicken Sie auf Secret-Schlüssel generieren, um einen Secret-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, aber dadurch wird der vorherige geheime Schlüssel ungültig.
  12. Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld 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 Feed-Endpunkt-URL 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 wiederverwenden, um sich bei Google SecOps zu authentifizieren.
  3. Geben Sie die Endpunkt-URL in Ihrer Anwendung an.

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 Logtyp 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.
    • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.
  8. Klicken Sie auf Weiter.
  9. Prüfen Sie die neue Nachrichten-Feed-Konfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
  10. Klicken Sie auf Secret-Schlüssel generieren, um einen Secret-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, aber durch die Neugenerierung wird der vorherige geheime Schlüssel 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 für 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 Console definieren.

Hauptvorteile

  • Integration beschleunigen: Neue Telemetriequellen lassen sich in wenigen Minuten über einen geführten Assistenten einbinden, ohne dass Sie auf Backend-Updates warten müssen.
  • Zustandsorientierte Prüfpunkte: Sorgen Sie dafür, dass es bei Abfragezyklen keine Datenduplizierung 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 Ausschöpfung des Kontingents. Für eine zuverlässige, unterbrechungsfreie Aufnahme werden HTTP 429-Antworten im Custom API-Feed automatisch mit exponentiellem 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 die folgenden Voraussetzungen, 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, Basic Auth-Anmeldedaten oder OAuth 2.0-Client-ID/-Secret).
    • API-Dokumentation zur Vendor API mit Details zu Endpunktpfaden, Anfrageparametern, JSON-Antwortstrukturen und Ratenbegrenzungen.
  • Secret Manager-Zugriff: Anmeldedaten werden in Secret Manager verschlüsselt und sicher 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 Nachrichten-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 nachgestellten Schrägstriche an.

    • Abfragehäufigkeit:Geben Sie an, wie oft die Plattform die API nach neuen Telemetriedaten abfragen soll (in Minuten). Unterstützter Bereich: 5 bis 2.880 Minuten (Standard: 15 Minuten). Bei Standard-API-Feeds (sequenziell) sind 10–15 Minuten üblich. Bei Listen- und Detail-Feeds (übergeordnet/untergeordnet) werden 30–60 Minuten empfohlen, damit die Fan-Out-Aufgaben ohne Überschneidungen vollständig ausgeführt werden können.

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

    • Basisauthentifizierung: Geben Sie den Nutzernamen (API-Kontoidentität) und das Secret (das geheime Passwort oder Token) ein.
    • OAuth 2.0-Clientanmeldedaten:Authentifizieren Sie sich mit dem OAuth 2.0-Genehmigungstyp für Clientanmeldedaten. Google SecOps fordert vor jedem Erfassungszyklus automatisch Bearer-Zugriffstokens an, speichert sie im Cache und aktualisiert sie. 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üsselanfrageheader:Authentifizierung mit benutzerdefinierten API-Schlüsseln, die in Anfrageheader eingefügt werden (das gängigste REST-Muster für Unternehmen). Geben Sie den Headernamen (z. B. Authorization oder X-API-Key) und den Headerwert (z. B. Bearer <SECRET_TOKEN> oder <SECRET_KEY>) ein.
    • Suchparameter für API-Schlüssel:Authentifizierung mit benutzerdefinierten API-Schlüsseln, die in URL-Suchparameter eingefügt werden. Geben Sie den Namen des Suchparameters (z. B. api_key) und den Wert des Suchparameters (z. B. <SECRET_KEY>) ein.

  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 aufbaut. In diesem Modell wird beim nächsten Abruf ein Cursor, Token oder Zeitstempel aus dem vorherigen Abruf verwendet, um nur neue Daten abzurufen. Wählen Sie diese Karte aus, wenn der Anbieter einen Endpunkt bereitstellt, der Telemetrieereignis-Datensätze direkt zurückgibt (z. B. 1Password, Okta, SentinelOne, GitHub oder Slack).
    • Liste und Details (über-/untergeordnet): Ein zweistufiger Discovery-Ablauf. Mit dem Feed wird ein erster Aufruf (übergeordnet) ausgeführt, um eine Liste von Ressourcen oder Objekten abzurufen, z. B. eine Liste von Nutzer-IDs oder Zonen. Der Feed löst dann automatisch abhängige Folgeaufrufe (untergeordnete Aufrufe) aus, um detaillierte Telemetriedaten für jede identifizierte Ressource abzurufen. Wählen Sie diese Karte aus, wenn die Anbieter-API ein zweistufiges Erkennungsmuster erfordert: Zuerst wird ein Endpunkt aufgerufen, um eine dynamische Liste von Entitäten (z. B. Zonen, Konten, Projekte, Geräte) abzurufen, und dann werden für jede Entität Folgeanfragen 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 Ratenabstufung 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 Filter-Body zu senden.
    2. Anfragetext: Geben Sie für POST-Anfragen die JSON-Datennutzlast an. Sie können dynamische Prüfpunktvariablen wie {"limit": 100, "start_time": "{{.last_timestamp}}"} einbetten.
    3. Maximale Anzahl von Anfragen pro Minute:Geben Sie die maximale Anzahl von 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 Headernamen 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-Abfragestring 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 der nächsten 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 URLs in der Antwort, 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:Eine bestimmte Anzahl von Datensätzen wird übersprungen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein (z. B. offset).
      • Seitenzahlnummerierung:Gehen Sie zur nächsten sequenziellen Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitennummer 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:Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad des Prüfpunktwerts (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Abfragen als {{.last_run_time}} verwiesen wird) ein.
        • 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 des Prüfpunktwerts 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 der Zieldaten:Geben Sie den genauen Pfad in der Nutzlast der API-Antwort ein, in dem sich die Liste der Ziel-Logeinträge befindet. Geben Sie für in Objekte verpackte Arrays (z. B. {"items": [...]}) items ein. Lassen Sie dieses Feld für APIs, die direkt ein JSON-Root-Array zurückgeben (z. B. [{...}, {...}]), vollständig leer ([]).

  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 Weiterleitung und die Ratensteuerung 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 Filter-Body 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 Anzahl von Anfragen pro Minute:Geben Sie die maximale Anzahl von 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-Abfragestring 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 der nächsten 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 URLs in der Antwort, 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:Eine bestimmte Anzahl von Datensätzen wird übersprungen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein (z. B. offset).
        • Seitenzahlnummerierung:Gehen Sie zur nächsten sequenziellen Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitenzahl ein, z. B. page.
      6. Konfigurieren Sie unter Prüfpunkte die Einstellungen, mit denen sich der Connector merken kann, wo er zwischen wiederkehrenden Abfragezyklen 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:Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad des Prüfpunktwerts (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Abfragen als {{.last_run_time}} verwiesen wird) ein.
          • Neuester 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, referenziert als {{.iterator_token}}).
    2. Datenextraktion (die Brücke): Konfigurieren Sie Folgendes:
      • JSON-Pfad für die Element-ID:Das spezifische Feld in der übergeordneten Antwort, das eine einzelne Einheit 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 Badge 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 Ratenabstufung 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 Filter-Body zu senden.
        • Anfragetext: Geben Sie für POST-Anfragen die JSON-Datennutzlast an. Sie können dynamische Prüfpunktvariablen wie {"limit": 100, "start_time": "{{.last_timestamp}}"} einbetten.
      2. Maximale Anzahl von Anfragen pro Minute:Geben Sie die maximale Anzahl von 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 ausgeschö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-Abfragestring 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, den die Drittanbieter-API für die Verarbeitung mehrseitiger Ergebnismengen benötigt, 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 der nächsten 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 URLs in der Antwort, 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:Eine bestimmte Anzahl von Datensätzen wird übersprungen, um den nächsten Satz abzurufen. Geben Sie den Namen des Offset-Suchparameters ein (z. B. offset).
        • Seitenzahlnummerierung:Gehen Sie zur nächsten sequenziellen Seitenzahl. Geben Sie den Namen des Suchparameters für die Seitenzahl ein, z. B. page.
      6. Konfigurieren Sie unter Prüfpunkte die Einstellungen, mit denen sich der Connector merken kann, wo er zwischen wiederkehrenden Abfragezyklen 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:Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad des Prüfpunktwerts (z. B. timestamp oder event_time) und die Prüfpunktvariable (z. B. last_run_time, auf die in nachfolgenden Abfragen als {{.last_run_time}} verwiesen wird) ein.

  13. Konfigurieren Sie die folgenden Einstellungen für Planung und Labels:

    • Abfragehäufigkeit: Wählen Sie ein Standardintervall aus (z. B. 5m, 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 von Anmeldedaten und Endpunkten 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 zeigt ein Standard API (Sequenziell)-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 (über-/untergeordnetes Modell)

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

  • Hinweise zur Abfragehäufigkeit:
    • Mit moderaten Abrufintervallen beginnen: Legen Sie das anfängliche Abrufintervall für Endpunkte mit hohem Volumen auf 15 oder 30 Minuten fest, um das Verhalten der Anbieter-API-Kontingente zu beobachten, bevor Sie es auf 5 Minuten senken.
    • Für Fan-out mit hohem 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 sauber abgeschlossen werden können, bevor der nächste Erkennungszyklus beginnt.
  • Aufnahmepfade validieren: Verwenden Sie die Dokumentation des Anbieters oder API-Testtools, um den genauen JSON-Feldnamen für Zeitstempel zu bestätigen, bevor Sie die Statusprüfung konfigurieren.
  • APIs mit mehreren untergeordneten Elementen aufschlüsseln: Wenn für eine Drittanbieter-API Warnungen und Audit-Logs für eine einzelne Nutzerliste abgerufen werden müssen, erstellen Sie zwei separate Feeds mit einem untergeordneten Element (einen für Warnungen und einen für Audit-Logs), um eine optimale Isolation zu gewährleisten.

Schutzmaßnahmen für Ratenbegrenzung und Drosselung

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

  • Konfigurierbare Anfrage-Taktung (Ratenbegrenzung): Ausgehende HTTP-Anfragen werden automatisch getaktet, um zu verhindern, dass die Ratenbegrenzungen des Anbieters überschritten werden. Die Standard-Taktungsrate beträgt 5 Anfragen pro Minute (1 Anfrage alle 12 Sekunden). Sie können dies für jeden Endpunkt über das Feld Max. 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.
  • Einstufige Fan-Out-Tiefe:Der Connector erzwingt strikt eine maximale Fan-Out-Tiefe von 1 Ebene (übergeordnete Erkennung → untergeordnete Details). Verschachtelte abhängige Anfragen (Anfragen von Enkelknoten) 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 API ohne Paginierung eine Antwort mit mehr als 50 MB zurückgibt, schlägt der Abruf mit einem Fehler „Ressource erschöpft“ fehl. Um dies zu verhindern, sollten Sie immer Suchparameter für die Paginierung (z. B. limit oder page_size) konfigurieren, um Datensätze in kleineren Batches abzurufen.
  • Automatischer HTTP 429-Backoff¢™: Wenn eine API-Antwort eines Drittanbieters HTTP 429 (Zu viele Anfragen) zurückgibt, erfasst Google SecOps automatisch den Status und leitet einen exponentiellen Backoff-Zeitraum ein. Die Ausführung von Aufgaben wird pausiert, bis das Kontingentfenster des Anbieters wieder aufgefüllt ist.

Einschränkungen für benutzerdefinierte APIs

Beachten Sie bei der Planung Ihrer Aufnahmepfade die folgenden Einschränkungen für den Feedtyp „Benutzerdefinierte API“:

  • 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, die vor dem Abruf einen ersten programmatischen Anmeldeaufruf erfordern, um Anmeldedaten gegen ein temporäres Sitzungstoken auszutauschen (z. B. Saviynt), werden nicht unterstützt.
  • Keine WebSockets oder Push-Aufnahme: Benutzerdefinierte API-Feeds unterstützen standardmäßiges HTTPS-Pull-Polling. Nichtflüchtige Streamingverbindungen (WebSockets) und eingehende Webhooks werden nicht unterstützt.
  • Kein gegenseitiges TLS (mTLS): Die Authentifizierung muss auf API-Schlüsseln, der Basisauthentifizierung oder Standard-OAuth 2.0-Clientanmeldedaten basieren. Clientseitige Zertifikats-Handshakes werden nicht unterstützt.

Fehlerbehebung bei benutzerdefinierten API-Feeds

Verwenden Sie die folgenden Abfragen, um Fehler bei benutzerdefinierten API-Feeds im Cloud Logging-Log-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, ungültiges Passwort 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. Sehen Sie sich den Endpunkt in der API-Dokumentation des Anbieters an. 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 Abfragehäufigkeit oder verringern Sie den Parameter limit in den Suchparametern.
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 Protokolleintrags auf den Zeitstempel und aktualisieren Sie den Extraktionspfad.

Feeds verwalten

Nachdem Sie Ihre Datenfeeds konfiguriert haben, können Sie mit den Managementtools 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 eine kontinuierliche Datensichtbarkeit zu gewährleisten.

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

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

  • Filter: 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.

  • Paginierung: Mit den Paginierungssteuerelementen können Sie Folgendes tun:

    • Ändern Sie die Anzahl der Zeilen pro Seite.

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

  • Zeitpunkt der letzten Aktualisierung: Anhand des Zeitstempels können Sie sehen, wann die Feedliste zuletzt aktualisiert wurde.

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ü 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. 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: Die Daten wurden erfolgreich über diesen Feed abgerufen.
  • Archiviert: Deaktivierter Feed.

  • Fehlgeschlagen: Daten können nicht abgerufen werden. 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. Gehen Sie dazu so vor:

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf more_vert.

  2. Klicken Sie auf Feed bearbeiten. Sie können jetzt die Eingabeparameter für den Feed ä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, sollten 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 überwachen.

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  more_vert.

  2. Optional: Klicken Sie auf den Ein/Aus-Button Feed aktiviert, um den Feed zu aktivieren.

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

Datenwiederherstellung, wenn Sie Feeds wieder aktivieren (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-Speicher-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, während der Feed deaktiviert war.

Push-basierte Feeds

Über diese 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 Daten-Backfill aus Push-basierten Feeds nicht automatisch initiieren. Wenn der Feed deaktiviert ist und Ihr System Daten sendet, gibt Google SecOps entweder den Fehler HTTP 403 Forbidden oder einen allgemeinen 4xx-Fehler zurück.

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 bei einem Fehler Daten gelöscht oder der Puffer geleert wird, gehen die Daten für den entsprechenden Zeitraum dauerhaft verloren. Um Datenverluste zu vermeiden, sollten Sie Ihr System so konfigurieren, dass Daten zwischengespeichert und noch einmal gesendet werden, sobald ein Feed wieder aktiviert wird. Google SecOps kann die fehlenden Daten dann aufnehmen, wenn der Feed fortgesetzt wird.

Hinweise zum Backfill

  • Limits des Quellsystems: Die Menge an Verlaufsdaten, die Google SecOps aus pull-basierten Feeds rückwirkend ergänzen kann, ist durch die Aufbewahrungsdauer der Daten im Quellsystem und die API-Limits begrenzt. Einige APIs bieten beispielsweise nur Zugriff auf Daten der letzten sieben Tage.
  • Google SecOps-Puffer:Für die automatische Wiederherstellung werden Daten im internen Puffer von Google SecOps für Pull-basierte Feeds bis zu 90 Tage lang gespeichert. Danach werden sie gelöscht.
  • Mandanteneinschränkungen: Bei nicht zahlenden Mandanten, z. B. Proof of Concepts, kann es Einschränkungen beim Backfill älterer Daten geben.
  • Aufnahmekontingente: Damit die Echtzeit-Datenaufnahme nicht beeinträchtigt wird, werden Backfill-Daten mit einer niedrigeren Priorität als Live-Daten verarbeitet. Das Pull-basierte 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 beeinflusst werden.
  • Dynamische Ratenbegrenzung:Wenn durch den Backfill das gesamte verfügbare Pull-Kontingent verbraucht wird, wird die Aufnahme für den Rest des fünfminütigen Intervalls pausiert und automatisch fortgesetzt, wenn das Intervall neu beginnt.
  • Cloud Storage: Sie können die Feedeinstellungen verwenden, um den Backfill zu steuern, z. B. Filter für neue oder aktualisierte Dateien oder Datumsbereichsfilter 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 der Feed ab diesem Zeitpunkt nur neue Daten aufnimmt und die fehlenden Daten nicht nachträglich eingefügt 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 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.
  • Ausgewählt: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 eine Quelle mit einer hohen Aufnahmerate die Aufnahmerate einer anderen Datenquelle beeinträchtigt. In diesem Fall kommt es zu einer Verzögerung, aber es gehen keine Daten verloren. Der Schwellenwert wird durch das Aufnahmevolumen und den Nutzungsverlauf des Mandanten bestimmt.

Sie können eine Erhöhung der Ratenbegrenzung 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 ansehen:

  1. Bewegen Sie den Mauszeiger auf einen vorhandenen Feed und klicken Sie in der rechten Spalte auf  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 Aufnahmefehler 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 aufrufen. 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