Wie Sie Zugriffsrollen für eine kleine Business-App festlegen

Beginnen Sie mit Handlungen, nicht mit Berufsbezeichnungen

Berufsbezeichnungen verbergen Details. Zwei Personen mit dem Titel Manager brauchen womöglich Unterschiedliches, und eine Teilzeithilfe braucht vielleicht nur eine Aufgabe. Listen Sie stattdessen die Handlungen mit einfachen Verben auf: einen Kunden ansehen, einen Auftrag bearbeiten, eine Erstattung freigeben, einen Bericht exportieren, einen Datensatz löschen, einen Kollegen einladen.

Notieren Sie anschließend, welche Datensätze jede Handlung betrifft. Den Namen eines Kunden zu sehen ist nicht dasselbe wie seinen Zahlungsverlauf zu sehen, und die Tabelle sollte diesen Unterschied zeigen.

Eine Checkliste zur Rollenplanung

Verwenden Sie eine Zeile pro Handlung und eine Spalte pro Rolle. Markieren Sie jede Zelle als erlaubt, nicht erlaubt oder nur für eigene Datensätze erlaubt. Fügen Sie diese Spalten hinzu, damit die Tabelle auch nach dem Start nützlich bleibt:

• Handlung als einfache Verbphrase
• Betroffene Datensätze
• Rollen, die sie ausführen dürfen
• Ob sie auf die eigenen Datensätze der Person beschränkt ist
• Ob eine zweite Person zustimmen muss
• Wer über die Änderung dieser Regel entscheidet

Halten Sie die erste Version klein

Ein vernünftiger Ausgangspunkt für eine kleine App sind drei oder vier Rollen, zum Beispiel jemand, der nur ansehen darf, jemand, der hinzufügen und bearbeiten darf, jemand, der freigeben darf, und ein Administrator. Verstehen Sie dies als Vorschlag zum Anpassen, nicht als Regel. Mehr Rollen bedeuten mehr Regeln, die erklärt, geprüft und getestet werden müssen. Fügen Sie eine Rolle erst hinzu, wenn eine echte Aufgabe nicht durch die vorhandenen abgedeckt werden kann.

Vermeiden Sie eine Rolle pro Person. Wenn es eine Regel für eine einzelne Person gibt, fragen Sie sich, ob es wirklich eine Aufgabe ist, die geteilt werden sollte.

Standardmäßig verweigern und nur das Nötigste geben

Das OWASP Authorization Cheat Sheet nennt die Durchsetzung geringster Rechte und die standardmäßige Verweigerung unter seinen Empfehlungen. Es erklärt, dass bei der Zugriffskontrolle Fehler passieren können, besonders bei komplexen Anforderungen, weshalb sich eine Anwendung nicht allein darauf verlassen sollte, dass ausdrückliche Regeln jede mögliche Anfrage abdecken. In der Praxis heißt das: Eine neue Handlung oder ein neuer Bildschirm ist für alle gesperrt, bis Sie entscheiden, wer sie nutzen darf.

Prüfen Sie Berechtigungen dort, wo die Arbeit stattfindet, auf dem Server, und nicht nur dadurch, dass Sie eine Schaltfläche ausblenden. Eine ausgeblendete Schaltfläche ist eine Erleichterung für den Nutzer. Sie hält niemanden auf, der die Anfrage direkt sendet.

Sensible Handlungen gesondert behandeln

Manche Handlungen verdienen besondere Sorgfalt, weil sie schwer rückgängig zu machen sind oder auf einen Schlag viel offenlegen. Legen Sie vor dem Start für jede von ihnen einen Verantwortlichen fest.

• Alle Datensätze oder eine vollständige Kundenliste exportieren
• Datensätze löschen oder zusammenführen
• Die Rolle einer Person ändern oder einen neuen Nutzer einladen
• Persönliche Angaben von Personen außerhalb der eigenen Arbeit des Nutzers einsehen
• Preise, Sätze oder Freigabegrenzen ändern

Ein anschauliches Beispiel

