Daten mit dem erweiterten BigQuery Export streamen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie mit der Funktion Erweiterter BigQuery-Export auf Ihre Google SecOps-Daten in BigQuery zugreifen und sie verwenden können. Als Enterprise Plus-Kunde können Sie mit dieser Funktion über eine vollständig verwaltete Streaming-Datenpipeline nahezu in Echtzeit auf Ihre Sicherheitsdaten zugreifen. Diese Funktion kann dazu beitragen, die kritische Herausforderung der Datenlatenz in Sicherheitsvorgängen zu bewältigen und zu einer zeitnahen und effektiven Bedrohungserkennung und -abwehr zu führen.

Hinweis

Sehen Sie sich die folgenden Punkte an, die die Teilnahmevoraussetzungen und erforderlichen Maßnahmen definieren:

  • Nur für Enterprise Plus-Kunden: Diese Funktion ist nur für Google SecOps Enterprise Plus-Kunden verfügbar. Alle anderen Kunden finden Informationen unter In ein selbstverwaltetes BigQuery-Projekt exportieren.
  • Funktionsaktivierung erforderlich: Diese Funktion wird auf Anfrage aktiviert und erfordert möglicherweise eine Erstkonfiguration in der Google SecOps-Instanz Ihrer Organisation. Wenden Sie sich gegebenenfalls an Ihren Google SecOps-Ansprechpartner, um die Aktivierung der Funktion zu bestätigen.
  • Datenmigration: Wenn Sie diese Funktion aktivieren, werden Ihre Daten zusätzlich zu den vorhandenen Exporten in Ihr von Google verwaltetes BigQuery-Projekt in ein neues BigQuery-Mandantenprojekt für Ihre Google SecOps-Instanz exportiert, wie unter In ein von Google verwaltetes BigQuery-Projekt exportieren beschrieben. Dieser duale Betrieb unterstützt die Umstellung auf die neue Funktion ohne Unterbrechung. Sie werden benachrichtigt, bevor die alte Exportpipeline für Ihr Konto deaktiviert wird.
  • VPC Service Controls: Der erweiterte BigQuery-Export kann in einem VPC Service Controls-Perimeter verwendet werden. Weitere Informationen finden Sie unter VPC Service Controls konfigurieren.
  • Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK): Der erweiterte BigQuery Export ist für Kunden verfügbar, die CMEK für ihre Google SecOps-Instanz aktiviert haben. Weitere Informationen finden Sie unter CMEK für Google SecOps. Wenn Sie CMEK mit VPC Service Controls verwenden, finden Sie unter VPC Service Controls für Google SecOps konfigurieren Empfehlungen und Anleitungen.

Funktionsübersicht

Beim erweiterten BigQuery-Export werden wichtige Google SecOps-Datasets, darunter UDM-Ereignisse (Unified Data Model), Regelerkennungen, Entity-Diagramme und IoC-Übereinstimmungen (Indicator of Compromise), automatisch in einem sicheren, von Google verwalteten BigQuery-Projekt bereitgestellt und verwaltet. Sie erhalten sicheren Lesezugriff auf diese Daten über ein verknüpftes BigQuery-Dataset, das direkt in Ihrem eigenen Google Cloud -Projekt angezeigt wird. Mit dieser Funktion können Sie Ihre Sicherheitsdaten abfragen, als wären sie lokal gespeichert, ohne dass Sie die Datenpipeline oder den Speicher verwalten müssen.

Google SecOps exportiert die folgenden Kategorien von Sicherheitsdaten nach BigQuery:

  • UDM-Ereignisdatensätze: UDM-Datensätze, die aus Logdaten erstellt werden, die von Kunden aufgenommen werden. Diese Datensätze werden mit Aliasinformationen angereichert.
  • Regelübereinstimmungen (Erkennungen): Instanzen, in denen eine Regel mit einem oder mehreren Ereignissen übereinstimmt.
  • IoC-Übereinstimmungen: Artefakte (z. B. Domains oder IP-Adressen) aus Ereignissen, die mit IoC-Feeds übereinstimmen. Dazu gehören Übereinstimmungen mit und aus globalen Feeds und kundenspezifischen Feeds.
  • Aufnahmemesswerte: Statistiken, z. B. die Anzahl der aufgenommenen Logzeilen, die Anzahl der aus Logs erzeugten Ereignisse und die Anzahl der Logfehler, die darauf hinweisen, dass Logs nicht geparst werden konnten.
  • Entitätsgraph und Entitätsbeziehungen: Die Beschreibung von Entitäten und ihren Beziehungen zu anderen Entitäten.

Wesentliche Vorteile

