IBM DB2-Logs erfassen

Unterstützt in:

Google SecOps SIEM

In diesem Dokument wird beschrieben, wie Sie IBM DB2-Logs mit dem Bindplane-Agent in Google Security Operations aufnehmen.

IBM Db2 ist ein relationales Datenbankverwaltungssystem, das eine Auditfunktion bietet, um unbekannte oder unerwartete Zugriffe auf Daten zu erkennen. Die Db2-Audit-Funktion generiert und ermöglicht die Verwaltung eines Audit-Trails für eine Reihe vordefinierter Datenbankereignisse.

Hinweis

Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:

• Eine Google SecOps-Instanz
• Windows Server 2016 oder höher oder Linux-Host mit systemd
• Netzwerkverbindung zwischen Bindplane-Agent und IBM DB2-Instanz
• Wenn der Agent hinter einem Proxy ausgeführt wird, müssen die Firewallports gemäß den Anforderungen des Bindplane-Agents geöffnet sein.
• IBM Db2-Instanz (Version 11.1 oder höher) mit SYSADM-Berechtigungen
• Ausreichend Speicherplatz für die Speicherung und Archivierung von Audit-Logs

Google SecOps-Anmeldedaten für den Bindplane-Agenten abrufen

Wählen Sie eine der folgenden Methoden aus, um den Bindplane-Agenten bei Google SecOps zu authentifizieren:

• Neue Bereitstellungen: Verwenden Sie die Chronicle API (Option 1).
• Alte Bereitstellungen: Verwenden Sie die Datei für die Authentifizierung bei der Aufnahme (Option 2) weiterhin, bis die Ingestion API am 20. Juli 2027 eingestellt wird.

Option 1: Dienstkonto für die Chronicle API erstellen (empfohlen)

1. 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.
2. Rufen Sie IAM und Verwaltung > Dienstkonten auf.
3. Klicken Sie auf Dienstkonto erstellen.
4. Geben Sie die folgenden Konfigurationsdetails an:
   • Name des Dienstkontos: Geben Sie einen Namen für das Konto ein, z. B. bindplane-ingest.
   • Dienstkontobeschreibung: Geben Sie eine Beschreibung ein (z. B. Bindplane agent log ingestion).
5. Klicken Sie auf Erstellen und fortfahren.
6. Klicken Sie im Abschnitt Diesem Dienstkonto Zugriff auf das Projekt erteilen auf Rolle auswählen und wählen Sie Chronicle Editor aus.
7. Klicken Sie auf Weiter und dann auf Fertig.
8. Klicken Sie auf das erstellte Dienstkonto und rufen Sie dann den Tab Schlüssel auf.
9. Klicken Sie auf Schlüssel hinzufügen > Neuen Schlüssel erstellen.
10. Wählen Sie JSON aus und klicken Sie auf Erstellen. Die Schlüsseldatei wird auf Ihren Computer heruntergeladen.
11. Speichern Sie die Schlüsseldatei als ingestion-auth.json im Bindplane-Collector-Verzeichnis (/opt/observiq-otel-collector/ingestion-auth.json unter Linux oder C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json unter Windows) oder aktualisieren Sie creds_file_path in config.yaml, damit der Pfad mit dem Pfad übereinstimmt, in dem Sie die Datei speichern.
12. Rufen Sie IAM & Verwaltung > Einstellungen auf und kopieren Sie die Projektnummer. Sie benötigen sie für die Exporter-Konfiguration.

Hinweis: Der JSON-Schlüssel ist ein Berechtigungsnachweis. Beschränken Sie den Zugriff auf die Datei auf dem Bindplane-Host und rotieren Sie den Schlüssel gemäß den Richtlinien Ihrer Organisation.

Option 2: Authentifizierungsdatei für die Datenaufnahme herunterladen (Legacy)

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Rufen Sie die SIEM-Einstellungen > Erfassungs-Agents auf.
3. Laden Sie die Authentifizierungsdatei für die Aufnahme herunter.
4. Speichern Sie die Datei sicher auf dem System, auf dem der Bindplane-Agent installiert werden soll.

