Bewährte Methoden für die Gestaltung eines Autorisierungsmodells

Wenn Sie sich darauf vorbereiten, den Service Amazon Verified Permissions in einer Softwareanwendung zu nutzen, kann es schwierig sein, als ersten Schritt sofort mit dem Verfassen von Richtlinienerklärungen zu beginnen. Dies wäre vergleichbar mit dem Beginn der Entwicklung anderer Teile einer Anwendung, indem Sie SQL Erklärungen oder API Spezifikationen verfassen, bevor Sie vollständig entscheiden, welche Funktion die Anwendung erfüllen soll. Stattdessen sollten Sie mit einer Benutzererfahrung beginnen und sich ein klares Bild davon machen, was Endbenutzer bei der Verwaltung von Berechtigungen in der Anwendungsbenutzeroberfläche sehen sollten. Gehen Sie dann von dieser Erfahrung aus, um zu einem Implementierungsansatz zu gelangen.

Während Sie diese Arbeit erledigen, werden Sie feststellen, dass Sie sich Fragen stellen wie:

• Was sind meine Ressourcen? Haben sie Beziehungen zueinander? Befinden sich Dateien beispielsweise in einem Ordner?

• Welche Aktionen können Principals für jede Ressource ausführen?

• Wie erwerben Principals diese Berechtigungen?

• Möchten Sie, dass Ihre Endbenutzer aus vordefinierten Berechtigungen wie „Admin“, „Operator“ oder „“ wählen können, oder sollten sie Ad-hoc-Richtlinienerklärungen erstellen? ReadOnly Oder beides?

• Sollten Berechtigungen ressourcenübergreifend vererbt werden, z. B. Dateien, die Berechtigungen von einem übergeordneten Ordner erben?

• Welche Arten von Abfragen sind erforderlich, um die Benutzererfahrung zu verbessern? Müssen Sie beispielsweise alle Ressourcen auflisten, auf die ein Principal zugreifen kann, um die Startseite dieses Benutzers zu rendern?

• Können sich Benutzer versehentlich selbst von ihren eigenen Ressourcen ausschließen? Muss das vermieden werden?

Das Endergebnis dieser Übung wird als Autorisierungsmodell bezeichnet. Es definiert die Prinzipien, Ressourcen und Aktionen und wie sie zueinander in Beziehung stehen. Für die Erstellung dieses Modells sind keine besonderen Kenntnisse über Cedar oder den Dienst Verified Permissions erforderlich. Stattdessen ist es in erster Linie eine Übung zur Gestaltung der Benutzererfahrung, wie jede andere Übung, die sich in Artefakten wie Schnittstellenmodellen, logischen Diagrammen und einer allgemeinen Beschreibung dessen, wie Berechtigungen beeinflussen, was Benutzer im Produkt sehen, äußern kann. Cedar ist so konzipiert, dass es flexibel genug ist, um den Kunden bei einem Modell entgegenzukommen, anstatt das Modell zu zwingen, sich unnatürlich zu verbiegen, um der Implementierung eines Cedar zu entsprechen. Daher ist ein klares Verständnis der gewünschten Benutzererfahrung der beste Weg, um zu einem optimalen Modell zu gelangen.

Dieser Abschnitt enthält allgemeine Hinweise zur Vorgehensweise bei der Entwurfsübung, worauf Sie achten sollten, und eine Sammlung von bewährten Methoden für die erfolgreiche Verwendung verifizierter Berechtigungen.

Denken Sie daran, zusätzlich zu den hier vorgestellten Richtlinien auch die bewährten Verfahren im Referenzhandbuch für Richtlinien von Cedar zu berücksichtigen.

Es gibt kein kanonisches „richtiges“ Modell

Wenn Sie ein Autorisierungsmodell entwerfen, gibt es keine einzige, eindeutig richtige Antwort. Verschiedene Anwendungen können effektiv unterschiedliche Autorisierungsmodelle für ähnliche Konzepte verwenden, und das ist in Ordnung. Stellen Sie sich zum Beispiel die Darstellung des Dateisystems eines Computers vor. Wenn Sie eine Datei in einem UNIX-ähnlichen Betriebssystem erstellen, erbt sie nicht automatisch die Berechtigungen des übergeordneten Ordners. Im Gegensatz dazu erben Dateien in vielen anderen Betriebssystemen und den meisten Online-Filesharing-Diensten die Berechtigungen des übergeordneten Ordners. Beide Optionen sind gültig, je nachdem, für welche Umstände die Anwendung optimiert wird.

Die Richtigkeit einer Autorisierungslösung ist nicht absolut, sondern sollte im Hinblick darauf betrachtet werden, wie sie das von Ihren Kunden gewünschte Erlebnis bietet und ob sie ihre Ressourcen so schützt, wie sie es erwarten. Wenn Ihr Autorisierungsmodell dies erfüllt, ist es erfolgreich.

