Autorisierung
Ein authentifizierter Aufrufer darf nicht automatisch jede Ressource bearbeiten.
- SubjektSubjekt: Nutzer oder Dienst fordert eine Aktion an.
- RessourceRessource: Zielobjekt und Schutzbedarf werden benannt.
- RegelRegel: Kontext entscheidet über erlaubte Handlung.
Einordnung
Warum das wichtig ist
Handlungen anhand expliziter Zugriffsregeln erlauben.
Handlungen anhand expliziter Zugriffsregeln erlauben.
Autorisierung: Entscheidung prüfen
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Eine Supportmitarbeiterin authentifiziert sich am Shop-Backoffice. Beim Öffnen von Bestellung B-1042 prüft der Dienst ihre Supportrolle, den Kundenbezug und die angeforderte Aktion. Sie darf Status und Versandverlauf lesen, aber die Zahlung nicht erneut auslösen. Die Regel wird serverseitig für jeden Zugriff angewandt und im Audit mit Subjekt, Ressource und Ergebnis festgehalten. Ein UI-Schalter allein würde die geschützte Aktion nicht absichern.
So liest du das Bild
- Subjekt Subjekt
- Ressource Ressource
- Regel Regel
| Begriff | Bedeutung | Prüffrage |
|---|---|---|
| Subjekt | Nutzer oder Dienst fordert eine Aktion an. | Welche Aktion bleibt dem Kundenprozess vorbehalten? |
| Ressource | Zielobjekt und Schutzbedarf werden benannt. | Welche Bestandteile sollte die Zugriffsregel benennen? |
| Regel | Kontext entscheidet über erlaubte Handlung. | Wo muss die Regel durchgesetzt werden? |
Nutzen & Grenzen
Hilft, wenn
- Handlungen anhand expliziter Zugriffsregeln erlauben.
- Jede Regel als Subjekt-Aktion-Ressource-Kontext modellieren.
Grenzen
- Verteilte Zugriffspfade können unterschiedliche Policy-Stände besitzen.
- Ressourcen- und Mandantengrenzen müssen in jeder API-Operation geprüft werden, auch bei indirekten Objektkennungen.
In der Praxis
- Formuliere die Supportregel mit Subjekt, Aktion, Ressource und Kontext und unterscheide Lesen von Statusdaten ausdrücklich vom erneuten Auslösen einer Zahlung.
- Rufe dieselbe Bestellressource mit erlaubter Supportrolle, fremdem Kundenbezug und unzulässiger Aktion direkt über die API auf; erwarte serverseitige Ablehnung.
- Prüfe Auditdaten auf Subjekt, Ressource, Aktion und Ergebnis und wiederhole den Test nach einer Policy-Änderung über alle relevanten Zugriffspfade.
Ausführliche Erklärung lesen
Autorisierung entscheidet, ob ein identifiziertes Subjekt eine konkrete Aktion auf einer Ressource unter den geltenden Bedingungen ausführen darf. Eine Entscheidung berücksichtigt typischerweise Rolle, Objekt, Aktion und Kontext.
Regeln können in ACLs, Rollen oder Policies ausgedrückt werden. Sie müssen an jedem relevanten Zugriffspunkt gelten und bei Änderungen widerrufbar bleiben; ein erfolgreicher Login begründet keine pauschale Erlaubnis.
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Eine Supportmitarbeiterin authentifiziert sich am Shop-Backoffice. Beim Öffnen von Bestellung B-1042 prüft der Dienst ihre Supportrolle, den Kundenbezug und die angeforderte Aktion. Sie darf Status und Versandverlauf lesen, aber die Zahlung nicht erneut auslösen. Die Regel wird serverseitig für jeden Zugriff angewandt und im Audit mit Subjekt, Ressource und Ergebnis festgehalten. Ein UI-Schalter allein würde die geschützte Aktion nicht absichern. auth und authentication helfen, diese Entscheidung mit benachbarten Fragen zu vergleichen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Aktion bleibt dem Kundenprozess vorbehalten?
Lösung mit Begründung ansehen
Eine erneute Zahlung; Support darf nur den Bestellstatus lesen.
AnwendenAuf eine neue Lage übertragen
Welche Bestandteile sollte die Zugriffsregel benennen?
Lösung mit Begründung ansehen
Subjekt, Aktion, Ressource und relevanten Kontext wie Mandant oder Eigentümer.
BewertenEine Alternative abwägen
Wo muss die Regel durchgesetzt werden?
Lösung mit Begründung ansehen
An jeder API-Operation, die den geschützten Zustand liest oder ändert.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Authorization Cheat Sheet (öffnet in neuem Tab)OWASP-Empfehlungen zur Durchsetzung von Zugriffsregeln.
- NIST SP 800-162 Attribute Based Access Control (öffnet in neuem Tab)NIST-Modell für kontextbezogene Autorisierungsentscheidungen.
- OWASP Access Control Testing Guide (öffnet in neuem Tab)Prüft Zugriffskontrolle an geschützten Funktionen und Objekten.