Verarbeitung des Anforderungskontexts - AWS Identity and Access Management
Das PARC-Modell verstehenBedeutung des AnfragekontextsWie AWS den Anfragekontext nutztBeispiel für die Richtlinienauswertung mit dem PARC-Modell

Verarbeitung des Anforderungskontexts

Wenn AWS eine Anfrage prüft und autorisiert, werden die Anfrageinformationen in einem Anfragekontext zusammengefasst. 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 – Eine oder mehrere AWS-Ressourcenobjekte, mit denen die Aktionen oder Vorgänge durchgeführt werden.

  • Ressourcendaten – Daten zu den angeforderten Ressourcen. Dies sind zum Beispiel Informationen wie ein DynamoDB-Tabellenname oder Tag auf einer Amazon EC2-Instance.

  • 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, Condition) strukturieren, um besser zu verstehen, wie AWS-Richtlinien ausgewertet 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=123

Bedeutung 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 Anfragekontexts mithilfe des PARC-Modells können Sie leichter verstehen, wie AWS Autorisierungsentscheidungen trifft und Ihre Richtlinien effektiver gestalten.

Wie AWS den Anfragekontext nutzt

Bei der Auswertung von Richtlinien vergleicht AWS die Informationen im Anfragekontext mit den in allen anwendbaren Richtlinien angegebenen Informationen. Dies umfasst identitätsbasierte Richtlinien, ressourcenbasierte Richtlinien, IAM-Berechtigungsgrenzen, Organisationen-SCPs, Organisations-RCPs und Sitzungsrichtlinien.

Für jeden Richtlinientyp prüft AWS anhand des Anfragekontexts:

  • 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 AWS Richtlinien auswertet, hängt von den Typen 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. Wie AWS die Richtlinien für den kontenübergreifenden Zugriff auswertet, erfahren Sie unter Logik für die kontenübergreifende Richtlinienauswertung.

  • Ressourcen-Kontrollrichtlinien (RCPs) von AWS Organizations – RCPs von AWS Organizations 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 Root-Benutzer des AWS-Kontos, unabhängig davon, ob die Prinzipale Ihrer Organisation angehören. RCPs gelten nicht für Ressourcen im Organisationsverwaltungskonto und für Aufrufe, die von serviceverknüpften Rollen getätigt werden. 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.

  • Service-Kontrollrichtlinien (SCPs) von AWS Organizations – SCPs von AWS Organizations 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 eines jeden 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 nur identitätsbasierte Richtlinien auf eine Anforderung anwendbar sind, überprüft AWS all diese Richtlinien auf mindestens ein 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-Vorgang GetFederationToken programmatisch aufzurufen. Weitere Informationen finden Sie unter Sitzungsrichtlinien.

Denken Sie daran, dass eine explizite Zugriffsverweigerung in all diesen Richtlinien eine Zugriffserlaubnis überschreibt.

Anmerkung

Mit den deklarativen Richtlinien von AWS Organizations können Sie die gewünschte Konfiguration für einen bestimmten AWS-Service zentral und organisationsweit festlegen 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:

JSON
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}

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 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

Match

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

Keine Übereinstimmung

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=321

Keine Übereinstimmung

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:

Kein aws:PrincipalTag in der Anforderung.

Keine Übereinstimmung