Aus diesem Grund ist es die hilfreichste Voraussetzung für die Erstellung eines effektiven Autorisierungsmodells, Ihr Design mit der gewünschten Benutzererfahrung zu beginnen.

Konzentrieren Sie sich über den API Betrieb hinaus auf Ihre Ressourcen

In den meisten kundenorientierten Anwendungen orientieren sich die Berechtigungen an den Ressourcen, die von der Anwendung unterstützt werden. Beispielsweise kann eine Filesharing-Anwendung Berechtigungen als Aktionen darstellen, die für eine Datei oder einen Ordner ausgeführt werden können. Dies ist ein gutes, einfaches Modell, das die zugrunde liegende Implementierung und die Backend-Operationen abstrahiert. API

Im Gegensatz dazu entwerfen andere Arten von Anwendungen, insbesondere Webservices, häufig Berechtigungen im Zusammenhang mit den API Vorgängen selbst. Wenn ein Webdienst beispielsweise eine API benanntecreateThing(), das Autorisierungsmodell eine entsprechende Berechtigung oder eine action in Cedar benannte Berechtigung bereitstelltcreateThing. Dies funktioniert in vielen Situationen und macht es einfach, die Berechtigungen zu verstehen. Um den createThing Vorgang aufzurufen, benötigen Sie die createThing Aktionsberechtigung. Scheint einfach, oder?

Sie werden feststellen, dass der Prozess „Erste Schritte“ in der Konsole „Verifizierte Berechtigungen“ die Option beinhaltet, Ihre Ressourcen und Aktionen direkt aus einem zu erstellenAPI. Dies ist eine nützliche Grundlage: eine direkte Zuordnung zwischen Ihrem Richtlinienspeicher und demAPI, für den er autorisiert ist.

Dieser API fokussierte Ansatz kann jedoch alles andere als optimal sein, da er APIs lediglich ein Proxy für das ist, was Ihre Kunden wirklich schützen wollen: die zugrunde liegenden Daten und Ressourcen. Wenn mehrere Personen den Zugriff auf dieselben Ressourcen APIs kontrollieren, kann es für Administratoren schwierig sein, sich Gedanken über die Pfade zu diesen Ressourcen zu machen und den Zugriff entsprechend zu verwalten.

Stellen Sie sich zum Beispiel ein Benutzerverzeichnis vor, das die Mitglieder einer Organisation enthält. Benutzer können in Gruppen organisiert werden, und eines der Sicherheitsziele besteht darin, die Entdeckung von Gruppenmitgliedschaften durch Unbefugte zu verhindern. Der Dienst, der dieses Benutzerverzeichnis verwaltet, bietet zwei API Operationen:

• listMembersOfGroup

• listGroupMembershipsForUser

Kunden können jeden dieser Vorgänge verwenden, um die Gruppenmitgliedschaft zu ermitteln. Daher muss der Berechtigungsadministrator daran denken, den Zugriff auf beide Vorgänge zu koordinieren. Dies wird noch komplizierter, wenn Sie später einen neuen API Vorgang hinzufügen möchten, um weitere Anwendungsfälle zu behandeln, z. B. die folgenden.

• isUserInGroups(eine neue OptionAPI, um schnell zu testen, ob ein Benutzer zu einer oder mehreren Gruppen gehört)

Aus Sicherheitsgründen API eröffnet dies einen dritten Weg zur Erkennung von Gruppenmitgliedschaften, wodurch die sorgfältig ausgearbeiteten Berechtigungen des Administrators beeinträchtigt werden.

Wir empfehlen, die API Semantik zu ignorieren und sich stattdessen auf die zugrunde liegenden Daten und Ressourcen und deren Zuordnungsvorgänge zu konzentrieren. Die Anwendung dieses Ansatzes auf das Beispiel der Gruppenmitgliedschaft würde zu einer abstrakten Berechtigung führen, wie z. B.viewGroupMembership, dass bei jeder der drei API Operationen eine Abfrage erforderlich ist.

APIName	Berechtigungen
listMembersOfGroup	benötigt eine viewGroupMembership Genehmigung für die Gruppe
listGroupMembershipsForUser	erfordert viewGroupMembership die Erlaubnis des Benutzers
isUserInGroups	erfordert viewGroupMembership die Erlaubnis des Benutzers

Durch die Definition dieser einen Berechtigung kontrolliert der Administrator erfolgreich den Zugriff auf die Erkennung von Gruppenmitgliedschaften — jetzt und für immer. Als Kompromiss muss nun jeder API Vorgang die möglicherweise mehreren erforderlichen Berechtigungen dokumentieren, und der Administrator muss diese Dokumentation bei der Erstellung von Berechtigungen heranziehen. Dies kann ein gültiger Kompromiss sein, wenn es notwendig ist, um Ihre Sicherheitsanforderungen zu erfüllen.