Die wichtigsten Vorteile des erweiterten BigQuery-Exports sind:

  • Datenaktualität nahezu in Echtzeit: Mit einer Streaming-Architektur sind Ihre Sicherheitsdaten innerhalb weniger Minuten nach der Aufnahme für Abfragen verfügbar. UDM-Ereignisse, Regelerkennungen und IoC-Übereinstimmungen sind mit einer erwarteten Latenz von 5 bis 10 Minuten verfügbar.
  • Vereinfachtes und vorhersehbares Kostenmodell: Google SecOps deckt alle Kosten für die Datenaufnahme und -speicherung im verwalteten BigQuery-Projekt ab. Ihre Organisation ist nur für die BigQuery-Analysegebühren verantwortlich, die anfallen, wenn Sie Abfragen ausführen.
  • Datenzugriff ohne Wartung: Die zugrunde liegende Infrastruktur wird vollständig von Google verwaltet. So kann sich Ihr Team auf die Datenanalyse statt auf die Datenaufbereitung konzentrieren.
  • Datenintegrität und Deduplizierung: Sicherheitsdaten werden nach der ersten Aufnahme häufig aktualisiert oder neu angereichert. Die Funktion verwendet detaillierte DML-Zusammenführungen (Datenbearbeitungssprache), um Datensätze direkt zu aktualisieren. Sie erhalten bereinigte, deduplizierte Daten, ohne komplexe SQL-Deduplizierungsroutinen schreiben zu müssen.
  • Nahtlose MSSP-Unterstützung (Hub-and-Spoke): Managed Security Service Providers (MSSPs) können Analysen für mehrere Kundenmandanten effizient verwalten, indem sie programmatisch die verknüpften Datasets ihrer Kunden über ein einzelnes, zentrales Hub-Projekt abonnieren.
  • Integrierte Compliance: Die Funktion unterstützt nativ VPC Service Controls, kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) und Datenstandorte (Data Residency Zones, DRZ). Kundenorientierte Audit-Logs (Access Transparency) werden über den Federated Resource Identification Service (FRIS) direkt an Ihren Cloud Logging-Arbeitsbereich gesendet.

Gängige Anwendungsfälle

Der erweiterte BigQuery-Export ist für Sicherheitsanalysten, Threat Hunter, Data Scientists und Sicherheitsingenieure gedacht, die direkten, leistungsstarken Zugriff auf aktuelle Sicherheitsdaten für Ad-hoc-Untersuchungen, benutzerdefinierte Analysen und die Integration in Business-Intelligence-Tools benötigen.

Gängige Anwendungsfälle für den erweiterten BigQuery-Export:

  • Ad-hoc-Abfragen direkt in BigQuery ausführen
  • Sie können Ihre eigenen Business-Intelligence-Tools wie Microsoft Power BI verwenden, um Dashboards, Berichte und Analysen zu erstellen.
  • Google SecOps-Daten mit Datasets von Drittanbietern zusammenführen

Architektur

Die Architektur des erweiterten BigQuery-Exports verwendet eine kontinuierliche Streamingpipeline. Daten aus Ihrer Google SecOps-Instanz werden über die BigQuery Storage Write API (gRPC) mit hohem Durchsatz in ein sicheres, von Google verwaltetes Mandantenprojekt übertragen.

Google SecOps verwendet die BigQuery-Freigabe, um einen sicheren Dateneintrag zu erstellen und Ihnen Zugriff zu gewähren. Im BigQuery-Bereich Explorer wird Ihr Projekt Google Cloud automatisch für diesen Eintrag abonniert. Er wird als verknüpftes Dataset secops_linked_datalake angezeigt.

Dieses Modell unterstützt eine starke Datenisolation und bietet Ihnen gleichzeitig nahtlosen schreibgeschützten Abfragezugriff.

Schlüsselterminologie

Im Folgenden finden Sie einige wichtige Begriffe und Konzepte für den erweiterten BigQuery-Export:

  • Mandantenprojekt: Ein Google Cloud Projekt, das Google SecOps gehört und von Google SecOps verwaltet wird. In diesem Projekt werden Ihre exportierten Sicherheitsdaten physisch gespeichert und verwaltet. Sie haben keinen direkten Zugriff auf dieses Projekt.
  • BYOP (Bring Your Own Project): Das Google Cloud Projekt, das Ihrer Organisation gehört und mit Ihrer Google SecOps-Instanz verknüpft ist. In diesem Projekt wird das verknüpfte Dataset angezeigt. Hier führen Sie Ihre Abfragen aus und es fallen Analysekosten an.
  • Projekt-ID: Die weltweit eindeutige Kennung für Ihr Google Cloud -Projekt, das mit Ihrer Google SecOps-Instanz verknüpft ist.
  • Verknüpftes Dataset: Ein schreibgeschütztes BigQuery-Dataset, das als symbolischer Link oder Verweis auf ein freigegebenes Dataset in einem anderen Projekt dient. Sie können Daten abfragen, ohne sie zu kopieren, und erhalten sicheren Zugriff, während der Datenanbieter den physischen Speicher verwaltet.
  • Feingranulare DML (FGDML): Der automatisierte Backend-Prozess, der von Advanced BigQuery Export verwendet wird, um Upserts (Aktualisierungen und Einfügungen) durchzuführen. Wenn ein Ereignis verspätet eintrifft oder neu angereichert wird, aktualisiert das System die vorhandene Zeile anhand der eindeutigen Kennung (z. B. metadata.id), anstatt ein Duplikat zu erstellen.
  • Einheitliches Datenmodell (Unified Data Model, UDM): Das erweiterbare Standardschema von Google zum Parsen und Normalisieren von Sicherheitstelemetriedaten aus Hunderten von Anbieterprodukten in ein einheitliches Format.
  • Managed Security Service Providers (MSSP): Google Cloud Zertifizierte MSSPs bieten eine umfassende Suite von Tools und Fachwissen, um Ihre Abwehr gegen sich ständig weiterentwickelnde Cyberbedrohungen zu stärken.

