Rollen und Berechtigungen für Webanwendungen planen

Bei einem internen Werkzeug werden Konten oft zuerst als „Administrator“ oder „normaler Nutzer“ bezeichnet. Das ist für die Planung zu grob. Eine Person legt Vorgänge an, eine andere bearbeitet zugewiesene Aufgaben, eine dritte gibt Ergebnisse frei. Vielleicht darf die externe Unterstützung nur einzelne Unterlagen sehen. Schreiben Sie diese Tätigkeiten auf, bevor Sie sie zu Rollen bündeln.

Die NIST-Einordnung von Role Based Access Control beschreibt Rollen als Verbindung zwischen Personen und zugewiesenen Rechten. Eine Person kann dabei mehrere Rollen haben. Für Ihr Projekt folgt daraus keine fertige Rollenliste. Sie müssen entscheiden, welche Tätigkeiten gemeinsam gebraucht werden und welche Kombinationen fachlich getrennt bleiben sollen.

Trennen Sie außerdem technisches Verwalten von fachlichem Entscheiden. Wer Konten einrichtet, muss nicht automatisch jeden Kundenvorgang lesen oder genehmigen dürfen. Umgekehrt benötigt eine fachliche Leitung nicht zwangsläufig Zugriff auf Systemeinstellungen. Eine nachvollziehbare Rollenbeschreibung enthält deshalb konkrete Handlungen und ihren Geltungsbereich. Dadurch wird später sichtbar, ob ein zusätzliches Recht tatsächlich zur Aufgabe gehört oder nur aus Bequemlichkeit mitvergeben wurde.

Eine Technikerin darf im Beispiel die Vorgangsansicht öffnen. Daraus folgt nicht, dass sie jeden Einsatz im System ansehen darf. Ihre Erlaubnis hängt auch davon ab, ob der Vorgang ihr zugewiesen ist und zu ihrer Organisation gehört. Die Anzeige einer Funktion, der Zugriff auf einen Datensatz und die Bearbeitung einer bestimmten Angabe sind drei unterschiedliche Fragen.

Die OWASP API Security Top 10 beschreiben fehlende Berechtigungsprüfungen auf Objektebene als eigene Fehlerklasse. Die Prüfung muss feststellen, ob die anfragende Person die gewünschte Handlung an diesem konkreten Objekt ausführen darf. Eine schwer erratbare Kennung ersetzt diese Entscheidung nicht. Das gilt unabhängig davon, ob die Kennung in einer URL, einem Formular oder einer Schnittstellenanfrage steht.

Für die Planung formulieren Sie deshalb ganze Regeln: „Technik darf die Notiz eines zugewiesenen Entwurfs innerhalb der eigenen Organisation ändern.“ Der Satz enthält Rolle, Handlung, Gegenstand und Bedingungen. Ergänzen Sie die Grenzen einzelner Felder. Darf eine Person eine Arbeitsnotiz ändern, aber keine Freigabeentscheidung? Ein allgemeines Bearbeitungsrecht für den ganzen Vorgang wäre dafür möglicherweise zu weit. Dieselbe Unterscheidung muss für Übersichten, Suche, Anhänge und Downloads gelten.

Eine Oberfläche kann unpassende Funktionen ausblenden oder mit einer verständlichen Erklärung deaktivieren. Das erleichtert die Bedienung. Eine eigene Anfrage an den Server kann trotzdem ohne diesen Bildschirm entstehen. Daher darf weder ein ausgeblendeter Button noch ein nicht verlinkter Download als abschließende Berechtigungsprüfung gelten.

Das OWASP Authorization Cheat Sheet unterscheidet Anmeldung von Autorisierung. Es empfiehlt unter anderem standardmäßiges Ablehnen ohne passende Erlaubnis, die Prüfung bei jeder Anfrage und die Durchsetzung auf der vertrauenswürdigen Serverseite. Für eine neue Funktion müssen die geltenden Regeln ausdrücklich feststehen; eine ungeklärte Standardfreigabe wäre keine belastbare Lösung.

