Berechtigungen — Zugangsdaten-Tresor

Berechtigungen im Zugangsdaten-Tresor laufen auf zwei Ebenen: einer Rollen-Vorgabe auf Tenant-Ebene (was darf eine Rolle standardmäßig) und einer Eintrags-spezifischen Feinjustierung, mit der einzelne Einträge restriktiver oder permissiver als der Standard sein können. Beides spielt sauber zusammen, ist aber zwei getrennte Konzepte.

Rollen-Modell der Plattform#

Die Plattform kennt drei Standard-Rollen, die für alle Tools gelten. Im Tresor verhalten sie sich wie folgt:

Admin#

Volle Kontrolle über den Tresor:

• Lesen aller Einträge im Tenant, unabhängig vom Eintrags-Owner
• Schreiben und Bearbeiten aller Einträge
• Löschen aller Einträge (Soft-Delete mit 90 Tagen Wiederherstellungs-Frist)
• Teilen mit Externen via Sharing-Link
• Konfigurieren der Policy — Master-Password-Stärke, Session-Lifetime, 2FA-Pflicht, Standard-Berechtigung pro Rolle

Ein Tenant hat in der Regel ein bis drei Admins — typischerweise Inhaber:in und Büroleitung.

Makler:in#

Operative Rolle. Darf:

• Eigene Einträge anlegen, lesen, bearbeiten, löschen
• Fremde Einträge lesen, sofern der Owner sie explizit mit der Rolle Makler:in oder mit der jeweiligen Person geteilt hat
• Eigene Einträge mit Kolleg:innen oder Externen teilen

Was eine Makler:in nicht darf:

• Einträge anderer Makler:innen bearbeiten oder löschen
• Tenant-weite Policy ändern
• Audit-Log einsehen (nur für Admins)

Assistent:in#

Read-only-Rolle für Backoffice-Mitarbeitende, die einzelne Zugänge brauchen, aber keine Verantwortung für den Tresor tragen sollen. Darf:

• Lesen ausschließlich der Einträge, die explizit mit ihr:ihm geteilt sind

Was eine Assistent:in nicht darf:

• Eigene Einträge anlegen
• Einträge bearbeiten, löschen, teilen
• Liste aller Tresor-Einträge sehen (sieht nur explizit geteilte)

Diese Trennung ist bewusst hart. Wer mehr Rechte braucht, kriegt die Rolle Makler:in. Die Assistent:in-Rolle ist für vertrauliche Backoffice-Zugriffe gedacht ohne dass eine versehentliche Lösch- oder Bearbeitungs-Aktion das Team gefährden kann.

Eintrags-spezifische Berechtigungen#

Über die Rolle hinaus lässt sich jeder Eintrag individuell konfigurieren. Drei Modi pro Eintrag:

1. Inherit (Standard) — Eintrag folgt der Tenant-weiten Policy für seine Sichtbarkeits-Stufe.
2. Restricted — Sichtbarkeit ist explizit auf benannte Personen oder Rollen eingeschränkt, auch wenn die Tenant-Policy mehr erlauben würde.
3. Shared with role — Sichtbarkeit wird auf eine ganze Rolle erweitert (z.B. "alle Assistent:innen dürfen lesen"), auch wenn die Rolle das standardmäßig nicht dürfte.

Beispiel: Der Eintrag Schlüsselsafe-Code Musterstraße 12 darf normalerweise von allen Makler:innen gelesen werden (Inherit), wird aber im konkreten Fall auf zwei Personen restringiert, weil das Objekt extrem hochpreisig ist und der Eigentümer Diskretion erwartet. Umgekehrt: der Eintrag WLAN-Passwort Büro wird auf die Rolle Assistent:in geöffnet, damit auch das Backoffice-Personal ohne Admin-Aktion arbeiten kann.

Berechtigungen für einen Eintrag ändern#

In der Tresor-UI: Eintrag öffnen → Reiter Zugriff → Modus wählen → Personen oder Rolle hinzufügen → Speichern.

Wichtig:

• Nur der Eintrags-Owner und Admins dürfen Berechtigungen ändern.
• Änderungen wirken sofort. Bereits offene Sessions, die den Eintrag entsperrt hatten, behalten den entschlüsselten Inhalt für die laufende Session — beim nächsten Lock-Cycle ist der neue Permission-Stand maßgeblich.
• Jede Berechtigungs-Änderung erzeugt einen Audit-Log-Eintrag mit altem und neuem Stand.

Vererbung und Standard-Policy#

Pro Tenant kann der Admin im Settings → Tools → Zugangsdaten-Tresor → Policy festlegen, welche Standard-Sichtbarkeit neue Einträge bekommen. Drei Optionen:

Die Policy wirkt nur auf neu angelegte Einträge. Bestehende Einträge bleiben unverändert. Wer rückwirkend eine ganze Tresor-Bibliothek umkonfigurieren will, muss das pro Eintrag tun — oder mit dem Support eine Batch-Migration vereinbaren.

Owner-Reassignment beim Mitarbeiter-Austritt#

Wenn eine Person das Büro verlässt, bleiben ihre Tresor-Einträge zunächst bestehen, werden aber für die ausscheidende Person gesperrt. Der Admin sieht im Settings → Team → Ausgeschiedene eine Liste verwaister Einträge und kann sie an einen anderen User reassignen.

Empfohlener Workflow beim Austritt:

1. Vor dem letzten Arbeitstag — Ausscheidende Person exportiert die Liste ihrer Einträge (Audit-Reason als Grund: "Austritt"), Admin reviewt.
2. Am letzten Arbeitstag — Admin reassignt alle Einträge an die Nachfolger:innen oder an eine sammelnde Rolle.
3. Nach dem Austritt — Account wird deaktiviert. Reassignte Einträge bleiben funktional, Audit-Log behält die Owner-History.
4. Innerhalb von 30 Tagen — Rotieren aller Passwörter und API-Keys, die die ausscheidende Person kannte. Das Tool kann den Rotations-Bedarf nicht erzwingen, aber via Tag oder Notiz-Feld kennzeichnen.

Der Schritt 4 ist organisatorisch und gehört in den Austrittsprozess des Büros — die Plattform unterstützt ihn durch eine Filter-Ansicht Audit → User → Letzte 90 Tage, die zeigt, welche Einträge die Person tatsächlich angesehen hat. Was sie nie geöffnet hat, muss nicht rotiert werden.