Die kombinierte Autorisierung ist normal

Eine kombinierte Autorisierung liegt vor, wenn für eine einzelne Benutzeraktivität, z. B. das Klicken auf eine Schaltfläche in der Benutzeroberfläche Ihrer Anwendung, mehrere individuelle Autorisierungsabfragen erforderlich sind, um festzustellen, ob diese Aktivität zulässig ist. Beispielsweise sind für das Verschieben einer Datei in ein neues Verzeichnis in einem Dateisystem möglicherweise drei verschiedene Berechtigungen erforderlich: die Fähigkeit, eine Datei aus dem Quellverzeichnis zu löschen, die Möglichkeit, dem Zielverzeichnis eine Datei hinzuzufügen, und möglicherweise die Möglichkeit, die Datei selbst zu berühren (abhängig von der Anwendung).

Wenn Sie mit der Entwicklung eines Autorisierungsmodells noch nicht vertraut sind, denken Sie vielleicht, dass jede Autorisierungsentscheidung in einer einzigen Autorisierungsabfrage lösbar sein muss. Dies kann jedoch zu übermäßig komplexen Modellen und verworrenen Grundsatzerklärungen führen. In der Praxis kann die Verwendung zusammengesetzter Autorisierungen hilfreich sein, um ein einfacheres Autorisierungsmodell zu erstellen. Ein gutes Autorisierungsmodell zeichnet sich unter anderem dadurch aus, dass Ihre zusammengesetzten Operationen, z. B. das Verschieben einer Datei, durch eine intuitive Aggregation von Primitiven dargestellt werden können, wenn Sie einzelne Aktionen ausreichend zerlegt haben.

Eine weitere Situation, in der eine kombinierte Autorisierung auftritt, ist, wenn mehrere Parteien an der Erteilung einer Genehmigung beteiligt sind. Stellen Sie sich ein Organisationsverzeichnis vor, in dem Benutzer Mitglieder von Gruppen sein können. Ein einfacher Ansatz besteht darin, dem Gruppenbesitzer die Erlaubnis zu erteilen, beliebige Personen hinzuzufügen. Was ist jedoch, wenn Sie möchten, dass Ihre Benutzer zuerst dem Hinzufügen zustimmen? Dadurch wird eine Handshake-Vereinbarung eingeführt, in der sowohl der Benutzer als auch die Gruppe der Mitgliedschaft zustimmen müssen. Um dies zu erreichen, können Sie eine weitere, an den Benutzer gebundene Berechtigung einführen, die festlegt, ob der Benutzer zu einer beliebigen Gruppe oder zu einer bestimmten Gruppe hinzugefügt werden kann. Wenn ein Anrufer anschließend versucht, Mitglieder zu einer Gruppe hinzuzufügen, muss die Anwendung beide Seiten der Berechtigungen erzwingen: Der Anrufer muss berechtigt sein, Mitglieder zu der angegebenen Gruppe hinzuzufügen, und dass der einzelne hinzugefügte Benutzer über die erforderlichen Berechtigungen verfügt. Wenn N -way-Handshakes existieren, ist es üblich, N zusammengesetzte Autorisierungsanfragen zu beobachten, um jeden Teil der Vereinbarung durchzusetzen.

Wenn Sie sich mit einer Entwurfsherausforderung konfrontiert sehen, bei der mehrere Ressourcen involviert sind und unklar ist, wie die Berechtigungen modelliert werden sollen, kann dies ein Zeichen dafür sein, dass Sie ein kombiniertes Autorisierungsszenario haben. In diesem Fall könnte eine Lösung gefunden werden, indem der Vorgang in mehrere, individuelle Autorisierungsprüfungen aufgeteilt wird.

Überlegungen zur Mehrmandantenfähigkeit

Möglicherweise möchten Sie Anwendungen für die Nutzung durch mehrere Kunden — Unternehmen, die Ihre Anwendung nutzen, oder Mandanten — entwickeln und sie in Amazon Verified Permissions integrieren. Bevor Sie Ihr Autorisierungsmodell entwickeln, sollten Sie eine Mehrmandantenstrategie entwickeln. Sie können die Richtlinien Ihrer Kunden in einem gemeinsamen Richtlinienspeicher verwalten oder jedem einzelnen Mandanten einen Richtlinienspeicher zuweisen.

1. Ein gemeinsam genutzter Richtlinienspeicher

   Alle Mandanten teilen sich einen einzigen Richtlinienspeicher. Die Anwendung sendet alle Autorisierungsanfragen an den gemeinsamen Richtlinienspeicher.

