# 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 |