Okera Dynamic Access Platform (ODAP)-Audit-Logs erfassen

Unterstützt in:

Google SecOps SIEM

Hinweis: Dieses Feature unterliegt den Bedingungen des Pre-GA-Angebots in den dienstspezifischen Nutzungsbedingungen für Google Security Operations. Pre-GA-Features werden eventuell nur eingeschränkt unterstützt und Änderungen an diesen Features sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie in den Richtlinien für den technischen Support von Google SecOps und den dienstspezifischen Nutzungsbedingungen für Google SecOps.
Wenn diese Funktion in Ihrer Umgebung nicht sichtbar ist, lesen Sie den Hilfeartikel Funktionen in der Vorabversion verwalten oder wenden Sie sich an Ihren Systemadministrator.

In diesem Dokument wird beschrieben, wie Sie Audit-Logs der Okera Dynamic Access Platform (ODAP) mit Cloud Storage (Amazon S3, Google Cloud Storage oder Azure Blob Storage) in Google Security Operations aufnehmen.

Die Okera Dynamic Access Platform (ODAP) ist eine Plattform für die Datenzugriffssteuerung und Governance, die eine detaillierte Zugriffssteuerung, automatisierte Datenerkennung und -klassifizierung sowie umfassende Audit-Logs für Data Lakes und Analyseplattformen bietet. Die Plattform generiert JSON-formatierte Audit-Logs, in denen alle Datenzugriffsereignisse, Richtlinienänderungen und administrativen Aktionen erfasst werden.

Hinweis: Okera wurde im Mai 2023 von Databricks übernommen und das Produkt wurde in Databricks Unity Catalog integriert. Für vorhandene Okera ODAP-Bereitstellungen, die noch verwendet werden, finden Sie in diesem Leitfaden eine Anleitung zum Exportieren von Audit-Logs in Cloud Storage für die Aufnahme in Google SecOps. Für neue Bereitstellungen sollten Sie stattdessen Databricks Unity Catalog-Audit-Logs verwenden.

Hinweis

Folgende Voraussetzungen müssen erfüllt sein:

• Eine Google SecOps-Instanz
• Eine aktive Okera ODAP-Bereitstellung (Version 2.0 oder höher)
• Administratorzugriff auf die Okera-Clusterkonfiguration (Helm-Diagramm oder Konfigurations-YAML)
• Privilegierter Zugriff auf eine der folgenden Cloud-Plattformen:
  • AWS (S3, IAM) für Amazon S3-Speicher
  • GCP (Cloud Storage, IAM) für Google Cloud Storage
  • Azure (Speicherkonten) für Azure Data Lake Storage Gen2
• Okera-Cluster muss Schreibzugriff auf den Cloud Storage-Speicherort haben

Export von Okera ODAP-Audit-Logs konfigurieren

Okera ODAP-Audit-Logs werden über die YAML-Datei für die Clusterkonfiguration konfiguriert und mithilfe des Okera Helm-Diagramms bereitgestellt. Die Audit-Logs werden im JSON-Format in einen freigegebenen Cloud Storage-Speicherort geschrieben.

Cloud-Speicherplattform bestimmen

Wählen Sie je nach Okera-Bereitstellung eine der folgenden Cloud-Speicherplattformen aus:

• Amazon S3: Für Okera-Cluster, die auf AWS ausgeführt werden
• Google Cloud Storage: Für Okera-Cluster, die auf der GCP ausgeführt werden
• Azure Data Lake Storage Gen2: Für Okera-Cluster, die in Azure ausgeführt werden

Speicherort für Audit-Logs konfigurieren

1. Greifen Sie auf die YAML-Konfigurationsdatei Ihres Okera-Clusters zu.
2. Suchen Sie den Abschnitt für die Audit-Log-Konfiguration.

3. Konfigurieren Sie das Audit-Log-Ziel basierend auf Ihrer Cloud-Plattform:

   • Für Amazon S3:

     WATCHER_LOG_DST_DIR: "s3://your-company/okera/ops/"
     WATCHER_AUDIT_LOG_DST_DIR: "s3://your-company/okera/audit/"
     WATCHER_S3_REGION: "us-east-1"
     WATCHER_S3_ENCRYPT: "true"
     WATCHER_AUDIT_UPLOAD_INTERVAL_SEC: "15"
     

     Ersetzen Sie Folgendes:

     • your-company: Name Ihres S3-Buckets.
     • us-east-1: Ihre AWS-Region

   • Für Google Cloud Storage:

     WATCHER_LOG_DST_DIR: "gs://your-company/okera/ops/"
     WATCHER_AUDIT_LOG_DST_DIR: "gs://your-company/okera/audit/"
     WATCHER_AUDIT_UPLOAD_INTERVAL_SEC: "15"
     

     Ersetzen Sie Folgendes:

     • your-company: Name Ihres GCS-Buckets

   • Für Azure Data Lake Storage Gen2:

     WATCHER_LOG_DST_DIR: "abfs://[e-mail]/"
     WATCHER_AUDIT_LOG_DST_DIR: "abfs://[e-mail]/"
     WATCHER_AUDIT_UPLOAD_INTERVAL_SEC: "15"
     

     Ersetzen Sie Folgendes:

     • yourstorageaccount: Name Ihres Azure Storage-Kontos
     • okera-ops und okera-audit: Ihre Containernamen

