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 Streamingdatenpipeline nahezu in Echtzeit auf Ihre Sicherheitsdaten zugreifen. Diese Funktion kann dazu beitragen, das kritische Problem der Datenlatenz im Sicherheitsbetrieb zu beheben und zu einer rechtzeitigeren und effektiveren Erkennung und Reaktion auf Bedrohungen 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 Ihren bestehenden Exporten in Ihr von Google verwaltetes BigQuery-Projekt, wie in Export in ein von Google verwaltetes BigQuery-Projekt beschrieben, in ein neues BigQuery-Mandantenprojekt für Ihre Google SecOps-Instanz exportiert. Diese doppelte Funktionsweise unterstützt Sie bei der Umstellung auf die neue Funktion ohne Unterbrechung. Sie werden benachrichtigt, bevor die alte Exportpipeline für Ihr Konto deaktiviert wird.
  • VPC Service Controls: Erweiterter BigQuery-Export kann in einem VPC Service Controls-Perimeter ausgeführt 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 Empfehlungen und Anleitungen unter VPC Service Controls für Google SecOps konfigurieren.

Funktionsübersicht

Mit dem erweiterten BigQuery-Export werden wichtige Google SecOps-Datasets, einschließlich UDM-Ereignisse (Unified Data Model), Regelerkennungen, Entity-Diagramme und Kompromittierungsindikator-Übereinstimmungen (IoC), automatisch in einem sicheren, von Google verwalteten BigQuery-Projekt bereitgestellt und verwaltet. Sie erhalten sicheren, schreibgeschützten Zugriff 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 von Kunden erfassten Protokolldaten erstellt wurden. Diese Datensätze werden mit Aliasinformationen angereichert.
  • Regelabgleich (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 Abgleiche mit und aus globalen Feeds und kundenspezifischen Feeds.
  • Messwerte für die Aufnahme: Statistiken wie die Anzahl der aufgenommenen Logzeilen, die Anzahl der aus Logs generierten 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: Dank einer Streamingarchitektur 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-10 Minuten verfügbar.
  • Vereinfachtes und vorhersehbares Kostenmodell: Google SecOps deckt alle Kosten für die Datenerfassung und -speicherung innerhalb des verwalteten BigQuery-Projekts ab. Ihre Organisation ist nur für die BigQuery-Analysekosten verantwortlich, die beim Ausführen von Abfragen anfallen.
  • 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 erneut angereichert. Bei dieser Funktion werden detaillierte DML-Zusammenführungen (Data Manipulation Language) verwendet, 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 Provider (MSSPs) können Analysen über mehrere Kundentenants hinweg effizient verwalten, indem sie programmatisch die verknüpften Datensätze ihrer Kunden von einem einzigen, zentralisierten Hub-Projekt abonnieren.
  • Integrierte Compliance: Die Funktion unterstützt nativ VPC Service Controls, kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) und Datenstandort (Data Residency Zone, DRZ). Kundenorientierte Audit-Logs (Access Transparency) werden mithilfe des 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 Sicherheitstechniker konzipiert, 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 Drittanbieter-Datensätzen zusammenführen

Architektur

Die Architektur des erweiterten BigQuery-Exports verwendet eine kontinuierliche Streaming-Pipeline. 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. In Ihrem BigQuery-Bereich Explorer ist Ihr Google Cloud Projekt automatisch für dieses Angebot abonniert. Es 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 global 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. So wird ein sicherer Zugriff ermöglicht, während der Datenanbieter die physische Speicherung verwaltet.
  • Fine-graned DML (FGDML): Der automatisierte Backend-Prozess, den Advanced BigQuery Export für Upserts (Aktualisierungen und Einfügungen) verwendet. Wenn ein Ereignis verspätet eintrifft oder erneut angereichert wird, aktualisiert das System die bestehende Zeile direkt anhand ihrer eindeutigen Kennung (z. B. metadata.id), anstatt ein Duplikat zu erstellen.
  • Unified Data Model (UDM): Googles erweiterbares Standardschema zum Parsen und Normalisieren von Sicherheitstelemetriedaten aus Hunderten von Produkten verschiedener Hersteller in ein einheitliches Format.
  • Managed Security Service Providers (MSSP): Google Cloud Zertifizierte MSSPs bieten eine umfassende Palette an Tools und Fachwissen, um Ihre Abwehr gegen sich ständig weiterentwickelnde Cybersicherheitsbedrohungen zu stärken.