Hinweis: Mit dieser Datei wird der Agent bei der Legacy Ingestion API (malachiteingestion-pa.googleapis.com) authentifiziert, die Google am 20. Juli 2027 einstellen wird. Planen Sie, vor diesem Datum zu Option 1 zu wechseln.

Google SecOps-Kundennummer abrufen

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Rufen Sie die SIEM-Einstellungen > Profil auf.

3. Kopieren und speichern Sie die Kundennummer aus dem Bereich Organisationsdetails.

   Hinweis: Der customer ID ist für die Konfiguration des Bindplane-Agent-Exporters erforderlich.

BindPlane-Agent installieren

Installieren Sie den Bindplane-Agent auf Ihrem Windows- oder Linux-Betriebssystem gemäß der folgenden Anleitung.

Windows-Installation

1. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.

2. Führen Sie dazu diesen Befehl aus:

   msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
   

3. Warte, bis die Installation abgeschlossen ist.

4. Überprüfen Sie die Installation mit folgendem Befehl:

   sc query observiq-otel-collector
   

   Der Dienst sollte als RUNNING (WIRD AUSGEFÜHRT) angezeigt werden.

Linux-Installation

1. Öffnen Sie ein Terminal mit Root- oder Sudo-Berechtigungen.

2. Führen Sie dazu diesen Befehl aus:

   sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
   

3. Warte, bis die Installation abgeschlossen ist.

4. Überprüfen Sie die Installation mit folgendem Befehl:

   sudo systemctl status observiq-otel-collector
   

   Der Dienst sollte als active (running) angezeigt werden.

Zusätzliche Installationsressourcen

Weitere Installationsoptionen und Informationen zur Fehlerbehebung finden Sie im Installationsanleitung für den Bindplane-Agenten.

Hinweis: Für die Konfiguration des Chronicle API-Exporters ist Bindplane Collector v1.106.0 oder höher erforderlich. Mit den vorherigen Befehlen wird der neueste Release installiert. Wenn Sie eine vorhandene Installation aktualisieren, aktualisieren Sie den Collector, bevor Sie die Konfiguration ändern.

Bindplane-Agent zum Erfassen von Syslog-Daten und Senden an Google SecOps konfigurieren

Konfigurationsdatei suchen

• Linux:

  sudo nano /opt/observiq-otel-collector/config.yaml
  

• Windows:

  notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"
  

Konfigurationsdatei bearbeiten

1. Ersetzen Sie den gesamten Inhalt von config.yaml durch die folgende Konfiguration:

   receivers:
     tcplog:
       listen_address: "0.0.0.0:1514"
   
   exporters:
     chronicle/db2_audit:
       protocol: https
       # Region of your instance, for example us, europe, asia-southeast1
       location: <LOCATION>
       # Project number of the Google Cloud project linked to the instance
       project: '<PROJECT_NUMBER>'
       compression: gzip
       creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json'
       customer_id: 'YOUR_CUSTOMER_ID'
       endpoint: chronicle.googleapis.com
       log_type: DB2_DB
       raw_log_field: body
       ingestion_labels:
         env: production
   
   service:
     pipelines:
       logs/db2_to_chronicle:
         receivers:
           - tcplog
         exporters:
           - chronicle/db2_audit
   

