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:

der Kunde dies für einen konkreten Fall (z. B. Support-Ticket) freigegeben hat, oder
eine rechtskräftige behördliche Anordnung dies zwingend verlangt, oder
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

6 KiB Raw Blame History