2. Richtlinienspeicher pro Mandant

   Jeder Mandant hat einen eigenen Richtlinienspeicher. Die Anwendung fragt je nach Mandant, der die Anfrage stellt, verschiedene Richtlinienspeicher nach einer Autorisierungsentscheidung ab.

Keine der beiden Strategien führt zu einem relativ höheren Volumen an Autorisierungsanfragen, was sich auf Ihre Rechnung auswirken könnte. AWS Wie sollten Sie dann Ihren Ansatz gestalten? Im Folgenden finden Sie allgemeine Bedingungen, die zu Ihrer Mehrmandanten-Autorisierungsstrategie von Verified Permissions beitragen könnten.

Isolierung der Mandantenrichtlinien

Die Isolierung der Richtlinien der einzelnen Mandanten von den anderen ist wichtig, um die Mandantendaten zu schützen. Wenn jeder Mandant seinen eigenen Richtlinienspeicher hat, hat jeder seine eigenen isolierten Richtlinien.

Ablauf der Autorisierung

Sie können einen Mandanten, der eine Autorisierungsanfrage stellt, anhand einer Policy-Store-ID in der Anfrage identifizieren, und zwar mit Policy-Stores pro Mandant. Bei einem gemeinsam genutzten Richtlinienspeicher verwenden alle Anfragen dieselbe Richtlinienspeicher-ID.

Vorlagen und Schemaverwaltung

Ihre Richtlinienvorlagen und ein Richtlinienspeicher-Schema erhöhen den Entwurfs- und Wartungsaufwand für jeden Richtlinienspeicher.

Verwaltung globaler Richtlinien

Möglicherweise möchten Sie einige globale Richtlinien auf jeden Mandanten anwenden. Die Höhe des Verwaltungsaufwands für globale Richtlinien variiert je nach Modell mit gemeinsam genutztem und mandantenspezifischem Policy-Store.

Ausgliederung von Mandanten

Einige Mieter werden Elemente zu Ihrem Schema und Ihren Richtlinien beitragen, die für ihren Fall spezifisch sind. Wenn ein Mandant nicht mehr in Ihrer Organisation aktiv ist und Sie seine Daten entfernen möchten, hängt der Aufwand davon ab, inwieweit er von anderen Mandanten isoliert ist.

Kontingente für Service-Ressourcen

Verified Permissions verfügt über Ressourcen- und Anforderungsquoten, die Ihre Entscheidung für mehrere Mandanten beeinflussen können. Weitere Informationen zu Kontingenten finden Sie unter Kontingente für Ressourcen.

Vergleich von gemeinsam genutzten Richtlinienspeichern und Richtlinienspeichern pro Mandant

Jede Überlegung erfordert ihr eigenes Maß an Zeit und Ressourcen in Form von gemeinsam genutzten und mandantenspezifischen Policy-Store-Modellen.

Überlegungen	Umfang des Aufwands in einem gemeinsamen Richtlinienspeicher	Umfang des Aufwands in den Policy-Speichern pro Mandant
Isolierung von Mandantenrichtlinien	Mittel.Muss Mandantenkennungen in Richtlinien und Autorisierungsanfragen enthalten.	Niedrig. Isolation ist Standardverhalten. Auf mandantenspezifische Richtlinien können andere Mandanten nicht zugreifen.
Ablauf der Autorisierung	Niedrig. Alle Abfragen zielen auf einen Richtlinienspeicher ab.	Mittel. Muss die Zuordnungen zwischen jedem Mandanten und seiner Policy-Store-ID beibehalten.
Vorlagen und Schemaverwaltung	Niedrig. Muss dafür sorgen, dass ein Schema für alle Mandanten funktioniert.	Hoch. Schemas und Vorlagen mögen für sich genommen weniger komplex sein, Änderungen erfordern jedoch mehr Koordination und Komplexität.
Globales Policy-Management	Niedrig. Alle Richtlinien sind global und können zentral aktualisiert werden.	Hoch. Beim Onboarding müssen Sie jedem Richtlinienspeicher globale Richtlinien hinzufügen. Replizieren Sie globale Richtlinienaktualisierungen zwischen vielen Richtlinienspeichern.
Ausgliederung von Mandanten	Mittel. Es müssen nur mandantenspezifische Richtlinien identifiziert und gelöscht werden.	Niedrig. Löschen Sie den Richtlinienspeicher.
Kontingente für Service-Ressourcen	Hoch. Mandanten teilen sich Ressourcenkontingente, die sich auf Richtlinienspeicher wie Schemagröße, Richtliniengröße pro Ressource und Identitätsquellen pro Richtlinienspeicher auswirken.	Niedrig. Jeder Mandant hat eigene Ressourcenkontingente.

Wie soll man wählen

