06 - Ziel-Konfiguration (Destinations)

Revisionshistorie

Inhaltsverzeichnis

1. Ueberblick
2. HEC Destination
   1. Konfiguration
   2. Token-Management
   3. TLS-Absicherung
   4. Kompression
3. S2S Destination
   1. Konfiguration
   2. Natives Splunk-Protokoll
4. Persistent Queue
   1. Konzept
   2. Sizing
   3. Backpressure-Handling
5. Protokollvergleich: HEC vs. S2S
6. Failover-Strategie
7. Verifikation der Ziele

1. Ueberblick

Im IceDataEmphasise-PoC werden zwei Ziel-Typen (Destinations) konfiguriert, um Daten von Cribl Stream an die Splunk-Infrastruktur der Bank zu liefern:

• Splunk HEC (HTTP Event Collector) – HTTPS-basiert, Token-authentifiziert, ideal fuer Web- und IoT-Daten
• Splunk S2S (Splunk-to-Splunk) – Natives Splunk-Protokoll (TCP 9997), ideal fuer sicherheitsrelevante Daten

Beide Ziele verfuegen ueber Persistent Queues (PQ) als Puffer bei voruebergehender Nichterreichbarkeit des Splunk-Indexers, was den regulatorischen Anforderungen an Datenverlustfreiheit (MaRisk AT 7.2) entspricht.

2. HEC Destination

2.1 Konfiguration

Die HEC-Destination ist in configs/stream/destinations/splunk-hec.json definiert:

{
  "id": "splunk_hec",
  "type": "splunk_hec",
  "url": "http://${SPLUNK_HOST}:${SPLUNK_HEC_PORT}/services/collector",
  "token": "${SPLUNK_HEC_TOKEN}",
  "nestedFields": "none",
  "concurrency": 5,
  "maxPayloadSizeKB": 4096,
  "compress": true,
  "rejectUnauthorized": false,
  "onBackpressure": "block",
  "description": "Splunk HEC - HTTP Event Collector"
}

# HTTP testen
curl -s "http://${SPLUNK_HOST}:8088/services/collector/health"
# HTTPS testen
curl -sk "https://${SPLUNK_HOST}:8088/services/collector/health"

2.2 Token-Management

Das HEC-Token wird niemals im Klartext in der Konfiguration oder im Git-Repository gespeichert. Die Verwaltung erfolgt ueber folgendes Konzept:

1. Das Token wird in Splunk unter Settings → Data Inputs → HTTP Event Collector erzeugt.
2. Das Token wird in der .env-Datei auf dem Cribl-Server hinterlegt:

   SPLUNK_HEC_TOKEN=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

3. Die .env-Datei ist in .gitignore eingetragen und wird nicht versioniert.
4. Cribl Stream liest die Variable beim Start und substituiert ${SPLUNK_HEC_TOKEN}.

2.3 TLS-Absicherung

TLS ist fuer die HEC-Verbindung aktiviert ("tls": { "disabled": false }). Die Konfiguration nutzt die Standard-TLS-Einstellungen von Cribl Stream:

• Minimum TLS-Version: 1.2
• Zertifikatsvalidierung: Aktiviert (Systemzertifikatspeicher)
• Bei selbstsignierten Zertifikaten: CA-Bundle unter $CRIBL_HOME/certs/ hinterlegen

Fuer die erweiterte TLS-Konfiguration (Client-Zertifikate, Cipher Suites) siehe Kapitel 10 - Sicherheitshandbuch.

2.4 Kompression

Die gzip-Kompression ("compress": true) reduziert das uebertragene Datenvolumen typischerweise um 70-85%. Dies ist besonders relevant, wenn die Daten ueber ein WAN oder VPN-Tunnel (Tailscale) uebertragen werden.

3. S2S Destination

3.1 Konfiguration

Die S2S-Destination ist in configs/stream/destinations/splunk-s2s.json definiert:

{
  "id": "splunk_s2s",
  "type": "splunk",
  "host": "${SPLUNK_HOST}",
  "port": ${SPLUNK_S2S_PORT},
  "nestedFields": "none",
  "onBackpressure": "block",
  "description": "Splunk S2S - Natives Splunk-Protokoll"
}

3.2 Natives Splunk-Protokoll

Das S2S-Protokoll (auch als "Splunk Forwarder Protocol" bekannt) ist das native, binaere Uebertragungsprotokoll zwischen Splunk-Komponenten. Vorteile:

• Optimierte binaere Serialisierung – effizienter als HTTP/JSON
• Automatische Erkennung durch den Splunk-Indexer
• Index- und Sourcetype-Metadaten werden nativ im Protokoll transportiert
• Keine zusaetzliche Token-Authentifizierung erforderlich (Zertifikat oder IP-basiert)
• Unterstuetzung fuer Load Balancing auf Indexer-Cluster

Der Parameter "nestedFields": "none" stellt sicher, dass Cribl keine verschachtelten JSON-Felder in das S2S-Paket einbettet, was zu Parsing-Problemen in Splunk fuehren koennte.

