Der Unterschied zwischen expliziten und impliziten Zugriffsverweigerungen
Eine Anforderung führt zu einer expliziten Zugriffsverweigerung, wenn eine anwendbare Richtlinie eine Deny
-Anweisung enthält. Wenn Richtlinien, die auf eine Anforderung anwendbar sind, eine Allow
-Anweisung und eine Deny
-Anweisung enthalten, übersteuert die Deny
-Anweisung die Allow
-Anweisung. Die Anforderung wird abgelehnt.
Eine implizite Verweigerung tritt auf, wenn es keine entsprechende Deny
-Anweisung, aber auch keine anwendbare Allow
-Anweisung gibt. Da einem IAM-Prinzipal standardmäßig der Zugriff verweigert wird, muss ihm explizit erlaubt werden, eine Aktion auszuführen. Andernfalls wird ihnen der Zugriff implizit verweigert.
Bei der Planung Ihrer Autorisierungsstrategie müssen Sie Richtlinien mit Allow
-Anweisungen erstellen, um Ihren Auftraggeber zu gestatten, erfolgreich Anforderungen durchzuführen. Sie können jedoch eine beliebige Kombination von expliziten und impliziten Zugriffsverweigerungen wählen.
Sie können beispielsweise die folgende Richtlinie erstellen, die zulässige Aktionen, implizit verweigerte Aktionen und explizit verweigerte Aktionen enthält. Die AllowGetList
-Aussage erlaubt Lesezugriff auf IAM-Aktionen, die mit den Präfixen Get
und List
beginnen. Alle anderen Aktionen in IAM, wie iam:CreatePolicy
sind implizit abgelehnt. Die DenyReports
-Aussage verweigert explizit Zugriff auf IAM-Berichte durch Verweigern des Zugriffs auf Aktionen, die den Report
-Suffix, wie iam:GetOrganizationsAccessReport
enthalten. Wenn jemand diesem Prinzipal eine andere Richtlinie hinzufügt, um ihm Zugriff auf IAM-Berichte zu gewähren, z. B. iam:GenerateCredentialReport
, werden berichtsbezogene Anfragen aufgrund dieser ausdrücklichen Ablehnung immer noch abgelehnt.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] }