Jede Multi-Tenant-Anwendung ist anders. Vergleichen Sie die beiden Ansätze und ihre Überlegungen sorgfältig, bevor Sie eine architektonische Entscheidung treffen.

Wenn Ihre Anwendung keine mandantenspezifischen Richtlinien erfordert und eine einzige Identitätsquelle verwendet, ist ein gemeinsamer Richtlinienspeicher für alle Mandanten wahrscheinlich die effektivste Lösung. Dies führt zu einem einfacheren Autorisierungsablauf und einer globalen Richtlinienverwaltung. Das Offboarding eines Mandanten mithilfe eines gemeinsamen Richtlinienspeichers erfordert weniger Aufwand, da die Anwendung keine mandantenspezifischen Richtlinien löschen muss.

Wenn Ihre Anwendung jedoch viele mandantenspezifische Richtlinien erfordert oder mehrere Identitätsquellen verwendet, sind richtlinienspeicher pro Mandant wahrscheinlich am effektivsten. Sie können den Zugriff auf Mandantenrichtlinien mit IAM Richtlinien steuern, die jedem Richtlinienspeicher mandantenspezifische Berechtigungen gewähren. Das Offboarding eines Mandanten beinhaltet das Löschen seines Richtlinienspeichers. In einer shared-policy-store Umgebung müssen Sie mandantenspezifische Richtlinien finden und löschen.

Füllen Sie nach Möglichkeit den Geltungsbereich der Richtlinie aus

Der Geltungsbereich der Richtlinie ist der Teil einer Cedar-Grundsatzerklärung nach den forbid Schlüsselwörtern permit oder und zwischen den ersten Klammern.

Wir empfehlen, dass Sie die Werte für principal und resource wann immer möglich auffüllen. Dadurch können Verified Permissions die Richtlinien für einen effizienteren Abruf indexieren und somit die Leistung verbessern. Wenn Sie vielen verschiedenen Prinzipalen oder Ressourcen dieselben Berechtigungen gewähren müssen, empfehlen wir, eine Richtlinienvorlage zu verwenden und diese an jedes Prinzipal- und Ressourcenpaar anzuhängen.

Vermeiden Sie es, eine umfangreiche Richtlinie zu erstellen, die Listen von Prinzipalen und Ressourcen in einer when Klausel enthält. Andernfalls stoßen Sie wahrscheinlich auf Skalierbarkeitsgrenzen oder betriebliche Probleme. Um beispielsweise einen einzelnen Benutzer zu einer großen Liste innerhalb einer Richtlinie hinzuzufügen oder daraus zu entfernen, müssen Sie die gesamte Richtlinie lesen, die Liste bearbeiten, die neue Richtlinie vollständig schreiben und Parallelitätsfehler beheben, wenn ein Administrator die Änderungen eines anderen überschreibt. Im Gegensatz dazu ist das Hinzufügen oder Entfernen eines Benutzers durch die Verwendung vieler detaillierter Berechtigungen so einfach wie das Hinzufügen oder Entfernen der einzelnen Richtlinie, die für ihn gilt.

Jede Ressource befindet sich in einem Container

Wenn Sie ein Autorisierungsmodell entwerfen, muss jede Aktion einer bestimmten Ressource zugeordnet werden. Bei einer Aktion wie z. B. ist die RessourceviewFile, auf die Sie sie anwenden können, intuitiv: eine einzelne Datei oder vielleicht eine Sammlung von Dateien in einem Ordner. Eine solche Operation createFile ist jedoch weniger intuitiv. Für welche Ressource gilt sie bei der Modellierung der Fähigkeit, eine Datei zu erstellen? Es kann nicht die Datei selbst sein, weil die Datei noch nicht existiert.

Dies ist ein Beispiel für das allgemeine Problem der Ressourcenerstellung. Die Erstellung von Ressourcen ist ein Bootstrapping-Problem. Es muss eine Möglichkeit geben, dass etwas die Erlaubnis erhält, Ressourcen zu erstellen, auch wenn noch keine Ressourcen vorhanden sind. Die Lösung besteht darin, zu erkennen, dass jede Ressource in einem Container existieren muss und dass der Container selbst als Ankerpunkt für Berechtigungen fungiert. Wenn beispielsweise ein Ordner bereits im System vorhanden ist, kann die Fähigkeit, eine Datei zu erstellen, als eine Berechtigung für diesen Ordner modelliert werden, da dies der Ort ist, an dem Berechtigungen erforderlich sind, um die neue Ressource zu instanziieren.

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Was aber, wenn kein Ordner existiert? Vielleicht ist dies ein brandneues Kundenkonto in einer Anwendung, für die noch keine Ressourcen vorhanden sind. In dieser Situation gibt es immer noch einen Kontext, der intuitiv verstanden werden kann, wenn man fragt: Wo kann der Kunde neue Dateien erstellen? Sie möchten nicht, dass sie Dateien in einem beliebigen Kundenkonto erstellen können. Vielmehr gibt es einen impliziten Kontext: die eigene Kontogrenze des Kunden. Daher stellt das Konto selbst den Container für die Ressourcenerstellung dar, und dies kann in einer Richtlinie, die dem folgenden Beispiel ähnelt, explizit modelliert werden.