Richten Sie Ihr System ein

Um Advanced BigQuery Export nutzen zu können, müssen Sie zunächst Ihr System einrichten. Je nach Ihren Gegebenheiten und Anforderungen befolgen Sie die Anweisungen in einem der folgenden Abschnitte.

Standardkonfiguration

Führen Sie diese Schritte aus, um Ihr System für die Verwendung von Advanced BigQuery Export einzurichten und mit der Abfrage Ihrer Daten zu beginnen:

  1. Bestätigen Sie Ihre Lizenz: Stellen Sie sicher, dass Ihre Organisation über eine Google SecOps Enterprise Plus-Lizenz verfügt.
  2. Identifizieren Sie Ihr Projekt: Melden Sie sich in der Google Cloud Konsole an und wählen Sie das Google Cloud Projekt aus, das mit Ihrer Google SecOps-Instanz verknüpft ist.
  3. Verknüpftes Dataset finden: Verwenden Sie in der BigQuery-Konsole den Bereich Explorer, um zu den Ressourcen Ihres Projekts zu navigieren. Sie sehen einen verknüpften Datensatz mit dem Namen secops_linked_datalake. Dieser Datensatz ist ein schreibgeschützter Verweis auf die von Google SecOps verwalteten Live-Sicherheitsdaten.

  4. Überprüfen Sie die Berechtigungen für Identity and Access Management (IAM):: Um die Daten abzufragen, muss Ihrem Benutzer- oder Dienstkonto die folgenden IAM-Rollen für Ihr Projekt zugewiesen sein:

    • roles/bigquery.dataViewer: Erforderlich, damit Endbenutzer oder BI-Tools in Ihrer Organisation SQL-Abfragen gegen die verknüpften Dataset-Ansichten ausführen können.
    • roles/bigquery.jobUser: Erforderlich, damit Endbenutzer oder BI-Tools in Ihrer Organisation SQL-Abfragen gegen die verknüpften Dataset-Ansichten ausführen können.
    • Chronicle API Admin: Wird innerhalb von Google SecOps benötigt, um die Dataplane APIs (z. B. ProvisionPartnerSubscription) zur Verwaltung von MSSP-Abonnements auszuführen.

    Diese Rollen ermöglichen es Benutzern (wie z. B. Sicherheitsanalysten und Datenkonsumenten), Daten im verknüpften Datensatz abzufragen und BigQuery-Jobs innerhalb ihres Projekts auszuführen.

  5. Führen Sie eine Testabfrage aus: Öffnen Sie den BigQuery SQL-Arbeitsbereich und führen Sie eine einfache Abfrage aus, um zu überprüfen, ob Ihr Zugriff korrekt konfiguriert ist. Sie können folgenden Codeausschnitt verwenden:

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

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

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

Um Advanced BigQuery Export innerhalb Ihres VPC Service Controls-Perimeters einzurichten, müssen Sie eine spezifische Ingress-Regel konfigurieren. Diese Regel erlaubt es den erforderlichen Google SecOps-Dienstkonten, mit BigQuery und verwandten Diensten in den durch den Perimeter geschützten Projekten zu interagieren. Ausführliche Anweisungen und weitere Informationen finden Sie unter Konfigurieren der VPC-Dienststeuerung für Google Security Operations.

  • Um Advanced BigQuery Export innerhalb Ihres VPC Service Controls-Perimeters einzurichten, konfigurieren Sie die folgende Eingangsregel:

    - 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 Projektnummer Ihres mit Google SecOps verknüpften Google Cloud Projekts.

Für MSSPs – Richten Sie einen zentralen Zugriff auf die BigQuery-Daten Ihrer Sub-Tenants ein

Wenn Sie als MSSP (Managed Security Service Provider) bereitgestellt sind, können Sie die Google SecOps Dataplane APIs nutzen, um programmgesteuert verknüpfte BigQuery-Datasets in Ihrem zentralen „Hub“-Projekt zu erstellen. Diese verknüpften Datensätze verweisen auf die BigQuery-Daten Ihrer Kunden (Spokes) und ermöglichen Ihnen so, Abfragen über mehrere Mandanten hinweg von einer einzigen Benutzeroberfläche aus durchzuführen. Dieser Prozess erfordert, dass Ihr Kunde Ihrer MSSP-Instanz Zugriff gewährt.