2. Ersetzen Sie die folgenden Platzhalter:

   • Empfängerkonfiguration:

     • listen_address: Auf 0.0.0.0:1514 setzen, um auf allen Schnittstellen auf Port 1514 zu lauschen (nicht privilegierter Port, der für Linux empfohlen wird).

   • Exporter-Konfiguration:

     • creds_file_path: Vollständiger Pfad zur JSON-Schlüsseldatei des Dienstkontos (Option 1):

       • Linux: /opt/observiq-otel-collector/ingestion-auth.json
       • Windows: C:\\Program Files\\observIQ OpenTelemetry Collector\\ingestion-auth.json

     • customer_id: Kundennummer aus dem vorherigen Schritt

     • location: Ersetzen Sie <LOCATION> durch die Region Ihrer Google SecOps-Instanz (z. B. us, europe oder asia-southeast1). Der Exporteur stellt diesem Wert das Präfix chronicle.googleapis.com voran. Eine vollständige Liste finden Sie unter Regionale Endpunkte.

     • project: Ersetzen Sie <PROJECT_NUMBER> durch die Projektnummer unter IAM & Verwaltung > Einstellungen.

     • endpoint: Behalten Sie die Einstellung chronicle.googleapis.com bei.

     • log_type: Auf DB2_DB festlegen

     • ingestion_labels: Optionale Labels im YAML-Format (z. B. env: production)

Exporter für die Legacy Ingestion API

• Wenn Sie die Authentifizierungsdatei für die Datenaufnahme aus Option 2 verwenden, ersetzen Sie den Block exporters durch Folgendes. Legen Sie für creds_file_path den Pfad zur Authentifizierungsdatei für die Datenaufnahme fest. Wenn sich Ihre Instanz außerhalb der USA befindet, ersetzen Sie malachiteingestion-pa.googleapis.com durch Ihren regionalen Endpunkt (z. B. europe-malachiteingestion-pa.googleapis.com).

  exporters:
    chronicle/db2_audit:
      compression: gzip
      creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json'
      customer_id: 'YOUR_CUSTOMER_ID'
      endpoint: malachiteingestion-pa.googleapis.com
      log_type: DB2_DB
      raw_log_field: body
      ingestion_labels:
        env: production
  

Hinweis: Dieser Exporter funktioniert nicht mehr, wenn die Ingestion API am 20. Juli 2027 eingestellt wird.

Konfigurationsdatei speichern

• Speichern Sie die Datei nach der Bearbeitung:

  • Linux: Drücken Sie Ctrl+O, dann Enter und dann Ctrl+X.
  • Windows: Klicken Sie auf Datei > Speichern.

Bindplane-Agent neu starten, um die Änderungen zu übernehmen

• Linux

  sudo systemctl restart observiq-otel-collector
  

  1. Prüfen Sie, ob der Dienst ausgeführt wird:

     sudo systemctl status observiq-otel-collector
     

  2. Prüfen Sie die Logs auf Fehler:

     sudo journalctl -u observiq-otel-collector -f
     

• Windows

  Wählen Sie eine der folgenden Optionen aus:

  • Über die Eingabeaufforderung oder PowerShell als Administrator:

    net stop observiq-otel-collector && net start observiq-otel-collector
    

  • Services Console verwenden:

    1. Drücken Sie Win+R, geben Sie services.msc ein und drücken Sie die Eingabetaste.
    2. Suchen Sie nach observIQ OpenTelemetry Collector.
    3. Klicken Sie mit der rechten Maustaste und wählen Sie Neu starten aus.

    4. Prüfen Sie, ob der Dienst ausgeführt wird:

       sc query observiq-otel-collector
       

    5. Logs auf Fehler prüfen:

       type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
       

IBM DB2-Prüffunktion konfigurieren

Konfigurieren Sie die DB2-Prüffunktion, um Sicherheitsereignisse zu erfassen und in Syslog zu extrahieren.

Aktuelle Konfiguration der Prüfung prüfen

• Stellen Sie als Nutzer mit SYSADM-Berechtigung eine Verbindung zu Ihrer DB2-Instanz her und führen Sie folgenden Befehl aus:

  db2audit describe
  

  Hier wird die aktuelle Audit-Konfiguration angezeigt, einschließlich Audit-Status, Kategorien und Pfaden.

Prüfpfade konfigurieren

1. Legen Sie die Verzeichnisse fest, in denen Audit-Logs gespeichert werden:

   db2audit configure datapath /db2audit/data
   db2audit configure archivepath /db2audit/archive
   

