# 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:** 02.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 | [ZU PRÜFEN: MFA erzwungen?] | | Admin-UI (SysAdmin) | Lokales Login / Session | **MFA erzwungen** (umgesetzt Juni 2026) | | SSH-Server | SSH-Key | [ZU PRÜFEN: Key + Passphrase? Bastion?] | | Drittdienste (OpenAI etc.) | API-Keys in `.env` | 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 über IdP (Azure AD/Google) und SSH-Details siehe unten — offene Punkte bleiben markiert. ## 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 | | Halbjährliche Rezertifizierung | Neu | Erstdurchführung terminieren |