System einrichten

Wenn Sie den erweiterten BigQuery-Export verwenden möchten, müssen Sie zuerst Ihr System einrichten. Folgen Sie je nach Umgebung und Anforderungen der Anleitung in einem der folgenden Abschnitte.

Standardeinrichtung

So richten Sie Ihr System für die Verwendung des erweiterten BigQuery-Exports ein und beginnen mit der Abfrage Ihrer Daten:

  1. Lizenz bestätigen: Prüfen Sie, ob Ihre Organisation eine Google SecOps Enterprise Plus-Lizenz hat.
  2. Projekt identifizieren: Melden Sie sich in der Google Cloud Console an und wählen Sie das Google Cloud Projekt aus, das mit Ihrer Google SecOps-Instanz verknüpft ist.
  3. Verknüpftes Dataset suchen: Rufen Sie in der BigQuery-Konsole im Bereich Explorer die Ressourcen Ihres Projekts auf. Sie sehen ein verknüpftes Dataset mit dem Namen secops_linked_datalake. Dieses Dataset ist ein schreibgeschützter Verweis auf die von Google SecOps verwalteten Live-Sicherheitsdaten.
  4. IAM-Berechtigungen (Identity and Access Management) prüfen: Zum Abfragen der Daten müssen Ihrem Nutzer- oder Dienstkonto die folgenden IAM-Rollen für Ihr Projekt zugewiesen sein:

    • roles/bigquery.dataViewer: Erforderlich, damit Endnutzer oder BI-Tools in Ihrer Organisation SQL-Abfragen für die verknüpften Dataset-Ansichten ausführen können.
    • roles/bigquery.jobUser: Erforderlich, damit Endnutzer oder BI-Tools in Ihrer Organisation SQL-Abfragen für die verknüpften Dataset-Ansichten ausführen können.
    • Chronicle API Admin: Erforderlich in Google SecOps, um die Dataplane APIs (z. B. ProvisionPartnerSubscription) auszuführen und MSSP-Abos zu verwalten.

    Mit diesen Rollen können Nutzer (z. B. Sicherheitsanalysten und Datenkonsumenten) Daten im verknüpften Dataset abfragen und BigQuery-Jobs in ihrem Projekt ausführen.

  5. Testabfrage ausführen: Öffnen Sie den BigQuery SQL-Arbeitsbereich und führen Sie eine einfache Abfrage aus, um zu prüfen, ob Ihr Zugriff richtig konfiguriert ist. Sie können das folgende Code-Snippet verwenden:

    SELECT *
    FROM `PROJECT_ID.secops_linked_datalake.events`
    LIMIT 10;
    

    Ersetzen Sie PROJECT_ID durch Ihre tatsächliche Projekt-ID in Google Cloud .

Erweiterten BigQuery-Export innerhalb eines VPC Service Controls-Perimeters einrichten

Wenn Sie den erweiterten BigQuery-Export innerhalb Ihres VPC Service Controls-Perimeters einrichten möchten, müssen Sie eine bestimmte Regel für eingehenden Traffic konfigurieren. Mit dieser Regel können die erforderlichen Google SecOps-Dienstkonten mit BigQuery und zugehörigen Diensten in den durch den Perimeter geschützten Projekten interagieren. Eine ausführliche Anleitung und weitere Informationen finden Sie unter VPC Service Controls für Google Security Operations konfigurieren.

  • Wenn Sie den erweiterten BigQuery-Export in Ihrem VPC Service Controls-Perimeter einrichten möchten, konfigurieren Sie die folgende Regel für eingehenden Traffic:

    - ingressFrom:
        identities:
        - serviceAccount:malachite-advanced-bq-exporter@system.gserviceaccount.com
        - serviceAccount:malachite-data-export-service@system.gserviceaccount.com
        sources:
        - accessLevel: "*"
      ingressTo:
        operations:
        - serviceName: analyticshub.googleapis.com
          methodSelectors:
          - method: "*"
        - serviceName: bigquery.googleapis.com
          methodSelectors:
          - method: "*"
        resources:
        - projects/PROJECT_NUMBER
    

    Ersetzen Sie PROJECT_NUMBER durch die mit Google SecOps verknüpfte Google Cloud Projektnummer.

Für MSSPs: Zentralen Zugriff auf BigQuery-Daten Ihrer Untermieter einrichten

Wenn Sie als MSSP bereitgestellt werden, können Sie die Google SecOps-Datenebene-APIs verwenden, um programmatisch verknüpfte BigQuery-Datasets in Ihrem zentralen Hub-Projekt zu erstellen. Diese verknüpften Datasets verweisen auf die BigQuery-Daten Ihrer Kunden (Spokes). So können Sie mehrere Mandanten über eine einzige Benutzeroberfläche abfragen. Dazu muss Ihr Kunde Ihrer MSSP-Instanz Zugriff gewähren.