2. Prüfen Sie, ob diese Verzeichnisse vorhanden sind und der DB2-Instanzinhaber die entsprechenden Berechtigungen hat:

   mkdir -p /db2audit/data /db2audit/archive
   chown db2inst1:db2iadm1 /db2audit/data /db2audit/archive
   chmod 750 /db2audit/data /db2audit/archive
   

Prüfungsumfang und ‑kategorien konfigurieren

• Konfigurieren Sie die Prüffunktion so, dass alle Sicherheitsereignisse erfasst werden:

  db2audit configure scope all status both errortype normal
  

  Damit wird Folgendes konfiguriert:

  • scope all: Prüft alle Kategorien (audit, checking, objmaint, secmaint, sysadmin, validate, context).
  • status both: Erfasst sowohl erfolgreiche als auch fehlgeschlagene Ereignisse.
  • errortype normal: Standardfehlerbehandlung

Prüffunktion starten

1. So starten Sie die Prüfung:

   db2audit start
   

2. Prüfen Sie, ob die Prüfung aktiv ist:

   db2audit describe
   

   Die Ausgabe sollte Audit active: "TRUE" enthalten.

Syslog für den Empfang von DB2-Audit-Logs konfigurieren

Konfigurieren Sie den Syslog-Daemon des Systems so, dass er DB2-Audit-Nachrichten empfängt und speichert.

Linux (rsyslog)

1. Bearbeiten Sie die rsyslog-Konfigurationsdatei:

   sudo nano /etc/rsyslog.conf
   

2. Fügen Sie die folgende Zeile hinzu, um DB2-Audit-Nachrichten an eine bestimmte Datei weiterzuleiten:

   user.info /var/log/db2/db2audit.log
   

3. Erstellen Sie das Logverzeichnis und die Logdatei:

   sudo mkdir -p /var/log/db2
   sudo touch /var/log/db2/db2audit.log
   sudo chmod 640 /var/log/db2/db2audit.log
   

4. Starten Sie rsyslog neu:

   sudo systemctl restart rsyslog
   

AIX (syslogd)

1. Bearbeiten Sie die Syslog-Konfigurationsdatei:

   sudo vi /etc/syslog.conf
   

2. Fügen Sie folgende Zeile hinzu:

   user.info /var/log/db2/db2audit.log
   

3. Erstellen Sie das Logverzeichnis und die Logdatei:

   sudo mkdir -p /var/log/db2
   sudo touch /var/log/db2/db2audit.log
   sudo chmod 640 /var/log/db2/db2audit.log
   

4. Starten Sie syslogd neu:

   sudo refresh -s syslogd
   

DB2-Audit-Logs in Syslog extrahieren

Archivierte Audit-Logs extrahieren und an den Syslog-Daemon des Systems senden.

Audit-Logs leeren und archivieren

• Leeren Sie vor der Extraktion alle ausstehenden Audit-Einträge und archivieren Sie das aktuelle Audit-Log:

  db2audit flush
  db2audit archive
  

  Mit dem Archivierungsbefehl werden zeitgestempelte Dateien im Archivierungspfad erstellt (z. B. db2audit.instance.log.0.20250110123456).

Audit-Logs in Syslog extrahieren

• Extrahieren Sie die archivierten Audit-Logs und senden Sie sie mit der Einrichtung und Priorität user.info an Syslog:

  db2audit extract syslog user.info from files /db2audit/archive/db2audit.instance.log.0.*
  

  Dieser Befehl:

  • Extrahiert Audit-Einträge aus den archivierten Logdateien
  • Sendet sie mit der Einrichtung user und der Priorität info an den Syslog-Daemon des Systems.
  • Der Syslog-Daemon leitet die Nachrichten gemäß /etc/syslog.conf oder /etc/rsyslog.conf weiter.

Prüfen, ob Logs gesendet werden

• Prüfen Sie, ob Audit-Nachrichten in die Syslog-Datei geschrieben werden:

  tail -f /var/log/db2/db2audit.log
  

  In der Logdatei sollten DB2-Audit-Einträge angezeigt werden.

