Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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 dem Bindplane-Agent und der 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

Authentifizierungsdatei für die Google SecOps-Datenaufnahme abrufen

Melden Sie sich in der Google SecOps-Konsole an.
Rufen Sie die SIEM-Einstellungen > Collection Agent auf.
Klicken Sie auf Herunterladen, um die Datei zur Authentifizierung der Aufnahme herunterzuladen.
Speichern Sie die Datei sicher auf dem System, auf dem der Bindplane-Agent installiert wird.

Hinweis: Diese JSON-Datei enthält Anmeldedaten für die Authentifizierung des Bindplane-Agents bei Google SecOps.

Google SecOps-Kundennummer abrufen

Melden Sie sich in der Google SecOps-Konsole an.
Rufen Sie die SIEM-Einstellungen > Profile auf.
Kopieren und speichern Sie die Kundennummer aus dem Bereich Organization Details (Organisationsdetails).

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

BindPlane-Agent installieren

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

Windows-Installation

Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.

Führen Sie dazu diesen Befehl aus:

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

Warte, bis die Installation abgeschlossen ist.
Überprüfen Sie die Installation mit folgendem Befehl:
```
sc query observiq-otel-collector
```
Der Dienst sollte als RUNNING angezeigt werden.

Linux-Installation

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

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

Warte, bis die Installation abgeschlossen ist.
Ü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 Installationsleitfaden für den Bindplane-Agent.

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

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:
    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

service:
  pipelines:
    logs/db2_to_chronicle:
      receivers:
        - tcplog
      exporters:
        - chronicle/db2_audit

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 Authentifizierungsdatei für die Datenaufnahme:
    - Linux: /opt/observiq-otel-collector/ingestion-auth.json
    - Windows: C:\\Program Files\\observIQ OpenTelemetry Collector\\ingestion-auth.json
  - customer_id: Kunden-ID aus dem vorherigen Schritt
  - endpoint: Regionale Endpunkt-URL:
    - USA: malachiteingestion-pa.googleapis.com
    - Europa: europe-malachiteingestion-pa.googleapis.com
    - Asien: asia-southeast1-malachiteingestion-pa.googleapis.com
    - Eine vollständige Liste finden Sie unter Regionale Endpunkte.
  - log_type: Auf DB2_DB festlegen
  - ingestion_labels: Optionale Labels im YAML-Format (z. B. env: production)

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.

Starten Sie den Bindplane-Agent neu, um die Änderungen zu übernehmen.

Linux

sudo systemctl restart observiq-otel-collector

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

sudo systemctl status observiq-otel-collector

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. Rechtsklicken Sie 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 so, dass Sicherheitsereignisse erfasst und in Syslog extrahiert werden.

Aktuelle Audit-Konfiguration prüfen

Stellen Sie als Nutzer mit SYSADM-Berechtigung eine Verbindung zu Ihrer DB2-Instanz her und führen Sie Folgendes aus:
```
db2audit describe
```
Hier wird die aktuelle Audit-Konfiguration angezeigt, einschließlich Audit-Status, Kategorien und Pfaden.

Prüfpfade konfigurieren

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

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

Prüfen Sie, ob diese Verzeichnisse vorhanden sind und die entsprechenden Berechtigungen für den Inhaber der DB2-Instanz haben:

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

Prüfbereich und ‑kategorien konfigurieren

Konfigurieren Sie die Audit-Einrichtung so, dass alle sicherheitsrelevanten Ereignisse 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

So starten Sie die Prüfung:
```
db2audit start
```
Prüfen, 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)

Bearbeiten Sie die rsyslog-Konfigurationsdatei:
```
sudo nano /etc/rsyslog.conf
```
Fügen Sie die folgende Zeile hinzu, um DB2-Audit-Nachrichten an eine dedizierte Datei weiterzuleiten:
```
user.info /var/log/db2/db2audit.log
```

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

Starten Sie rsyslog neu:
```
sudo systemctl restart rsyslog
```

AIX (syslogd)

Bearbeiten Sie die Syslog-Konfigurationsdatei:
```
sudo vi /etc/syslog.conf
```
Fügen Sie folgende Zeile hinzu:
```
user.info /var/log/db2/db2audit.log
```

Erstellen Sie das Log-Verzeichnis und die Log-Datei:

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

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

Spülen Sie vor dem Extrahieren alle ausstehenden Audit-Datensätze 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 an den Syslog-Daemon des Systems mit der Einrichtung user und der Priorität info.
- 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-Prüfdatensätze 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.

Erstellen Sie eine neue rsyslog-Konfigurationsdatei:
```
sudo nano /etc/rsyslog.d/50-db2-forward.conf
```
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.
Starten Sie rsyslog neu:
```
sudo systemctl restart rsyslog
```

Extrahieren von Audit-Logs automatisieren

Skript zur Automatisierung des Prozesses zum Leeren, Archivieren und Extrahieren erstellen

Extraktionsskript erstellen

So erstellen Sie ein Skript zum automatischen Extrahieren von Audit-Logs:
```
sudo nano /usr/local/bin/db2audit-extract.sh
```

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

Machen Sie das Skript ausführbar:

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

Mit Cron planen

Planen Sie die regelmäßige Ausführung des Skripts mit cron:
```
sudo crontab -e
```
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

Melden Sie sich in der Google SecOps-Konsole an.
Rufen Sie die Suche auf.
Führen Sie eine Suchanfrage aus, um zu prüfen, ob DB2-Logs aufgenommen werden:
```
metadata.log_type = "DB2_DB"
```
Prüfen Sie, ob 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 aus dem Subsystem, 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 von Datums- und Zeitfeldern in das ISO8601-Format, wenn beide != ""
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; sonst 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 aus SSID, wenn SSID != „“
Job	event.idm.read_only_udm.principal.application	Wert aus dem Job, 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–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	Vom Creator übernommener Wert
Name	event.idm.read_only_udm.principal.user.user_display_name	Wert wird aus dem Namen übernommen, wenn name != „“
AuthenticatedUser	event.idm.read_only_udm.principal.user.userid	Wert wird von 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 aus 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“ extrahiert aus SQL, wenn SQL != „“ und nicht leer
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 (in 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 dem Ä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 dem Änderungsprotokoll zugeordnet

Änderungsprotokoll

Änderungsprotokoll für diesen Parser ansehen

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