Die wichtigsten Vorteile:

  • Zentrale Sichtbarkeit: Analysieren Sie Sicherheitsdaten aller Ihrer Kunden an einem Ort.
  • Effiziente Arbeitsabläufe:Optimieren Sie die Suche nach Bedrohungen und die Berichterstellung für Ihren Kundenstamm.
  • Programmatische Verwaltung: Automatisieren Sie die Einrichtung und den Abbau des Datenzugriffs.

Vorbereitung

  • MSSP

    • Ein Google Cloud -Projekt, das als zentraler „Hub“ dient.
    • Eine Google SecOps-Instanz.
    • Sie benötigen die entsprechenden IAM-Berechtigungen, um BigQuery-Datasets in Ihrem Hub-Projekt zu verwalten.
  • Kunde (Untermieter)

    • Eine Google SecOps Enterprise Plus-Lizenz.
    • Ein Google Cloud -Projekt (BYOP), das mit Ihrer Google SecOps-Instanz verknüpft ist.
    • Entsprechende IAM-Berechtigungen zum Verwalten des Google SecOps API-Zugriffs.
    • gcloud-CLI installiert und authentifiziert.

Schritt 1: Kunde gewährt MSSP-Zugriff

Der Kunde kann die ProvisionPartnerSubscription API aufrufen, um der Google SecOps-Instanz seines MSSP Berechtigungen zu gewähren. Google SecOps stellt automatisch ein verknüpftes BigQuery-Dataset im Format secops_linked_datalake_<customer_id> im Google Cloud -Projekt des MSSP bereit, das mit der Google SecOps-Instanz des MSSP verknüpft ist. Dieses Dataset ist mit den Google SecOps-Daten des Kunden verknüpft.

API-Endpunkt:
POST
https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:provisionPartnerSubscription
Methode

POST

Anfragetext

Leeres JSON-Objekt.

{}

Beispiel für einen CURL-Befehl (vom Kunden auszuführen):

curl -X POST \
  -H "Authorization: Bearer ${OAUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{}' \
  "https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:provisionPartnerSubscription"

Ersetzen Sie die folgenden Platzhalter:

  • CUSTOMER_PROJECT: Die Google Cloud Projekt-ID oder Projektnummer des Kunden. Weitere Informationen finden Sie unter Projekte erstellen und verwalten.
  • REGION: Die Google Cloud Region, in der sich die Google SecOps-Instanz des Kunden befindet, z. B. „us“ oder „europe-west2“. Liste der Regionen
  • CUSTOMER_INSTANCE_ID: Die Google SecOps-Instanz-ID des Kunden.
Antworttext

Gibt ProvisionPartnerSubscriptionResponse mit den Abodetails zurück.

{
  "subscriptionDetails": {
    "subscription": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID",
    "linkedDataset": "string"
  }
}
  • SUBSCRIBER_PROJECT_ID: Die Google Cloud Projekt-ID des MSSP des Abonnenten.
  • SUBSCRIBER_REGION: Die Region, in der sich das Google Cloud Projekt des Abonnenten befindet.
  • SUBSCRIPTION_ID: Eine eindeutige Kennung für das vorhandene Abo.

Schritt 2: MSSP fragt Daten tenantübergreifend ab

Sobald die verknüpften Datasets von mehreren Kunden in Ihrem (MSSP) Google Cloud -Projekt bereitgestellt wurden, können Sie die Daten mit Standard-BigQuery-SQL-Abfragen analysieren. Wenn Sie Daten für mehrere Kunden abfragen möchten, verwenden Sie den Operator UNION ALL.

Beispielabfrage (vom MSSP im Hub-Projekt auszuführen):

SELECT event_type, timestamp
FROM `PARTNER_PROJECT_ID.secops_linked_datalake_CUSTOMER_ID_1.events`
WHERE <your_conditions>

UNION ALL

SELECT event_type, timestamp
FROM `PARTNER_PROJECT_ID.secops_linked_datalake_CUSTOMER_ID_2.events`
WHERE <your_conditions>

-- Add more UNION ALL clauses for other customers

Schritt 3: Zugriff durch Kunden prüfen

Der Kunde kann die fetchSubscriptions API aufrufen, um alle aktiven Abos und MSSP-Instanzen zu sehen, die auf seine Daten zugreifen.

API-Endpunkt
GET https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:fetchSubscriptions
Methode

GET

Beispiel für einen CURL-Befehl (vom Kunden auszuführen):

curl -X GET \
  -H "Authorization: Bearer ${OAUTH_TOKEN}" \
  "https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:fetchSubscriptions"

Ersetzen Sie die folgenden Platzhalter:

  • CUSTOMER_PROJECT: Die Google Cloud Projekt-ID oder Projektnummer des Kunden. Weitere Informationen finden Sie unter Projekte erstellen und verwalten.
  • REGION: Die Google Cloud Region, in der sich die Google SecOps-Instanz des Kunden befindet, z.B. „us“ oder „europe-west2“. Eine Liste der Regionen finden Sie in diesem Artikel.
  • CUSTOMER_INSTANCE_ID: Die Google SecOps-Instanz-ID des Kunden.
