Berechtigungen für AssumeRole, AssumeRoleWith SAML und AssumeRoleWithWebIdentity

Die Berechtigungsrichtlinie der übernommenen Rolle bestimmt die Berechtigungen für die temporären Sicherheitsanmeldeinformationen, die von AssumeRole, AssumeRoleWithSAML und AssumeRoleWithWebIdentity zurückgegeben werden. Sie definieren diese Berechtigungen beim Erstellen oder Aktualisieren der Rolle.

Optional können Sie eingebundene oder verwaltete Sitzungsrichtlinien als Parameter der API-Operationen AssumeRole, AssumeRoleWithSAML oder AssumeRoleWithWebIdentity übergeben. Sitzungsrichtlinien beschränken die Berechtigungen für die temporäre Anmeldedatensitzung der Rolle. Die resultierenden Sitzungsberechtigungen sind eine Schnittmenge der auf der Identität der Rolle basierenden Richtlinien und der Sitzungsrichtlinien. Sie können die temporären Anmeldeinformationen der Rolle in nachfolgenden AWS API-Aufrufen verwenden, um auf Ressourcen in dem Konto zuzugreifen, dem die Rolle gehört. Sie können mit Sitzungsrichtlinien nicht mehr Berechtigungen erteilen, als durch die identitätsbasierte Richtlinie der Rolle, die angenommen wird, zulässig sind. Weitere Informationen darüber, wie AWS die effektiven Berechtigungen einer Rolle bestimmt, finden Sie unter Auswertungslogik für Richtlinien.

Die Richtlinien, die an die Anmeldeinformationen angehängt sind, die den ursprünglichen Aufruf getätigt haben, AssumeRole werden AWS bei der Entscheidung über die Autorisierung „Zulassen“ oder „Verweigern“ nicht berücksichtigt. Der Benutzer verliert vorübergehend seine ursprünglichen Berechtigungen zugunsten der Berechtigungen, die von der angenommenen Rolle zugewiesen sind. Bei den Operationen AssumeRoleWithSAML und der AssumeRoleWithWebIdentity API gibt es keine zu bewertenden Richtlinien, da es sich bei dem API-Aufrufer nicht um eine AWS Identität handelt.

Beispiel: Zuweisen von Berechtigungen mit AssumeRole

Sie können die API-Operation AssumeRole mit verschiedenen Arten von Richtlinien verwenden. Nachfolgend sind einige Beispiele aufgeführt.

Rollenberechtigungsrichtlinie

In diesem Beispiel rufen Sie die API-Operation AssumeRole auf, ohne die Sitzungsrichtlinie im optionalen Parameter Policy anzugeben. Die den temporären Anmeldeinformationen zugewiesenen Berechtigungen werden laut der Berechtigungsrichtlinie der übernommenen Rolle bestimmt. Das folgende Beispiel einer Berechtigungsrichtlinie gewährt der Rolle die Berechtigung, alle Objekte in einem S3-Bucket namens productionapp aufzulisten. Außerdem wird der Rolle gestattet, Objekte im Bucket zu platzieren, daraus abzurufen oder zu löschen.

Beispiel Rollenberechtigungsrichtlinie

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Als Parameter übergebene Sitzungsrichtlinie

Stellen Sie sich vor, Sie möchten einem Benutzer erlauben, die gleiche Rolle wie im vorherigen Beispiel anzunehmen. Aber in diesem Fall soll die Rollensitzung nur über die Berechtigung zum Abrufen und Speichern von Objekten im S3-Bucket productionapp verfügen. Sie wollen nicht zulassen, dass sie Objekte löschen. Eine Möglichkeit, dies zu erreichen, ist das Erstellen einer neuen Rolle und das Angeben der gewünschten Berechtigungen in der Berechtigungsrichtlinie dieser Rolle. Eine weitere Möglichkeit besteht darin, die AssumeRole-API aufzurufen und eine Sitzungsrichtlinie in den optionalen Policy-Parameter als Teil der API-Operation einzuschließen. Die resultierenden Sitzungsberechtigungen sind eine Schnittmenge der auf der Identität des Benutzers oder der Rolle basierenden Richtlinien und der Sitzungsrichtlinien. Sie können mit Sitzungsrichtlinien nicht mehr Berechtigungen erteilen, als durch die identitätsbasierte Richtlinie der Rolle, die angenommen wird, zulässig sind. Weitere Informationen über Rollensitzungsberechtigungen finden Sie unter Sitzungsrichtlinien.

Nachdem Sie die temporären Anmeldedaten der neuen Sitzung abgerufen haben, können Sie sie an den Benutzer übergeben, der diese Berechtigungen erhalten soll.

Stellen Sie sich beispielsweise vor, dass Sie die folgende Richtlinie als Parameter des API-Aufrufs übergeben wird. Die Person, die die Sitzung verwendet, hat Berechtigungen, um nur diese Aktionen durchzuführen:

• Liste aller Objekte im productionapp-Bucket.

• Rufen und legen Sie Objekte im productionapp-Bucket ab.

In der folgenden Sitzungsrichtlinie wird die Berechtigung s3:DeleteObject herausgefiltert und der übernommenen Sitzung wird die Berechtigung s3:DeleteObject nicht gewährt. Die Richtlinie legt die maximalen Berechtigungen für die Rollensitzung so fest, dass sie alle vorhandenen Berechtigungsrichtlinien für die Rolle überschreibt.

Beispiel Mit API-Aufruf AssumeRole übergebene Sitzungsrichtlinie

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Ressourcenbasierte Richtlinie

Einige AWS Ressourcen unterstützen ressourcenbasierte Richtlinien, und diese Richtlinien bieten einen weiteren Mechanismus zur Definition von Berechtigungen, die sich auf temporäre Sicherheitsanmeldedaten auswirken. Nur einige Ressourcen, wie Amazon S3-Buckets, Amazon SNS-Themen und Amazon SQS-Warteschlangen, unterstützen ressourcenbasierte Richtlinien. Das folgende Beispiel ist eine Erweiterung der vorherigen Beispiele, in dem ein S3-Bucket mit dem Namen productionapp verwendet wird. Die folgende Richtlinie ist zum Bucket angefügt.

Wenn Sie die folgende ressourcenbasierte Richtlinie an den productionapp-Bucket anfügen, wird allen Benutzern die Berechtigung zum Löschen von Objekten aus dem Bucket verweigert. (Weitere Informationen finden Sie im Principal-Element in der Richtlinie.) Dies umfasst alle Benutzer der angenommenen Rolle, auch wenn die Rollenberechtigungsrichtlinie die DeleteObject-Berechtigung erteilt. Eine explizite Deny-Anweisung hat immer Vorrang vor einer Allow-Anweisung.

Beispiel einer Bucket-Richtlinie

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}

Weitere Informationen darüber, wie mehrere Richtlinientypen kombiniert und bewertet werden AWS, finden Sie unter. Auswertungslogik für Richtlinien