09 - Betriebshandbuch

Revisionshistorie

Inhaltsverzeichnis

1. Taegliche Betriebsaufgaben
2. Start/Stop/Restart Prozeduren
3. Log-Rotation und Housekeeping
4. Performance-Monitoring
5. Kapazitaetsplanung
6. Backup und Restore
7. Wartungsfenster-Prozedur
8. Kontaktliste und Eskalation

1. Taegliche Betriebsaufgaben

Die folgenden Aufgaben muessen taeglich im Rahmen des regulaeren Betriebs durchgefuehrt werden. Die Checkliste dient als Nachweis fuer die Aufsicht (MaRisk AT 7.2).

Morgendliche Checkliste (bis 09:00 Uhr)

• Cribl Stream UI erreichbar unter https://<cribl-host>:9000
• Alle Quellen (Sources) melden aktiven Status (gruene Indikatoren)
• Beide Destinations (HEC + S2S) zeigen Connected
• PQ-Fuellstand beider Destinations unter 5%
• Keine Fehlermeldungen im Cribl-System-Log der letzten 24h
• Splunk-seitig: Daten in allen Indexes aktuell (letzte 15 Minuten)
• Cribl Edge Nodes: Alle registrierten Nodes sind online
• Tailscale-VPN: Alle Peers verbunden
• Disk-Space auf Cribl-Server > 20% frei
• CPU-Auslastung des Cribl-Servers < 70% (Durchschnitt letzte Stunde)

RACI-Matrix: Taegliche Aufgaben

R = Responsible, A = Accountable, C = Consulted, I = Informed

2. Start/Stop/Restart Prozeduren

2.1 Cribl Stream

Cribl Stream laeuft als systemd-Dienst auf dem NUC-Server:

# Status pruefen
sudo systemctl status cribl

# Starten
sudo systemctl start cribl

# Stoppen (Graceful Shutdown)
sudo systemctl stop cribl

# Neustart
sudo systemctl restart cribl

# Logs anzeigen
sudo journalctl -u cribl -f --no-pager

2.2 Cribl Edge

# Status pruefen
sudo systemctl status cribl-edge

# Starten
sudo systemctl start cribl-edge

# Stoppen
sudo systemctl stop cribl-edge

# Neustart
sudo systemctl restart cribl-edge

# Logs anzeigen
sudo journalctl -u cribl-edge -f --no-pager

2.3 Abhaengigkeiten und Reihenfolge

2.4 Notfall-Restart (bei Haenger)

# Nur wenn normaler Restart nicht funktioniert:
# 1. Sanftes Signal senden
sudo kill -SIGTERM $(pgrep -f cribl)
sleep 30

# 2. Falls Prozess immer noch laeuft:
sudo kill -SIGTERM $(pgrep -f cribl)
sleep 10

# 3. Dienst normal starten
sudo systemctl start cribl

# 4. Sofort PQ-Status pruefen (moeglicher Datenverlust?)
curl -s http://localhost:9000/api/v1/system/metrics | jq '.pq'

3. Log-Rotation und Housekeeping

3.1 Cribl-eigene Logs

Cribl Stream erzeugt eigene Betriebslogs unter /opt/cribl/log/:

3.2 Zusaetzliche Log-Rotation via logrotate

# /etc/logrotate.d/cribl
/opt/cribl/log/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0640 cribl cribl
    sharedscripts
    postrotate
        systemctl reload cribl 2>/dev/null || true
    endscript
}

3.3 Housekeeping-Aufgaben

4. Performance-Monitoring

4.1 Wichtige Metriken

4.2 Monitoring-Befehle

# Cribl Stream Metriken (API)
curl -s http://localhost:9000/api/v1/system/metrics | jq '.'

# Cribl Stream Health Check
curl -s http://localhost:9000/api/v1/health | jq '.'

# Systemressourcen
top -bn1 | head -20
free -h
df -h /opt

# Netzwerk-Durchsatz (Cribl-Ports)
ss -s
ss -tlnp | grep -E '(9000|9420|9997|8088)'

# Tailscale-Status
tailscale status

4.3 Splunk-basiertes Monitoring