4. Persistent Queue

4.1 Konzept

Die Persistent Queue (PQ) ist ein festplattenbasierter Puffer, der zwischen der Cribl-Verarbeitungs-Engine und der Destination liegt. Wenn die Destination nicht erreichbar ist (Netzwerkausfall, Splunk-Wartung, Ueberlast), werden Events in der PQ zwischengespeichert und bei Wiederherstellung der Verbindung automatisch nachgeliefert.

Funktionsweise:

1. Events durchlaufen die Pipeline-Verarbeitung.
2. Bei erfolgreicher Zustellung an die Destination: Event wird direkt geliefert (PQ wird nicht genutzt).
3. Bei Nichterreichbarkeit: Events werden in die PQ auf der lokalen Festplatte geschrieben.
4. Ein Hintergrundprozess versucht periodisch, die Destination erneut zu erreichen.
5. Bei Wiederherstellung: PQ wird in FIFO-Reihenfolge abgearbeitet (aelteste Events zuerst).

4.2 Sizing

Beide Destinations sind mit einer PQ von maximal 1 GB konfiguriert. Die folgende Tabelle zeigt die Berechnung der Pufferkapazitaet:

4.3 Backpressure-Handling

Wenn die PQ voll ist, tritt der Backpressure-Mechanismus in Kraft. Cribl Stream reagiert wie folgt:

Im Falle eines Backpressure-Events wird empfohlen:

1. Sofortige Pruefung der Destination-Erreichbarkeit
2. Falls Splunk nicht erreichbar: Netzwerk und Splunk-Dienst pruefen
3. Falls PQ fast voll: Temporaer die pqMaxSize erhoehen (erfordert Neustart)
4. Vorfall im Incident-Management-System dokumentieren

5. Protokollvergleich: HEC vs. S2S

6. Failover-Strategie

Die Failover-Strategie im IceDataEmphasise-PoC basiert auf mehreren Schichten:

6.1 Schicht 1: Persistent Queue

Beide Destinations verwenden PQ als erste Verteidigungslinie gegen kurzzeitige Ausfaelle. Events werden lokal gepuffert und bei Wiederherstellung automatisch nachgeliefert.

6.2 Schicht 2: Verbindungswiederholung

Cribl Stream versucht automatisch, fehlgeschlagene Zustellungen erneut durchzufuehren:

6.3 Schicht 3: Alerting

Bei PQ-Fuellstand ueber 80% wird ein Alert ausgeloest (Konfiguration im Monitoring, siehe Kapitel 09 - Betriebshandbuch). Der Alert informiert das Betriebsteam per E-Mail und/oder Splunk-Alert.

6.4 Schicht 4: Manuelle Eskalation

Wenn die automatischen Mechanismen nicht ausreichen (PQ > 95%), erfolgt eine manuelle Eskalation gemaess der Kontaktliste im Betriebshandbuch. Massnahmen:

• Pruefung der Netzwerkverbindung (Tailscale-VPN-Tunnel)
• Pruefung des Splunk-Indexers (Dienststatus, Disk-Space, Lizenz)
• Temporaere Erhoehung der PQ-Groesse
• Im Extremfall: Umleitung der Events auf eine alternative Destination (z.B. lokales Dateisystem)

7. Verifikation der Ziele

Nach der Konfiguration der Destinations muessen folgende Pruefungen durchgefuehrt werden:

7.1 HEC-Destination pruefen

# Manueller HEC-Test vom Cribl-Server
curl -k https://${SPLUNK_HOST}:8088/services/collector/event \
  -H "Authorization: Splunk ${SPLUNK_HEC_TOKEN}" \
  -d '{"event":"HEC test from Cribl","sourcetype":"cribl:test","index":"main"}'

# Erwartete Antwort:
# {"text":"Success","code":0}

7.2 S2S-Destination pruefen

# Port-Erreichbarkeit pruefen
nc -zv ${SPLUNK_HOST} 9997

# In Cribl Stream UI:
# Settings → Destinations → splunk_s2s → Test Connection

7.3 PQ-Status pruefen

# Cribl Stream API: PQ-Status abfragen
curl -s http://localhost:9000/api/v1/system/metrics \
  | jq '.pq'

# Oder im Cribl UI:
# Monitoring → Destinations → PQ-Status

7.4 Verifikations-Checkliste

• HEC-Token in Splunk erstellt und getestet
• HEC-Destination in Cribl konfiguriert und Verbindung erfolgreich
• S2S-Receiving-Port (9997) in Splunk aktiviert
• S2S-Destination in Cribl konfiguriert und Verbindung erfolgreich
• PQ fuer beide Destinations aktiviert und Speicherplatz ausreichend
• TLS fuer HEC-Verbindung verifiziert (Zertifikat gueltig)
• Test-Events in Splunk sichtbar (beide Wege)
• PQ-Failover getestet (Splunk kurzzeitig stoppen, Events puffern, wieder starten)