Lassen Sie sich im Projekt erklären, wo die maßgebliche Entscheidung getroffen wird. Eine zentrale Prüfung kann wiederkehrende Regeln konsistent halten, während konkrete Objekte und fachliche Zustände ergänzend geprüft werden. Entscheidend ist das tatsächlich durchgesetzte Ergebnis über alle Zugriffswege. Im fiktiven Portal darf etwa der Export nicht mehr Daten liefern als die erlaubte Vorgangsmenge, nur weil er über eine separate Route aufgerufen wird.

Das Verhalten bei einer Ablehnung gehört ebenfalls in den Auftrag. Die Anwendung sollte keine geschützten Inhalte oder Hinweise auf fremde Vorgänge verraten und keine Teiländerung hinterlassen. Welche Rückmeldung angemessen ist, hängt vom System ab. Für die fachliche Abnahme reicht die Aussage „Button fehlt“ deshalb nicht; gebraucht wird der Nachweis, dass die verbotene Handlung tatsächlich unterbleibt.

Im Beispielportal kann die Freigaberolle einen prüffähigen Vorgang bestätigen. Ein noch unvollständiger Entwurf sollte dadurch nicht automatisch freigabefähig werden. Die Berechtigung beantwortet, wer handeln darf. Die fachliche Zustandsregel beantwortet, wann und unter welchen Voraussetzungen die Handlung sinnvoll ist. Beide Entscheidungen müssen in der Anwendung zusammenwirken.

Klären Sie besondere Kombinationen ausdrücklich. Darf dieselbe Person einen Entwurf erstellen und anschließend freigeben? Darf die technische Kontenverwaltung sich selbst eine Freigaberolle zuweisen? Was passiert, wenn die einzige freigabeberechtigte Person ausfällt? Die richtige Antwort hängt vom betrieblichen Prozess ab. Eine Trennung zweier Aufgaben sollte nur versprochen werden, wenn die möglichen Rollenwechsel und Verwaltungswege sie tatsächlich erhalten.

Halten Sie für wichtige Rollenänderungen den Anlass, die freigebende Verantwortung und den Zeitpunkt fest. Für besonders relevante Handlungen kann ein passender Nachweis ebenfalls sinnvoll sein. Planen Sie Umfang und Zugriff auf solche Protokolle bewusst, statt alle Anwendungsinhalte unbegrenzt mitzuschreiben. Die Abnahmekriterien für Software-Funktionen helfen dabei, einen erlaubten Zustandswechsel und sein sichtbares Ergebnis eindeutig zu beschreiben.

Nehmen Sie Rollenmatrix, Datenbereiche und wichtige Gegenfälle in die Projektbeschreibung auf. Damit lässt sich vor der Umsetzung besprechen, welche Anmeldung bereits vorhanden ist, welche Regeln das Werkzeug benötigt und welche Verwaltungsfunktionen tatsächlich gebraucht werden. Eine vorhandene Anmeldung kann eine Grundlage sein, ersetzt jedoch die anwendungsspezifische Entscheidung über Datensätze und Handlungen nicht.

Nach der Veröffentlichung sollte die fachliche Verantwortung die tatsächlich vergebenen Rechte in einem zur Nutzung passenden Rhythmus prüfen. Ein neues Team, ein zusätzlicher Kundenbereich oder ein neuer Export kann die frühere Matrix verändern. Halten Sie solche Änderungen gemeinsam mit den relevanten Tests aktuell. Einzelne Ausnahmen brauchen eine begründete Regel; andernfalls entsteht neben dem offiziellen Rollenmodell schleichend ein zweites, kaum überschaubares System.

Ruhrstack beschreibt auf Entwicklung individuelle Webanwendungen, Portale und interne Werkzeuge. Ein Gespräch dazu kann mit einer Nutzergruppe und einem typischen Vorgang beginnen. Die technische Umsetzung folgt dann dem geklärten Umfang. Wenn darüber hinaus eine spezialisierte Sicherheitsprüfung benötigt wird, muss deren Aufgabe separat vereinbart sein. Welche Grenzen ein solcher Auftrag hat, erläutert der Beitrag Website-Sicherheitscheck: Den Umfang klären.