4. Speichern Sie die Konfigurationsdatei.

5. Aktualisieren Sie den Okera-Cluster mit dem Helm-Diagramm:

   helm upgrade okera okera/okera -f your-config.yaml
   

6. Prüfen Sie, ob die Audit-Logs an den konfigurierten Speicherort geschrieben werden:

   • Für S3:

     aws s3 ls s3://your-company/okera/audit/
     

   • Für GCS:

     gsutil ls gs://your-company/okera/audit/
     

   • Für Azure:

     az storage blob list --account-name yourstorageaccount --container-name okera-audit
     

Hinweis: Die Audit-Logs werden als JSON-Textdateien geschrieben, die nach Datum partitioniert sind. Jede Datei enthält durch Zeilenumbrüche getrennte JSON-Einträge für Audit-Ereignisse.

Audit-Logformat

Okera-Audit-Logs werden im JSON-Format mit den folgenden Merkmalen geschrieben:

• Jede Datei enthält mehrere JSON-Datensätze, einen pro Zeile (NDJSON-Format).
• Die Einträge umfassen alle Datenzugriffsereignisse, Richtlinienänderungen und Administratoraktionen.
• Dateien werden am Speicherort nach Datum sortiert
• Das Dataset okera_system.audit_logs bietet eine abfragbare Ansicht der Auditdaten.

Cloud Storage-Zugriff für Google SecOps konfigurieren

Folgen Sie der entsprechenden Anleitung für Ihre Cloud-Speicherplattform:

Für Amazon S3

1. Erstellen Sie einen IAM-Nutzer mit Lesezugriff auf den S3-Bucket, der Okera-Audit-Logs enthält.
2. Folgen Sie der Anleitung im AWS S3-Konfigurationsleitfaden, um Folgendes zu tun:
   • IAM-Nutzer erstellen
   • Zugriffsschlüssel generieren
   • Gewähren Sie AmazonS3ReadOnlyAccess oder eine benutzerdefinierte Richtlinie mit den Berechtigungen s3:GetObject und s3:ListBucket.

Für Google Cloud Storage

1. Rufen Sie die E‑Mail-Adresse des Google SecOps-Dienstkontos ab:

   1. Rufen Sie die Einstellungen > Datenverwaltung > Feeds auf. Wenn Sie eine reine SIEM-Plattform verwenden, rufen Sie die Einstellungen > Feeds auf.
   2. Klicken Sie auf Neuen Feed hinzufügen.
   3. Klicken Sie auf Einzelnen Feed konfigurieren.
   4. Geben Sie einen Namen für den Feed ein (z. B. okera-audit-logs).
   5. Wählen Sie Google Cloud Storage V2 als Quelltyp aus.
   6. Wählen Sie Okera DAP als Protokolltyp aus.
   7. Klicken Sie auf Dienstkonto abrufen.
   8. Kopieren Sie die angezeigte E‑Mail-Adresse des Dienstkontos.

2. Gewähren Sie dem Dienstkonto Zugriff auf Ihren GCS-Bucket:

   1. Rufen Sie in der GCP Console Cloud Storage > Buckets auf.
   2. Klicken Sie auf den Bucket, der die Okera-Audit-Logs enthält.
   3. Wechseln Sie zum Tab Berechtigungen.
   4. Klicken Sie auf Zugriff erlauben.
   5. Fügen Sie unter Hauptkonten hinzufügen die E‑Mail-Adresse des Google SecOps-Dienstkontos ein.
   6. Wählen Sie unter Rollen zuweisen die Option Storage Object Viewer aus.
   7. Klicken Sie auf Speichern.

Für Azure Blob Storage

1. Rufen Sie den Zugriffsschlüssel für das Speicherkonto ab:

   1. Rufen Sie im Azure-Portal Ihr Speicherkonto auf.
   2. Wählen Sie unter Sicherheit + Netzwerk die Option Zugriffsschlüssel aus.
   3. Klicken Sie auf Schlüssel anzeigen.
   4. Kopieren Sie Schlüssel 1 oder Schlüssel 2.