// Grants permission to create files within an account,
// or within any sub-folder inside the account.
permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Was aber, wenn auch keine Konten existieren? Sie können sich dafür entscheiden, den Workflow für die Kundenregistrierung so zu gestalten, dass neue Konten im System erstellt werden. In diesem Fall benötigen Sie einen Container für die äußerste Grenze, innerhalb derer der Prozess die Konten erstellen kann. Dieser Container auf Stammebene stellt das System als Ganzes dar und könnte so etwas wie „Systemstamm“ heißen. Die Entscheidung, ob dies erforderlich ist und wie er benannt wird, liegt jedoch bei Ihnen, dem Eigentümer der Anwendung.

Für diese Beispielanwendung würde die resultierende Containerhierarchie daher wie folgt aussehen:

Dies ist ein Beispiel für eine Hierarchie. Andere sind ebenfalls gültig. Denken Sie daran, dass die Erstellung von Ressourcen immer im Kontext eines Ressourcencontainers erfolgt. Diese Container können implizit sein, z. B. eine Kontogrenze, und es kann leicht sein, sie zu übersehen. Achten Sie beim Entwurf Ihres Autorisierungsmodells darauf, diese impliziten Annahmen zu berücksichtigen, damit sie formell dokumentiert und im Autorisierungsmodell dargestellt werden können.

Trennen Sie die Principals von den Ressourcencontainern

Beim Entwerfen einer Ressourcenhierarchie besteht eine der häufigsten Tendenzen, insbesondere bei kundenorientierten Anwendungen, die Benutzeridentität des Kunden als Container für Ressourcen innerhalb eines Kundenkontos zu verwenden.

Wir empfehlen, diese Strategie als Anti-Pattern-Strategie zu behandeln. Dies liegt daran, dass umfangreichere Anwendungen von Natur aus dazu neigen, den Zugriff an zusätzliche Benutzer zu delegieren. Sie könnten sich beispielsweise dafür entscheiden, „Familienkonten“ einzuführen, bei denen andere Benutzer Kontoressourcen gemeinsam nutzen können. In ähnlicher Weise möchten Unternehmenskunden manchmal mehrere Mitarbeiter als Operatoren für Teile des Accounts benennen. Möglicherweise müssen Sie auch die Inhaberschaft eines Kontos auf einen anderen Benutzer übertragen oder die Ressourcen mehrerer Konten zusammenführen.

Wenn eine Benutzeridentität als Ressourcencontainer für ein Konto verwendet wird, wird es schwieriger, die vorherigen Szenarien zu erreichen. Noch alarmierender ist, dass, wenn anderen bei diesem Ansatz Zugriff auf den Kontocontainer gewährt wird, ihnen versehentlich Zugriff gewährt werden kann, um die Benutzeridentität selbst zu ändern, z. B. um Janes E-Mail-Adresse oder Anmeldeinformationen zu ändern.

Ein robusterer Ansatz besteht daher, wenn möglich, darin, die Principals von den Ressourcencontainern zu trennen und die Verbindung zwischen ihnen mithilfe von Konzepten wie „Administratorberechtigungen“ oder „Eigentum“ zu modellieren.

Wenn Sie über eine bestehende Anwendung verfügen, die dieses entkoppelte Modell nicht nutzen kann, empfehlen wir Ihnen, bei der Entwicklung eines Autorisierungsmodells zu erwägen, es so weit wie möglich nachzuahmen. Beispielsweise könnte eine Anwendung, die nur ein einziges Konzept mit dem Namen besitzt, Customer das die Benutzeridentität, die Anmeldeinformationen und die Ressourcen, die sie besitzt, kapselt, dies einem Autorisierungsmodell zuordnen, das eine logische Entität für Customer Identity (mit Name, E-Mail usw.) und eine separate logische Entität für Customer Resources oder enthältCustomer Account, die als übergeordneter Knoten für alle Ressourcen fungiert, die sie besitzt. Beide Entitäten können dasselbe verwendenId, aber mit einer anderen. Type

Verwendung von Attributen oder Vorlagen zur Darstellung von Beziehungen

Es gibt zwei Hauptmethoden, um Beziehungen zwischen Ressourcen auszudrücken. Wann die eine oder die andere verwendet wird, hängt davon ab, ob die Beziehung bereits in Ihrer Anwendungsdatenbank gespeichert ist und aus anderen Gründen, wie z. B. der Einhaltung von Vorschriften, verwendet wird. Wenn ja, wählen Sie den attributbasierten Ansatz. Wenn nicht, wählen Sie den vorlagenbasierten Ansatz.

