# Zugriffsmanagement (IAM / PAM)

**Dokumenttyp:** Richtlinie & Prozess
**Geltungsbereich:** Alle Zugänge zu PORTA-Systemen (Server, Datenbank, Admin-UI, Drittdienste)
**Version:** 1.0
**Status:** Entwurf zur internen Freigabe
**Owner:** Betrieb / DevOps
**Letzte Aktualisierung:** 11.06.2026
**Deckt ab (CACC):** 25, 36, 37, 66, 67, 68, 69

---

## 1. Grundprinzipien

PowerOn gewährt Zugriffe ausschliesslich nach **Need-to-Know** und **Least Privilege**. Kein Mitarbeiter erhält mehr Rechte, als für seine Aufgabe erforderlich sind.

## 2. Zugriffsebenen der Plattform

| Ebene | Beschreibung | Berechtigte |
|---|---|---|
| **SysAdmin (Admin-UI)** | Höchste Stufe in der PORTA-Admin-UI: DB-Export/Import, Mandatsverwaltung, Feature-Steuerung | Patrick Motsch |
| **Server-Zugang (SSH)** | `ubuntu@api.poweron.swiss` / `api-int` — Vollzugriff auf Anwendung und Konfiguration | Patrick Motsch |
| **Datenbank** | DB-User `poweron_dev` auf `db.poweron.swiss:5432` | Patrick Motsch |
| **Mandats-Administrator (kundenseitig)** | Verwaltet Nutzer innerhalb des eigenen Tenants | Kunde selbst |
| **Endnutzer** | Nutzung der gebuchten Features | Kunde |

> **Offener Punkt (kompensierende Massnahme nötig):** Der SSH-Zugang erfolgt aktuell über den geteilten Benutzer `ubuntu`. Für Nachvollziehbarkeit auf Personenebene ist entweder (a) Umstellung auf personalisierte SSH-Accounts oder (b) lückenlose Protokollierung jeder SSH-Sitzung mit eindeutiger Personenzuordnung erforderlich. → siehe `11_Logging_und_Monitoring.md`. **[ZU PRÜFEN / UMZUSETZEN]**

## 3. Zugang zu Kundendaten im Klartext (#25, #66)

Mitarbeitende von PowerOn greifen auf Inhaltsdaten eines Kunden im Klartext **nur** zu, wenn:

1. der Kunde dies für einen konkreten Fall (z. B. Support-Ticket) freigegeben hat, **oder**
2. eine rechtskräftige behördliche Anordnung dies zwingend verlangt, **oder**
3. ein schwerer technischer Störfall den Zugriff temporär erfordert — mit unverzüglicher nachträglicher Information des Kunden.

Jeder solche Zugriff wird protokolliert (Datenbank-Export/Import wird serverseitig geloggt, siehe `datenbank-handling.md` Abschnitt 6).

## 4. Authentifizierung (#68)

| System | Authentifizierungsmethode | MFA |
|---|---|---|
| PORTA Endnutzer | Microsoft Azure AD OAuth / Google OAuth / lokales Login | Konfigurierbar pro Mandat (`mfaRequired`) oder pro User (Opt-in) |
| Admin-UI (SysAdmin) | Lokales Login / Session | **MFA erzwungen** (`MFA_REQUIRE_ADMINS=True`, umgesetzt Juni 2026) |
| SSH-Server | SSH-Key | [ZU PRÜFEN: Key + Passphrase? Bastion?] |
| Drittdienste (OpenAI etc.) | API-Keys in `.env` (verschlüsselt) | n/a |

**Vorgabe:** Für privilegierte Zugänge (SysAdmin, SSH, DB) ist Zwei-Faktor-Authentifizierung zu konfigurieren. SMS-/mobile TAN ist möglichst zu vermeiden; bevorzugt App- oder Hardware-Token.

**Stand Juni 2026:** MFA auf Admin-UI (SysAdmin) und Server-Zugängen umgesetzt. Endnutzer-MFA konfigurierbar pro Mandat. Trusted-Device-Mechanismus (60 Tage) reduziert MFA-Haeufigkeit bei gleicher Sicherheit — konform mit NIST SP 800-63B Abschnitt 5.2.8.

