Zuerst das Ergebnis definieren
Zugriff beginnt mit einer Geschäftsfrage: Wer darf was mit welchem Datensatz unter welchen Bedingungen tun? Rollennamen allein reichen nicht. Bestimmen Sie Aktionen, Eigentumsgrenzen und Ausnahmebefugnisse. Lesen, Bearbeiten, Exportieren und Zugriffsvergabe sind unterschiedliche Rechte.
Den passenden Ansatz wählen
Für kleine interne Anwendungen können einfache Rollen genügen. Datensatzbesitz, Organisation oder Prozesszustand benötigen möglicherweise zusätzliche Prüfungen. Erzeugen Sie nicht für jede Kombination eine Rolle, wenn wenige Merkmale die Regel klarer beschreiben. OWASP empfiehlt standardmäßige Verweigerung und Prüfung jeder Anfrage; versteckte Buttons sind keine Zugriffsschranke.
Einen konkreten Fall abgleichen
In einem fiktiven Partnerportal liest die Kundenbetreuung eigene Firmenaufträge, Finanzpersonal lädt Rechnungen. Testen Sie jede Aktion mit fremden Firmenkennungen, direkten Downloads und Suchergebnissen. Entfernen Sie anschließend eine Mitgliedschaft bei offenem Browser. Die nächste geschützte Anfrage muss die neue Entscheidung anwenden, nicht die früher geladene Oberfläche.
Nachweise nutzbar halten
Geben Sie Support nicht aus Bequemlichkeit dauerhaften Vollzugriff. Für Ausnahmen definieren Sie Grund, Dauer und Protokoll. Prüfen Sie Exporte, Hintergrundaufgaben und Integrationszugänge ebenso wie Masken. Eine Berechtigungstabelle wird erst mit ausführbaren Prüfungen und Negativtests wirksam.
Die Matrix aus Aktionen und Grenzen entwickeln
Schreiben Sie Aktionen in Zeilen, Rollen in Spalten und ergänzen Sie Datensatzgrenzen. Nur Bestellungen der zugewiesenen Firma lesen zu dürfen ist Teil des Rechts, keine Randnotiz. Berücksichtigen Sie Suche, Download, Export, Hintergrundarbeit und Rechtevergabe. Geschützte Bearbeitung mit offenem Export kann dieselben Daten verraten.
Prüfen Sie Einladung, Organisationsnachweis, Rollenwechsel und Entzug. Bestimmen Sie Änderungen mit zweiter Person sowie Ablauf von Notzugriff. Trennen Sie Geschäftsbetrieb und Anwendungsverwaltung. Einkaufsfreigabe erfordert nicht automatisch Authentifizierungseinstellungen oder Fremddaten. Integrationsidentitäten brauchen enges Aufgabenrecht, Verantwortung und Widerruf.
Machen Sie daraus erlaubte und verbotene Beispiele. Prüfen Sie berechtigte Datensätze, fremde Organisation bei gleicher Rolle, entzogene Mitgliedschaft und direkte Anfrage. Wiederholen Sie für Sammel- und Hintergrundarbeit, deren Rechte sich zwischen Auswahl und Ausführung ändern können. Dokumentieren Sie die Genehmigung sensibler Vorgänge ohne ganze persönliche Inhalte. Lassen Sie einen abgelehnten Vorgang damit untersuchen. Die Ablehnung schützt und bietet berechtigten Nutzern einen Korrekturweg ohne fremde Daten zu verraten.
Abnahmefälle für Rechte
| Fall | Erwartete Grenze |
|---|---|
| Gleiche Rolle, andere Organisation | Keine fremden Datensätze, Suchergebnisse oder Anhänge allein aufgrund der Rolle. |
| Entzug bei offener Sitzung | Die nächste Aktion nutzt aktuelle Befugnis statt früher gerenderter Kontrolle. |
| Eigene Höherstufung versucht | Die Freigaberegel greift; der Versuch bleibt nachvollziehbar ohne heimlichen Machtgewinn. |
| Export nach Rechteänderung | Die Ausführung folgt der vereinbarten Regel, nicht allein einer alten Auswahl. |
Fragen an die Verantwortlichen
Wer vergibt und entzieht Rechte? Kann jemand die eigene Höherstufung genehmigen? Welche Datensätze bleiben trotz gleicher Rolle getrennt? Bringen Sie eine Rollen-Aktions-Datensatz-Matrix und verbotene Beispiele zur Prüfung. Unzulässiges ist ebenso wichtig wie Erlaubtes.
Quellen und weiterführende Informationen
Individuelle Software
Software, die zu Ihren Arbeitsabläufen passt.
Über diese Leistung sprechen