rsyslog so konfigurieren, dass Logs an den Bindplane-Agenten weitergeleitet werden

Konfigurieren Sie rsyslog so, dass DB2-Audit-Logs an den Bindplane-Agenten weitergeleitet werden.

1. Erstellen Sie eine neue rsyslog-Konfigurationsdatei:

   sudo nano /etc/rsyslog.d/50-db2-forward.conf
   

2. Fügen Sie die folgende Konfiguration hinzu, um Logs an den Bindplane-Agenten weiterzuleiten:

   # Forward DB2 audit logs to Bindplane agent
   user.info @@127.0.0.1:1514
   

   Das Präfix @@ gibt die TCP-Weiterleitung an. Verwenden Sie bei Bedarf @ für UDP.

3. Starten Sie rsyslog neu:

   sudo systemctl restart rsyslog
   

Audit-Log-Extraktion automatisieren

Erstellen Sie ein Skript, um das Leeren, Archivieren und Extrahieren zu automatisieren.

Extraktionsskript erstellen

1. Erstellen Sie ein Skript, um die Extraktion von Audit-Logs zu automatisieren:

   sudo nano /usr/local/bin/db2audit-extract.sh
   

2. Fügen Sie den folgenden Inhalt hinzu:

   #!/bin/bash
   # DB2 Audit Log Extraction Script
   
   # Set DB2 environment
   export DB2INSTANCE=db2inst1
   . /home/db2inst1/sqllib/db2profile
   
   # Flush pending audit records
   db2audit flush
   
   # Archive current audit log
   db2audit archive
   
   # Extract archived logs to syslog
   db2audit extract syslog user.info from files /db2audit/archive/db2audit.instance.log.0.*
   
   # Optional: Clean up old archived logs (older than 30 days)
   find /db2audit/archive -name "db2audit.instance.log.0.*" -mtime +30 -delete
   
   exit 0
   

3. Machen Sie das Skript ausführbar:

   sudo chmod +x /usr/local/bin/db2audit-extract.sh
   

Mit Cron planen

1. Planen Sie die regelmäßige Ausführung des Skripts mit cron:

   sudo crontab -e
   

2. Fügen Sie die folgende Zeile hinzu, um das Skript stündlich auszuführen:

   Wählen Sie eine der folgenden Optionen aus:

   0 * * * * /usr/local/bin/db2audit-extract.sh >> /var/log/db2/db2audit-extract.log 2>&1
   

   Oder führen Sie den Befehl alle 15 Minuten aus, um die Daten häufiger zu extrahieren:

   */15 * * * * /usr/local/bin/db2audit-extract.sh >> /var/log/db2/db2audit-extract.log 2>&1
   

Logaufnahme in Google SecOps prüfen

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Gehen Sie zu Suchen.

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

   metadata.log_type = "DB2_DB"
   

4. Prüfen Sie, ob die Logs mit dem richtigen Zeitstempel und den richtigen Feldern angezeigt werden.

   Hinweis: Nach der Erstkonfiguration kann es 5 bis 10 Minuten dauern, bis Logs in Google SecOps angezeigt werden.

UDM-Zuordnungstabelle

