Erfassen Sie Ressourcen und Aktionen, ordnen Sie sie den Arbeitsverantwortlichkeiten zu, trennen Sie die Rolle vom Eigentum an einem konkreten Datensatz und vergeben Sie minimale Rechte. Setzen Sie die Autorisierung serverseitig durch, protokollieren Sie sensible Aktionen in einem Audit und überprüfen Sie regelmäßig Konten, temporäre Zugänge sowie Tests verbotener Szenarien.
Rollen und Berechtigungen in einer Webanwendung bestimmen, wer Daten sehen und eine bestimmte Aktion ausführen darf. Eine einfache Aufteilung in Benutzer und Administrator stößt bei Wachstum schnell an ihre Grenzen. Der Support muss Einsicht in einen Fall nehmen können, ohne den Preis zu ändern, eine Führungskraft nur ihr eigenes Team freigeben und ein externer Mitarbeiter für begrenzte Zeit auf ein ausgewähltes Projekt zugreifen können.
Ein sicheres Modell entsteht aus realen Aufgaben, der Zuständigkeit für Ressourcen und dem Prinzip der minimalen Rechte. Die Prüfung muss bei jeder Operation auf dem Server greifen und darf nicht nur eine Schaltfläche in der Oberfläche ausblenden. Zugleich sollte sie für Administratoren verständlich, für die Entwicklung testbar und bei einem Vorfall oder Personalwechsel auditierbar bleiben.
Modellieren Sie Aktionen und Ressourcen vor Rollennamen
Sammeln Sie die Aufgaben der Nutzer und zerlegen Sie sie in Ressource, Aktion und Geltungsbereich. Ein Recht „Bestellungen“ reicht nicht aus; unterscheiden Sie zwischen Lesen, Erstellen, Bearbeiten, Freigeben, Exportieren und Stornieren. Der Geltungsbereich kann ein eigener Datensatz, ein Team, eine Filiale oder die gesamte Organisation sein. Eine solche Matrix deckt gefährliche Rechtekombinationen ebenso auf wie fehlende Verantwortlichkeiten.
Fassen Sie erst danach die Berechtigungen zu Rollen zusammen, die der tatsächlichen Arbeit entsprechen. Die Bezeichnung „Manager“ kann in verschiedenen Abteilungen unterschiedliche Bedeutungen haben; ergänzen Sie die Rolle daher um eine Beschreibung und einen Verantwortlichen. Legen Sie nicht für jede Person eine neue Rolle an. Lösen Sie Ausnahmen über zeitlich befristeten Zugriff oder eine klare Regel, sonst bleibt das Modell nicht wartbar.
- Quelle und konkret erlaubte Aktion
- Umfang eigener, Team- oder Unternehmensdaten
- Bedingungen für Freigabe und Sensibilität
- verantwortliche Rolle und Eigentümer der Berechtigung
Kombinieren Sie Rollen mit Eigentum und Kontext
Die Rolle allein reicht häufig nicht aus. Ein Redakteur darf nur zugewiesene Projekte bearbeiten und ein Kunde nur eigene Bestellungen. Der Server prüft daher auch die Verknüpfung des Benutzers mit dem konkreten Objekt, der Organisation und dem Status. Ist ein Datensatz freigegeben, darf dieselbe Rolle den Preis möglicherweise nicht mehr ändern. Dokumentieren Sie kontextabhängige Regeln als Teil des Domänenprozesses.
Vermeiden Sie eine Autorisierung, die auf Angaben des Clients beruht, etwa auf einer übermittelten Organisations-ID ohne serverseitige Prüfung der Mitgliedschaft. Jede Abfrage und jede Mutation muss einen vertrauenswürdigen Identitätskontext verwenden. Prüfen Sie bei einer Massenoperation jedes Ziel oder eine sicher eingeschränkte Sammlung, nicht nur den ersten Datensatz.
Konzipieren Sie die Administration und den temporären Zugang
Ein Administrator muss sehen können, warum ein Nutzer ein bestimmtes Recht hat, wer es vergeben hat und wie lange es gilt. Vergeben Sie kritische Rollen über einen freigegebenen Prozess und schützen Sie sie mit Multi-Faktor-Authentifizierung. Die Standardrolle eines neuen Kontos sollte minimal sein. Einladung, Teamwechsel und Deaktivierung müssen den Zugriff ohne manuellen Eingriff in die Datenbank aktualisieren.
Der Support muss möglicherweise vorübergehend den Zustand eines Kunden einsehen oder in dessen Namen handeln. Eine solche Funktion sollte technisch eingeschränkt, zeitlich begrenzt, sichtbar gekennzeichnet und auditiert werden. Eine sensible Aktion kann eine zusätzliche Bestätigung erfordern. Teilen Sie weder das Passwort des Kunden noch ein universelles Administratorkonto, das eine Zuordnung des Eingriffs zu einer Person unmöglich macht.
Setzen Sie Regeln serverseitig durch und protokollieren Sie sensible Aktionen
Die Benutzeroberfläche kann einen nicht erlaubten Button ausblenden, der Server muss jedoch eine direkte Anfrage ablehnen. Platzieren Sie die Autorisierung in einer wiederverwendbaren Schicht nahe der Domänenoperation, damit sie in einem neuen Endpoint oder einem Batch-Prozess nicht vergessen wird. Die Antwort sollte die Existenz eines fremden sensiblen Objekts nicht mehr als nötig preisgeben.
Ein Audit-Eintrag bei einer wesentlichen Änderung enthält Akteur, Aktion, Objekt, Zeitpunkt, einen unbedenklichen Grund und das Ergebnis. Speichern Sie nicht unnötig den gesamten sensiblen Inhalt. Schützen Sie das Log vor Änderungen durch normale Administratoren und legen Sie die Aufbewahrungsdauer nach Risiko und Pflichten fest. Ein Audit hilft bei der Untersuchung, ersetzt aber keine Prävention.
Testen Sie verbotene Pfade und überprüfen Sie Zugriffe regelmäßig
Automatisierte Tests decken für jede sensible Kombination aus Rolle, Eigentum und Zustand sowohl die erlaubte als auch die verbotene Aktion ab. Versuchen Sie, die ID in der URL zu ändern, eine alte Einladung zu verwenden, die API direkt aufzurufen und eine Massenoperation mit einem fremden Datensatz auszuführen. Fügen Sie bei jedem Vorfall oder jeder neuen Regel einen Regressionstest hinzu.
Überprüfen Sie regelmäßig aktive Konten, kritische Rollen, vorübergehende Ausnahmen und technische Identitäten. Das Ausscheiden einer Person oder die Einstellung eines Projekts muss den Entzug des Zugriffs auslösen. Beobachten Sie ungewöhnliche Ablehnungen und Rollenänderungen, interpretieren Sie Alarme aber im Kontext. Aktualisieren Sie das Modell zusammen mit dem Prozess, nicht erst, wenn eine alte Rolle plötzlich alles bedeutet.
- zulässiges Szenario für jede Arbeitsrolle
- verweigerter Zugriff auf eine fremde Ressource
- abgelaufene Einladung und deaktivierter Nutzer
- Überprüfung temporärer und privilegierter Berechtigungen
- Audit jeder Änderung einer kritischen Rolle
Häufige Fragen
Was ist der Unterschied zwischen einer Rolle und einer Berechtigung?
Eine Berechtigung erlaubt eine konkrete Aktion an einer Ressource. Eine Rolle bündelt Berechtigungen nach beruflicher Verantwortung. Der tatsächliche Zugriff kann zusätzlich von Eigentümerschaft, Organisation und Status des Datensatzes abhängen.
Reicht es, eine unerlaubte Funktion in der Oberfläche auszublenden?
Nein. Das Ausblenden verbessert die Benutzerfreundlichkeit, doch der Client lässt sich umgehen. Der Server muss bei jeder Operation Identität, Berechtigung und den Kontext des Zielobjekts prüfen.
Sollte der Support ein Administratorkonto haben?
Nur die für den Support erforderlichen Rechte, idealerweise befristet und auditiert. Ein universeller, gemeinsam genutzter Administrator-Account vergrößert die Auswirkungen eines Fehlers und macht es unmöglich, die Verantwortung für eine konkrete Aktion festzustellen.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
