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.
Verarbeitung des Anforderungskontexts
Wenn eine Anfrage AWS ausgewertet und autorisiert wird, fügt sie die Anforderungsinformationen zu einem Anforderungskontext zusammen. Der Anfragekontext enthält alle Informationen, die für die Richtlinienauswertung verwendet werden können.
-
Prinzipal – Der Benutzer, die Rolle oder der Verbundbenutzer-Prinzipal, der die Anfrage gesendet hat. Informationen über den Auftraggeber beinhalten die Richtlinien, die diesem Auftraggeber zugeordnet sind.
-
Aktionen – Eine oder mehrere Aktionen, die der Prinzipal ausführen möchte.
-
Ressourcen — Ein oder mehrere AWS Ressourcenobjekte, für die die Aktionen oder Operationen ausgeführt werden.
-
Ressourcendaten – Daten zu den angeforderten Ressourcen. Dies kann Informationen wie einen DynamoDB-Tabellennamen oder ein Tag auf einer EC2 Amazon-Instance beinhalten.
-
Umgebungsdaten – Informationen über die IP-Adresse, den Benutzeragent, den SSL-Status oder die Tageszeit.
Diese Informationen werden mit den geltenden Richtlinien verglichen, um zu entscheiden, ob die Anfrage zugelassen oder abgelehnt wird. Sie können diese Eigenschaftsinformationen mithilfe des PARC-Modells (Principal, Action, Resource and Condition) organisieren, um besser zu verstehen, wie AWS Richtlinien bewertet werden.
Das PARC-Modell verstehen
Das PARC-Modell stellt den Anfragekontext anhand der vier JSON-Elemente der Richtliniensprache dar:
-
Principal – Die Entität, die die Anfrage stellt. Ein Prinzipal stellt einen menschlichen Benutzer oder einen programmgesteuerten Workload dar, der authentifiziert und dann zur Ausführung von Aktionen in AWS-Konten autorisiert werden kann.
-
Action – Der Vorgang, der gerade ausgeführt wird. Oft wird die Aktion einer API-Aktion zugeordnet.
-
Resource – Die AWS -Ressource, auf der die Aktion ausgeführt wird.
-
Condition – Zusätzliche Einschränkungen, die erfüllt sein müssen, damit die Anfrage zugelassen wird.
Das folgende Beispiel zeigt, wie das PARC-Modell einen Anfragekontext darstellen kann:
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123Bedeutung des Anfragekontexts
Das Verständnis des Anfragekontexts und seiner Interaktion mit der Richtlinienauswertung ist entscheidend für:
-
Die Behebung von Zugriffsproblemen
-
Die Entwicklung effektiver und sicherer Richtlinien
-
Das vollständige Verständnis des Umfangs der durch eine Richtlinie gewährten Berechtigungen
-
Die Vorhersage des Ergebnisses von Richtlinienauswertungen in verschiedenen Szenarien
Durch die Visualisierung des Anforderungskontextes mithilfe des PARC-Modells können Sie leichter nachvollziehen, wie AWS Autorisierungsentscheidungen getroffen werden, und Ihre Richtlinien effektiver gestalten.
Wie AWS wird der Anforderungskontext verwendet
Bei der Bewertung von Richtlinien werden die Informationen im Anforderungskontext mit den Informationen AWS verglichen, die in allen geltenden Richtlinien angegeben sind. Dazu gehören identitätsbasierte Richtlinien, ressourcenbasierte Richtlinien, IAM-Berechtigungsgrenzen, Organizations SCPs, Organizations und Sitzungsrichtlinien. RCPs
AWS Verwendet für jeden Richtlinientyp den Anforderungskontext, um Folgendes zu überprüfen:
-
Ob die Richtlinie basierend auf dem Prinzipal auf die Anfrage anwendbar ist.
-
Ob die angeforderte Aktion für die angegebene Ressource zulässig ist.
-
Ob die in der Richtlinie festgelegten Bedingungen vom Anfragekontext erfüllt werden.
Wie Richtlinien AWS bewertet werden, hängt von den Arten von Richtlinien ab, die für den Anforderungskontext gelten. Diese Richtlinientypen können innerhalb eines einzelnen AWS-Konto verwendet werden. Weitere Informationen zu diesen Richtlinientypen finden Sie unter Richtlinien und Berechtigungen in AWS Identity and Access Management. Informationen darüber, wie Richtlinien für den kontoübergreifenden Zugriff AWS bewertet werden, finden Sie unter. Logik für die kontoübergreifende Richtlinienauswertung
-
AWS Organizations Richtlinien zur Ressourcenkontrolle (RCPs) — AWS Organizations RCPs geben die maximal verfügbaren Berechtigungen für Ressourcen innerhalb von Konten in einer Organisation oder Organisationseinheit (OU) an. RCPs gelten für Ressourcen in Mitgliedskonten und wirken sich auf die effektiven Berechtigungen für Prinzipale aus, einschließlich der Root-Benutzer des AWS-Kontos, unabhängig davon, ob die Prinzipale zu Ihrer Organisation gehören. RCPs gelten nicht für Ressourcen im Organisationsverwaltungskonto und nicht für Aufrufe von Rollen, die mit dem Dienst verknüpft sind. Wenn eine RCP vorhanden ist, sind Berechtigungen, die durch identitätsbasierte und ressourcenbasierte Richtlinien für Ressourcen in Ihren Mitgliedskonten erteilt werden, nur dann wirksam, wenn die RCP die Aktion zulässt.
-
AWS Organizations Dienststeuerungsrichtlinien (SCPs) — AWS Organizations SCPs geben die maximal verfügbaren Berechtigungen für Prinzipale innerhalb von Konten in einer Organisation oder Organisationseinheit (OU) an. SCPs gelten für Prinzipale in Mitgliedskonten, einschließlich der einzelnen Konten. Root-Benutzer des AWS-Kontos Wenn eine SCP vorhanden ist, sind durch identitäts- und ressourcenbasierte Richtlinien gewährte Berechtigungen an Prinzipalen in Ihren Mitgliedskonten nur wirksam, wenn die SCP die Aktion zulässt. Die einzigen Ausnahmen sind Prinzipale im Organisationsverwaltungskonto und serviceverknüpfte Rollen.
-
Ressourcenbasierte Richtlinien – Ressourcenbasierte Richtlinien gewähren Berechtigungen für in der Richtlinie angegebene Prinzipale. Die Berechtigungen definieren, welche Aktionen der Auftraggeber mit der Ressource, der die Richtlinie zugewiesen ist. durchführen kann.
-
Berechtigungsgrenzen – Berechtigungsgrenzen sind ein Feature, das die maximalen Berechtigungen festlegt, die eine identitätsbasierte Richtlinie einer IAM-Entität (Benutzer oder Rolle) gewähren kann. Wenn Sie eine Berechtigungsgrenze für eine Entität festlegen, kann die Entität nur die Aktionen ausführen, die sowohl von ihren identitätsbasierten Richtlinien als auch von ihrer Berechtigungsgrenze zugelassen werden. In einigen Fällen kann eine implizite Verweigerung in einer Berechtigungsgrenze die Berechtigungen nicht bechränken, die von einer ressourcenbasierten Richtlinie gewährt werden. Weitere Informationen finden Sie unter So wertet die Logik des AWS-Durchsetzungscodes Anfragen zum Gewähren oder Verweigern des Zugriffs aus.
-
Identitätsbasierte Richtlinien – Identitätsbasierte Richtlinien werden einer IAM-Identität (Benutzer, Benutzergruppe oder Rolle) angefügt und gewähren IAM-Entitäten (Benutzer und Rollen) Berechtigungen. Wenn für eine Anfrage nur identitätsbasierte Richtlinien gelten, AWS überprüft es alle diese Richtlinien auf mindestens eine.
Allow -
Sitzungsrichtlinien – Sitzungsrichtlinien sind Richtlinien, die Sie als Parameter übergeben, wenn Sie programmgesteuert eine temporäre Sitzung für eine Rolle oder Verbundbenutzersitzung erstellen. Um eine Rollensitzung programmgesteuert zu erstellen, verwenden Sie eine der
AssumeRole*-API-Operationen. Wenn Sie dies tun und Richtlinien für die Sitzung übergeben, sind die resultierenden Sitzungsberechtigungen eine Schnittmenge der identitätsbasierten Richtlinie der IAM-Entität und der Sitzungsrichtlinien. Um eine Sitzung eines Verbundbenutzers zu erstellen, verwenden Sie die Zugriffsschlüssel eines IAM-Benutzers, um den API-VorgangGetFederationTokenprogrammatisch aufzurufen. Weitere Informationen finden Sie unter Sitzungsrichtlinien.
Denken Sie daran, dass eine explizite Zugriffsverweigerung in all diesen Richtlinien eine Zugriffserlaubnis überschreibt.
Anmerkung
AWS Organizations Mit deklarativen Richtlinien können Sie Ihre gewünschte Konfiguration für eine bestimmte Größe AWS-Service im gesamten Unternehmen zentral deklarieren und durchsetzen. Da deklarative Richtlinien direkt auf Serviceebene angewendet werden, haben sie keinen direkten Einfluss auf die Richtlinienauswertung und sind nicht Teil des Anfragekontexts. Weitere Informationen finden Sie unter Deklarative Richtlinien im AWS Organizations Benutzerhandbuch.
Beispiel für die Richtlinienauswertung mit dem PARC-Modell
Um zu veranschaulichen, wie der Anfragekontext die Richtlinienauswertung beeinflusst, betrachten wir eine Beispielrichtlinie:
In diesem Beispiel würde die Richtlinie die Aktion „CreateBucket“ nur dann zulassen, wenn der Anfragekontext den Wert „123“ für „aws:PrincipalTag/dept“ enthält und die Ressource mit dem Bucket-Namen „amzn-s3-demo-bucket1“ übereinstimmt. Die folgende Tabelle zeigt, wie AWS den Anfragekontext verwendet, um diese Richtlinie auszuwerten und Autorisierungsentscheidungen zu treffen.
| Richtlinie | Kontext anfordern | Ergebnis der Bewertung |
|---|---|---|
|
|
Spiel |
|
|
Kein Spiel |
|
|
Kein Spiel |
|
Kein |
Kein Spiel |
