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 lösen und zu einer zeitnaheren 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 den vorhandenen Exporten in Ihr von Google verwaltetes BigQuery-Projekt, wie unter In ein von Google verwaltetes BigQuery-Projekt exportieren 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: 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 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 Logdaten erstellt wurden, die von Kunden aufgenommen 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-Abgleiche 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 erneut angereichert. Bei dieser Funktion werden detaillierte Datenbearbeitungssprache (DML)-Zusammenführungen 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 Providers (MSSPs) können Analysen für mehrere Kundenmandanten effizient verwalten, indem sie programmatisch über ein einzelnes, zentrales Hub-Projekt die verknüpften Datasets ihrer Kunden 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 mithilfe der BigQuery Storage Write API 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

Hier sind 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.
  • Feingranulare DML (FGDML): Der automatisierte Backend-Prozess, der von Advanced BigQuery Export verwendet wird, um Upserts (Aktualisierungen und Einfügungen) auszuführen. Wenn ein Ereignis verspätet eintrifft oder noch einmal 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 Sicherheits-Telemetriedaten 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 den erweiterten BigQuery-Export ein und beginnen mit dem Abfragen Ihrer Daten:

  1. Lizenz bestätigen: Prüfen Sie, ob Ihre Organisation eine Google SecOps Enterprise Plus-Lizenz hat.
  2. Projekt ermitteln: 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: Verwenden Sie in der BigQuery Console den Bereich Explorer, um zu den Ressourcen Ihres Projekts zu navigieren. 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) zum Verwalten von MSSP-Abos auszuführen.

    Mit diesen Rollen können Nutzer (z. B. Sicherheitsanalysten und Datenverbraucher) 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 Google Cloud Projekt-ID.

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 detaillierte Anleitung und weitere Informationen finden Sie unter VPC Service Controls für Google Security Operations konfigurieren.

  • Wenn Sie den erweiterten BigQuery-Export innerhalb Ihres VPC Service Controls-Perimeters 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 Projektnummer Ihres mit Google SecOps verknüpften Google Cloud Projekts.

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

Wenn Sie als MSSP bereitgestellt werden, können Sie die Google SecOps-Datenebene-APIs nutzen, 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), sodass Sie Abfragen für mehrere Mandanten über eine einzige Benutzeroberfläche ausführen können. Dazu muss Ihr Kunde Ihrer MSSP-Instanz Zugriff gewähren.

Die wichtigsten Vorteile:

  • Zentrale Sichtbarkeit:Analysieren Sie Sicherheitsdaten aller Ihrer Kunden an einem zentralen Ort.
  • Effiziente Workflows:Optimieren Sie die Suche nach Bedrohungen und die Berichterstellung für Ihren Kundenstamm.
  • Programmatische Verwaltung:Richten Sie den Datenzugriff automatisch ein und heben Sie ihn automatisch auf.

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.
    • Sie haben die entsprechenden IAM-Berechtigungen zum Verwalten des Google SecOps API-Zugriffs.
    • Die gcloud-Befehlszeile ist installiert und authentifiziert.

Schritt 1: Kunde gewährt MSSP-Zugriff

Der Kunde kann die ProvisionPartnerSubscription API aufrufen, um Berechtigungen für die Google SecOps-Instanz seines MSSP zu erteilen. Google SecOps stellt automatisch ein mit BigQuery verknüpftes 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 (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 Abodetails zurück.

{
  "subscriptionDetails": {
    "subscription": "projects/SUBSCRIBER_PROJECT_ID/locations/SUBSCRIBER_REGION/subscriptions/SUBSCRIPTION_ID",
    "linkedDataset": "string"
  }
}
  • SUBSCRIBER_PROJECT_ID: Die Projekt-ID des MSSP des Abonnenten. Google Cloud
  • 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 tenantübergreifend ab

Sobald die verknüpften Datasets mehrerer Kunden in Ihrem Google Cloud -Projekt (MSSP) bereitgestellt wurden, können Sie die Daten mit Standard-BigQuery-SQL-Abfragen 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 muss):

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: Kundenzugriff auf Audits

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 (der vom Kunden ausgeführt werden muss):

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 Es wurden Übereinstimmungen mit Kompromittierungsindikatoren (Indicators of Compromise, IOCs) für UDM-Ereignisse 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“ 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 String-Werten für aufgezählte Typen im Entitätsdiagramm zu. Keine
udm_enum_value_to_name_mapping Ordnet numerische Werte Stringwerten für aufgezählte UDM-Ereignistypen 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 10 häufigsten Regelerkennungen zählen

Mit dieser Abfrage für die Tabelle „rule_detections“ lassen sich 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 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. Verwenden Sie WHERE..., um effizient nach bestimmten Ereignistypen zu filtern. 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 – Spaltenlimits:In BigQuery gilt ein Softlimit von 10.000 Spalten pro Tabelle. Das UDM-Schema enthält über 27.000 Felder und ist nur spärlich gefüllt. In der Exportpipeline werden nur Spalten für ein bestimmtes Ereignis berücksichtigt, die Daten enthalten. Die meisten Kunden bleiben so weit unter dem Limit. 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-Abos werden in derselben Region unterstützt. Die regionenübergreifende Föderation (z. B. 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 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. Mit gcloud projects get-iam-policy YOUR_PROJECT_ID --flatten="bindings.members" --format='table(bindings.role)' --filter="bindings.members:user:your-user@example.com" bestätigen
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 nutzt nicht die Enterprise Plus-Version.
3. Ihre Organisation verwendet die Enterprise Plus-Version, 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 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.
Benutzerdefinierte Spalten fehlen oder es liegt eine Schemadiskrepanz vor 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

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 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 Aufbewahrungsdauer für Daten im erweiterten BigQuery Export entspricht direkt Ihrer Aufbewahrungsrichtlinie für Google SecOps-Daten. 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 Backend-Speicher-, Streaming-Insert-Anweisungen und detaillierten 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 für Google SecOps Enterprise Plus 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 zwischen den Zählungen in den Daten im erweiterten BigQuery-Export und den Statistiken in der Google Security Operations-Benutzeroberfläche auftreten?

Vorübergehende Abweichungen können aufgrund der Streaming-Natur der Advanced BigQuery Export-Pipeline, die Daten nahezu in Echtzeit verarbeitet, auftreten. Hier sind 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 mit dem Quellsystem können Ereignisse jedoch manchmal erst spät in der Verarbeitungspipeline 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 der neuesten Threat Intelligence und Kontextinformationen an. Beim erweiterten BigQuery-Export werden Ereignisse basierend auf ihrem Status zum Zeitpunkt der ersten Anreicherung exportiert. 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. Da diese Zusammenführungen verarbeitet werden müssen, entsteht eine gewisse Latenz, insbesondere bei detaillierten Aktualisierungen. Während dieses Zusammenführungsintervalls werden in Abfragen für BigQuery möglicherweise nicht die neuesten Mikroupdates erfasst, die bereits in der Google Security Operations-Benutzeroberfläche 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 nahezu in 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