Logging und Monitoring (Sicherheitsprotokollierung)

Dokumenttyp: Konzept Geltungsbereich: Protokollierung und Überwachung der PORTA-Plattform Version: 1.0 Status: Entwurf zur internen Freigabe Owner: Betrieb / DevOps Letzte Aktualisierung: 02.06.2026 Deckt ab (CACC): 88, 89, 90, 91, 92, 93, 94

1. Vorhandene Protokolle

Protokoll	Inhalt	Ort
Anwendungslog	App-Ereignisse	`/srv/gateway/shared/logs/log_app_YYYYMMDD.log`
Systemlog	Service `gateway`	`journalctl -u gateway`
AuthEvent (DB)	Login-Protokoll	DB-Tabelle (vom Export ausgeschlossen)
Export/Import-Log	DB-Operationen durch SysAdmins	serverseitig (siehe `datenbank-handling.md` §6)
CI/CD	Deployments	Forgejo

2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)

Zugriffe auf Kundendaten im Klartext (z. B. DB-Export/Import) werden serverseitig geloggt.
Anforderung #94: Eindeutige Identifizierung von Benutzerzugriffen auf Tenant-Ebene für forensische Analyse.
Offener Punkt: Da der SSH-Zugang über den geteilten ubuntu-User läuft, ist die Personenzuordnung auf Server-Ebene aktuell eingeschränkt. → personalisierte Zugänge oder Sitzungsprotokollierung erforderlich (siehe Dok 02). [ZU PRÜFEN/UMZUSETZEN]

3. Kundenzugang zu Protokollen (#88)

Punkt #88 verlangt, dass Protokolle dem Kunden jederzeit (ggf. in Echtzeit) zur Verfügung stehen.

[ZU PRÜFEN: Können Kunden ihre Tenant-bezogenen Logs einsehen/exportieren? Falls nicht vorhanden, als Massnahme aufnehmen — z. B. Log-Export pro Mandant oder API.]

4. Automatische Analyse und Ereigniserkennung (#89, #90)

Element	Status
Etablierter Logging-/Monitoring-Prozess	[ZU PRÜFEN]
Automatische, proaktive Loganalyse (SIEM/Alerting)	Offen — kleines Team, kein SIEM
Anomalie-/Schwellwert-Alerting	[ZU PRÜFEN]

Kompensierende Massnahme (kleines Team): Statt eines vollwertigen SIEM ein leichtgewichtiges, automatisiertes Alerting (z. B. Log-Monitor, der bei definierten Mustern — fehlgeschlagene Logins, Fehlerraten, Health-Check-Ausfall — eine Benachrichtigung an die Rufbereitschaft sendet). [ZU PRÜFEN/EINFÜHREN]

5. Schutz der Protokolldaten (#91)

Anforderung	Status / Massnahme
Schutz vor unbefugtem Zugriff	Logs auf Server, nur über privilegierten Zugang erreichbar
Schutz vor Veränderung/Löschung (Integrität)	Offen — Logs aktuell auf demselben Server, kein Write-Once. Massnahme: Logs an einen getrennten, append-only/write-once Speicher weiterleiten
Aufbewahrungsdauer	[ZU PRÜFEN, Vorschlag: mind. 12 Monate, sicherheitsrelevante Zugriffslogs 3 Jahre]

6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)

#92 (7×24-Analyse): Mit 2–5 Personen nicht als Vollbetrieb leistbar. Kompensierend: automatisiertes Alerting + Rufbereitschaft (siehe Dok 07).
#93 (Schnittstellen zum Kunden-SOC): [ZU PRÜFEN: Kann Log-Streaming/Export an ein Kunden-SOC bereitgestellt werden (Syslog, API)? Falls nicht, als optionales Angebot dokumentieren.]

7. Stand der Umsetzung / Lücken

Thema	Status	Massnahme
Personenbezogene Nachvollziehbarkeit (Tenant-Ebene)	Teilweise	personalisierte Zugänge / Sitzungslog
Log-Integritätsschutz	Offen	append-only/getrennter Speicher
Automatisches Alerting	Offen	einführen
Aufbewahrungsdauer definiert	Offen	festlegen
Kundenzugang zu Logs	[ZU PRÜFEN]	klären

3.5 KiB Raw Blame History Unescape Escape