Logfeld	UDM-Zuordnung	Logik
msg	event.idm.read_only_udm.additional.fields	Wert aus „msg“, wenn „msg“ != „“
System	event.idm.read_only_udm.additional.fields	Wert wird aus dem System übernommen, wenn System != „“
Subsystem	event.idm.read_only_udm.additional.fields	Wert wird aus dem Subsystem übernommen, wenn Subsystem != „“
auth_mechanism	event.idm.read_only_udm.extensions.auth.mechanism	Für USER_LOGIN-Ereignisse auf „USERNAME_PASSWORD“ festgelegt
CorrelationUser	event.idm.read_only_udm.intermediary.user.userid	Wert aus CorrelationUser, wenn CorrelationUser != „“
Summe	event.idm.read_only_udm.metadata.description	Wert aus Summe
date_time	event.idm.read_only_udm.metadata.event_timestamp	Konvertiert aus Datums- und Uhrzeitfeldern in das ISO8601-Format, wenn beide != "" sind
leef_event_id	event.idm.read_only_udm.metadata.product_event_type	Wert aus „leef_event_id“
	event.idm.read_only_udm.metadata.event_type	Abgeleitet von leef_event_id: wenn in ["102-87", "102-83"] → USER_LOGIN; wenn in ["102-6", "102-7", "102-8", "102-10", "102-24", "102-143"] → USER_RESOURCE_ACCESS oder USER_RESOURCE_UPDATE_CONTENT basierend auf der Absicht; wenn "102-319" → USER_RESOURCE_ACCESS; andernfalls GENERIC_EVENT
	event.idm.read_only_udm.metadata.product_name	Auf „DB2“ festgelegt
	event.idm.read_only_udm.metadata.vendor_name	Auf „IBM“ festgelegt
SSID	event.idm.read_only_udm.network.session_id	Wert wird aus SSID übernommen, wenn SSID != „“
Job	event.idm.read_only_udm.principal.application	Wert wird aus dem Job übernommen, wenn job != ""
sourceServiceName	event.idm.read_only_udm.principal.application	Wert aus „sourceServiceName“
sourceHostName	event.idm.read_only_udm.principal.asset.hostname	Wert wird aus sourceHostName übernommen, wenn sourceHostName != „“
principal_ip	event.idm.read_only_udm.principal.asset.ip	Wert aus „principal_ip“ für Ereignisse vom Typ 102–319
product_id	event.idm.read_only_udm.principal.asset_id	Für Ereignisse vom Typ 102 bis 319 auf „Produkt-ID: %{product_id}“ festgelegt
sourceHostName	event.idm.read_only_udm.principal.hostname	Wert wird aus sourceHostName übernommen, wenn sourceHostName != „“
principal_ip	event.idm.read_only_udm.principal.ip	Wert aus „principal_ip“ für 102-319-Ereignisse
Ersteller	event.idm.read_only_udm.principal.user.user_display_name	Wert vom Creator übernommen
Name	event.idm.read_only_udm.principal.user.user_display_name	Wert wird aus dem Namen übernommen, wenn der Name nicht „“ ist
AuthenticatedUser	event.idm.read_only_udm.principal.user.userid	Wert wird aus AuthenticatedUser übernommen, wenn AuthenticatedUser != ""
sourceUserName	event.idm.read_only_udm.principal.user.userid	Wert aus „sourceUserName“
usrName	event.idm.read_only_udm.principal.user.userid	Wert aus usrName
_action	event.idm.read_only_udm.security_result.action	Abgeleitet von der Summe: Wenn „successful“ enthalten ist → ALLOW; andernfalls BLOCK für USER_LOGIN-Ereignisse
deviceHostName	event.idm.read_only_udm.target.asset.hostname	Wert aus deviceHostName
conn_location3	event.idm.read_only_udm.target.asset.hostname	Wert aus conn_location3, wenn conn_location3 != „“
file_name	event.idm.read_only_udm.target.file.full_path	Wert aus „file_name“, wenn „file_name“ != „“
deviceHostName	event.idm.read_only_udm.target.hostname	Wert aus deviceHostName
conn_location3	event.idm.read_only_udm.target.hostname	Wert aus conn_location3, wenn conn_location3 != „“
conn_location, conn_location2	event.idm.read_only_udm.target.location.name	Verkettung von conn_location und conn_location2, wenn beide != „“
deviceProcessName	event.idm.read_only_udm.target.process.command_line	Wert aus „deviceProcessName“
SQL	event.idm.read_only_udm.target.process.command_line	Wert aus SQL, wenn SQL != „“
Connection_Type	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Connection Type“ mit Wert aus Connection_Type
Planen	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Plan“ mit Wert aus Plan
DB2_Subsystem	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „DB2 Subsystem“ mit Wert aus DB2_Subsystem
Priv_Check_Code	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Priv Check Code“ mit Wert aus Priv_Check_Code
Table_Name	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Table Name“ mit Wert aus Table_Name
MessageType	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Message Type“ mit Wert aus MessageType
Check_type	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Check Type“ mit Wert aus Check_type
deviceAction	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Device Action“ mit Wert, der von deviceAction zugeordnet wird: G → GRANT, R → REVOKE
SSID	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „SSID“ mit Wert aus SSID, wenn Wert != „“
SQL	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „SQL-Abfrage“ mit Wert aus SQL, wenn SQL != „“
messageid	event.idm.read_only_udm.target.resource.id	Wert aus „messageid“
Object_Class_Code	event.idm.read_only_udm.target.resource.parent	Wert aus Object_Class_Code
obj	event.idm.read_only_udm.target.resource.name	Wert aus „obj“
ressource_name	event.idm.read_only_udm.target.resource.name	Wert aus resource_name, der aus SQL extrahiert wurde, wenn SQL != „“ und nicht leer ist
Database_Name	event.idm.read_only_udm.target.resource.name	Wert aus „Database_Name“ übernommen
objtyp	event.idm.read_only_udm.target.resource.resource_subtype	Wert aus objtyp (Großbuchstaben), wenn objtyp != ""
Typ	event.idm.read_only_udm.target.resource.resource_subtype	Abgeleitet von Typ: T → TABLE, V → VIEW, X → AUXILIARY TABLE
	event.idm.read_only_udm.target.resource.resource_type	Auf „DATABASE“ festgelegt