Zu den wichtigsten Vorteilen gehören:

  • Zentrale Transparenz: Analysieren Sie Sicherheitsdaten all Ihrer Kunden an einem Ort.
  • Effiziente Arbeitsabläufe: Optimieren Sie die Bedrohungssuche und das Reporting für Ihren gesamten Kundenstamm.
  • Programmatische Verwaltung: Automatisieren Sie die Einrichtung und Deaktivierung des Datenzugriffs.

Vorbereitung

  • MSSP

    • Ein Google Cloud -Projekt, das als zentraler „Hub“ dient.
    • Eine Google SecOps-Instanz.
    • Geeignete IAM-Berechtigungen zur Verwaltung von BigQuery-Datasets in Ihrem Hub-Projekt.

  • Kunde (Untermieter)

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

Schritt 1: Der Kunde gewährt dem MSSP Zugriff

Der Kunde kann die ProvisionPartnerSubscription API aufrufen, um der Google SecOps-Instanz seines MSSP Berechtigungen zu erteilen. Google SecOps stellt automatisch ein verknüpftes BigQuery-Dataset bereit, das im Format secops_linked_datalake_<customer_id> innerhalb des MSSP-Projekts Google Cloud benannt ist, das mit der Google SecOps-Instanz des MSSP verknüpft ist. Dieser Datensatz 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 (der vom Kunden ausgeführt werden muss):

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, europe-west2). Liste der Regionen
  • CUSTOMER_INSTANCE_ID: Die Google SecOps-Instanz-ID des Kunden.
Antworttext

Gibt ProvisionPartnerSubscriptionResponse mit den Abonnementdetails zurück.

{
  "subscriptionDetails": {
    "subscription": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID",
    "linkedDataset": "string"
  }
}
  • SUBSCRIBER_PROJECT_ID: Die Projekt-ID Google Cloud 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 bestehende Abo.

Schritt 2: MSSP fragt Daten mandantenübergreifend ab

Sobald die verknüpften Datensätze mehrerer Kunden in Ihrem (MSSP's) Google Cloud Projekt bereitgestellt sind, können Sie Standard-BigQuery-SQL-Abfragen verwenden, um die Daten zu analysieren. Wenn Sie Daten von mehreren Kunden abfragen möchten, verwenden Sie den Operator UNION ALL.

Beispielabfrage (die vom MSSP in seinem Hub-Projekt ausgeführt werden soll):

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: Kundenprüfung Zugriff

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 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, europe-west2). Liste der Regionen
  • 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 sich entweder an den Kunden oder an einen MSSP wenden.
  • SUBSCRIBER_REGION: Die Region, in der sich das Google Cloud -Projekt des Abonnenten befindet.
  • SUBSCRIPTION_ID: Eine eindeutige Kennung für das bestehende Abo.

Schritt 4: Kunde widerruft den Zugriff (falls erforderlich)

Wenn ein Kunde den Zugriff eines MSSP widerrufen muss, kann er die revokePartnerSubscription API verwenden. Durch diese Aktion 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 zu widerrufenden Abos, der über den fetchSubscriptions-API-Aufruf abgerufen wurde.

