Rollen und Berechtigungen
Eine Fehlkonfiguration der Zugriffssteuerung ist eine der häufigsten Ursachen für Vorfälle mit Datenexposition. Dieser Abschnitt überprüft, ob Rollen, Tresortypen und Benutzerberechtigungen dem Prinzip der geringsten Rechte folgen und ob administrative Aufgaben angemessen getrennt sind.
Navigieren Sie zu Einstellungen → Benutzerverwaltung für die meisten Kontrollen in diesem Abschnitt.
1. Standardrollen — Berechtigungsüberprüfung
Passwork enthält drei integrierte Rollen: Besitzer, Administrator und Mitglied (Benutzer). Zusätzlich kann Ihre Organisation über benutzerdefinierte Rollen verfügen.
Öffnen Sie für jede Rolle die Rolleneinstellungen und überprüfen Sie die aktivierten Berechtigungen anhand der folgenden Matrix.
Rolle Besitzer
Es gibt genau einen Besitzer. Die Rolle Besitzer kann nicht geändert werden und gewährt die höchste Zugriffsebene, einschließlich der Möglichkeit, die Rollen anderer Benutzer zu ändern.
Was zu überprüfen ist:
- Nur einem Benutzer ist die Rolle Besitzer zugewiesen
- Für das Besitzer-Konto ist 2FA aktiviert
- Die Anmeldedaten des Besitzers werden im Notfall-Servicekonto oder in einem versiegelten Offline-Datensatz gespeichert (siehe Phase 2 des Admin-Rollouts)
- Das Besitzer-Konto wird nur für administrative Aufgaben verwendet, nicht für den täglichen Zugriff auf Anmeldedaten
Rolle Administrator
Administratoren können Benutzer verwalten, Einstellungen konfigurieren und auf alle Tresore zugreifen, für die sie Corporate-Administratoren sind.
Was zu überprüfen ist:
| Berechtigung | Erwartet für Admin | Sicherheitsbedenken bei Aktivierung für alle |
|---|---|---|
| Alle Systemeinstellungen verwalten | Ja | Gering — für Admin-Rolle erwartet |
| Aktivitätsprotokoll anzeigen | Ja | Gering |
| LDAP-Einstellungen verwalten | Ja | Gering |
| SSO-Einstellungen verwalten | Ja | Gering |
| Alle Tresortypen verwalten | Ja (globale Admins) | Hoch — für Abteilungs-Admins nur auf relevante Typen beschränken |
| Zugriff auf alle Tresore | Nur über Zuweisung als Corporate-Administrator | Hoch — Admins sollten standardmäßig nicht alle Tresore sehen |
| Benutzerverwaltung (alle Benutzer) | Ja (globale Admins) | Mittel — Abteilungs-Admins sollten nur die Benutzer ihrer Rolle verwalten |
Rolle Mitglied
Die Standardrolle für alle Endbenutzer. Darf keinen Zugriff auf administrative Funktionen haben.
Überprüfen Sie, dass die Rolle Mitglied Folgendes nicht hat:
- Zugriff auf Systemeinstellungen
- Zugriff auf Benutzerverwaltung
- Tresorerstellung (sofern Ihre Richtlinie keine von Benutzern erstellten Tresore erlaubt)
- Zugriff auf den Aktionsverlauf (sofern Ihre Richtlinie kein Audit auf Benutzerebene erfordert)
- Generierung von API-Tokens (sofern nicht für einen bestimmten Anwendungsfall erforderlich)
2. Benutzerdefinierte Rollen — Prinzip der geringsten Rechte
Überprüfen Sie für jede benutzerdefinierte Rolle:
- Nur die mindestens notwendigen Berechtigungen — jede in der Rolle aktivierte Berechtigung sollte eine dokumentierte geschäftliche Begründung haben.
- Umfang der rollenbasierten Benutzerverwaltung — wenn eine benutzerdefinierte Admin-Rolle Benutzer verwalten kann, überprüfen Sie, ob die Einstellung Rollenbasierte Benutzerverwaltung sie darauf beschränkt, nur Benutzer der entsprechenden Mitgliederrolle zu verwalten (nicht alle Benutzer im System).
- Keine „Catch-all"-Admin-Rollen — vermeiden Sie Rollen, die Zugriff auf alle Tresortypen und alle Einstellungen gewähren. Admin-Rollen auf Abteilungsebene sollten im Umfang beschränkt sein.
Matrix zur Aufgabentrennung
Überprüfen Sie für Organisationen mit Compliance-Anforderungen (ISO 27001, SOC 2), dass die folgenden Trennungen bestehen:
| Aufgabenpaar | Sollten getrennte Rollen sein | Risiko bei Kombination |
|---|---|---|
| Tresorzugriff gewähren / Auf Tresorinhalte zugreifen | Ja | Selbstautorisierung |
| Benutzer verwalten / Tresorzugriffsanfragen genehmigen | Ja | Rechteausweitung |
| LDAP konfigurieren / LDAP-Anmeldedaten verwenden | Ja | Exposition von Anmeldedaten |
| Audit-Log konfigurieren / Auf Audit-Log zugreifen | Ja | Manipulation des Audits |
| API-Tokens erstellen / API-Tokens verwenden | Kontextabhängig | Überprivilegierte Automatisierung |
3. Tresortypen und Corporate-Administratoren
3.1 Corporate-Administratoren für alle Tresortypen
Jeder Tresortyp sollte mindestens einen Corporate-Administrator haben — ein Konto, das automatisch allen Tresoren dieses Typs hinzugefügt wird und von den Tresorbesitzern nicht entfernt werden kann. Dies stellt den Notfallzugriff sicher und verhindert, dass Tresore verwaisen.
Navigieren Sie zu Einstellungen → Tresorverwaltung → Tresortypen.
Überprüfen Sie für jeden Tresortyp:
- Mindestens ein Corporate-Administrator ist zugewiesen
- Der Corporate-Administrator ist entweder das Servicekonto (siehe Abschnitt 4) oder ein benanntes, aktives administratives Konto
- Corporate-Administratoren sind keine Benutzer, die ihre Rolle ändern oder die Organisation ohne einen Nachfolgeplan verlassen könnten
3.2 Beschränkungen für private Tresore
Beurteilen Sie, ob eine uneingeschränkte Erstellung privater Tresore für Ihre Organisation angemessen ist.
Risiko: Benutzer, die private Tresore erstellen und dort Unternehmensanmeldedaten speichern, machen diese Anmeldedaten für die IT während Audits, beim Offboarding oder bei der Incident Response unzugänglich.
Navigieren Sie zu Einstellungen → Tresorverwaltung → Typ Benutzer-Tresore → Wer kann Tresore erstellen.
| Richtlinienoption | Wann verwenden |
|---|---|
| Alle Benutzer können private Tresore erstellen | Umgebungen mit geringem Risiko; Benutzer speichern nur persönliche Anmeldedaten |
| Beschränkt auf bestimmte Rollen/Benutzer | Umgebungen mit mittlerem/hohem Risiko; verhindert das Horten von Anmeldedaten |
| Hinzufügen von Benutzern zu privaten Tresoren verbieten | Stellt sicher, dass private Tresore nicht zu improvisierten geteilten Tresoren werden |
3.3 Audit der Tresorbesitzverhältnisse
Führen Sie eine Überprüfung aller bestehenden Tresore durch:
Überprüfen Sie unter Einstellungen → Tresorverwaltung → Alle Tresore:
- Jeder Tresor hat einen aktiven Besitzer (keinen gelöschten oder gesperrten Benutzer)
- Corporate-Administratoren sind jedem Tresor wie vom Tresortyp erwartet zugewiesen
- Es existieren keine „verwaisten" Tresore (Tresore ohne aktive Benutzer)
4. Servicekonto (Notfallzugriff)
Wie in Phase 2: Struktur und Rollen konfiguriert, muss ein Servicekonto für die Notfallwiederherstellung von Tresoren existieren.
Was zu überprüfen ist
- Ein dediziertes Servicekonto existiert
- Das Servicekonto ist als Corporate-Administrator für alle kritischen Tresortypen zugewiesen
- Das Servicekonto ist in Passwork gesperrt — es kann sich unter normalen Umständen nicht anmelden
- Die Anmeldedaten und das Masterpasswort des Servicekontos (falls CSE aktiviert ist) werden an einem physisch sicheren Offline-Ort gespeichert
- Der Zugriff auf den physischen Datensatz der Anmeldedaten ist dokumentiert (wer darf unter welchen Bedingungen darauf zugreifen)
- Für das Servicekonto ist 2FA deaktiviert (ein gesperrtes Konto kann sich nicht anmelden, daher ist 2FA irrelevant, dies bestätigt jedoch, dass keine aktiven Sitzungen bestehen)
Das Servicekonto darf niemals für tägliche administrative Aufgaben verwendet werden. Jede Verwendung muss im IT-Incident-Record-System der Organisation protokolliert werden. Nach jeder Verwendung muss das Konto erneut gesperrt und die Anmeldedaten müssen rotiert werden.
5. Überprüfung des API-Zugriffs
Die Passwork-API ermöglicht den programmatischen Zugriff auf Tresordaten. Kompromittierte API-Tokens sind gleichbedeutend mit kompromittierten Benutzeranmeldedaten.
Was zu überprüfen ist
Navigieren Sie zu Einstellungen → Benutzer und überprüfen Sie die Benutzer, die über API-Tokens verfügen:
- Jedes API-Token hat einen dokumentierten Besitzer und Zweck
- Tokens für außer Betrieb genommene Integrationen wurden widerrufen
- API-Tokens folgen einem Rotationsplan (siehe API-Token-Rotation)
- Die den API-Servicebenutzern zugewiesene Rolle beschränkt ihre Berechtigungen auf das erforderliche Minimum (z. B. Nur-Lese-Zugriff auf bestimmte Tresore)
- Der API-Zugriff ist für Standard-Benutzerrollen deaktiviert, wenn keine Integration ihn erfordert
6. Überprüfung übermäßigen Tresorzugriffs
Ein Benutzer sollte nur Zugriff auf die Tresore und Ordner haben, die für seine aktuelle Rolle erforderlich sind.
Was zu überprüfen ist
Für eine Stichprobe von Benutzern (insbesondere solche mit administrativen Rollen):
- Öffnen Sie das Profil des Benutzers unter Einstellungen → Benutzer.
- Prüfen Sie den Tab Zugriff — dieser zeigt den gesamten Tresor- und Ordnerzugriff für diesen Benutzer.
- Überprüfen Sie, dass jede Zugriffsgewährung einem aktuellen geschäftlichen Bedarf entspricht.
Achten Sie insbesondere auf:
- Frühere Abteilungszugehörigkeit (Zugriff nach einem Wechsel nicht entzogen)
- Zugriff von Auftragnehmern, der nach Projektende bestehen bleibt
- Admin-Zugriff auf Tresore ohne operativen Bedarf
Die vollständige Dokumentation der Zugriffsrechte finden Sie unter Benutzer-Zugriffsrechte.
Zusammenfassende Checkliste
| # | Kontrolle | Status |
|---|---|---|
| 1.1 | Es existiert genau ein Besitzer-Konto | |
| 1.2 | Für das Besitzer-Konto ist 2FA aktiviert | |
| 1.3 | Die Rolle Mitglied hat keine Admin-Berechtigungen | |
| 2 | Benutzerdefinierte Rollen folgen den geringsten Rechten; Abteilungs-Admins sind im Umfang beschränkt | |
| 2 (SoD) | Administrative Aufgaben gemäß obiger Matrix getrennt | |
| 3.1 | Alle Tresortypen haben einen Corporate-Administrator | |
| 3.2 | Die Richtlinie zur Erstellung privater Tresore ist beabsichtigt und dokumentiert | |
| 3.3 | Keine verwaisten Tresore; alle Tresore haben aktive Besitzer | |
| 4 | Servicekonto existiert, ist gesperrt, Anmeldedaten offline gespeichert | |
| 5 | Alle API-Tokens sind aktiv, dokumentiert und rotiert | |
| 6 | Stichprobenüberprüfung des Benutzerzugriffs abgeschlossen; keine überflüssigen Berechtigungen gefunden |