principal_hostname	event.idm.read_only_udm.principal.asset.hostname und event.idm.read_only_udm.principal.hostname	Aus Änderungsprotokoll zugeordnet
category	event.idm.read_only_udm.security_result.category_details	Aus Änderungsprotokoll zugeordnet
audit event	event.idm.read_only_udm.metadata.product_event_type	Aus Änderungsprotokoll zugeordnet
event correlator	event.idm.read_only_udm.metadata.product_log_id	Aus Änderungsprotokoll zugeordnet
instance name	event.idm.read_only_udm.target.resource.name	Aus Änderungsprotokoll zugeordnet
application name	event.idm.read_only_udm.principal.application	Aus Änderungsprotokoll zugeordnet
archive path	event.idm.read_only_udm.target.file.full_path	Aus Änderungsprotokoll zugeordnet
execution id	event.idm.read_only_udm.principal.resource.attribute.labels	Aus Änderungsprotokoll zugeordnet
application id	event.idm.read_only_udm.principal.resource.attribute.labels	Aus Änderungsprotokoll zugeordnet
authid	event.idm.read_only_udm.principal.resource.attribute.labels	Aus Änderungsprotokoll zugeordnet
event status	event.idm.read_only_udm.security_result.detection_fields	Aus Änderungsprotokoll zugeordnet
access attempted	event.idm.read_only_udm.security_result.detection_fields	Aus Änderungsprotokoll zugeordnet
access_approval_reason	event.idm.read_only_udm.security_result.detection_fields	Aus Änderungsprotokoll zugeordnet
timestamp_1	event.idm.read_only_udm.additional.fields	Aus Änderungsprotokoll zugeordnet
object type	event.idm.read_only_udm.additional.fields	Aus Änderungsprotokoll zugeordnet
plugin name	event.idm.read_only_udm.additional.fields	Aus Änderungsprotokoll zugeordnet
auth type	event.idm.read_only_udm.additional.fields	Aus Änderungsprotokoll zugeordnet
System" and "Subsystem	additional.fields	Aus Änderungsprotokoll zugeordnet
ConnectionType	principal.process.pid	Aus Änderungsprotokoll zugeordnet
plan	principal.resource.name	Aus Änderungsprotokoll zugeordnet
SQL	principal.process.command_line	Aus Änderungsprotokoll zugeordnet

Änderungsprotokoll

Änderungsprotokoll für diesen Parser ansehen

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