{
  "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 Google Cloud Projekt-ID oder Projektnummer des Kunden.
  • 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 wie Microsoft Power BI mit BigQuery verbinden.

Weitere Informationen zu Abfragen finden Sie hier:

Aufbewahrungszeitraum für Daten in Ihrem BigQuery-Mandantenprojekt

Der Aufbewahrungszeitraum für Ihre Daten in BigQuery entspricht dem für Ihren Google SecOps-Mandanten konfigurierten Aufbewahrungszeitraum. Es gibt keine separate, konfigurierbare Einstellung, mit der Sie die Aufbewahrungsrichtlinie für Daten in BigQuery anpassen können. Daten werden automatisch aus den BigQuery-Tabellen gelöscht, wenn sie älter als der Aufbewahrungszeitraum Ihres Mandanten sind.

Verknüpfte Datasets

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

In der folgenden Tabelle finden Sie 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 Sicherheitsereignisse im UDM-Schema. Informationen zum Schema finden Sie unter Google SecOps-Ereignisschema. < 5 Minuten id (String-Darstellung)
rule_detections Erkennungen, die von den Regeln der Google SecOps-Erkennungs-Engine generiert werden. < 5 Minuten detection.id
ioc_matches Kompromittierungsindikatoren (IOC)-Übereinstimmungen bei UDM-Ereignissen gefunden. < 5 Minuten Zusammengesetzter Schlüssel aus „day_bucket_seconds“, „feed_log_type“, „ioc_type“ und „ioc_value“
entity_graph Kontextbezogene Daten zu Entitäten (Nutzer, Assets) und ihren Beziehungen. ca. 4 Stunden (Batch) Zusammengesetzter Schlüssel aus partition_day, metadata.product_entity_id, 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 String-Werten für aufgezählte Typen im Entitätsdiagramm zu. – Keine
udm_enum_value_to_name_mapping Ordnet numerische Werte Zeichenkettenwerten für UDM-Ereignis-Enumerationstypen 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 in der Ereignistabelle nach aktuellen Netzwerkaktivitäten von einer verdächtigen IP-Adresse gesucht.

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 Google Cloud Projekt-ID.

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

Im Folgenden finden Sie einige Best Practices für Abfragen mit dem erweiterten BigQuery-Export:

  • Abfragekosten optimieren:Obwohl Speicherplatz 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 Partitionierungsspalte „hour_time_bucket“) und das Clustering („hour_time_bucket“, „log_type“, „event_type“, „id“) nutzen, um weniger Daten zu scannen und die Abfragekosten deutlich zu senken.

  • Partitionsfilter verwenden:Die Ereignistabelle ist nach der Spalte „hour_time_bucket“ partitioniert. Fügen Sie immer einen WHERE-Klauselfilter für diese Spalte ein, um Abfragen auf den kleinstmöglichen Zeitraum 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. Um effizient nach bestimmten Ereignistypen zu filtern, 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, damit 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 für Menschen lesbare Strings zu übersetzen, ohne manuelle Übersetzungslogik in Ihre Abfragen schreiben zu müssen.

  • Integration des Audit-Loggings:Advanced BigQuery Export wird in den Federated Resource Identification Service (FRIS) eingebunden. Kundenorientierte Audit-Logs, die die Google Access Transparency-Funktion 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-Exportfunktion 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-Spaltenbeschränkungen: BigQuery hat eine weiche Beschränkung von 10.000 Spalten pro Tabelle. Das UDM-Schema enthält über 27.000 Felder und ist nur spärlich belegt. In der Exportpipeline werden nur Spalten für ein bestimmtes Ereignis berücksichtigt, die auch Daten enthalten. So wird das Limit für die meisten Kunden nicht überschritten. Google SecOps überwacht die Spaltennutzung und beantragt proaktiv eine Erhöhung des Limits für Ihr Mandantenprojekt, wenn es sich diesem Grenzwert nähert.
  • Aufbewahrungszeitraum ist nicht konfigurierbar:Der Aufbewahrungszeitraum für alle Sicherheitsdaten, die nach BigQuery exportiert werden, wird automatisch mit dem Aufbewahrungszeitraum 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-Abonnements werden innerhalb derselben Region unterstützt. Regionsübergreifende Föderationen (z. B. USA nach Europa) werden 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 Grenzfall-Zeiträumen doppelte Ereignisse auftreten, bevor die Zusammenführung im Hintergrund abgeschlossen ist.
  • Verlaufsdaten sind zugänglich, erfordern aber bestimmte Methoden:Der Datenexport beginnt mit 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, mit der Daten aus beiden Projekten zusammengeführt werden, oder zwei separate Abfragen für die jeweiligen Projekte ausführen (eine für das alte und eine für das neue Dataset).

Fehlerbehebung und Support