Stellen Sie sich einen kleinen Geräteverleih mit einer App für Buchungen vor. Ein Mitarbeiter an der Theke kann Geräte ansehen und Buchungen anlegen. Ein Depotleiter kann zusätzlich Artikel als zurückgegeben oder beschädigt markieren. Der Inhaber kann Rabatte freigeben, die monatliche Buchungsliste exportieren und Mitarbeitende einladen. Ein Lieferfahrer sieht nur die Abgabeliste des Tages und markiert jede als zugestellt. Niemand außer dem Inhaber kann Rollen ändern. Dieses Beispiel ist hypothetisch.

Nur eigene Datensätze: eine Prüfung mit zwei Nutzern

Wenn in einer Zelle Ihrer Tabelle „nur für eigene Datensätze erlaubt“ steht, muss die App bei jeder Anfrage für einen bestimmten Datensatz bestätigen, dass der Datensatz der anfragenden Person gehört. OWASP beschreibt eine unsichere direkte Objektreferenz (Insecure Direct Object Reference) als etwas mit drei Bestandteilen: einem Objekt wie einem Konto oder Dokument, einer Referenz darauf wie einer ID oder einem Slug und einer fehlenden Autorisierungsprüfung auf Objektebene. Die Datensätze anderer Personen aus einer Liste wegzulassen ist nicht dasselbe, wie die Anfrage abzulehnen, wenn jemand die Kennung eines anderen Datensatzes angibt. OWASP rät, bei jedem Zugriffsversuch die Berechtigung des Nutzers zu prüfen.

Eine kurze manuelle Prüfung kann eine offensichtliche Lücke aufdecken. Führen Sie sie nur in einer isolierten Testkopie der App durch, die Sie testen dürfen, und mit erfundenen Datensätzen. Verwenden Sie dafür niemals den Datensatz eines echten Kunden. Diese manuelle Prüfung kann nicht beweisen, dass die App sicher ist, und sie ersetzt keine Sicherheitsüberprüfung. Dass sie bestanden wird, bedeutet nur, dass sich diese beiden Nutzer und diese Datensätze wie erwartet verhalten haben.

• Legen Sie zwei Testnutzer mit derselben Rolle an, Testnutzer A und Testnutzer B, und geben Sie jedem einen erfundenen Datensatz, etwa Beispielbuchung A und Beispielbuchung B.
• Melden Sie sich als Testnutzer A an und öffnen Sie den eigenen Datensatz von A und bearbeiten Sie ihn, sofern die Rolle es erlaubt. Jede Handlung sollte erlaubt sein.
• Versuchen Sie weiterhin als A, den Datensatz von B über den normalen Bildschirm und über die Adresse oder Referenz zu erreichen, die die App dafür verwendet. Jeder Versuch sollte abgelehnt werden, mit der klaren Meldung, die Sie für andere Ablehnungen gewählt haben.
• Wiederholen Sie dies mit vertauschten Nutzern und tragen Sie das Ergebnis erlaubt oder abgelehnt neben dem erwarteten Ergebnis in Ihre Tabelle ein.

Die Regeln vor dem Start prüfen

Das OWASP-Merkblatt beschreibt einfache Unit- und Integrationstests als wichtiges Mittel, um Autorisierungsprobleme schnell zu finden und zu beheben, weist aber darauf hin, dass sie manuelle Tests durch einen erfahrenen Tester nicht ersetzen können. Für eine kleine App ist ein manueller Durchlauf ein sinnvoller Anfang: Legen Sie pro Rolle einen Testnutzer an und versuchen Sie dann jede Zeile Ihrer Tabelle, einschließlich der Handlungen, die abgelehnt werden sollen. Halten Sie neben dem erwarteten Ergebnis fest, was passiert ist.

Wiederholen Sie den Durchlauf, sobald sich eine Rolle oder Handlung ändert. Legen Sie außerdem fest, was bei einer Ablehnung geschehen soll, etwa eine klare Meldung und ein Vermerk im Aktivitätsprotokoll, damit niemand im Ungewissen bleibt.