9f5f8bfc11
Includes CACC/FINMA legal processes, updated AGB with PowerOn AG stammdaten, and internal legal and best-practice analysis report. Co-authored-by: Cursor <cursoragent@cursor.com>
3.5 KiB
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 |