2. Notieren Sie sich den Blob-Dienstendpunkt:

   • Format: https://yourstorageaccount.blob.core.windows.net/

Feed in Google SecOps konfigurieren, um Okera ODAP-Audit-Logs aufzunehmen

Für Amazon S3

1. Rufen Sie die Einstellungen > Datenverwaltung > Feeds auf. Wenn Sie eine reine SIEM-Plattform verwenden, rufen Sie die Einstellungen > Feeds auf.
2. Klicken Sie auf Neuen Feed hinzufügen.
3. Klicken Sie auf Einzelnen Feed konfigurieren.
4. Geben Sie einen eindeutigen Feednamen ein (z. B. okera-audit-s3).
5. Wählen Sie als Quelltyp Amazon S3 V2 aus.
6. Wählen Sie Okera DAP als Protokolltyp aus.
7. Klicken Sie auf Weiter und dann auf Senden.

8. Geben Sie Werte für die folgenden Felder an:

   • S3-URI: s3://your-company/okera/audit/
   • Option zum Löschen der Quelle: Wählen Sie Nie aus (empfohlen, um Audit-Logs beizubehalten).
   • Maximales Dateialter: Dateien einschließen, die in den letzten Tagen geändert wurden (Standardwert: 180 Tage)
   • Zugriffsschlüssel-ID: IAM-Nutzerzugriffsschlüssel mit Lesezugriff auf den S3-Bucket
   • Geheimer Zugriffsschlüssel: Geheimer Schlüssel des IAM-Nutzers
   • Asset-Namespace: Der Asset-Namespace
   • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.

9. Klicken Sie auf Weiter und dann auf Senden.

Für Google Cloud Storage

1. Rufen Sie die Einstellungen > Datenverwaltung > Feeds auf. Wenn Sie eine reine SIEM-Plattform verwenden, rufen Sie die Einstellungen > Feeds auf.
2. Klicken Sie auf Neuen Feed hinzufügen.
3. Klicken Sie auf Einzelnen Feed konfigurieren.
4. Geben Sie einen eindeutigen Feednamen ein (z. B. okera-audit-gcs).
5. Wählen Sie Google Cloud Storage V2 als Quelltyp aus.
6. Wählen Sie Okera DAP als Protokolltyp aus.
7. Klicken Sie auf Weiter.

8. Geben Sie Werte für die folgenden Felder an:

   • Storage-Bucket-URL: gs://your-company/okera/audit/
   • Option zum Löschen der Quelle: Wählen Sie Nie aus (empfohlen, um Audit-Logs beizubehalten).
   • Maximales Dateialter: Dateien einschließen, die in den letzten Tagen geändert wurden (Standardwert: 180 Tage)
   • Asset-Namespace: Der Asset-Namespace
   • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.

9. Klicken Sie auf Weiter und dann auf Senden.

Für Azure Blob Storage

1. Rufen Sie die Einstellungen > Datenverwaltung > Feeds auf. Wenn Sie eine reine SIEM-Plattform verwenden, rufen Sie die Einstellungen > Feeds auf.
2. Klicken Sie auf Neuen Feed hinzufügen.
3. Klicken Sie auf Einzelnen Feed konfigurieren.
4. Geben Sie einen eindeutigen Feednamen ein (z. B. okera-audit-azure).
5. Wählen Sie Microsoft Azure Blob Storage V2 als Quelltyp aus.
6. Wählen Sie Okera DAP als Protokolltyp aus.
7. Klicken Sie auf Weiter.

8. Geben Sie Werte für die folgenden Felder an:

   • Azure-URI: https://yourstorageaccount.blob.core.windows.net/okera-audit/
   • Option zum Löschen der Quelle: Wählen Sie Nie aus (empfohlen, um Audit-Logs beizubehalten).
   • Maximales Dateialter: Dateien einschließen, die in den letzten Tagen geändert wurden (Standardwert: 180 Tage)
   • Geteilter Schlüssel: Der Zugriffsschlüssel für das Speicherkonto
   • Asset-Namespace: Der Asset-Namespace
   • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll.

9. Klicken Sie auf Weiter und dann auf Senden.

Aufnahme von Audit-Logs prüfen

1. Warten Sie 10–15 Minuten, bis die erste Aufnahme abgeschlossen ist.
2. Rufen Sie in Google SecOps die Suche auf.

3. Führen Sie eine Suchanfrage aus, um zu prüfen, ob Okera-Audit-Logs aufgenommen werden:

   metadata.vendor_name = "Okera"
   

