Revisionshistorie
| Version | Datum | Autor | Beschreibung |
|---|
| 1.0 | 2026-02-10 | Marcus Pauli | Erstversion des Compliance- und Regulatorik-Dokuments |
Inhaltsverzeichnis
- Regulatorischer Rahmen
- Anforderungen an Log-Management in Banken
- Nachvollziehbarkeit und Audit Trail
- Datenklassifizierung und Datenschutz (DSGVO)
- Aufbewahrungsfristen
- Change-Management-Prozess
- Dokumentationspflichten
- Pruefungsrelevante Nachweise
- Mapping: Regulatorische Anforderung → Cribl-Umsetzung
1. Regulatorischer Rahmen
Die Log-Management-Infrastruktur einer deutschen Bank unterliegt einer Vielzahl regulatorischer Vorgaben. Die folgenden Regelwerke sind fuer das IceDataEmphasise-Projekt unmittelbar relevant:
1.1 MaRisk AT 7.2 – Technisch-organisatorische Ausstattung
Die Mindestanforderungen an das Risikomanagement (MaRisk) der BaFin fordern in AT 7.2:
- Die IT-Systeme muessen den Anforderungen an Integritaet, Verfuegbarkeit, Authentizitaet und Vertraulichkeit gerecht werden
- IT-Risiken sind angemessen zu steuern und zu ueberwachen
- Notfallvorsorge ist sicherzustellen (siehe Notfallhandbuch)
- Aenderungen an IT-Systemen unterliegen einem geordneten Change-Management-Prozess
1.2 BAIT – Bankaufsichtliche Anforderungen an die IT
Die BAIT konkretisieren die MaRisk und stellen spezifische Anforderungen:
| BAIT-Abschnitt | Anforderung | Relevanz fuer IceDataEmphasise |
|---|
| II. IT-Governance |
Nachvollziehbare IT-Strategie und -Organisation |
Dokumentation des PoC als Teil der IT-Strategie |
| III. Informationsrisikomanagement |
Identifikation, Bewertung und Steuerung von IT-Risiken |
Risikobewertung der Log-Pipeline |
| IV. Informationssicherheitsmanagement |
Schutz der Vertraulichkeit, Integritaet, Verfuegbarkeit |
TLS-Verschluesselung, Zugriffskontrolle, Integritaetspruefung |
| V. Benutzerberechtigungsmanagement |
Minimale Berechtigungen, Nachvollziehbarkeit |
Cribl RBAC, dedizierter Service-User (cribl) |
| VI. IT-Projekte und Anwendungsentwicklung |
Geordnete Projektdurchfuehrung |
ITSO-konforme Dokumentation, Test-Verfahren |
| VII. IT-Betrieb |
Sicherer und stabiler IT-Betrieb |
Monitoring, Alerting, Backup-Verfahren |
| VIII. Auslagerung |
Steuerung von Auslagerungen an Dritte |
Cribl als Software-Hersteller (kein Cloud-Service im PoC) |
| X. IT-Notfallmanagement |
Notfallplaene und -tests |
Notfallhandbuch, Wiederanlaufprozeduren |
1.3 DORA – Digital Operational Resilience Act
Die EU-Verordnung DORA (ab Januar 2025 in Kraft) stellt erweiterte Anforderungen an die digitale operationale Resilienz:
- IKT-Risikomanagement (Art. 5-16): Umfassende Identifikation und Management von IKT-Risiken, einschliesslich der Log-Infrastruktur
- IKT-Vorfallmanagement (Art. 17-23): Erkennung, Klassifizierung und Meldung von IKT-Vorfaellen; Log-Daten sind essentiell fuer die Vorfallanalyse
- Testen der digitalen Resilienz (Art. 24-27): Regelmaessige Tests der IKT-Systeme, einschliesslich der Log-Pipeline
- IKT-Drittparteienrisiko (Art. 28-44): Management der Risiken durch IKT-Dienstleister (Cribl als Softwareanbieter)
Regulatorischer Hinweis: Die Log-Management-Infrastruktur ist kein Selbstzweck, sondern ein wesentlicher Baustein zur Erfuellung regulatorischer Anforderungen. Ausfaelle oder Manipulationen der Log-Pipeline koennen direkte aufsichtsrechtliche Konsequenzen haben.
2. Anforderungen an Log-Management in Banken
2.1 Grundlegende Anforderungen
| Anforderung | Beschreibung | Umsetzung im PoC |
|---|
| Vollstaendigkeit |
Alle sicherheitsrelevanten Ereignisse muessen erfasst werden |
12 Log-Quellen konfiguriert (Systemd, SSH, Apache, Samba, Docker, etc.) |
| Integritaet |
Logs duerfen nicht unbemerkt veraendert werden |
TLS-Transport, Persistent Queue, Splunk-Indizierung mit Pruefhashes |
| Vertraulichkeit |
Zugriff auf Logs nur fuer berechtigte Personen |
RBAC in Cribl, Splunk-Berechtigungen, dedizierter Service-User |
| Verfuegbarkeit |
Logs muessen zeitnah abrufbar sein |
Persistent Queue als Puffer, Monitoring und Alerting |
| Nachvollziehbarkeit |
Wer hat wann was getan? |
Audit-Trail in Cribl, Aenderungshistorie ueber Git |
| Aufbewahrung |
Einhaltung regulatorischer Aufbewahrungsfristen |
Splunk Retention Policies, siehe Abschnitt 5 |
2.2 Sicherheitsrelevante Log-Quellen
| Quelle | Beispiel-Events | Regulatorische Relevanz |
|---|
| SSH / Authentifizierung | Login-Versuche, fehlgeschlagene Anmeldungen | MaRisk AT 7.2, BAIT V (Berechtigungsmanagement) |
| Systemd Journal | Service-Starts/Stops, Kernel-Meldungen | BAIT VII (IT-Betrieb) |
| Apache / Webserver | HTTP-Zugriffe, Fehler | BAIT IV (Informationssicherheit) |
| Samba / Dateifreigaben | Dateizugriffe, Berechtigungsaenderungen | BAIT V (Berechtigungsmanagement) |
| Docker | Container-Lifecycle, Sicherheitsereignisse | BAIT VII (IT-Betrieb) |
| Firewall / Netzwerk | Verbindungsversuche, Blockierungen | BAIT IV (Netzwerksicherheit) |
3. Nachvollziehbarkeit und Audit Trail
3.1 Audit Trail in Cribl
Cribl Stream protokolliert Aenderungen an der Konfiguration in einem internen Audit-Log:
| Ereignis | Protokollierte Information | Speicherort |
|---|
| Konfigurationsaenderung | Benutzer, Zeitstempel, geaendertes Objekt, alter/neuer Wert | Cribl Audit Log |
| Login/Logout | Benutzer, Zeitstempel, Quell-IP, Erfolg/Misserfolg | Cribl Audit Log |
| Pipeline-Aenderung | Benutzer, Zeitstempel, Pipeline-ID, Aenderungsdetails | Cribl Audit Log + Git |
| Deployment/Commit | Benutzer, Zeitstempel, betroffene Gruppen | Cribl Audit Log + Git |
# Cribl Audit Logs einsehen
cat /opt/cribl/log/audit.log | jq .
# Letzte 20 Audit-Eintraege
tail -20 /opt/cribl/log/audit.log | jq '.'
3.2 Git-basierte Nachvollziehbarkeit
Alle Projekt-Konfigurationen werden im Git-Repository versioniert:
- Jede Aenderung ist ueber Git-History nachvollziehbar (
git log, git diff)
- Commit-Messages dokumentieren den Grund der Aenderung
- Branch-basiertes Arbeiten ermoeglicht Review vor Deployment
- Cribl-eigene Git-Integration fuer Konfigurationsversioning
3.3 Splunk Audit Trail
In Splunk werden Log-Daten unveraenderlich indiziert. Fuer die Nachvollziehbarkeit stellt Splunk bereit:
- Index-Signierung und Hash-Validierung
- Search Audit Logs (wer hat welche Suche ausgefuehrt)
- Zugriffsprotokollierung auf Dashboards und Reports
4. Datenklassifizierung und Datenschutz (DSGVO)
4.1 Datenklassifizierung
| Klasse | Beschreibung | Beispiele in Logs | Schutzmassnahmen |
|---|
| Oeffentlich |
Keine Einschraenkungen |
Allgemeine Systemstatus-Informationen |
Keine besonderen |
| Intern |
Nur fuer internen Gebrauch |
Service-Logs, Performance-Metriken, Anwendungslogs |
Zugriffskontrolle, keine externe Weitergabe |
| Vertraulich |
Eingeschraenkter Personenkreis |
Authentifizierungs-Logs, IP-Adressen, Benutzernamen |
Verschluesselung, RBAC, Audit-Trail |
| Streng vertraulich |
Nur explizit autorisierte Personen |
Sicherheitsvorfaelle, forensische Daten, personenbezogene Daten |
Verschluesselung, starke Zugriffskontrolle, Vier-Augen-Prinzip |
4.2 DSGVO-Relevanz im Log-Management
Datenschutz-Hinweis: Log-Daten koennen personenbezogene Daten enthalten (IP-Adressen, Benutzernamen, E-Mail-Adressen). Die Verarbeitung unterliegt der DSGVO.
| DSGVO-Grundsatz | Anforderung | Umsetzung in Cribl |
|---|
| Datenminimierung (Art. 5 Abs. 1c) |
Nur erforderliche Daten erheben und speichern |
Cribl Pipelines filtern und reduzieren Daten vor der Weiterleitung. Unnoetige Felder werden entfernt. |
| Speicherbegrenzung (Art. 5 Abs. 1e) |
Daten nicht laenger als noetig speichern |
Splunk Retention Policies, automatische Loeschung nach Ablauf |
| Integritaet (Art. 5 Abs. 1f) |
Schutz vor unbefugter Veraenderung |
TLS-Transport, Zugriffskontrolle, Audit-Trail |
| Vertraulichkeit (Art. 5 Abs. 1f) |
Schutz vor unbefugtem Zugriff |
RBAC, Verschluesselung, Netzwerksegmentierung (Tailscale) |
| Rechenschaftspflicht (Art. 5 Abs. 2) |
Nachweis der Einhaltung |
Dokumentation, Audit-Logs, diese Compliance-Dokumentation |
4.3 Datenschutzmassnahmen in Cribl Pipelines
Cribl bietet folgende Funktionen zur DSGVO-konformen Datenverarbeitung:
| Funktion | Pipeline-Aktion | Anwendungsfall |
|---|
| Feld-Maskierung | Mask | IP-Adressen, E-Mail-Adressen in Logs maskieren |
| Feld-Entfernung | Remove Fields | Personenbezogene Felder vor der Indexierung entfernen |
| Feld-Hashing | Eval mit Hash-Funktion | Pseudonymisierung von Benutzernamen |
| Regex-Ersetzung | Regex Extract/Replace | Gezielte Redaktion sensibler Muster |
| Event-Filterung | Drop / Filter | Events mit sensiblen Daten nicht weiterleiten |
| Routing nach Klassifikation | Routes | Verschiedene Retention/Zugriffslevel je nach Datenklasse |
5. Aufbewahrungsfristen
| Log-Typ |
Regulatorische Grundlage |
Mindestaufbewahrung |
Empfohlene Aufbewahrung |
Umsetzung |
| Sicherheitsrelevante Logs (SSH, Auth) |
MaRisk, BAIT IV |
12 Monate |
24 Monate |
Splunk Index Retention |
| System-/Betriebslogs |
BAIT VII |
6 Monate |
12 Monate |
Splunk Index Retention |
| Anwendungslogs |
BAIT VII |
6 Monate |
12 Monate |
Splunk Index Retention |
| Audit-Logs (Konfigurationsaenderungen) |
MaRisk, BAIT V, DORA |
36 Monate |
60 Monate |
Splunk Index Retention + Archivierung |
| Netzwerk-/Firewall-Logs |
BAIT IV |
6 Monate |
12 Monate |
Splunk Index Retention |
| Transaktionslogs |
HGB §257, AO §147 |
10 Jahre |
10 Jahre |
Splunk Archivierung + Langzeitspeicher |
| Vorfallbezogene Logs |
DORA Art. 17-23 |
36 Monate (nach Vorfallabschluss) |
60 Monate |
Separate Sicherung bei Vorfaellen |
Hinweis: Im PoC-Betrieb werden die Aufbewahrungsfristen ueber Splunk Index Retention Policies gesteuert. Fuer den Produktivbetrieb ist eine Archivierungsstrategie fuer Langzeitdaten zu implementieren (z.B. Splunk SmartStore oder externes Archiv).
6. Change-Management-Prozess
6.1 Prozessuebersicht
Jede Aenderung an der Cribl-Infrastruktur durchlaeuft den folgenden Prozess:
| Phase | Aktivitaet | Verantwortlich | Artefakt |
|---|
| 1. Antrag |
Change Request erstellen mit Beschreibung, Risikobewertung, Rollback-Plan |
Antragsteller |
Change Request (Ticketsystem) |
| 2. Bewertung |
Risikobewertung, Kategorisierung (Standard/Normal/Emergency) |
Change Manager |
Risikobewertung |
| 3. Genehmigung |
Freigabe durch Change Advisory Board (CAB) oder Change Manager |
CAB / Change Manager |
Genehmigungsnachweis |
| 4. Umsetzung |
Aenderung durchfuehren, Backup vorher erstellen |
Administrator |
Backup, Git-Commit |
| 5. Test |
Verifikation mit 07-verify-deployment.sh |
Administrator |
Testprotokoll |
| 6. Review |
Post-Implementation Review |
Change Manager |
Review-Protokoll |
6.2 Change-Kategorien
| Kategorie | Beschreibung | Genehmigung | Vorlaufzeit |
|---|
| Standard |
Vorab genehmigte, risikoarme Aenderungen (z.B. neue Log-Quelle hinzufuegen) |
Keine Einzelgenehmigung noetig |
Keine |
| Normal |
Aenderungen mit moderatem Risiko (z.B. Pipeline-Aenderung, Destination-Konfiguration) |
Change Manager |
≥ 3 Arbeitstage |
| Major |
Aenderungen mit hohem Risiko (z.B. Cribl-Version-Upgrade, Architektur-Aenderung) |
CAB |
≥ 10 Arbeitstage |
| Emergency |
Dringende Aenderungen zur Behebung von Sev1/Sev2 Vorfaellen |
Nachtraegliche Genehmigung |
Sofort |
6.3 Vier-Augen-Prinzip
Regulatorische Anforderung: Aenderungen an der produktiven Log-Infrastruktur erfordern das Vier-Augen-Prinzip. Der Umsetzer darf nicht gleichzeitig der Genehmigende sein.
Im IceDataEmphasise-Projekt wird das Vier-Augen-Prinzip wie folgt umgesetzt:
- Git-basierter Workflow: Pull Requests mit verpflichtendem Review
- Deployment erst nach Merge-Genehmigung
- Im PoC: Dokumentation der Genehmigung im Change Request
7. Dokumentationspflichten
7.1 Erforderliche Dokumentation
| Dokument | Inhalt | Aktualisierung | Verantwortlich |
|---|
| Betriebshandbuch |
Installation, Konfiguration, Betriebsverfahren |
Bei jeder Aenderung |
IT-Betrieb |
| Notfallhandbuch |
DR-Szenarien, Wiederanlauf, Eskalation |
Jaehrlich + nach jedem Vorfall |
IT-Betrieb + ISB |
| Sicherheitskonzept |
Schutzbedarf, Massnahmen, Restrisiken |
Jaehrlich + bei Architektur-Aenderungen |
ISB |
| Datenschutz-Folgenabschaetzung |
DSGVO-Bewertung der Log-Verarbeitung |
Bei Aenderung der Verarbeitung |
DSB |
| Berechtigungskonzept |
Rollen, Zugriffsrechte, Vergabe-/Entzugsprozess |
Bei Aenderung der Berechtigungen |
IT-Betrieb + ISB |
| Monitoring-Konzept |
KPIs, Schwellwerte, Alerting |
Bei Aenderung der Monitoring-Strategie |
IT-Betrieb |
| Change-Log |
Alle Aenderungen mit Zeitstempel, Beschreibung, Genehmigung |
Fortlaufend |
IT-Betrieb |
| Compliance-Mapping |
Zuordnung regulatorischer Anforderungen zu technischen Massnahmen |
Jaehrlich + bei regulatorischen Aenderungen |
ISB + Compliance |
7.2 IceDataEmphasise Dokumentationsstruktur
Das Projekt liefert die folgende ITSO-konforme Dokumentation (14 HTML-Seiten):
| Seite | Titel | Regulatorische Abdeckung |
|---|
| 01-10 | Architektur, Installation, Konfiguration, Betrieb, Schulung | BAIT VI, VII |
| 11 | Notfallhandbuch | MaRisk AT 7.2, BAIT X, DORA Art. 11 |
| 12 | Monitoring und Alerting | BAIT VII, DORA Art. 10 |
| 13 | Compliance und Regulatorik (dieses Dokument) | MaRisk, BAIT, DORA, DSGVO |
| 14 | Troubleshooting | BAIT VII |
8. Pruefungsrelevante Nachweise
Bei einer Pruefung durch interne Revision, Wirtschaftspruefer oder BaFin muessen folgende Nachweise vorgelegt werden koennen:
| Nachweis | Quelle | Format | Aufbewahrung |
|---|
| Systemarchitektur und Datenfluss |
Architekturdokumentation |
HTML/PDF |
Projektdokumentation |
| Installationsnachweis |
Installationsskripte + Logs |
Shell-Skripte, Log-Dateien |
Git-Repository + Logs |
| Konfigurationshistorie |
Git-Log, Cribl Audit Log |
Git-History, JSON-Logs |
Git-Repository |
| Berechtigungsnachweise |
Cribl RBAC-Konfiguration, OS-Benutzer |
Konfigurationsdateien |
Git-Repository |
| Change-Nachweise |
Ticketsystem, Git-Commits |
Tickets, Commit-Messages |
Ticketsystem + Git |
| Test-/Verifikationsberichte |
07-verify-deployment.sh Ausgaben |
Log-Dateien |
Dateisystem + Archiv |
| Monitoring-Nachweise |
Health-Check-Logs, Cribl-Metriken |
Log-Dateien, Dashboards |
Dateisystem + Splunk |
| Incident-Berichte |
Post-Incident Reviews |
HTML/PDF |
Ticketsystem + Dokumentation |
| Backup-Nachweise |
Backup-Logs, Pruefsummen |
Log-Dateien, SHA256-Hashes |
Backup-Server |
| Schulungsnachweise |
Schulungsdokumentation |
HTML/PDF, Teilnehmerlisten |
Projektdokumentation |
Pruefungsvorbereitung: Alle genannten Nachweise sollten viertjaehrlich auf Vollstaendigkeit und Aktualitaet geprueft werden. Eine Checkliste fuer die Pruefungsvorbereitung ist empfehlenswert.
9. Mapping: Regulatorische Anforderung → Cribl-Umsetzung
| Regulatorische Anforderung |
Quelle |
Cribl-Umsetzung |
Nachweis |
| Protokollierung sicherheitsrelevanter Ereignisse |
MaRisk AT 7.2, BAIT IV |
12 Log-Quellen konfiguriert (Systemd, SSH, Apache, Samba, Docker, etc.); Cribl Edge sammelt dezentral |
Source-Konfiguration, 04-configure-sources.sh |
| Integritaet der Log-Daten |
MaRisk AT 7.2, BAIT IV, DORA Art. 9 |
TLS-verschluesselter Transport (Source → Cribl → Splunk); Persistent Queue verhindert Datenverlust |
TLS-Konfiguration, Destination-Config |
| Verfuegbarkeit der IT-Systeme |
MaRisk AT 7.2, BAIT VII, DORA Art. 11 |
Monitoring (Health Checks, KPIs); Alerting bei Ausfaellen; Notfallhandbuch mit DR-Szenarien |
07-verify-deployment.sh, Monitoring-Logs, Notfallhandbuch |
| Benutzerberechtigungsmanagement |
BAIT V |
Cribl RBAC mit rollenbasiertem Zugriff; dedizierter Service-User (cribl); Splunk-Berechtigungen |
RBAC-Konfiguration, OS-User-Setup |
| Change Management |
MaRisk AT 7.2, BAIT VI |
Git-basierter Workflow; Vier-Augen-Prinzip; Change-Kategorien; Rollback-Faehigkeit |
Git-History, Change Requests |
| Notfallmanagement |
MaRisk AT 7.2, BAIT X, DORA Art. 11 |
Notfallhandbuch mit Severity-Levels, Eskalationsmatrix, DR-Szenarien, Wiederanlauf-Prozeduren |
Notfallhandbuch (Seite 11) |
| IKT-Vorfallmanagement |
DORA Art. 17-23 |
Eskalationsmatrix; Kommunikationsplan; Post-Incident Review; Log-Daten fuer Forensik |
Notfallhandbuch, Incident-Berichte |
| Datenminimierung |
DSGVO Art. 5 Abs. 1c |
Cribl Pipelines: Feld-Entfernung, Maskierung, Filterung; 5 Processing Pipelines konfiguriert |
Pipeline-Konfiguration |
| Aufbewahrungsfristen |
MaRisk, HGB §257, AO §147 |
Splunk Retention Policies je Index; Archivierung fuer Langzeitdaten |
Splunk Index-Konfiguration |
| Nachvollziehbarkeit / Audit Trail |
MaRisk, BAIT V, DORA |
Cribl Audit Log; Git-Versionierung; Splunk Search Audit; ITSO-Dokumentation |
Audit-Logs, Git-History, Dokumentation |
| Testen der Resilienz |
DORA Art. 24-27 |
End-to-End Verifikationssuite (20 Tests); Service-Restart-Test; Regelmaessige Ausfuehrung via Cron |
07-verify-deployment.sh, Testprotokolle |
| Dokumentationspflichten |
MaRisk, BAIT VI, DORA |
14-seitige ITSO-konforme HTML-Dokumentation; Revisionshistorie; Klassifikation |
Dokumentation im Repository |
| IKT-Drittparteienrisiko |
DORA Art. 28-44 |
Cribl als On-Premises-Software (kein Cloud-SaaS im PoC); Risikobewertung des Anbieters erforderlich |
Lieferantenbewertung |
Hinweis: Dieses Mapping dient als Orientierung fuer den PoC. Fuer den Produktivbetrieb muss eine vollstaendige Compliance-Bewertung durch die Compliance-Abteilung und den ISB erfolgen. Dieses Dokument ersetzt keine formale regulatorische Bewertung.