Attributbasierte Beziehungen

Attribute können als Eingabe für die Autorisierungsentscheidung verwendet werden, um eine Beziehung zwischen einem Prinzipal und einer oder mehreren Ressourcen darzustellen.

Dieses Muster eignet sich, wenn die Beziehung für Zwecke verfolgt und verwaltet wird, die über die reine Rechteverwaltung hinausgehen. Beispielsweise ist die Erfassung des Hauptkontoinhabers für die finanzielle Einhaltung der Know Your Customer-Regeln erforderlich. Aus diesen Beziehungen ergeben sich Berechtigungen. Die Beziehungsdaten werden außerhalb des Autorisierungssystems verwaltet und als Eingabe abgerufen, wenn eine Autorisierungsentscheidung getroffen wird.

Das folgende Beispiel zeigt, wie eine Beziehung zwischen einem Benutzer Alice und einer Reihe von Konten, bei denen sie die Hauptkontoinhaberin ist, dargestellt werden könnte:

// Using a user attribute to represent the primary account holder relationship 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ]
}

Und anschließend wird das Attribut innerhalb einer Richtlinie verwendet:

// Derived relationship permissions
  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };

Umgekehrt könnte dieselbe Beziehung als ein Attribut auf der aufgerufenen Ressource dargestellt werdenprimaryAccountHolders, das eine Gruppe von Benutzern enthält.

Wenn es mehrere Beziehungstypen zwischen Prinzipalen und Ressourcen gibt, sollten diese als unterschiedliche Attribute modelliert werden. Wenn Konten beispielsweise auch autorisierte Unterzeichner haben können und diese Personen unterschiedliche Berechtigungen für das Konto haben, würde dies als ein anderes Attribut dargestellt werden.

Im obigen Fall Alice könnte es sich auch um einen autorisierten Unterzeichner für ein drittes Konto handeln. Das folgende Beispiel zeigt, wie dies dargestellt werden könnte:

// Using user attributes to represent the primary account holder and authorized signatory relationships 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ],
  "authorizedSignatoryOnAccounts": [
    "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\""
  ]
}

Im Folgenden sind die entsprechenden Richtlinien aufgeführt:

// Derived relationship permissions

  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };
  permit (
    principal,
    action in Action::"authorizedSignatoryActions",
    resource
  )when {
    resource in principal.authorizedSignatoryOnAccounts
  };

Auf Vorlagen basierende Beziehungen

Wenn die Beziehung zwischen Ressourcen ausschließlich zum Zweck der Rechteverwaltung besteht, ist es angemessen, diese Beziehung als mit einer Vorlage verknüpfte Richtlinie oder Vorlage zu speichern. Sie können sich diese Vorlagen auch als Rollen vorstellen, die einer bestimmten Ressource zugewiesen sind.

In einem Dokumentenverwaltungssystem kann sich der Eigentümer des Dokuments beispielsweise dafür entscheidenAlice, einem anderen Benutzer die Erlaubnis zu erteilenBob, zu dem Dokument beizutragen. Dadurch wird eine Beziehung zwischen Bobs und Alices Dokument als Mitwirkender hergestellt. Der einzige Zweck dieser Beziehung besteht darin, die Erlaubnis zu erteilen, das Dokument zu bearbeiten und zu kommentieren. Daher kann diese Beziehung als Vorlage dargestellt werden. In diesen Fällen wird empfohlen, für jeden Beziehungstyp eine Vorlage zu erstellen. In den folgenden Beispielen gibt es zwei Beziehungstypen Contributor undReviewer, und somit zwei Vorlagen.

Die folgenden Vorlagen können verwendet werden, um mit Vorlagen verknüpfte Richtlinien für einzelne Benutzer zu erstellen.

  // Managed relationship permissions - Contributor template
  permit (
    principal == ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );
    
  // Managed relationship permissions - Reviewer template
  permit (
    principal == ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

Die folgenden Vorlagen können verwendet werden, um mit Vorlagen verknüpfte Richtlinien für Benutzergruppen zu erstellen. Der einzige Unterschied zu den Vorlagen für einzelne Benutzer besteht darin, dass der in Operator anstelle von verwendet wird. ==

  // Managed relationship permissions - Contributor template
  permit (
    principal in ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );

  // Managed relationship permissions - Reviewer template
  permit (
    principal in ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

Sie können diese Vorlagen dann verwenden, um Richtlinien wie die folgenden zu erstellen, die Berechtigungen für verwaltete Beziehungen jedes Mal darstellen, wenn Zugriff auf ein Dokument gewährt wird.

  //Managed relationship permissions
  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",  
    action in Action::"DocumentContributorActions",
    resource in Document::"c943927f-d803-4f40-9a53-7740272cb969"
  );

  permit (
    principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentReviewerActions",
    resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a"
  );

  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentContributorActions",
    resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894"
  );