# Cribl-Durchsatz in Splunk verfolgen (letzte 4 Stunden)
index=* cribl_pipeline=*
| timechart span=5m count by cribl_pipeline

# Alarmierung bei fehlenden Daten (Saved Search)
index=idx_security sourcetype=linux_secure earliest=-15m
| stats count
| where count < 10
| eval alert_message="Weniger als 10 Security-Events in den letzten 15 Minuten"

5. Kapazitaetsplanung

5.1 Aktuelle Ressourcenauslastung (PoC-Phase)

5.2 Skalierungsplanung

6. Backup und Restore

6.1 Backup-Konzept

Das Backup umfasst die vollstaendige Cribl-Konfiguration. Das Skript 08-backup-cribl-config.sh automatisiert den Backup-Prozess.

6.2 Backup-Durchfuehrung

# Manuelles Backup
sudo /home/mpauli/IceDataEmphasise/scripts/08-backup-cribl-config.sh

# Automatisiertes Backup via Cron (taeglich um 02:00 Uhr)
# Eintrag in /etc/crontab:
0 2 * * * root /home/mpauli/IceDataEmphasise/scripts/08-backup-cribl-config.sh

# Backup-Verzeichnis pruefen
ls -lah /var/backups/cribl/

6.3 Restore-Prozedur

1. Cribl Stream stoppen:

   sudo systemctl stop cribl

2. Aktuellen Zustand sichern:

   sudo cp -r /opt/cribl/local/ /opt/cribl/local.pre-restore.$(date +%Y%m%d)

3. Backup entpacken:

   sudo tar xzf /var/backups/cribl/cribl-backup-YYYYMMDD-HHMMSS.tar.gz -C /opt/cribl/

4. Berechtigungen pruefen:

   sudo chown -R cribl:cribl /opt/cribl/local/

5. Cribl Stream starten:

   sudo systemctl start cribl

6. Funktionspruefung:

   curl -s http://localhost:9000/api/v1/health | jq '.'

7. Alle Quellen und Destinations im UI pruefen

6.4 Backup-Aufbewahrung

7. Wartungsfenster-Prozedur

7.1 Planung

7.2 Empfohlenes Wartungsfenster

• Zeitraum: Samstag 02:00 - 06:00 Uhr
• Begruendung: Geringstes Log-Volumen, minimale Auswirkung auf Betrieb
• Maximale Dauer: 4 Stunden
• Rollback-Zeitfenster: 1 Stunde innerhalb des Wartungsfensters

7.3 Checkliste: Wartungsfenster

• Change-Genehmigung liegt vor
• Backup erstellt und verifiziert
• Rollback-Plan dokumentiert und getestet
• Alle Beteiligten informiert und erreichbar
• Monitoring-Dashboard geoeffnet
• Wartungsarbeiten durchgefuehrt
• Funktionspruefung abgeschlossen (alle Quellen, Destinations, Pipelines)
• PQ-Status geprueft (keine Rueckstaende)
• Splunk-Datenfluss verifiziert
• Wartungsprotokoll ausgefuellt

7.4 Rollback-Prozedur

Falls waehrend der Wartung ein Problem auftritt, das nicht innerhalb von 60 Minuten behoben werden kann, wird der Rollback eingeleitet:

1. Cribl Stream stoppen
2. Restore des Backups (siehe Abschnitt 6.3)
3. Cribl Stream starten
4. Vollstaendige Funktionspruefung
5. Vorfall dokumentieren und Nachbesprechung planen

8. Kontaktliste und Eskalation

8.1 Kontaktliste

8.2 Eskalationsmatrix

8.3 Eskalationspfad bei P1-Vorfaellen

1. 0-15 Min: Cribl-Administrator analysiert das Problem, versucht Sofortmassnahme
2. 15-30 Min: Teamleitung wird informiert, Security Operations wird einbezogen
3. 30-60 Min: Falls nicht behoben: Rollback auf letztes Backup einleiten
4. 60+ Min: Cribl-Support kontaktieren, Management-Eskalation
5. Nach Behebung: Incident-Report innerhalb von 24 Stunden, Post-Mortem innerhalb von 5 Werktagen