In der folgenden Tabelle finden Sie Lösungen für häufige 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 Prinzipal die Rollen BigQuery-Datenbetrachter und BigQuery-Jobnutzer zu. Überprüfen 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.
2. Ihre Organisation befindet sich nicht auf dem Enterprise Plus-Tarif.
3. Ihre Organisation befindet sich auf dem Enterprise Plus-Tarif, aber der erweiterte BigQuery-Export ist in Ihrer Google SecOps-Instanz nicht aktiviert.		 1. Prüfen Sie in der Google Cloud -Konsole, 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. Wenden Sie sich an Ihren Google SecOps-Ansprechpartner und bitten Sie ihn, den erweiterten BigQuery Export in Ihrer Google SecOps-Instanz zu aktivieren.
API-Aufruf schlägt mit einem Berechtigungsfehler für ProvisionPartnerSubscription oder FetchSubscriptions fehl Die aufrufende Identität besitzt nicht die erforderlichen Berechtigungen. Stellen Sie sicher, dass das Dienstkonto oder der Benutzer, der den Aufruf tätigt, über die Chronicle API-Administrator-IAM-Rolle verfügt, die Berechtigungen für die Hub-Instanzressource beinhaltet.
Fehlende benutzerdefinierte Spalten oder ein Schema-Konflikt Ein neuer Logtyp oder ein tief verschachteltes UDM-Feld wurde 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 Einfügung noch einmal. Sie müssen nichts tun.

Häufig gestellte Fragen

Im Folgenden finden Sie einige häufig gestellte Fragen.

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

Nein. Um die vollständige Abwärtskompatibilität zu gewährleisten, stellt Google SecOps Ansichten (z. B. „events“, „ioc_matches“) im verknüpften Dataset bereit, die genau dem Schema der Tabellen aus der alten Google SecOps-Exportfunktion entsprechen.

Kann ich die Aufbewahrungsdauer für meinen Advanced BigQuery Export anpassen?

Nein. Die Datenaufbewahrungsfrist im erweiterten BigQuery-Export entspricht direkt Ihrer Google SecOps-Datenaufbewahrungsrichtlinie. 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. Sämtliche Backend-Speicher-, Streaming-Einfüge- und detaillierte DML-Berechnungskosten 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 ausschließlich im Google SecOps Enterprise Plus-Tarif enthalten ist. Standard- und Enterprise-Kunden können das Bring Your Own BigQuery (BYOBQ)-Modell nutzen, bei dem sie das BigQuery-Projekt bereitstellen und sowohl die Speicher- als auch die Rechenkosten übernehmen.

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

Aufgrund der nahezu Echtzeit-basierten Streaming-Natur der Advanced BigQuery Export-Pipeline können vorübergehende Abweichungen auftreten. Hier die wichtigsten Gründe:

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

  • Datenanreicherung: Google SecOps reichert Ereignisdaten kontinuierlich mit den neuesten Informationen zu Bedrohungen und Kontextinformationen an. Der erweiterte BigQuery-Export exportiert Ereignisse basierend auf ihrem Zustand zum Zeitpunkt der ersten Anreicherung. Wenn ein Ereignis mit neuen Informationen angereichert wird, nachdem es in BigQuery gestreamt wurde, ist diese aktualisierte Version möglicherweise nicht sofort in BigQuery verfügbar. Das kann zu Unterschieden führen, wenn Sie die Daten mit UI-Elementen vergleichen, in denen immer die vollständig neu angereicherten Daten angezeigt werden.

  • DML-Zusammenführungs-Latenz:Damit die Daten in BigQuery auf dem neuesten Stand sind und Probleme wie verspätet eingehende Daten oder potenzielle Duplikate behandelt werden können, werden im Hintergrund DML-Vorgänge (Datenbearbeitungssprache) MERGE verwendet. Diese Vorgänge sind zwar effizient, werden aber nicht sofort ausgeführt. Bei der Verarbeitung dieser Zusammenführungen entsteht eine systembedingte Verzögerung, insbesondere bei detaillierten Aktualisierungen. Während dieses Zusammenführungsintervalls erfassen Abfragen an BigQuery möglicherweise nicht die allerneuesten Mikroaktualisierungen, die bereits in der Google Security Operations UI sichtbar sind.

Aufgrund der genannten Faktoren (späte Daten, Verarbeitung von Re-Enrichment und Zusammenführungslatenzen) ist eine perfekte 1:1-Übereinstimmung zwischen BigQuery und Live-UI-Statistiken zu einem bestimmten Zeitpunkt möglicherweise nicht immer gegeben. Der erweiterte BigQuery-Export bietet Daten in nahezu Echtzeit, die für Anwendungsfälle wie die Suche nach Bedrohungen, 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