### 4.1 Session-Management

| Eigenschaft | Umsetzung |
|---|---|
| Token-Typ | JWT (HS256) in httpOnly/Secure Cookie |
| Multi-Session | Erlaubt (parallele Browser/Geräte) |
| Session-Dauer (Access) | Konfigurierbar, Default 300 Min |
| Session-Dauer (Refresh) | Konfigurierbar, Default 7 Tage |
| Silent Refresh | Frontend erneuert Access Token automatisch via Refresh-Endpoint |
| Token-Revocation | Serverseitig via PostgreSQL Token-Registry; Admin kann einzelne oder alle Sessions revoken |
| Trusted Device | httpOnly Cookie nach MFA-Erfolg; Default 60 Tage; jederzeit durch Admin/User widerrufbar |

**Regulatorische Grundlage:**
- Multi-Session ist Standard bei Enterprise-Software (NIST SP 800-63B Section 7.1 erlaubt mehrere aktive Sessions).
- Trusted Device entspricht NIST SP 800-63B Section 5.2.8 ("Verifier MAY re-authenticate only after a configurable period").
- Session-Revocation erfüllt ISO 27001 A.9.4.2 (Secure log-on procedures) und A.9.2.6 (Removal/adjustment of access rights).

## 5. Berechtigungsvergabe, -änderung und -entzug (#67)

| Ereignis | Massnahme | Frist |
|---|---|---|
| Onboarding | Zugänge gemäss Rolle einrichten, Minimalprinzip | Bei Eintritt |
| Rollenwechsel | Berechtigungen anpassen, nicht mehr benötigte entziehen | Innert 5 Werktagen |
| Offboarding | **Alle** Zugänge sofort sperren: SSH-Key entfernen, Admin-UI deaktivieren, API-Keys rotieren, DB-Zugang entziehen | Am letzten Arbeitstag |
| Rezertifizierung | Vollständige Überprüfung aller Zugänge und Berechtigungen | Mindestens halbjährlich |

## 6. Privilegierte Zugriffe (PAM) (#36, #37)

Privilegierter Zugriff (SSH, DB-Admin, SysAdmin) wird nur sorgfältig ausgewählten, geschulten Personen gewährt. Aufgrund der Teamgrösse ist die Anzahl privilegierter Personen sehr klein, was das Risiko begrenzt. Kompensierend zu fehlender vollständiger Funktionstrennung gilt:

- Protokollierung privilegierter Aktionen (Export/Import, Deployments, DB-Zugriffe).
- Vier-Augen-Prinzip bei produktiven Releases (siehe `feature_release_bugfix.md` / `08_Change_Management.md`).
- Regelmässige Stichprobenprüfung der Protokolle.

## 7. Zugangsbeschränkung auf IP/Domain (#69)

[ZU PRÜFEN: Ist der Admin-/Server-Zugang auf bestimmte IP-Adressen beschränkt? Falls ja, dokumentieren. Falls nein, als geplante Massnahme aufnehmen.]

## 8. Stand der Umsetzung / Lücken

| Thema | Status | Massnahme |
|---|---|---|
| Personalisierte SSH-Accounts | Offen | Umstellung oder vollständige Sitzungsprotokollierung |
| MFA auf privilegierten Zugängen | **Umgesetzt** (Juni 2026) | Halbjährliche Rezertifizierung |
| Multi-Session + Silent Refresh | **Umgesetzt** (Juni 2026) | Parallele Sessions erlaubt; automatische Token-Erneuerung |
| Trusted Device (MFA-Skip 60d) | **Umgesetzt** (Juni 2026) | NIST-konform; Admin-Revoke jederzeit moeglich |
| Admin Session-Verwaltung | **Umgesetzt** (Juni 2026) | Sessions/Trusted Devices pro User einsehbar und widerrufbar |
| Halbjährliche Rezertifizierung | Neu | Erstdurchführung terminieren |