Amazon Verified Permissions kann viele individuelle, fein abgestufte Richtlinien bei der Autorisierungsprüfung effizient handhaben, und die Modellierung der Dinge auf diese Weise bedeutet, dass Verified Permissions ein vollständiges Audit-Protokoll aller Autorisierungsentscheidungen führt. AWS CloudTrail

Bevorzugen Sie detaillierte Berechtigungen im Modell und aggregierte Berechtigungen in der Benutzeroberfläche

Eine Strategie, die Designer später oft bereuen, besteht darin, ein Autorisierungsmodell mit sehr umfassenden Aktionen wie Read und zu entwickeln und später zu erkennenWrite, dass detailliertere Aktionen erforderlich sind. Der Bedarf an feinerer Granularität kann auf Kundenfeedback für detailliertere Zugriffskontrollen oder auf Compliance- und Sicherheitsprüfer zurückzuführen sein, die Berechtigungen mit den geringsten Rechten befürworten.

Wenn keine detaillierten Berechtigungen im Voraus definiert werden, kann eine komplizierte Konvertierung erforderlich sein, um den Anwendungscode und die Richtlinienanweisungen in detailliertere Benutzerberechtigungen zu ändern. Beispielsweise muss der Anwendungscode, der zuvor für eine spezielle Aktion autorisiert wurde, geändert werden, um die detaillierten Aktionen verwenden zu können. Darüber hinaus müssen die Richtlinien aktualisiert werden, um der Migration Rechnung zu tragen:

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    // action  ==  Action::"read",              -- coarse-grained permission -- commented out
    action in [                       //        -- finer grained permissions
        Action::"listFolderContents", 
        Action::"viewFile"
    ],
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Um diese kostspielige Migration zu vermeiden, ist es besser, vorab detaillierte Berechtigungen zu definieren. Dies kann jedoch zu einem Kompromiss führen, wenn Ihre Endbenutzer später gezwungen sind, eine größere Anzahl detaillierter Berechtigungen zu verstehen, insbesondere wenn die meisten Kunden mit detaillierten Steuerelementen wie und zufrieden wären. Read Write Um das Beste aus beiden Welten herauszuholen, können Sie feinkörnige Berechtigungen in vordefinierten Sammlungen gruppieren und dabei Mechanismen wie Read Richtlinienvorlagen oder Aktionsgruppen verwenden. Write Mit diesem Ansatz sehen Kunden nur die maßgeschneiderten Berechtigungen. Aber hinter den Kulissen haben Sie Ihre Anwendung zukunftssicher gemacht, indem Sie die kursspezifischen Berechtigungen als eine Sammlung detaillierter Aktionen modelliert haben. Wenn Kunden oder Prüfer danach fragen, können die detaillierten Berechtigungen offengelegt werden.

Erwägen Sie andere Gründe, um die Autorisierung abzufragen

Normalerweise verknüpfen wir Autorisierungsprüfungen mit Benutzeranfragen. Mit der Prüfung kann festgestellt werden, ob der Benutzer berechtigt ist, diese Anfrage auszuführen. Sie können jedoch auch Autorisierungsdaten verwenden, um das Design der Programmoberfläche zu beeinflussen. Möglicherweise möchten Sie beispielsweise einen Startbildschirm anzeigen, auf dem nur die Ressourcen aufgeführt sind, auf die der Endbenutzer zugreifen kann. Wenn Sie sich die Details einer Ressource ansehen, möchten Sie vielleicht, dass auf der Benutzeroberfläche nur die Operationen angezeigt werden, die der Benutzer mit dieser Ressource ausführen kann.

Diese Situationen können zu Kompromissen im Autorisierungsmodell führen. So kann es beispielsweise schwieriger werden, die Frage „Wer hat Zugriff auf was?“ schnell zu beantworten, wenn man sich stark auf attributed-based Access Control (ABAC) -Richtlinien verlässt. Das liegt daran, dass für die Beantwortung dieser Frage jede Regel anhand jedes Prinzipals und jeder Ressource geprüft werden muss, um festzustellen, ob es eine Übereinstimmung gibt. Daher könnte sich ein Produkt, das dahingehend optimiert werden muss, dass es nur die Ressourcen auflistet, auf die der Benutzer Zugriff hat, für ein rollenbasiertes Zugriffskontrollmodell (RBAC) entscheiden. Durch diese Verwendung kann es einfacher seinRBAC, alle Richtlinien, die einem Benutzer zugewiesen sind, zu überprüfen, um den Ressourcenzugriff zu bestimmen.