Anderen Personen zu ermöglichen, Aufgaben im Namen einer Person zu erledigen, kann einem tatsächlichen geschäftlichen Bedarf entsprechen. Das sollte jedoch weder die Weitergabe von Passwörtern noch den allgemeinen Zugriff auf ein Konto erfordern. In einer PHP-Anwendung muss bei einer sicheren Delegation klar sein, wer handelt, wen diese Person vertritt, auf welche Ressourcen sie zugreifen darf und wie lange. Außerdem muss die Delegation widerrufbar und auditierbar sein.
Ziel ist es, eine konkrete Aktion zu autorisieren und dabei die Identität beider Personen zu erhalten. Dafür braucht es mehr als eine Oberfläche zum Erteilen von Berechtigungen: Betroffen sind das Datenmodell, jeder Autorisierungspunkt, asynchrone Vorgänge und Tests. Wenn diese Elemente gemeinsam entworfen werden, sinkt das Risiko, dass eine auf einer Seite gültige Delegation über einen alternativen Pfad zu übermäßigem Zugriff führt.
Delegation, Identitätswechsel und gemeinsam genutzten Zugriff unterscheiden
Bei einer Delegation bleibt die Person, die den Vorgang startet, die authentifizierte Identität. Zusätzlich protokolliert die Anwendung, dass sie im Rahmen einer begrenzten Berechtigung eine andere Person vertritt. Die vertretene Person hat sich nicht angemeldet und darf nicht als direkte Urheberin der Anfrage erscheinen.
Bei einer Identitätsübernahme ändert sich die effektive Identität, unter der das System eine Anfrage behandelt. Ohne spezielle Kontrollen kann dadurch verborgen bleiben, wer die Aktion ausgeführt hat. Gemeinsam genutzter Zugriff, etwa durch die Weitergabe von Zugangsdaten, hebt die Trennung zwischen Benutzern auf und erschwert den Widerruf und die Zuordnung von Aktivitäten. Für einen gewöhnlichen Delegationsablauf ersetzt keiner dieser Ansätze einen expliziten Kontext mit handelnder Person und vertretener Person.
Es empfiehlt sich, beide Rollen im Code und in den Protokollen eindeutig zu benennen. Beispielsweise bezeichnet actor_id die Person, die den Vorgang ausgeführt hat, und principal_id die Person, in deren Namen er ausgeführt wurde. Vermeide mehrdeutige Namen wie user_id in Protokollen, in denen damit eine der beiden Personen gemeint sein könnte.
Umfang, Ressourcen und Gültigkeit vor der Implementierung festlegen
Eine sinnvolle Delegation beschreibt genau, wozu sie berechtigt. „Konto verwalten“ ist in der Regel zu weit gefasst. Stattdessen kann die Delegation auf Aktionen wie Aufgaben prüfen, ihren Status aktualisieren oder auf eine Anfrage antworten begrenzt werden. Wenn sich die Folgen der Aktionen unterscheiden, modelliere separate Berechtigungen, anstatt Lesen, Bearbeiten, Genehmigen und Löschen in einer allgemeinen Berechtigung zusammenzufassen.
Lege auch den Geltungsbereich der Ressourcen fest: eine Organisation, ein Projekt, eine Aufgabenliste oder eine bestimmte Gruppe von Datensätzen. Die Berechtigung, Aufgaben in einem Projekt zu bearbeiten, sollte nicht allein deshalb das Lesen von Daten aus einem anderen Projekt ermöglichen, weil dieselbe delegierte Person über eine andere Funktion auf beide zugreifen kann.
Die Gültigkeit muss einen eindeutigen Beginn und ein eindeutiges Ende haben. Außerdem braucht es einen Status, mit dem die Delegation vor Ablauf widerrufen werden kann. Lege fest, welche Zeitzone zur Anzeige von Datumsangaben verwendet wird, und halte interne Vergleiche konsistent. Wenn die Richtlinie eine Genehmigung verlangt oder verkettete Delegationen verhindert, formuliere das als explizite und überprüfbare Regel, statt es als Konvention der Benutzeroberfläche zu behandeln.
Die Autorisierung modellieren und bei jeder Operation prüfen
Ein relationales Schema kann eine Delegation mit Feldern wie einer Kennung, dem autorisierten Akteur, der vertretenen Person, dem Geltungsbereich, den Aktionen, Startdatum, Ablaufdatum, Status, erstellender Person und Widerrufsdatum abbilden. Die genaue Struktur hängt vom Anwendungsbereich ab: Aktionen können in einer verknüpften Tabelle oder in einem anderen validierten Format gespeichert werden. Sie müssen sich jedoch eindeutig abfragen und prüfen lassen.
Bei der Autorisierung müssen die Berechtigungen der vertretenen Person von der an den Akteur delegierten Autorisierung getrennt werden. Prüfe für den angeforderten Vorgang, ob die vertretene Person normalerweise Zugriff auf die Ressource hätte und ob die geltenden Geschäftsregeln den Vorgang erlauben. Prüfe anschließend, ob der authentifizierte Akteur Empfänger einer gültigen, nicht widerrufenen Delegation ist und ob diese die betreffende Aktion für die Ressource erlaubt. Die effektive Berechtigung wird sowohl durch den Zugriff der vertretenen Person als auch durch den Umfang der Delegation begrenzt: Die Delegation darf dem Akteur weder mehr Aktionen oder Ressourcen gewähren, als die vertretene Person autorisieren kann, noch mehr, als in der Delegation selbst festgelegt ist. Verlange nicht, dass der Akteur zusätzlich einen eigenen Zugriff auf die Ressource hat; gerade durch die Delegation kann er handeln. Wende jedoch die Einschränkungen an, die für die Identität des Akteurs gelten, etwa Authentifizierung, Zugehörigkeit zum erforderlichen Kontext oder Sicherheitskontrollen für den Vorgang.
In der Praxis sollte die Prüfung Folgendes umfassen:
- Der Akteur ist authentifiziert und die Delegation gilt für ihn.
- Die vertretene Person ist in diesem Kontext gültig und hat normalerweise Zugriff auf die angeforderte Ressource.
- Die Delegation ist zum Zeitpunkt des Vorgangs aktiv, nicht widerrufen und innerhalb ihrer Gültigkeitsdauer.
- Die angeforderte Aktion und die Ressource liegen innerhalb des gewährten Umfangs und überschreiten nicht die Berechtigungen der vertretenen Person.
- Die für den Akteur und den Vorgang geltenden Geschäfts- und Sicherheitsbeschränkungen sind erfüllt.
Bündle diese Entscheidung in einem Autorisierungsdienst oder einer wiederverwendbaren Richtlinie, anstatt Teilbedingungen in Controllern zu wiederholen. Rufe sie trotzdem bei jedem relevanten Vorgang auf: Eine geschützte Ansicht schützt nicht automatisch eine API, einen Download, eine Massenaktion oder eine Administrationsroute. In PHP kann der Controller den authentifizierten Akteur abrufen, den Delegationskontext auflösen und den Dienst um die Autorisierung der Aktion für die konkrete Ressource bitten. Bei folgenreichen Vorgängen kann auch die Domänenschicht kritische Invarianten durchsetzen.
Vertraue einer vom Browser übermittelten principal_id nicht als Autorisierungsnachweis. Der Server muss die Beziehung zwischen Akteur, vertretener Person, Delegation, Ressource und Aktion anhand vertrauenswürdiger Daten prüfen. Gehe auch nicht davon aus, dass das Ausblenden einer Schaltfläche in der Benutzeroberfläche den direkten Aufruf des Endpunkts verhindert.
Zuordnung in Audit-Protokollen und asynchronen Vorgängen erhalten
Ein aussagekräftiger Protokolleintrag ermöglicht es, nachzuvollziehen, was geschehen ist, ohne Identitäten zu verwechseln. Halte für jedes relevante Ereignis den Akteur, die vertretene Person, die Aktion, den Ressourcentyp und die Ressourcenkennung, den Zeitpunkt, das Ergebnis sowie einen Verweis auf die angewandte Delegation fest. Je nach Risiko solltest du auch den Grund des Vorgangs oder eine Korrelationskennung protokollieren. Speichere im Verlauf keine Geheimnisse oder unnötigen personenbezogenen Daten.
Die Zuordnung muss auch bei Warteschlangen und Hintergrundaufträgen erhalten bleiben. Wenn eine delegierte Anfrage einen Auftrag einplant, sollte die Nachricht einen überprüfbaren Kontext mit Akteur, vertretener Person und Autorisierungsreferenz übermitteln, statt von der Websitzung abzuhängen, die dann nicht mehr verfügbar ist. Entscheide bei der Ausführung des Auftrags, ob erneut geprüft wird, ob die Delegation noch aktiv ist. Bei einer Aktion, die noch abgebrochen werden kann, verhindert eine Prüfung zum Ausführungszeitpunkt in der Regel, dass ein Widerruf einen ausstehenden Auftrag mit veralteter Berechtigung zurücklässt. Wenn der Vorgang bereits unumkehrbar festgelegt wurde, dokumentiere diese Grenze und protokolliere den Zeitpunkt der Autorisierung.
Schütze die Protokolle vor unbefugten Änderungen und beschränke, wer sie einsehen darf. Die Audit-Protokollierung sollte Untersuchungen und Rechenschaft unterstützen, aber nicht zu einer undifferenzierten Kopie der Betriebsdaten werden.
Ablauf und Widerruf als Teil des Ablaufs entwerfen
Ablauf und Widerruf sind nicht lediglich Statusänderungen auf einer Seite. Eine Sitzung, die einen Delegationskontext speichert, kann weiterhin veraltete Optionen anzeigen. Deshalb muss die Autorisierung auf dem Server den aktuellen Status bei jeder Anfrage prüfen, auch wenn die Benutzeroberfläche ebenfalls aktualisiert wird. Wenn Berechtigungen zwischengespeichert werden, lege fest, wie sie ungültig gemacht werden und welche maximale Verzögerung akzeptabel ist, bis ein Widerruf wirksam wird.
Protokolliere beim Widerruf, wer ihn vorgenommen hat und wann. Berücksichtige ausdrücklich aktive Sitzungen, ausgestellte Tokens, Warteschlangenaufträge und zugehörige temporäre Links. Gehe nicht davon aus, dass das Beenden einer Sitzung oder das Ändern eines Datenbankwerts all diese Elemente automatisch ungültig macht. Die passende Vorgehensweise hängt vom Design ab, muss aber vor der Veröffentlichung des Ablaufs feststehen.
Grenzfälle und leicht übersehene Situationen testen
Tests müssen sowohl erlaubte als auch verweigerte Aktionen überprüfen. Berücksichtige mindestens: Delegationen, die noch nicht gültig, abgelaufen oder widerrufen sind; einen anderen als den autorisierten Akteur; eine Ressource außerhalb des Geltungsbereichs; eine nicht gewährte Aktion; eine falsche vertretene Person oder eine Person ohne normalen Zugriff auf die Ressource; sowie den direkten Zugriff auf Endpunkte, die in der Benutzeroberfläche nicht angezeigt werden. Nimm auch einen positiven Fall auf, in dem der Akteur keinen eigenen Zugriff auf die Ressource hat, die vertretene Person jedoch schon und die Delegation sowohl die Aktion als auch die Ressource abdeckt. So lässt sich prüfen, dass das System die eigenen Berechtigungen des Akteurs nicht mit der delegierten Autorität verwechselt.
Ergänze Tests zu zeitlichen Grenzen, gleichzeitigen Änderungen und indirekten Auswirkungen. Prüfe beispielsweise, was geschieht, wenn eine Delegation widerrufen wird, während ein Vorgang läuft oder ein Auftrag aussteht, und ob eine Aktion an einer Aufgabe Benachrichtigungen, Exporte oder weitere Änderungen auslöst. Stelle sicher, dass diese Auswirkungen korrekt zugeordnet bleiben und den Geltungsbereich nicht erweitern.
Trenne Unit-Tests der Autorisierungsrichtlinie von Integrationstests, die Routen, Persistenz und Warteschlangen durchlaufen. Ein Test, der nur die Entscheidungsmethode prüft, beweist nicht, dass alle Routen sie aufrufen. Ein Test der Benutzeroberfläche belegt ebenso wenig den Schutz auf dem Server.
Checkliste vor der Veröffentlichung
- Sind Akteur und vertretene Person in Code, Benutzeroberfläche und Audit-Protokollen eindeutig unterschieden?
- Begrenzt jede Delegation Aktionen, Ressourcen und Gültigkeitsdauer, und werden ungültige Kombinationen verhindert?
- Prüft die Richtlinie den Zugriff der vertretenen Person und begrenzt den Akteur auf den delegierten Umfang, ohne einen eigenen Zugriff auf die Ressource zu verlangen?
- Prüft jeder serverseitige Vorgang Identität, Status, Zeitpunkt, Geltungsbereich und Aktion?
- Wirkt sich ein Widerruf gemäß einer festgelegten Richtlinie auf Sitzungen, Tokens, Caches und ausstehende Aufträge aus?
- Ermöglichen die Protokolle die Zuordnung von Aktionen, ohne unnötige Informationen zu speichern?
- Decken die Tests verweigerte Aktionen, zeitliche Grenzen, gültige Delegationen ohne eigenen Zugriff des Akteurs und indirekte Auswirkungen ab?
Eine Delegation ist sicher, wenn sie nicht mit dem Zugriff auf das Konto einer anderen Person verwechselt wird und jede Aktion durch die Berechtigungen der vertretenen Person sowie eine gültige, begrenzte Delegation begründet werden kann. Wenn das Team nicht präzise beantworten kann, wer gehandelt hat, in wessen Namen, für welche Ressource und auf Grundlage welcher Berechtigung, muss der Ablauf vor dem Produktiveinsatz noch besser ausgearbeitet werden.
