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

Zu den unterstützten Komprimierungsformaten für die Feedaufnahme gehören .gz, .tar.gz, .tar und solr.gz. In der folgenden Tabelle sind die verschiedenen Dateigrößen aufgeführt, die von der Feedtransformation in Google SecOps 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 dekomprimieren Nicht-ZIP < 5 GB Variiert je nach Anzahl der Dateien 10 GB (unkomprimiert)
Dateien dekomprimieren Postleitzahl - Variiert je nach Anzahl der Dateien 4 GB (unkomprimiert)

Limits und Trennzeichen für Logzeilen

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

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

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

Wenn Sie das mit Ihrer Google SecOps-Instanz verknüpfte Google Cloud -Projekt aktualisieren, werden alle Feeds, die Daten über die 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 werden Sie die folgenden Änderungen feststellen:

  • Feedstatus: Feeds, die vor der Migration erstellt wurden, rufen sofort keine Live-Daten mehr ab und 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, erhalten Sie die folgende Meldung: 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 Kundenorganisationen

Damit die Datenaufnahme nicht unterbrochen wird, 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 Zeitpuffer sorgt für einen reibungslosen Übergang.

  3. Doppelte Daten verwalten: Je nach ausgewähltem 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 bleiben als verwaiste Einstellungen in der Google SecOps-Weboberfläche erhalten.

Möglichkeiten zum Einrichten von Feeds

Google SecOps-Kunden haben zwei Möglichkeiten, einen Feed auf 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)

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:

  • V2-Feeds (S3_V2, SQS_V2, Azure_Blobstore_V2): Diese Feeds verwenden ausschließlich den Google Cloud Storage Transfer Service (STS), um Daten aus dem Kundenspeicher abzurufen. Die STS-IP-Bereiche müssen auf die Zulassungsliste gesetzt werden: ipranges.json.
  • Drittanbieter-APIs: Erfordern goog.json.
  • Legacy-Feeds (S3, Azure_Blobstore): Erfordern dedizierte IP-Bereiche. Weitere Informationen erhalten Sie vom Google SecOps-Support.
  • Azure Event Hub: Erfordert regionsspezifische IP-Bereiche. Weitere Informationen finden Sie unter Netzwerksicherheit konfigurieren (optional) in Azure Event Hub-Feed erstellen.

Da sich die IP-Bereiche von Google-Diensten dynamisch ändern, empfiehlt Google, die Firewall so zu konfigurieren, dass die Feeds regelmäßig 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 APIs von Drittanbietern: Diese Verbindungen stammen aus der Google-Infrastruktur. Sie müssen nur regelmäßig goog.json und cloud.json 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 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 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 Feedquellentyp 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 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 Logtyp, die auf dem Tab Attribute festlegen ausgewählt wurden. 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 basierend auf dem Logtyp konfigurieren.

  • Baseline-Logtypen: Als empfohlen markiert. Diese Logtypen werden für die grundlegenden Plattformfunktionen empfohlen.
  • Ergänzende Protokolltypen: Als optional gekennzeichnet. Diese Logtypen bieten zusätzlichen Kontext.

Um die Einrichtung zu vereinfachen, bietet die Plattform spezifische Einrichtungsanleitungen und vordefinierte Parameter für jede Konfiguration. 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 Feed-Quellobjekte (Dateien und Ordner) nach einer erfolgreichen Übertragung aus dem Speicher löschen. Diese Option ist nur für ausgewählte Feedquellentypen verfügbar, einschließlich Cloud Storage. Diese Feedquellentypen enthalten das Feld SOURCE DELETION OPTION in den Workflows Neu hinzufügen und Feed bearbeiten.

Optionen zum Löschen von Quellen

  • Für unterstützte Feedquellentypen, einschließlich Cloud Storage, bietet das Feld SOURCE DELETION OPTION 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 OPTION ZUM LÖSCHEN DER QUELLE nur die Option 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 SOURCE DELETION OPTION zwei Optionen:

    • NIE: Dateien werden nach Übertragungen nie gelöscht.
    • ON_SUCCESS: Alle Dateien und leeren Verzeichnisse werden nach der Übertragung gelöscht.