Antworttext

Gibt „FetchSubscriptionsResponse“ mit einer Liste aktiver Abos zurück.

{
  "subscriptions": [
    {
      "subscription": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID",
      "linkedDataset": "string"
    }
  ]
}
  • SUBSCRIBER_PROJECT_ID: Die Google Cloud Projekt-ID des Abonnenten. Der Abonnent kann entweder der Kunde oder ein MSSP sein.
  • SUBSCRIBER_REGION: Die Region, in der sich das Google Cloud Projekt des Abonnenten befindet.
  • SUBSCRIPTION_ID: Eine eindeutige Kennung für das vorhandene Abo.

Schritt 4: Kunde widerruft den Zugriff (falls erforderlich)

Wenn ein Kunde den Zugriff eines MSSP widerrufen muss, kann er die API „revokePartnerSubscription“ verwenden. Dadurch wird die Berechtigung zum Abfragen des verknüpften Datasets über das Hub-Projekt des MSSP sofort widerrufen. Die ID des gekündigten Abos wird inaktiv.

API-Endpunkt
POST https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:revokePartnerSubscription
Methode

POST

Anfragetext

Erfordert den URI des Abos, das widerrufen werden soll. Dieser wurde vom fetchSubscriptions-API-Aufruf abgerufen.

{
  "subscriptionUri": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID"
}

Beispiel für einen CURL-Befehl (der vom Kunden ausgeführt werden muss):

# Set subscription details obtained from Fetch Subscriptions
export SUBSCRIBER_PROJECT_ID="partner-byop-project-id"
export SUBSCRIBER_REGION="subscription-location"
export SUBSCRIPTION_ID="subscription-id"

curl -X POST \
  -H "Authorization: Bearer ${OAUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "subscriptionUri": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID"
  }' \
  "https://chronicle.googleapis.com/v1alpha/projects/CUSTOMER_PROJECT/locations/REGION/instances/CUSTOMER_INSTANCE_ID/bigQueryExport:revokePartnerSubscription"

Ersetzen Sie die folgenden Platzhalter:

  • SUBSCRIBER_PROJECT_ID: Die Google Cloud Projekt-ID des Abonnenten.
  • SUBSCRIBER_REGION: Die Region, in der sich das Google Cloud Projekt des Abonnenten befindet.
  • SUBSCRIPTION_ID: Eine eindeutige Kennung für das bestehende Abo.
  • CUSTOMER_PROJECT: Die Projekt-ID oder Projektnummer des Kunden in Google Cloud .
  • REGION: Die Google Cloud Region, in der sich die Google SecOps-Instanz des Kunden befindet.
  • CUSTOMER_INSTANCE_ID: Die Google SecOps-Instanz-ID des Kunden.
Antworttext

Leeres JSON-Objekt.

{}

BigQuery-Daten abfragen

Sie können Abfragen direkt in BigQuery ausführen oder Ihr eigenes Business-Intelligence-Tool, z. B. Microsoft Power BI, mit BigQuery verbinden.

Weitere Informationen zu Abfragen finden Sie hier:

Aufbewahrungszeitraum für Daten in Ihrem BigQuery-Mandantenprojekt

Die Aufbewahrungsdauer für Ihre Daten in BigQuery ist identisch mit der für Ihren Google SecOps-Mandanten konfigurierten Datenaufbewahrungsdauer. Es gibt keine separate, konfigurierbare Einstellung, um die Aufbewahrungsrichtlinie für Daten in BigQuery anzupassen. Daten werden automatisch aus den BigQuery-Tabellen gelöscht, wenn sie das Aufbewahrungsfenster Ihres Mandanten überschreiten.

Verknüpfte Datasets

Verknüpfte Datasets enthalten Tabellen, die verschiedenen Arten von Sicherheitsdaten entsprechen.

Die folgende Tabelle enthält eine Zusammenfassung der verfügbaren Datasets, der angestrebten Datenaktualität und der eindeutigen Kennungen, die zur Gewährleistung der Datenintegrität verwendet werden:

Dataset-Name Beschreibung Beste erwartete Aktualität Eindeutige Kennungen für die Deduplizierung
events Normalisierte sicherheitsrelevante Ereignisse im UDM-Schema. Informationen zum Schema finden Sie unter Google SecOps-Ereignisschema. < 5 Minuten id (Stringdarstellung)
rule_detections Erkennungen, die von den Regeln der Google SecOps-Erkennungs-Engine generiert werden. < 5 Minuten detection.id
ioc_matches Übereinstimmungen von Kompromittierungsindikatoren (Indicators of Compromise, IOCs) mit UDM-Ereignissen gefunden. < 5 Minuten Zusammengesetzter Schlüssel aus day_bucket_seconds, feed_log_type, ioc_type, ioc_value
entity_graph Kontextdaten zu Entitäten (Nutzer, Assets) und ihren Beziehungen. ca. 4 Stunden (Batch) Zusammengesetzter Schlüssel aus „partition_day“, „metadata.product_entity_id“ und „metadata.event_metadata.id“
ingestion_metrics Statistiken zum Volumen der Logaufnahme und zu Datenquellen. ~5 Minuten Keine (nur anhängen)
entity_enum_value_to_name_mapping Ordnet numerische Werte Stringwerten für Aufzählungstypen im Entitätsgraphen zu. – Keine
udm_enum_value_to_name_mapping Ordnet numerische Werte Stringwerten für Aufzählungstypen von UDM-Ereignissen zu. – Keine

