SaaS
Rollen und Rechte in einer SaaS-Plattform vor dem Code
Rollen und Rechte einer SaaS-Plattform werden vor dem Code geschrieben, als Tabelle, die zeigt, welche Rolle was darf. Die Basis sind drei Regeln des OWASP: minimale Rechte, Ablehnung als Standard und Prüfung bei jeder Anfrage auf dem Server. Das Ergebnis wird mit Tests geprüft.
In einer SaaS-Plattform sehen nicht alle dasselbe. Eine Führungskraft, ein Sachbearbeiter und ein Kunde haben unterschiedliche Bedürfnisse und unterschiedliche Rechte. Diese Rechte werden vor dem Code geschrieben, in einer einfachen Tabelle, die Sie freigeben. Der Grund ist praktisch: Ein Fehler hier ist auf dem Bildschirm nicht zu sehen, legt aber Daten für jemanden offen, der sie nicht sehen sollte.
Was ist Zugriffskontrolle?
Die Zugriffskontrolle entscheidet, was jeder Nutzer nach der Anmeldung tun darf. Die Anmeldung sagt, wer der Nutzer ist. Die Zugriffskontrolle sagt, was er sehen, ändern oder löschen kann. Das sind zwei verschiedene Aufgaben, und die zweite braucht eine eigene Planung.
Das OWASP, die offene Gemeinschaft für Anwendungssicherheit, setzt in der Liste Top 10 von 2021 Broken Access Control auf Platz eins, also die gebrochene Zugriffskontrolle. Gegenüber der vorherigen Liste stieg sie von Platz fünf auf Platz eins. Das zeigt, wie oft Anwendungen Nutzer dorthin lassen, wo sie nicht hingehören.
Was ist eine Rolle?
Eine Rolle ist ein Name für eine Gruppe von Rechten. Das NIST beschreibt RBAC (role-based access control) als Modell, in dem Nutzer Rollen zugewiesen werden und jede Rolle ein oder mehrere Rechte hat. Administratoren legen fest, welche Aktionen jede Stelle braucht, und ordnen die Menschen der passenden Rolle zu. Eine Rolle beschreibt also eine Aufgabe in der Organisation und nicht einen einzelnen Menschen.
Das NIST merkt an, dass Administratoren ohne Rollen oft Zugriffslisten pro Nutzer pflegen, was teuer und fehleranfällig ist. Mit Rollen folgt die Verwaltung der Struktur der Organisation. Wechselt ein Mitarbeiter die Stelle, wechselt er die Rolle und nicht Dutzende einzelne Einstellungen.
Wie wird die Rechtetabelle geschrieben?
Die Rechtetabelle hat eine Zeile pro Aktion und eine Spalte pro Rolle. Wir erstellen sie in der Phase der Anforderungen, zusammen mit den Menschen, die das System nutzen werden. Jede Zelle antwortet mit Ja oder Nein.
Aktion | Führungskraft | Sachbearbeiter | Kunde |
|---|---|---|---|
Sieht die Dashboards des ganzen Teams | Ja | Nein | Nein |
Erstellt und bearbeitet Anfragen | Ja | Ja | Nur die eigenen |
Genehmigt eine Anfrage | Ja | Nein | Nein |
Löscht Daten | Ja | Nein | Nein |
Das Obige ist ein Beispiel und kein fertiges Rezept. In jedem Projekt sind die Rollen anders. Der Wert der Tabelle liegt darin, dass man sich einigt, bevor etwas gebaut wird, und dass Code und Tests genau dem folgen, was freigegeben wurde.
Welche Regeln gelten?
Wir folgen drei Regeln aus dem Authorization Cheat Sheet des OWASP. Die erste sind minimale Rechte: Der Nutzer bekommt nur, was er für seine Arbeit braucht. Die zweite ist die Ablehnung als Standard, also ist alles verboten, was nicht ausdrücklich erlaubt wurde. Die dritte ist die Prüfung bei jeder Anfrage.
Die dritte Regel hat eine praktische Folge. Das OWASP betont, dass die Prüfung auf dem Server erfolgt und nicht nur im Browser, weil der Browser vom Nutzer kontrolliert wird. Ein Knopf, der auf dem Bildschirm versteckt wird, schützt nichts, wenn der Server die Anfrage annimmt. Aus demselben Grund kann eine Prüfung, die an nur einer Stelle fehlt, eine ganze Ressource offenlegen.
Was ist mit den Daten des Nutzers selbst?
Die Rolle reicht nicht immer. In der Tabelle oben kann der Kunde Anfragen bearbeiten, aber nur seine eigenen. Das ist eine Regel für den Datensatz und nicht für die Rolle. Die OWASP Top 10 nennen es als Vorbeugung: Die Zugriffsmodelle müssen den Besitz des Datensatzes durchsetzen, damit ein Nutzer die Datensätze anderer nicht lesen, ändern oder löschen kann.
Das Cheat Sheet des OWASP empfiehlt für Anwendungen meist Modelle, die auf Eigenschaften oder Beziehungen schauen (ABAC, ReBAC), weil Rollen an ihre Grenzen kommen, wenn die Entscheidung vom Datensatz selbst abhängt. Deshalb beginnen wir bei den Rollen, die sich der ganzen Gruppe leicht erklären lassen, und ergänzen Besitzregeln dort, wo die Tabelle es verlangt. Bei einer Plattform mit vielen Kunden gibt es noch eine Ebene, die Trennung der Daten pro Tenant, beschrieben im Beitrag zu den Kundendaten in einer SaaS-Plattform.
Wie wird geprüft, dass es funktioniert?
Es wird mit automatischen Tests geprüft, die vor dem Code geschrieben werden. Das OWASP empfiehlt Tests für die Logik der Rechte, die bestätigen, dass der Zugriff standardmäßig verweigert wird und dass die Regeln greifen. Es fügt hinzu, dass automatische Tests die manuelle Sicherheitsprüfung nicht ersetzen.
In unserer Arbeit wird für jede Funktion zuerst der Test geschrieben, und für jede Funktion mit Daten kommt ein Test für den falschen Nutzer hinzu: Was antwortet das System einer anderen Rolle, einem Besucher ohne Anmeldung, einem Nutzer eines anderen Kunden? Zur Methode lesen Sie den Beitrag erst der Test, dann der Code. Ein Team von Agents prüft zusätzlich das fertige Projekt, wie wir in der Fallstudie zu den Agents für Qualität und Sicherheit erklären.
Häufig gestellte Fragen: Rollen und Rechte in einer SaaS-Plattform vor dem Code
Wie viele Rollen braucht eine Plattform?
So viele, wie die Menschen brauchen, die sie nutzen, und nicht mehr. Wir beginnen mit wenigen Rollen, die echten Stellen entsprechen. Braucht das Team etwas dazwischen, kommt es über das Änderungsverfahren hinzu, mit einer neuen Zeile in der Tabelle.
Kann mein Kunde eigene Rollen anlegen?
Das hängt vom Produkt ab und wird in den Anforderungen entschieden. Manche Plattformen haben feste Rollen, andere lassen den Administrator jedes Kunden Rollen festlegen. Die zweite Wahl bedeutet mehr Arbeit, weil jede Rolle mit Tests geprüft werden muss.
Genügt es, die nicht erlaubten Knöpfe zu verstecken?
Nein. Ein versteckter Knopf hilft der Bedienung, ist aber keine Zugriffskontrolle. Die Prüfung erfolgt auf dem Server, bei jeder Anfrage, damit sie auch gilt, wenn jemand die Anfrage auf anderem Weg sendet.
Wann beginnt diese Arbeit?
In der ersten Phase, bei den Anforderungen, vor den Entwürfen der Bildschirme. Die Rechtetabelle beeinflusst Bildschirme, Daten und Tests, deshalb lohnt es sich, sie von Anfang an zu haben.
Sollen wir die Rollen Ihrer Plattform festlegen?
Wenn Sie eine Plattform mit verschiedenen Nutzerrollen planen, ist die Rechtetabelle ein guter erster Schritt, den Sie auch allein auf einer Seite beginnen können. Beschreiben Sie Ihr Projekt in der Projektanfrage, dann vervollständigen wir sie gemeinsam in der Phase der Anforderungen. Sehen Sie sich auch die Seite zu den SaaS-Plattformen an.