Objekte in STS-Feeds nach Präfix filtern

Im Feld Präfixe einschließen (include_prefixes) werden Speicherobjekte, die vom Storage Transfer Service (STS) übertragen werden, vor der Aufnahme anhand von Objekt-Schlüsselpräfixen gefiltert. Werte, die Sie in diesem Feld angeben, werden direkt an STS ObjectConditions.include_prefixes übergeben.

Unterstützte STS-Feedquellentypen

Die präfixbasierte Filterung wird für die folgenden STS-Feed-Quelltypen (feedSourceType) unterstützt:

  • Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) und Cloud Storage Event Driven (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
  • Amazon S3 (V2) (AMAZON_S3_V2) und Amazon SQS (V2) (AMAZON_SQS_V2)
  • Azure Blob Storage (V2) (AZURE_BLOBSTORE_V2) und Azure Blob Storage Event Driven (AZURE_BLOBSTORE_EVENT_DRIVEN)

Präfixsyntax und Validierungsregeln

Beachten Sie beim Konfigurieren von Präfixe einschließen (include_prefixes) die folgenden Syntax- und Validierungsregeln:

  • Keine führenden Schrägstriche: Präfixe sind relativ zum Bucket- oder Containerstamm und dürfen nicht mit einem führenden Schrägstrich (/) beginnen. Geben Sie beispielsweise logs/audit/ anstelle von /logs/audit/ ein.
  • Nachgestellte Schrägstriche im Vergleich zu Teilübereinstimmungen: Nachgestellte Schrägstriche steuern, ob ein Präfix nur mit Objekten in einem bestimmten Ordner oder mit einem beliebigen Objektschlüssel übereinstimmt, der mit dem Präfix beginnt:
    • Mit abschließendem Schrägstrich: Ein Präfix, das mit / endet (z. B. logs/app/), beschränkt Übereinstimmungen strikt auf Objekte in diesem Ordner. Fügen Sie einen abschließenden Schrägstrich für die Bereichsdefinition auf Verzeichnisebene hinzu.
    • Ohne abschließenden Schrägstrich: Ein Präfix ohne abschließenden / (z. B. logs/app) stimmt mit jedem Objekt überein, das mit diesem String beginnt, einschließlich logs/app_old/ und logs/application/.
  • Groß-/Kleinschreibung: Bei Objektschlüsselpräfixen wird strikt zwischen Groß- und Kleinschreibung unterschieden.
  • Keine Platzhalter oder regulären Ausdrücke: Musterabgleich wird nicht unterstützt. Zeichen wie * und ? werden als Literalzeichen behandelt.
  • Keine leeren Werte: Einzelne Präfixeinträge dürfen nicht leer sein oder nur Leerzeichen enthalten. Wenn Sie den gesamten Bucket oder Container aufnehmen möchten, lassen Sie das Feld Präfixe einschließen leer.
  • Eindeutige, sich nicht überschneidende Namespaces: Ein Präfix darf kein Präfix eines anderen Präfixes in derselben Liste sein. Beispiel: ["logs/", "logs/audit/"] ist ungültig, während gleichgeordnete Präfixe wie ["logs/audit/", "logs/vpc/"] gültig sind.
  • Limits: Ein Feed unterstützt bis zu 1.000 Präfixe. Jedes Präfix kann bei UTF-8-Codierung eine maximale Länge von 1.024 Byte haben und darf keine Zeilenumbruchzeichen (\r) oder Zeilenwechselzeichen (\n) enthalten.

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 Cloud Storage-Aufnahme (Pull-basiert), die Multi-Cloud-Aufnahme (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 Einzelnen Feed konfigurieren. Dieser Schritt gilt nicht, wenn Sie die eigenständige Google SecOps SIEM-Plattform verwenden.
  4. Wählen Sie als 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 Google SecOps zum Aufnehmen von Daten verwendet. 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 der Quelle

    • Optional: Präfixe einschließen (optional). Diese Funktion befindet sich derzeit in der eingeschränkten Vorschau. Informationen zu Syntaxregeln und Zulassungslisten finden Sie unter Objekte nach Präfix in STS-Feeds filtern.

    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.

    • So gewähren Sie Leseberechtigungen für mehrere Dateien auf Bucket-Ebene:

      • 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 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 "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2" die folgenden Rollen zu:

        1. 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 von Legacy-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)

Der STS sendet Datenübertragungsanfragen an die Amazon S3- und Azure-Speicherdienste von einer 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, die Daten aus dieser JSON-Datei mindestens einmal pro Woche zu lesen, damit Ihre Sicherheitskonfiguration auf dem neuesten Stand bleibt. Wenn der Datei ein neuer Bereich hinzugefügt wird, wartet das System mindestens 7 Tage, bevor dieser Bereich für Anfragen von STS verwendet wird.

    Ein Python-Beispielskript, 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 abweichen, 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 beschrieben: Zugriff basierend auf bestimmten IP-Adressen verwalten.

    • 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 IP-Adressen hinzufügen möchten, folgen Sie der Anleitung unter Azure Storage-Firewalls und virtuelle Netzwerke konfigurieren.

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: 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. Überprü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 Schalter 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 Pub/Sub-Push-Feed von Google Cloud verfügbar ist.
  3. Wählen Sie Authentifizierung aktivieren und dann ein Dienstkonto aus.
  4. Deaktivieren Sie die Optionen Entpacken der Push-Nutzlast und 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 Secret Key.
  2. Erstellen Sie einen API-Schlüssel, um sich bei Google SecOps zu authentifizieren. Sie können auch Ihren vorhandenen API-Schlüssel wiederverwenden, um sich bei Google SecOps zu authentifizieren.
  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 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 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: 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. Überprü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, aber dadurch wird der vorherige geheime Schlüssel hinfällig.
  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 Lieferstream in Amazon Data Firehose angeben.
  13. Optional: Klicken Sie auf den Schalter 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. Beschränken Sie den Zugriff des API-Schlüssels auf die Chronicle API.

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 zur 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:

  • Prüfen Sie, ob ein Google Cloud -Projekt für Google SecOps konfiguriert und die Chronicle API für das Projekt aktiviert ist.

  • Google SecOps-Instanz mit Google Cloud -Diensten verknüpfen.

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 einzigen 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 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 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: 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. Überprü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, aber dadurch wird der vorherige geheime Schlüssel hinfällig.
  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 Schalter 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. Beschränken Sie den Zugriff des API-Schlüssels auf die Chronicle API.

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 zur 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 codelose Connectors bezeichnet) können Sie Telemetriedaten von 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 keine Datenduplikate und keine fehlenden Logs über Abfragezyklen hinweg gibt.
  • Übergeordnete/untergeordnete Fan-Outs: Unterstützt zweistufige Erkennungs-Workflows, z. B. das Auflisten von Ressourcen und das Abrufen der zugehörigen Telemetriedaten.
  • Automatisierte Ausfallsicherheit und Ratenbegrenzung: Verhindert Drosselung durch Anbieter und Kontingentüberschreitungen. Für eine zuverlässige, unterbrechungsfreie Aufnahme verarbeitet der benutzerdefinierte API-Feed HTTP-429-Antworten automatisch mit einem exponentiellen Backoff, drosselt Anfragen mit konfigurierbarer Ratenbegrenzung und gestaffelter Aufgabenverzögerung und erzwingt Sicherheitsmaßnahmen. Weitere Informationen finden Sie unter Schutzmaßnahmen 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 des Anbieters 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 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 Google SecOps-Ziel-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. Fügen Sie keine Unterpfade oder abschließenden Schrägstriche an.

    • Abrufhäufigkeit: Geben Sie in Minuten an, wie oft die Plattform die API auf neue Telemetriedaten prüft. 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-Clientanmeldedaten-Grant-Flow. Google SecOps fordert vor jedem Aufnahmezyklus 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 den OAuth-Clientschlüssel 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 Headernamen (z. B. Authorization oder X-API-Key) und den Headerwert (z. B. Bearer <SECRET_TOKEN> oder <SECRET_KEY>) ein.
    • API-Schlüssel-Suchparameter: 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 Connector-Modell aus, das Ihre benutzerdefinierte API verwendet:

    • 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 Suchablauf. 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). Der Feed generiert dann automatisch abhängige Folgeaufrufe (untergeordnete Aufrufe), um detaillierte Telemetriedaten für jede einzelne 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 Filtertext 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 ein clientseitiger Ratenbegrenzer, 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.
    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 Suchparameter 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, den die Drittanbieter-API für die Verarbeitung von mehrseitigen Ergebnismengen benötigt, und konfigurieren Sie dann die erforderlichen Felder:
      • Keine: Daten werden in einer einzigen Anfrage ohne Paginierung abgerufen.
      • 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 Suchparameters 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-Abfrageparameters ein (z. B. offset).
      • Seitennummerierung:Gehen Sie zur nächsten Seitennummer. 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 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 werden abgerufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
        • Neuester Zeitstempel: Verfolgen Sie den Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert (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 für den Prüfpunktwert (z. B. id oder event_id) und die Prüfpunktvariable (z. B. last_id, referenziert als {{.last_id}}) ein.
        • 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 Ziellogeinträge befindet. Geben Sie für in Objekte verpackte Arrays (z. B. {"items": [...]}) items ein. Lassen Sie dieses Feld bei APIs, die ein JSON-Stammarray direkt 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 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 Filtertext 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 ein clientseitiger Ratenbegrenzer, 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 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).
      4. Optional: Konfigurieren Sie unter Suchparameter 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 von mehrseitigen Ergebnismengen benötigt, und konfigurieren Sie dann die erforderlichen Felder:
        • Keine: Daten werden in einer einzigen Anfrage ohne Paginierung abgerufen.
        • 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 Suchparameters 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-Abfrageparameters ein (z. B. offset).
        • Seitennummerierung:Gehen Sie zur nächsten Seitennummer. Geben Sie den Namen des Suchparameters für die Seitennummer 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 werden abgerufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
          • Neuester Zeitstempel: Verfolgen Sie den Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert (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 für den Prüfpunktwert (z. B. id oder event_id) und die Prüfpunktvariable (z. B. last_id, referenziert als {{.last_id}}) ein.
          • 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 Element-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 Vorlagenvariable: Geben Sie einen benutzerdefinierten Variablennamen an, der die extrahierte ID enthalten soll (z. B. zone_id). In der Benutzeroberfläche wird ein dynamisches Badge angezeigt: Verwenden Sie {{.zone_id}} in Ihrer untergeordneten Anfrage unten.
    3. Untergeordnete Anfrage (Detail): Konfigurieren Sie den Endpunkt, der detaillierte Protokolle 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). 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 Filtertext 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 ein clientseitiger Ratenbegrenzer, 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 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).
      4. Optional: Konfigurieren Sie unter Suchparameter 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 von mehrseitigen Ergebnismengen benötigt, und konfigurieren Sie dann die erforderlichen Felder:
        • Keine: Daten werden in einer einzigen Anfrage ohne Paginierung abgerufen.
        • 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 Suchparameters 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-Abfrageparameters ein (z. B. offset).
        • Seitennummerierung:Gehen Sie zur nächsten Seitennummer. Geben Sie den Namen des Suchparameters für die Seitennummer 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 werden abgerufen, ohne den Fortschritt über Zyklen hinweg zu verfolgen.
          • Neuester Zeitstempel: Verfolgen Sie den Zeitstempel des neuesten Datensatzes. Geben Sie den JSON-Pfad für den Prüfpunktwert (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:

    • Abrufhä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 automatisierte Prüfung der Anmeldedaten und Endpunkte durch. Wenn die Validierung erfolgreich ist, beginnt die Abfrage des Feeds.

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

Die folgende deklarative JSON-Konfiguration zeigt 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-Zonentelemetrie (Modell „Liste und Details (über-/untergeordnet)“)

Die folgende deklarative JSON-Konfiguration zeigt ein Fan-out-Modell vom Typ Liste und Details (übergeordnet/untergeordnet) 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

  • Anleitung 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 der Anbieter-API-Kontingente zu beobachten, bevor Sie es auf 5 Minuten senken.
    • Für umfangreiches Fan-Out optimieren: Bei Übergeordnet/Untergeordnet (Liste und Detail)-Feeds, die Dutzende oder Hunderte von Ressourcen erkennen, empfiehlt Google dringend, die Abfragehäufigkeit auf 30 bis 60 Minuten festzulegen, damit alle untergeordneten Aufgaben mit Zeitlimit abgeschlossen werden können, bevor der nächste Erkennungszyklus gestartet wird.
  • 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 Zustandsprüfung konfigurieren.
  • APIs mit mehreren untergeordneten Elementen aufteilen: Wenn eine Drittanbieter-API Meldungen und Audit-Logs für eine einzelne Nutzerliste abrufen muss, erstellen Sie zwei separate Feeds mit einem untergeordneten Element (einen für Meldungen und einen für Audit-Logs), um eine optimale Isolation zu gewährleisten.

Schutzmaßnahmen für Ratenbegrenzung und Drosselung

Damit die Konfigurationen von Kundenfeeds nicht die Kontingente von Drittanbietern überlasten oder Systemressourcen monopolisieren, werden beim Feedtyp „Benutzerdefinierte API“ die folgenden automatisierten Schutzmaßnahmen implementiert:

  • Konfigurierbare Anfragegeschwindigkeit (Ratenbegrenzung): Ausgehende HTTP-Anfragen werden automatisch so gesteuert, dass die Ratenbegrenzungen des Anbieters nicht überschritten werden. Die Standard-Pacing-Rate beträgt 5 Anfragen pro Minute (1 Anfrage alle 12 Sekunden). Sie können dies pro Endpunkt über das Feld Maximale Anfragen pro Minute in den Endpunkteinstellungen an die veröffentlichten API-Kontingente Ihres Anbieters anpassen.
  • Obergrenze für untergeordnete Anfragen:Bei übergeordneten/untergeordneten Feeds (Liste und Detail) können bei einer Erkennungsanfrage bis zu 500 untergeordnete Anfragen pro Abrufzyklus 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 (Aufrufe von Enkelkindern) 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 die API eines Drittanbieters mit HTTP 429 (Too Many Requests) antwortet, erfasst Google SecOps den Status automatisch und initiiert einen exponentiellen Backoff-Zeitraum. Die Ausführung der Aufgabe wird pausiert, bis das Kontingentfenster des Anbieters wieder gefü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 Anfragesignierung: APIs, die dynamische kryptografische Signaturen pro Anfrage erfordern, 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 über API-Schlüssel, Basisauthentifizierung oder Standard-OAuth 2.0-Clientanmeldedaten erfolgen. Clientseitige Zertifikat-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-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.

Verwenden Sie die folgende Abfrage, um speziell nach fehlgeschlagenen HTTP-Anfragen zu filtern:

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

Ersetzen Sie FEED_ID durch Ihre Feed-ID.

Häufige Fehler 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 ein und klicken Sie auf Senden.
HTTP 404 Nicht gefunden Falsche Basis-URL oder Endpunktpfad-Vorlage. Prüfen Sie den Endpunkt in der API-Dokumentation des Anbieters. Achten Sie darauf, dass die Basis-URL sauber endet und der Endpunktpfad mit „/“ beginnt.
HTTP 429 Too Many Requests Die API-Ratenbegrenzungen des Anbieters wurden überschritten. Erhöhen Sie die Abrufhä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 ID-Extraktorpfad. 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 die Managementtools verwenden, um den Status der Datenaufnahme zu überwachen, vorhandene Parameter zu ändern und den Lebenszyklus des Feeds zu 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 aufrufen 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.

    • Über die Seiten-Tabs und Pfeile können Sie zwischen mehreren Seiten mit Feeds wechseln.

  • 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 eine Zeile, um das Menü more_vert Mehr einzublenden.
  3. Im Menü können Sie sich die Feeddetails ansehen, den Feed bearbeiten, deaktivieren oder löschen.

Feedstatus überwachen

Sie können den Status des Feeds auf der ersten 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: Der Feed ist deaktiviert.

  • Fehlgeschlagen: Daten konnten nicht abgerufen werden. Dies ist wahrscheinlich auf ein Konfigurationsproblem zurückzuführen. Klicken Sie auf die Frage, um den Konfigurationsfehler aufzurufen. Nachdem Sie den Fehler behoben und den Feed noch einmal eingereicht haben, rufen Sie die Seite Feeds auf, um zu prüfen, ob der Feed jetzt funktioniert.

Vorhandene Feeds bearbeiten

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

  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, nimmt Google SecOps keine neuen Daten mehr aus dieser Quelle auf. Wenn Sie die Datenaufnahme sofort beenden möchten, müssen Sie den Feed löschen. Vorhandene aktive oder gedrosselte Übertragungen werden bis zum Abschluss fortgesetzt. 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 „Backfillability“ bezeichnet.

In der Spalte Status sind aktivierte Feeds als 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 als 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

Mit diesen Feeds ruft Google SecOps Daten aus externen Quellen ab. Pull-Feeds umfassen:

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

  • Drittanbieter-APIs wie Microsoft 365, Okta, 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 senden externe Systeme Daten an Google SecOps. 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, sendet Google SecOps entweder einen HTTP 403 Forbidden-Fehler oder einen allgemeinen 4xx-Fehler.

Wenn Ihr System die Daten nicht speichert und nicht versucht, sie noch einmal an Google SecOps zu senden, gehen die Daten verloren. Wenn Ihr System so eingestellt ist, dass es bei einem Fehler Daten verwirft oder den Zwischenspeicher leert, 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 die Daten der letzten sieben Tage.
  • Google SecOps-Puffer: Für die automatisierte Wiederherstellung speichert der interne Puffer von Google SecOps für pull-basierte Feeds Daten bis zu 90 Tage lang. Danach werden die Daten 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. Der Pull-basierte Daten-Backfill ist ebenfalls ratenbegrenzt, in der Regel auf ein Drittel (33%) des Burst-Limits Ihres Mandanten pro Logtyp. So wird sichergestellt, dass kritische 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 Filter für den Zeitraum, z. B. „Maximales Dateialter“.
  • Große Rückstände:Wenn ein großer Rückstand aus einem Pull-basierten Feed nach der erneuten Aktivierung Probleme verursacht, können Sie sich an den Google-Support wenden, um den Rückstand zu beheben. Das bedeutet, dass der Feed ab diesem Zeitpunkt nur noch 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 wirksam, 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. Klicken Sie auf Ja, löschen, um den Feed endgültig zu löschen.

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

  • Nicht ausgewählt (Standardeinstellung): Die Feedkonfiguration und die Anmeldedaten werden gelöscht, aber die in der Warteschlange befindlichen Backlog-Daten werden bis zur Aufnahme verarbeitet.
  • 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. Das Aufnahmevolumen und der Nutzungsverlauf des Mandanten bestimmen den Schwellenwert.

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 Quelltyp, 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 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 Fehlerursache 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.

  • Generic::failed_precondition-Fehler:

    Fehler: Generic::failed_precondition: include_prefixes is not enabled for this customer

    Dieser Fehler tritt auf, wenn Sie einen STS-Feed mit Werten im Feld Präfixe einschließen (include_prefixes) speichern, Ihr Google SecOps-Mandant jedoch nicht auf der Zulassungsliste für die präfixbasierte Filterung steht.

    Führen Sie einen der folgenden Schritte aus, um diesen Fehler zu beheben:

    1. Entfernen Sie alle Präfixe aus dem Feld Präfixe einschließen (include_prefixes) und speichern Sie den Feed noch einmal, um den gesamten Bucket oder Container aufzunehmen.
    2. Wenden Sie sich an Ihr Google Cloud Account-Management-Team, Ihren Technical Account Manager (TAM) oder Cloud Customer Care, um Zugriff auf die Funktion include_prefixes (enable_feed_include_prefixes) für Ihren Mandanten anzufordern. Weitere Informationen finden Sie unter Objekte in STS-Feeds nach Präfix filtern.

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