Beispielabfragen

Die folgenden Beispiele zeigen, wie Sie die Datasets für gängige Sicherheitsanwendungsfälle abfragen.

Beispiel: Alle Netzwerkverbindungen von einer bestimmten IP-Adresse in den letzten 24 Stunden finden

Mit dieser Abfrage wird die Tabelle „events“ nach aktuellen Netzwerkaktivitäten von einer verdächtigen IP-Adresse durchsucht.

SELECT
  metadata.product_event_type,
  principal.ip,
  target.ip,
  network.application_protocol
FROM
  `PROJECT_ID.secops_linked_datalake.events`
WHERE
  principal.ip = '192.0.2.1'
  AND metadata.event_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR);
  • Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID in Google Cloud .

Beispiel: Die zehn häufigsten Regelerkennungen zählen

Mit dieser Abfrage für die Tabelle „rule_detections“ können Sie die häufigsten Bedrohungen oder Richtlinienverstöße ermitteln, die in Ihrer Umgebung erkannt werden.

SELECT
  rule_name,
  COUNT(*) AS detection_count
FROM
  `PROJECT_ID.secops_linked_datalake.rule_detections`
WHERE
  detection.id IS NOT NULL
GROUP BY
  1
ORDER BY
  2 DESC
LIMIT
  10;
  • Ersetzen Sie PROJECT_ID durch Ihre Google Cloud Projekt-ID.

Best Practices

Hier sind einige Best Practices für Abfragen mit dem erweiterten BigQuery-Export:

  • Abfragekosten optimieren:Obwohl der Speicher kostenlos ist, werden die Datenverarbeitungskosten Ihrem Projekt in Rechnung gestellt. Gehen Sie daher so vor:

    • Vermeiden Sie SELECT *. Geben Sie in Ihrer Abfrage nur die Spalten an, die Sie benötigen, um die Menge der gescannten Daten zu reduzieren und die Abfragekosten zu senken.
    • Achten Sie darauf, dass Ihre Abfragen die BigQuery-Partitionierung (mit der Partitionierungszeitspalte „hour_time_bucket“) und das Clustering („hour_time_bucket“, „log_type“, „event_type“, „id“) nutzen, um weniger Daten zu scannen und die Abfragekosten erheblich zu senken.
  • Partitionsfilter verwenden: Die Tabelle „events“ ist nach der Spalte „hour_time_bucket“ partitioniert. Fügen Sie immer einen WHERE-Klauselfilter für diese Spalte ein, um Abfragen auf das kleinstmögliche Zeitfenster zu beschränken. Dadurch wird die Leistung erheblich verbessert und die Kosten werden gesenkt.

  • Effiziente Abfragen schreiben:Das UDM-Schema ist breit und spärlich. Wenn Sie effizient nach bestimmten Ereignistypen filtern möchten, verwenden Sie WHERE... IS NOT NULL für relevante Felder. Wenn Sie beispielsweise nur DNS-Abfragen finden möchten, filtern Sie mit WHERE network.dns.questions.name IS NOT NULL.

  • Abfragen validieren:Verwenden Sie die Abfragevalidierung in der BigQuery-Benutzeroberfläche, bevor Sie eine Abfrage ausführen. Die Abfragevalidierung liefert eine Schätzung der verarbeiteten Daten, sodass Sie unerwartet große und kostspielige Abfragen vermeiden können.

  • Tabellen für die Enum-Zuordnung verwenden:Der erweiterte BigQuery-Export umfasst die Tabellen „entity_enum_value_to_name_mapping“ und „udm_enum_value_to_name_mapping“. Sie können diese verwenden, um Ihre Ereignisse zu verknüpfen und numerische enum-Werte in menschenlesbare Strings zu übersetzen, ohne manuelle Übersetzungslogik in Ihre Abfragen schreiben zu müssen.

  • Integration von Audit-Logs:Der erweiterte BigQuery-Export ist in den Federated Resource Identification Service (FRIS) eingebunden. Kundenorientierte Audit-Logs, die das Google Access Transparency-Feature verwenden, werden nativ in Ihrem BYOP Cloud Logging-Arbeitsbereich bereitgestellt, wenn Google-Mitarbeiter auf das verwaltete Mandantenprojekt zugreifen.

Bekannte Einschränkungen