4. Prüfen Sie, ob Ereignisse mit aktuellen Zeitstempeln angezeigt werden.

5. Prüfen Sie den Feedstatus:

   1. Rufen Sie die Einstellungen > Datenverwaltung > Feeds auf. Wenn Sie eine reine SIEM-Plattform verwenden, rufen Sie die Einstellungen > Feeds auf.
   2. Suchen Sie Ihren Okera-Audit-Feed.
   3. Prüfen Sie, ob der Status Aktiv ist.
   4. Prüfen Sie den Zeitstempel Letzte erfolgreiche Aufnahme.

Fehlerbehebung

In Google SecOps werden keine Logs angezeigt

• Prüfen, ob Okera Audit-Logs in den konfigurierten Cloud Storage-Speicherort schreibt
• Prüfen Sie, ob der Speicherpfad in der Feedkonfiguration mit der Einstellung WATCHER_AUDIT_LOG_DST_DIR übereinstimmt.
• Prüfen, ob die Cloud Storage-Berechtigungen richtig konfiguriert sind
• Feedstatus auf Fehlermeldungen prüfen

Berechtigungsfehler

• S3: Prüfen Sie, ob der IAM-Nutzer die Berechtigungen s3:GetObject und s3:ListBucket hat.
• GCS: Prüfen Sie, ob das Google SecOps-Dienstkonto die Rolle Storage-Objekt-Betrachter hat.
• Azure: Prüfen Sie, ob der Zugriffsschlüssel für das Speicherkonto korrekt und nicht abgelaufen ist.

Okera schreibt keine Audit-Logs

• Prüfen, ob die WATCHER_AUDIT_LOG_DST_DIR-Konfiguration korrekt ist
• Prüfen Sie, ob der Okera-Cluster Schreibberechtigungen für den Cloud-Speicherort hat.
• Prüfen, ob das Helm-Diagramm-Update erfolgreich angewendet wurde
• Prüfen Sie die Okera-Clusterlogs auf Fehler im Zusammenhang mit Audit-Log-Uploads.

Migration zu Databricks Unity Catalog

Wenn Sie von Okera ODAP zu Databricks Unity Catalog migrieren möchten:

1. Dokumentation zu Audit-Logs für Databricks Unity Catalog lesen
2. Übermittlung von Unity Catalog-Audit-Logs an Cloud Storage konfigurieren
3. Neuen Google SecOps-Feed für Unity Catalog-Audit-Logs erstellen
4. Beide Feeds während der Migrationsphase beibehalten
5. Okera-Feed nach Abschluss der Migration außer Betrieb nehmen

Wenn Sie Unterstützung bei Okera ODAP oder der Migration zu Unity Catalog benötigen, wenden Sie sich an den Databricks-Support.

UDM-Zuordnungstabelle

Logfeld	UDM-Zuordnung	Logik
extensions.auth.type	extensions.auth.type	Authentifizierungstyp
json_entry.request_time	metadata.event_timestamp	Zeitstempel des Ereignisses
metadata.event_type	metadata.event_type	Ereignistyp
json_entry.statement_type	metadata.product_event_type	Produktspezifischer Ereignistyp
metadata.product_name	metadata.product_name	Produktname
metadata.vendor_name	metadata.vendor_name	Name des Anbieters/Unternehmens
json_entry.session_id	network.session_id	Sitzungs-ID
json_entry.connected_user	principal.user.userid	Nutzer-ID
json_entry.auth_failure	security_result.action	Ergriffene Maßnahme
json_entry.status	security_result.summary	Zusammenfassung des Sicherheitsergebnisses
json_entry.client_application	target.application	Name der Anwendung
json_entry.client_network_address	target.ip	IP-Adresse
json_entry.client_network_address	target.port	Portnummer
json_entry.request_id	target.resource.attribute.labels	Schlüssel/Wert-Paare von Attributen für die Ressource
json_entry.num_results_read	target.resource.attribute.labels
json_entry.num_results_returned	target.resource.attribute.labels
json_entry.peak_memory_usage	target.resource.attribute.labels
json_entry.statement	target.resource.attribute.labels
json_entry.bytes_scanned	target.resource.attribute.labels
json_entry.for_reporting	target.resource.attribute.labels
json_entry.auth_failure	target.resource.attribute.labels
json_entry.default_db	target.resource.name	Name der Ressource
target.resource.resource_type	target.resource.resource_type	Ressourcentyp
json_entry.user	target.user.userid	Nutzer-ID

Änderungsprotokoll

Änderungsprotokoll für diesen Parser ansehen

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