Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Auswertungslogik
Das Ziel zum Bewertungszeitpunkt ist, zu entscheiden, ob eine bestimmte Anfrage gewährt oder abgelehnt werden soll. Die Auswertungslogik unterliegt mehreren Grundregeln:
-
Standardmäßig werden alle Anforderungen zur Verwendung Ihrer Ressourcen, die nicht von Ihnen stammen, verweigert
-
Eine Zugriffserlaubnis überschreibt jedwede standardmäßige Ablehnung.
-
Eine explizite Zugriffsverweigerung überschreibt jedwede Zugriffserlaubnis
-
Es spielt keine Rolle, in welcher Reihenfolge die Richtlinien ausgewertet werden
Das folgende Flussdiagramm stellt genauer dar, wie die Entscheidung getroffen wird.

1 |
Die Entscheidung beginnt mit einer standardmäßigen Ablehnung. |
2 |
Durch den Durchführungscode werden alle Richtlinien ausgewertet, die auf die Anfrage anwendbar sind (basierend auf der Ressource, dem Prinzipal, der Aktion und den Bedingungen). Es spielt keine Rolle, in welcher Reihenfolge die Richtlinien ausgewertet werden. |
3 |
Es wird in allen Richtlinien nach expliziten Anweisungen für Zugriffsverweigerungen gesucht, die auf die Anforderung zutreffen. Wenn auch nur eine gefunden wird, gibt der Durchführungscode eine Ablehnungsentscheidung zurück und der Prozess wird beendet (dies ist eine explizite Zugriffsverweigerung; weitere Informationen siehe Explizite Zugriffsverweigerung). |
4 |
Wenn keine explizite Zugriffsverweigerung gefunden wird, wird nach "allow"-Anweisungen gesucht, die auf die Anfrage zutreffen. Wenn auch nur eine gefunden wird, gibt der Durchführungscode eine Zugriffserlaubnis zurück und der Prozess ist beendet (bzw. der Service setzt die Verarbeitung der Anfrage fort). |
5 |
Wenn kein "allow" gefunden wird, ist die endgültige Entscheidung "deny" (da es keine explizite Zugriffsverweigerung bzw. Zugriffserlaubnis gab, gilt dies als standardmäßige Ablehnung) (weitere Informationen siehe Standardmäßige Ablehnung). |
Das Zusammenspiel von expliziten und standardmäßigen Zugriffsverweigerungen
Wenn eine Richtlinie nicht direkt auf eine Anfrage anwendbar ist, wird der Zugriff standardmäßig verweigert ("standardmäßige Ablehnung"). Wenn ein Benutzer beispielsweise die Nutzung von Amazon anfordertSNS, sich die Richtlinie zu diesem Thema jedoch AWS-Konto überhaupt nicht auf die des Benutzers bezieht, führt diese Richtlinie zu einer Standardverweigerung.
Eine Richtlinie hat außerdem eine standardmäßige Ablehnung zur Folge, wenn eine Bedingung in einer Anweisung nicht erfüllt ist. Wenn alle Bedingungen einer Anweisung erfüllt sind, hat dies für diese Richtlinie abhängig vom Wert des Auswirkungselements in der Richtlinie entweder eine Zugriffserlaubnis oder eine explizite Zugriffsverweigerung zur Folge. In Richtlinien ist nicht festgelegt, was geschieht, wenn eine Bedingung nicht erfüllt ist, daher ist das Ergebnis in diesem Fall eine standardmäßige Ablehnung.
Angenommen, Sie möchten Anforderungen verhindern, die aus der Antarktis stammen. Sie erstellen eine Richtlinie ("Richtlinie A1"), um Zugriff nur dann zu gewähren, wenn Anfragen von außerhalb von Antarktis kommen. Diese Richtlinie ist in der folgenden Abbildung dargestellt.

Wenn eine Anforderung aus den USA gesendet wird, ist die Bedingung erfüllt (die Anforderung stammt nicht aus der Antarktis). Daher wird die Anforderung zugelassen. Wenn jedoch eine Anforderung aus der Antarktis eingeht, ist die Bedingung nicht erfüllt und der Zugriff wird standardmäßig abgelehnt.
Sie könnten das Ergebnis in eine explizite Zugriffsverweigerung umwandeln, indem Sie die Richtlinie ("Richtlinie A2") wie im folgenden Diagramm dargestellt neu schreiben. Hier lehnt die Richtlinie eine Anfrage explizit ab, wenn sie von der Antarktis stammt.

Wenn eine Anforderung aus der Antarktis eingeht, ist die Bedingung erfüllt und das Richtlinienergebnis ist daher eine explizite Zugriffsverweigerung.
Die Unterscheidung zwischen "standardmäßiger Ablehnung" und "expliziter Zugriffsverweigerung" ist wichtig, da eine standardmäßige Ablehnung durch eine Zugriffserlaubnis überschrieben werden kann, eine explizite Zugriffsverweigerung jedoch nicht. Angenommen, es gibt eine andere Richtlinie, die Anforderungen zulässt, wenn diese am 1. Juni 2010 gesendet werden. Zu welchem Gesamtergebnis führt diese Richtlinie, wenn sie gemeinsam mit der Richtlinie ausgewertet wird, die Zugriff aus der Antarktis verweigert? Wir vergleichen das Gesamtergebnis, wenn diese datenbasierte Richtlinie (nennen wir sie "Richtlinie B") zusammen mit den vorherigen Richtlinien (A1 und A2) ausgewertet wird. In Szenario 1 werden die Richtlinien A1 und B zusammen ausgewertet, in Szenario 2 die Richtlinien A2 und B. Die folgende Abbildung zeigt die Ergebnisse, wenn eine Anfrage am 1. Juni 2010 aus der Antarktis eingeht.

In Szenario 1 gibt Richtlinie A1 eine standardmäßige Ablehnung wie zuvor beschrieben zurück. Richtlinie B gibt eine Zugriffserlaubnis zurück, da die Richtlinie (laut Definition) Anfragen zulässt, die am 1. Juni 2010 eingehen. Die Zugriffserlaubnis aus Richtlinie B überschreibt die standardmäßige Zugriffsverweigerung aus Richtlinie A1 und die Anforderung wird zugelassen.
In Szenario 2 gibt Richtlinie A2 eine explizite Zugriffsverweigerung wie zuvor beschrieben zurück. Richtlinie B gibt auch hier "allow" zurück. Die Zugriffserlaubnis aus Richtlinie B wird durch die explizite Zugriffsverweigerung aus Richtlinie A2 überschrieben und die Anforderung wird abgelehnt.