Die folgenden Einschränkungen der erweiterten BigQuery Export-Funktion sind bekannt:

  • Latenz des Entity-Graphen:Das Dataset „entity_graph“ wird mit einem Batchprozess exportiert und hat eine Datenaktualität von etwa vier Stunden.
  • UDM-Schema-Spaltenlimits: BigQuery hat ein weiches Limit von 10.000 Spalten pro Tabelle. Das UDM-Schema enthält über 27.000 Felder und ist dünnbesetzt. In der Exportpipeline werden nur ausgefüllte Spalten für ein bestimmtes Ereignis berücksichtigt, sodass die meisten Kunden weit unter dem Limit bleiben. Google SecOps überwacht die Spaltennutzung und fordert proaktiv eine Erhöhung des Limits für Ihr Mandantenprojekt an, wenn es sich diesem Schwellenwert nähert.
  • Aufbewahrungsdauer ist nicht konfigurierbar: Die Aufbewahrungsdauer für alle nach BigQuery exportierten Sicherheitsdaten wird automatisch mit der Aufbewahrungsdauer Ihres Google SecOps-Projekts synchronisiert und kann nicht separat konfiguriert werden.
  • SOAR-Daten werden nicht unterstützt:Daten aus Google Security Operations SOAR (search_everything_db) werden im erweiterten BigQuery-Export nicht unterstützt.
  • Regionenübergreifende Föderation wird nicht unterstützt: Hub-and-Spoke-MSSP-Abos werden innerhalb derselben Region unterstützt. Die regionenübergreifende Föderation (z. B. von den USA nach Europa) wird nicht unterstützt.
  • Doppelte Ereignisse sind möglich (Wahrscheinlichkeit unter 1 %): Obwohl das System DML-Zusammenführungen verwendet, um die Deduplizierung automatisch zu verarbeiten, besteht aufgrund der Art des verteilten Streamings eine geringe Wahrscheinlichkeit (< 1%), dass während der Aufnahme von Grenzfallereignissen vor Abschluss der Hintergrundzusammenführung doppelte Ereignisse auftreten.
  • Verlaufsdaten sind zugänglich, erfordern aber bestimmte Methoden: Der Datenexport beginnt ab dem Zeitpunkt, an dem der erweiterte BigQuery-Export aktiviert wird. Ältere Daten bleiben in Ihrem bestehenden Projekt zugänglich. Wenn Sie Daten abfragen möchten, die vor der Aktivierung des erweiterten BigQuery-Exports exportiert wurden, müssen Sie entweder eine einzelne Abfrage verwenden, die Daten aus beiden Projekten zusammenführt, oder zwei separate Abfragen für die jeweiligen Projekte ausführen (eine für das ältere Dataset und eine für das neue Dataset).

Fehlerbehebung und Support

In der folgenden Tabelle finden Sie Lösungen für häufig auftretende Probleme:

Beobachtetes Symptom Mögliche Ursache Empfohlene Maßnahmen
Abfragen schlagen mit Access Denied: User does not have permission. fehl Dem Nutzer- oder Dienstkonto fehlen die erforderlichen BigQuery-IAM-Rollen für das Google Cloud -Projekt, das mit Ihrer Google SecOps-Instanz verknüpft ist. Weisen Sie dem Hauptkonto die Rollen BigQuery-Datenbetrachter und BigQuery-Jobnutzer zu. Bestätigen Sie dies mit gcloud projects get-iam-policy YOUR_PROJECT_ID --flatten="bindings.members" --format='table(bindings.role)' --filter="bindings.members:user:your-user@example.com".
Das Dataset secops_linked_datalake ist in meinem BigQuery-Projekt nicht sichtbar. 1. Sie befinden sich nicht im richtigen Google Cloud Projekt
. Ihre Organisation verwendet nicht die Enterprise Plus-Stufe.
3. Ihre Organisation verwendet die Enterprise Plus-Stufe, aber der erweiterte BigQuery-Export ist in Ihrer Google SecOps-Instanz nicht aktiviert.
1. Prüfen Sie in der Google Cloud Console, ob Sie das Projekt ausgewählt haben, das mit Ihrer Google SecOps-Instanz verknüpft ist.
2. Wenden Sie sich an Ihren Google-Ansprechpartner, um Ihren Google SecOps-Lizenzierungsgrad zu bestätigen.
3. Bitten Sie Ihren Google SecOps-Ansprechpartner, den erweiterten BigQuery-Export in Ihrer Google SecOps-Instanz zu aktivieren.
API-Aufruf schlägt mit einem Berechtigungsfehler für ProvisionPartnerSubscription oder FetchSubscriptions fehl Der aufrufenden Identität fehlen die erforderlichen Berechtigungen. Achten Sie darauf, dass das Dienstkonto oder der Nutzer, der den Aufruf ausführt, die IAM-Rolle „Chronicle API Administrator“ hat, die Berechtigungen für die Hub-Instanzressource enthält.
Fehlende benutzerdefinierte Spalten oder Schemaabweichung Es wurde ein neuer Logtyp oder ein tief verschachteltes UDM-Feld aufgenommen. Beim erweiterten BigQuery-Export werden dynamische Schemaaktualisierungen verwendet. Wenn neue UDM-Felder ausgefüllt werden, erkennt das System automatisch die Schemaabweichung, pausiert kurz, aktualisiert das BigQuery-Schema und versucht, die Daten noch einmal einzufügen. Sie müssen nichts tun.

Häufig gestellte Fragen

In den folgenden Abschnitten finden Sie Antworten auf einige häufig gestellte Fragen.

Muss ich meine vorhandenen, alten BigQuery-SQL-Abfragen ändern, um den erweiterten Google SecOps-Export zu verwenden?

Nein. Um eine 100% ige Abwärtskompatibilität zu gewährleisten, stellt Google SecOps im verknüpften Dataset Ansichten (z. B. Ereignisse, ioc_matches) bereit, die genau dem Schema der Tabellen aus der alten Google SecOps-Exportfunktion entsprechen.

Kann ich den Zeitraum für die Datenaufbewahrung für meinen erweiterten BigQuery-Export anpassen?

Nein. Die Datenaufbewahrungsdauer im erweiterten BigQuery-Export entspricht direkt Ihren Richtlinien zur Datenaufbewahrung in Google SecOps. Wenn Daten in Google SecOps ablaufen, laufen sie automatisch ab und werden aus dem BigQuery-Mandantenprojekt gelöscht.

Werden mir die DML-Aktualisierungen und die Deduplizierung im Backend in Rechnung gestellt?

Nein. Alle Kosten für Backend-Speicher, Streaming-Insert-Anweisungen und detaillierte DML-Berechnungen werden von Google SecOps übernommen. Sie zahlen nur für die Abfragen, die Sie explizit in Ihrem BYOP ausführen.

Ist diese Funktion für Google SecOps Standard- oder Enterprise-Versionen verfügbar?

Nein. Der erweiterte BigQuery-Export (verwalteter Speicher und Streaming) ist eine Premium-Funktion, die nur in der Google SecOps Enterprise Plus-Stufe verfügbar ist. Standard- und Enterprise-Kunden können das BYOBQ-Modell (Bring Your Own BigQuery) verwenden. Dabei stellen sie das BigQuery-Projekt bereit und übernehmen sowohl die Speicher- als auch die Computing-Kosten.

Warum können vorübergehende Unterschiede bei den Zählungen zwischen Daten im erweiterten BigQuery-Export und Statistiken in der Google Security Operations-Benutzeroberfläche auftreten?

Aufgrund der nahezu in Echtzeit erfolgenden Streaming-Natur der Pipeline für den erweiterten BigQuery-Export kann es zu vorübergehenden Abweichungen kommen. Hier sind die wichtigsten Gründe:

  • Spät eintreffende Daten:Die Exportpipeline ist für einen hohen Durchsatz konzipiert. Die meisten Daten werden innerhalb von 5 bis 10 Minuten in BigQuery angezeigt. Aufgrund von Netzwerkverzögerungen oder Problemen mit dem Quellsystem können Ereignisse jedoch manchmal verspätet in der Verarbeitungspipeline ankommen. Das System versucht zwar, diese verspäteten Ereignisse zusammenzuführen, aber es kann kurzzeitig vorkommen, dass sich die Live-UI-Statistiken, die den absolut neuesten Stand widerspiegeln, von den BigQuery-Daten unterscheiden, die fortlaufend aktualisiert werden.

  • Datenanreicherung: Google SecOps reichert Ereignisdaten kontinuierlich mit den neuesten Informationen zu Bedrohungen und Kontextinformationen an. Beim erweiterten BigQuery-Export werden Ereignisse basierend auf ihrem Status zum Zeitpunkt der ersten Anreicherung exportiert. Wenn ein Ereignis nach dem Streaming zu BigQuery mit neuen Informationen angereichert wird, wird diese aktualisierte Version möglicherweise nicht sofort in BigQuery angezeigt. Dies kann zu Abweichungen führen, wenn Sie die Daten mit UI-Elementen vergleichen, in denen immer die vollständig angereicherten Daten angezeigt werden.

  • DML-Zusammenführungslatenz: Damit die Daten in BigQuery auf dem neuesten Stand bleiben und Probleme wie verspätete Daten oder potenzielle Duplikate behoben werden, verwendet die Pipeline im Hintergrund MERGE-Vorgänge der Datenbearbeitungssprache (Data Manipulation Language, DML). Diese Vorgänge sind zwar effizient, erfolgen aber nicht sofort. Da diese Zusammenführungen verarbeitet werden müssen, kommt es zu einer gewissen Latenz, insbesondere bei detaillierten Aktualisierungen. Während dieses Zusammenführungsintervalls werden bei Abfragen in BigQuery möglicherweise nicht die neuesten Mikro-Updates erfasst, die bereits in der Google Security Operations-Benutzeroberfläche sichtbar sind.

Aufgrund der genannten Faktoren (verspätete Daten, Verarbeitung von Anreicherungen und Zusammenführungsverzögerungen) ist eine perfekte 1:1-Übereinstimmung zwischen BigQuery und den Live-UI-Statistiken zu einem bestimmten Zeitpunkt möglicherweise nicht immer gegeben. Der erweiterte BigQuery-Export bietet Daten nahezu in Echtzeit, die für Anwendungsfälle wie die Bedrohungssuche, benutzerdefinierte Analysen und Dashboards optimiert sind, bei denen die Datenaktualität innerhalb von Minuten entscheidend ist. Bei Prüfungen, die eine absolute Konsistenz zu einem bestimmten Zeitpunkt erfordern, sollten Sie mögliche geringfügige, vorübergehende Unterschiede berücksichtigen.

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