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.
# Berechtigungen für temporäre Sicherheits-Anmeldeinformationen
Sie können AWS -Security-Token-Service (AWS STS) verwenden, um vertrauenswürdige Benutzer zu erstellen und ihnen temporäre Sicherheitsanmeldeinformationen zur Verfügung zu stellen, mit denen der Zugriff auf Ihre AWS Ressourcen gesteuert werden kann. Weitere Informationen zu finden AWS STS Sie unter[Temporäre IAM Sicherheitsanmeldeinformationen](id_credentials_temp.md). Nachdem AWS STS temporäre Sicherheitsanmeldeinformationen ausgestellt hat, sind diese bis zum Ablaufzeitpunkt gültig und können nicht aufgehoben werden. Die den temporären Sicherheitsanmeldeinformationen zugewiesenen Berechtigungen werden jedoch bei jeder Anforderung, die über diese Anmeldeinformationen gestellt wird, erneut überprüft. daher können Sie die Gültigkeit von Anmeldeinformationen aufheben, indem Sie die Zugriffsrechte nach dem Ausstellen der Anmeldeinformationen widerrufen.
Bei den folgenden Themen wird davon ausgegangen, dass Sie über fundierte Kenntnisse im Bereich AWS Berechtigungen und Richtlinien verfügen. Weitere Informationen zu diesen Themen finden Sie unter [Zugriffsmanagement für AWS Ressourcen](access.md).
**Topics**
+ [Berechtigungen für AssumeRole, AssumeRoleWith SAML und AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md)
+ [Überwachen und Steuern von Aktionen mit übernommenen Rollen](id_credentials_temp_control-access_monitor.md)
+ [Berechtigungen für GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md)
+ [Berechtigungen für GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md)
+ [Deaktivieren von Berechtigungen für temporäre Sicherheitsanmeldeinformationen](id_credentials_temp_control-access_disable-perms.md)
+ [Erteilen von Berechtigungen zum Erstellen von temporären Sicherheitsanmeldeinformationen](id_credentials_temp_control-access_enable-create.md)
+ [Gewähren von Berechtigungen zur Verwendung von Konsolensitzungen mit verbesserter Identität](id_credentials_temp_control-access_sts-setcontext.md)
# 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](access_policies.md#policies_session) 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](reference_policies_evaluation-logic.md).
![\[PermissionsWhenPassingRoles_Diagramm\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
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.
**Example 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](access_policies.md#policies_session).
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.
**Example 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.
**Example 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](reference_policies_evaluation-logic.md)
# Überwachen und Steuern von Aktionen mit übernommenen Rollen
Eine [IAM-Rolle](id_roles.md) ist ein Objekt in IAM, dem [Berechtigungen](access_policies.md) zugewiesen sind. Wenn Sie [diese Rolle mit einer IAM-Identität oder einer Identität von außerhalb übernehmen](id_roles_manage-assume.md) AWS, erhalten Sie eine Sitzung mit den Berechtigungen, die der Rolle zugewiesen sind.
Wenn Sie Aktionen in ausführen AWS, können die Informationen über Ihre Sitzung protokolliert werden, AWS CloudTrail sodass Ihr Kontoadministrator sie überwachen kann. Administratoren können Rollen so konfigurieren, dass Identitäten eine benutzerdefinierte Zeichenfolge übergeben müssen, die die Person oder Anwendung identifiziert, die Aktionen in AWS durchführt. Diese Identitätsinformation wird als *Quellidentität* in AWS CloudTrail gespeichert. Wenn der Administrator die Aktivitäten in überprüft CloudTrail, kann er anhand der Informationen zur Quellenidentität feststellen, wer oder was Aktionen in Sitzungen mit angenommenen Rollen ausgeführt hat.
Nachdem eine Quellidentität festgelegt wurde, ist sie in Anfragen für alle AWS Aktionen enthalten, die während der Rollensitzung ausgeführt wurden. Der festgelegte Wert bleibt bestehen, wenn eine Rolle verwendet wird, um über die AWS CLI AWS OR-API eine andere Rolle anzunehmen, was als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet wird. Der festgelegte Wert kann während der Rollensitzung nicht geändert werden. Administratoren können detaillierte Berechtigungen auf der Grundlage des Vorhandenseins oder des Werts der Quellidentität konfigurieren, um die AWS Aktionen, die mit gemeinsam genutzten Rollen ausgeführt werden, weiter zu kontrollieren. Sie können entscheiden, ob das Quellidentitätsattribut verwendet werden kann, ob es erforderlich ist und welcher Wert verwendet werden kann.
Die Art und Weise, wie Sie die Quellidentität verwenden, unterscheidet sich von Rollensitzungsnamen und Sitzungs-Tags auf wichtige Weise. Der Quellidentitätswert kann nicht geändert werden, nachdem er festgelegt wurde, und er bleibt für alle zusätzlichen Aktionen bestehen, die mit der Rollensitzung ausgeführt werden. So können Sie Sitzungs-Tags und Rollensitzungsnamen verwenden:
+ **Sitzungs-Tags** – Sie können Sitzungs-Tags übergeben, wenn Sie eine Rolle übernehmen oder einen Benutzer föderieren. Sitzungs-Tags sind vorhanden, wenn eine Rolle angenommen wird. Sie können Richtlinien definieren, die Tag-Bedingungsschlüssel verwenden, um Ihren Auftraggeber basierend auf ihren Tags Berechtigungen zu erteilen. Anschließend können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Weitere Informationen zu Sitzungs-Tags finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md).
+ **Rollensitzungsname** – Sie können den `sts:RoleSessionName`-Bedingungsschlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer einen bestimmten Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Rollensitzungsname kann verwendet werden, um Rollensitzungen zu unterscheiden, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird. Weitere Informationen zum Namen der Rollensitzung finden Sie unter [sts: RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname).
Es wird empfohlen, die Quellidentität zu verwenden, wenn Sie die Identität steuern möchten, die eine Rolle übernimmt. Die Quellenidentität ist auch nützlich für das CloudTrail Miningprotokoll, um festzustellen, wer die Rolle zur Ausführung von Aktionen verwendet hat.
**Topics**
+ [Einrichten für die Verwendung der Quellidentität](#id_credentials_temp_control-access_monitor-setup)
+ [Wissenswertes über die Quellidentität](#id_credentials_temp_control-access_monitor-know)
+ [Zum Festlegen der Quellidentität erforderliche Berechtigungen](#id_credentials_temp_control-access_monitor-perms)
+ [Angeben einer Quellidentität bei der Übernahme einer Rolle](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [Verwenden Sie die Quellidentität mit AssumeRole](#id_credentials_temp_control-access_monitor-assume-role)
+ [Verwendung der Quellidentität mit AssumeRoleWith SAML](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [Verwenden Sie die Quellidentität mit AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [Steuern des Zugriffs mithilfe von Informationen zur Quell](#id_credentials_temp_control-access_monitor-control-access)
+ [Quellenidentität anzeigen in CloudTrail](#id_credentials_temp_control-access_monitor-ct)
## Einrichten für die Verwendung der Quellidentität
Die Art und Weise, wie Sie die Quellidentität verwenden, hängt von der Methode ab, die verwendet wird, wenn Ihre Rollen angenommen werden. Beispielsweise können Ihre IAM-Benutzer Rollen direkt übernehmen, indem sie die `AssumeRole` verwenden. Wenn Sie über Unternehmensidentitäten verfügen, die auch als Personalidentitäten bezeichnet werden, greifen diese möglicherweise mithilfe von auf Ihre AWS Ressourcen zu. `AssumeRoleWithSAML` Wenn Endbenutzer auf Ihre mobilen oder Webanwendungen zugreifen, tun sie dies möglicherweise über `AssumeRoleWithWebIdentity`. Im Folgenden finden Sie einen Überblick über den Workflow auf hoher Ebene, mit dem Sie verstehen, wie Sie die Verwendung von Quellidentitätsinformationen in Ihrer vorhandenen Umgebung einrichten können.
1. **Konfigurieren von Testbenutzern und -rollen** – Konfigurieren Sie mithilfe einer Vorproduktionsumgebung Testbenutzer und -rollen und konfigurieren Sie ihre Richtlinien so, dass eine Quellidentität festgelegt werden kann.
Wenn Sie einen Identitätsanbieter (IdP) für Ihre Verbundidentitäten verwenden, konfigurieren Sie Ihren IdP so, dass ein Benutzerattribut Ihrer Wahl für die Quellidentität in der Assertion oder Token übergeben wird.
1. **Nehmen Sie die Rolle an.** – Testen Sie das Annehmen von Rollen und Übergeben einer Quellidentität mit den Benutzern und Rollen, die Sie zum Testen eingerichtet haben.
1. **Überprüfung CloudTrail** — Überprüfen Sie die Quellidentitätsinformationen für Ihre Testrollen in Ihren CloudTrail Protokollen.
1. **Trainieren von Benutzern** – Stellen Sie nach dem Test in Ihrer Vorproduktionsumgebung sicher, dass Ihre Benutzer wissen, wie sie die Quellidentitätsinformationen eingeben, falls erforderlich. Legen Sie einen Stichtag fest, an dem Ihre Benutzer eine Quellidentität in Ihrer Produktionsumgebung angeben müssen.
1. **Konfigurieren von Produktionsrichtlinien** – Konfigurieren Sie Ihre Richtlinien für Ihre Produktionsumgebung und fügen Sie sie dann Ihren Produktionsbenutzern und -rollen hinzu.
1. **Aktivität überwachen** — Überwachen Sie die Aktivitäten Ihrer Produktionsrollen mithilfe von CloudTrail Protokollen.
## Wissenswertes über die Quellidentität
Beachten Sie bei der Arbeit mit der Quellenidentität folgende Punkte.
+ Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die `sts:SetSourceIdentity`-Berechtigung verfügen. Bei Rollen, die diese Berechtigung in der Vertrauensrichtlinie nicht haben, schlägt der `AssumeRole*`-Vorgang fehl. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP-Instance zum Übergeben von Sitzungs-Tags verwenden. Fügen Sie dann die `sts:SetSourceIdentity`-Berechtigung nur den Rollen hinzu, die mit dem separaten IdP verbunden sind.
+ Wenn eine Identität eine Quellidentität festlegt, wird die `sts:SourceIdentity`-Schlüssel in der Anforderung. Für nachfolgende Aktionen, die während der Rollensitzung ausgeführt werden, ist der Schlüssel `aws:SourceIdentity` in der Anfrage vorhanden. AWS kontrolliert den Wert der Quellidentität weder in den Schlüsseln `sts:SourceIdentity` noch `aws:SourceIdentity`. Wenn Sie eine Quellidentität benötigen, müssen Sie ein Attribut auswählen, das Ihre Benutzer oder IdP bereitstellen sollen. Aus Sicherheitsgründen müssen Sie sicherstellen, dass Sie steuern können, wie diese Werte bereitgestellt werden.
+ Der Wert der Quell-Identität muss zwischen 2 und 64 Zeichen lang sein und darf nur alphanumerische Zeichen, Unterstriche und die folgenden Zeichen enthalten:**., \$1 = @ -**(Bindestrich). Sie können keinen Tag-Schlüssel oder -Wert erstellen, der mit dem Text **aws:** beginnt. Dieses Präfix ist für den AWS internen Gebrauch reserviert.
+ Die Quellidentitätsinformationen werden nicht erfasst, CloudTrail wenn ein AWS Dienst oder eine dienstbezogene Rolle eine Aktion im Namen einer föderierten Identität oder einer Belegschaftsidentität ausführt.
**Wichtig**
Sie können nicht zu einer Rolle in der wechseln, für AWS-Managementkonsole die eine Quellidentität festgelegt werden muss, wenn die Rolle übernommen wird. Um eine solche Rolle anzunehmen, können Sie die AWS CLI AWS OR-API verwenden, um den `AssumeRole` Vorgang aufzurufen und den Quellidentitätsparameter anzugeben.
## Zum Festlegen der Quellidentität erforderliche Berechtigungen
Zusätzlich zu der Aktion, die der API-Operation entspricht, muss in Ihrer Richtlinie die folgende reine Berechtigungsaktion enthalten sein:
```
sts:SetSourceIdentity
```
+ Um eine Quellidentität anzugeben, müssen Auftraggeber (IAM-Benutzer und IAM-Rollen) über Berechtigungen für `sts:SetSourceIdentity` haben. Als Administrator können Sie dies in der Rollenvertrauensrichtlinie und in der Berechtigungsrichtlinie des Auftraggebers konfigurieren.
+ Wenn Sie eine Rolle mit einer anderen Rolle übernehmen, was als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet wird, sind Berechtigungen für `sts:SetSourceIdentity` sowohl in der Berechtigungsrichtlinie des Auftraggebers, der die Rolle übernimmt, als auch in der Rollenvertrauensrichtlinie der Zielrolle erforderlich. Andernfalls schlägt die Operation fehl.
+ Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die `sts:SetSourceIdentity`-Berechtigung verfügen. Der `AssumeRole*`-Vorgang schlägt für jede Rolle fehl, die mit einem IdP verbunden ist, der Sitzungs-Tags ohne diese Berechtigung übergibt. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP Instance zum Übergeben der Quell-Identität verwenden und die `sts:SetSourceIdentity`-Berechtigung nur die Rollen, die mit dem separaten IdP verbunden sind.
+ Um eine Quellidentität über Kontogrenzen hinweg festzulegen, müssen Sie die Berechtigung `sts:SetSourceIdentity` an zwei Stellen einfügen. Sie muss sich in der Berechtigungsrichtlinie des Auftraggebers im Ursprungskonto und in der Rollenvertrauensrichtlinie der Rolle im Zielkonto befinden. Dies kann z. B. erforderlich sein, wenn eine Rolle verwendet wird, um eine Rolle in einem anderen Konto mit [Rollenverkettung](id_roles.md#iam-term-role-chaining) zu übernehmen.
Stellen Sie sich als Kontoadministrator vor, Sie möchten den IAM-Benutzer `DevUser` in Ihrem Konto, um die `Developer_Role` auf demselben Konto zu übernehmen. Sie möchten diese Aktion jedoch nur zulassen, wenn der Benutzer die Quellidentität auf seinen IAM-Benutzernamen festgelegt hat. Sie können dazu diesem Benutzer die folgende IAM-Richtlinie zuweisen.
**Example Beispiel für eine identitätsbasierte Richtlinie, die angehängt ist DevUser**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
Um die zulässigen Werte für die Quellidentität zu erzwingen, können Sie die folgende Rollenvertrauensrichtlinie konfigurieren. Die Richtlinie gibt dem IAM-Benutzer `DevUser` die Berechtigung, die Rolle zu übernehmen und eine Quellidentität festzulegen. Der `sts:SourceIdentity`-Bedingungsschlüssel definiert den zulässigen Wert der Quellenidentität.
**Example Beispiel einer Rollenvertrauensrichtlinie für Quellidentität**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
Unter Verwendung der Anmeldeinformationen für den IAM-Benutzer versucht der Benutzer anzunehmen`DevUser`, dass er die folgende Anfrage `DeveloperRole` verwendet. AWS CLI
**Example Beispiel für eine AssumeRole CLI-Anfrage**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
Bei der AWS Auswertung der Anfrage enthält der Anforderungskontext das `sts:SourceIdentity` of`DevUser`.
## Angeben einer Quellidentität bei der Übernahme einer Rolle
Sie können eine Quellidentität angeben, wenn Sie eine der AWS STS `AssumeRole*` API-Operationen verwenden, um temporäre Sicherheitsanmeldeinformationen für eine Rolle abzurufen. Die API-Operation, die Sie verwenden, unterscheidet sich je nach Anwendungsfall. Wenn Sie beispielsweise IAM-Rollen verwenden, um IAM-Benutzern Zugriff auf AWS Ressourcen zu gewähren, auf die sie normalerweise keinen Zugriff haben, können Sie den `AssumeRole` Vorgang verwenden. Wenn Sie zur Verwaltung Ihrer Mitarbeiter den Identitätsverbund verwenden, können Sie den Vorgang `AssumeRoleWithSAML` verwenden. Wenn Sie den OIDC-Verbund verwenden, um Endbenutzern den Zugriff auf Ihre Mobil- oder Webanwendungen zu ermöglichen, können Sie diese `AssumeRoleWithWebIdentity`-Operation verwenden. In den folgenden Abschnitten wird die Verwendung von Quellidentitäten bei jedem Vorgang erläutert. Weitere Informationen über häufige Szenarien für temporäre Berechtigungsnachweise finden Sie unter [Gängige Szenarien für temporäre Anmeldeinformationen](id_credentials_temp.md#sts-introduction).
## Verwenden Sie die Quellidentität mit AssumeRole
Der `AssumeRole` Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Sie können IAM-Benutzer- oder Rollenanmeldeinformationen verwenden, um `AssumeRole` aufzurufen. Verwenden Sie die `-–source-identity` AWS CLI Option oder den `SourceIdentity` AWS API-Parameter, um bei der Übernahme einer Rolle die Quellenidentität zu übergeben. Das folgende Beispiel zeigt, wie die Quellidentität mit der AWS CLI angegeben werden kann.
**Example Beispiel für eine AssumeRole CLI-Anfrage**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## Verwendung der Quellidentität mit AssumeRoleWith SAML
Die `AssumeRoleWithSAML`-Operation wird mit dem SAML-basierten Verbund authentifiziert. Dieser Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Weitere Informationen zur Verwendung eines SAML-basierten Verbunds für den AWS-Managementkonsole Zugriff finden Sie unter. [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md) Einzelheiten zu AWS CLI unserem AWS API-Zugriff finden Sie unter. [SAML 2.0-Föderation](id_roles_providers_saml.md) Eine Anleitung zur Einrichtung eines SAML-Verbunds für Ihre Active Directory-Benutzer finden Sie unter [AWS Verbundauthentifizierung mit Active Directory Federation Services (ADFS) im AWS Sicherheitsblog](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/).
Als Administrator können Sie es Mitgliedern Ihres Unternehmensverzeichnisses ermöglichen, den Vorgang gemeinsam zu AWS nutzen. AWS STS `AssumeRoleWithSAML` Hierfür müssen Sie die folgenden Aufgaben ausführen:
1. [Konfigurieren Sie einen SAML-Anbieter in Ihrer Organisation.](id_roles_providers_saml_3rd-party.md)
1. [Erstellen eines SAML-Anbieters in IAM](id_roles_providers_create_saml.md).
1. [Konfigurieren Sie eine Rolle und ihre Berechtigungen AWS für Ihre SAML-Verbundprinzipale](id_roles_create_for-idp_saml.md).
1. [Abschließen der Konfiguration des SAML-Identitätsanbieters und Erstellen von Zusicherungen für die SAML-Authentifizierungsantwort](id_roles_providers_create_saml_assertions.md).
Um ein SAML-Attribut für die Quellidentität festzulegen, schließen Sie das `Attribute`-Element mit dem `Name`-Attribut gesetzt auf `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Verwenden Sie das `AttributeValue`-Element, um den Wert der Quellidentität anzugeben. Angenommen, Sie möchten die folgenden Identitätsattribute als Sitzungs-Tags übergeben.
`SourceIdentity:DiegoRamirez`
Um diese Attribute zu übergeben, schließen Sie die folgenden Elemente in Ihre SAML-Zusicherung ein.
**Example Beispielausschnitt einer SAML-Zusicherung**
```
DiegoRamirez
```
## Verwenden Sie die Quellidentität mit AssumeRoleWithWebIdentity
Der Aufruf der `AssumeRoleWithWebIdentity`-Operation durch den Prinzipal wird mithilfe eines OpenID Connect (OIDC)-konformen Verbunds authentifiziert. Diese Operation gibt einen Satz temporärer Anmeldeinformationen zurück, die Sie für den Zugriff auf AWS -Ressourcen verwenden können. Weitere Informationen zur Verwendung des OIDC-Verbundes für den AWS-Managementkonsole -Zugriff finden Sie unter [OIDC-Verbund](id_roles_providers_oidc.md).
Um die Quellidentität von OpenID Connect (OIDC) zu übergeben, müssen Sie die Quellidentität in das JSON Web Token (JWT) einbeziehen. Fügen Sie Sitzungs-Tags in den `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity`-Namespace in dem Token ein, wenn Sie die `AssumeRoleWithWebIdentity`-Anforderung senden. Weitere Informationen zu OIDC-Token und Ansprüchen finden Sie unter [Verwenden von Token mit Benutzerpools](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) im *Amazon Cognito Developer Guide*.
Der folgende entschlüsselte JWT ist beispielsweise ein Token, das zum Aufrufen von `AssumeRoleWithWebIdentity` mit der Quellidentität `Admin` verwendet wird.
**Example Beispiel für ein dekodiertes JSON-Web-Token**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## Steuern des Zugriffs mithilfe von Informationen zur Quell
Wenn eine Quellidentität anfänglich festgelegt wird, ist der SourceIdentity Schlüssel [sts:](reference_policies_iam-condition-keys.md#ck_sourceidentity) in der Anfrage enthalten. Nachdem eine Quellidentität festgelegt wurde, ist der SourceIdentity Schlüssel [aws:](reference_policies_condition-keys.md#condition-keys-sourceidentity) in allen nachfolgenden Anfragen vorhanden, die während der Rollensitzung gestellt wurden. Als Administrator können Sie Richtlinien schreiben, die eine bedingte Autorisierung zur Ausführung von AWS Aktionen gewähren, die auf der Existenz oder dem Wert des Quellidentitätsattributs basieren.
Stellen Sie sich vor, Sie möchten von Ihren Entwicklern verlangen, dass sie eine Quellidentität festlegen, damit sie eine wichtige Rolle übernehmen können, die über Schreibberechtigungen für eine produktionskritische AWS Ressource verfügt. Stellen Sie sich außerdem vor, Sie gewähren AWS Zugriff auf die Identitäten Ihrer Belegschaft mithilfe von`AssumeRoleWithSAML`. Sie möchten nur, dass ältere Entwickler Saanvi und Diego Zugriff auf die Rolle haben. Daher erstellen Sie die folgende Vertrauensrichtlinie für die Rolle.
**Example Beispiel einer Rollenvetrauensichtlinie für Quellidentität (SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
Die Vertrauensrichtlinie enthält eine Bedingung für `sts:SourceIdentity`, die eine Quellidentität erfordert, die auf Saanvi oder Diego eingestellt ist, um die kritische Rolle anzunehmen.
Wenn Sie jedoch einen OIDC-Anbieter für den Verbund verwenden und Benutzer mit `AssumeRoleWithWebIdentity` authentifiziert werden, könnte Ihre Rollenvertrauensrichtlinie wie folgt aussehen.
**Example Beispiel einer Rollenvetrauensichtlinie für Quellidentität (OIDC-Anbieter)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### Rollenverkettung und kontenübergreifende Anforderungen
Stellen Sie sich vor, Sie möchten Benutzern, die `CriticalRole` angenommen haben, erlauben, ein `CriticalRole_2` in einem anderen Konto anzunehmen. Die Anmeldeinformationen für die Rollensitzung, die für die Annahme von `CriticalRole` erlangt wurden, werden für die [Rollenkette](id_roles.md#iam-term-role-chaining) einer zweiten Rolle, `CriticalRole_2`, in einem anderen Konto verwendet. Die Rolle wird über eine Kontengrenze hinweg übernommen. Daher muss die Berechtigung `sts:SetSourceIdentity` sowohl in der Berechtigungsrichtlinie für `CriticalRole` als auch in der Rollenvertrauensrichtlinie für `CriticalRole_2` erteilt werden.
**Example Beispiel für eine Berechtigungsrichtlinie für CriticalRole**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
Um das Festlegen der Quellidentität über die Kontengrenze hinweg zu sichern, vertraut die folgende Rollenvertrauensrichtlinie nur dem Rollenauftraggeber für`CriticalRole`, um die Quellidentität festzulegen.
**Example Beispiel für eine Vertrauensrichtlinie für eine Rolle auf CriticalRole \$12**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
Der Benutzer führt den folgenden Aufruf mit den Anmeldeinformationen für die Rollensitzung durch, die er bei der Annahme abgerufen hat CriticalRole. Die Quellidentität wurde während der Annahme von festgelegt CriticalRole, sodass sie nicht erneut explizit festgelegt werden muss. Wenn der Benutzer versucht, eine Quellidentität festzulegen, die sich von dem Wert unterscheidet, der bei der Übernahme von `CriticalRole` festgelegt wurde, wird die Anforderung der Rollenübernahme abgelehnt.
**Example Beispiel für eine AssumeRole CLI-Anfrage**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
Wenn der aufrufende Auftraggeber die Rolle übernimmt, bleibt die Quellidentität in der Anforderung ab der ersten angenommenen Rollensitzung bestehen. Daher sind sowohl der `aws:SourceIdentity`- als auch der `sts:SourceIdentity`-Schlüssel im Anfragekontext vorhanden.
## Quellenidentität anzeigen in CloudTrail
Hier können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Sie können auch die Rolle oder die Benutzeranfragen zur Durchführung von Aktionen in AWS einsehen. Die CloudTrail Protokolldatei enthält Informationen über die Quellidentität, die für die Sitzung mit übernommener Rolle oder Verbundbenutzer festgelegt wurde. Weitere Informationen finden Sie unter [Protokollierung von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail](cloudtrail-integration.md).
Gehen Sie beispielsweise davon aus, dass ein Benutzer eine AWS STS `AssumeRole` Anfrage stellt und eine Quellidentität festlegt. Sie finden die `sourceIdentity` Informationen im `requestParameters` Schlüssel in Ihrem CloudTrail Protokoll.
**Example Beispiel für einen RequestParameter-Abschnitt in einem Protokoll AWS CloudTrail**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
Wenn der Benutzer die angenommene Rollensitzung verwendet, um eine Aktion auszuführen, sind die Informationen zur Quellidentität im `userIdentity` Schlüssel im CloudTrail Protokoll enthalten.
**Example Beispiel für einen UserIdentity-Schlüssel in einem Protokoll AWS CloudTrail**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
Beispiele für AWS STS API-Ereignisse in CloudTrail Protokollen finden Sie unter. [Beispiel für IAM-API-Ereignisse im Protokoll CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api) Weitere Informationen zu den in CloudTrail Protokolldateien enthaltenen Informationen finden Sie unter [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) im *AWS CloudTrail Benutzerhandbuch*.
# Berechtigungen für GetFederationToken
Die `GetFederationToken`-Operation wird von einem IAM-Benutzer aufgerufen und gibt temporäre Anmeldedaten für diesen Benutzer zurück. Diese Operation *verbindet* die Benutzer. Die einer AWS STS Verbundbenutzersitzung zugewiesenen Berechtigungen werden an einer von zwei Stellen definiert:
+ In den Sitzungsrichtlinien, die als Parameter im API-Aufruf `GetFederationToken` übergeben werden. (Dies ist am üblichsten.)
+ Eine ressourcenbasierte Richtlinie, die die AWS STS Verbundbenutzersitzung explizit im `Principal` Element der Richtlinie benennt. (Dies ist weniger üblich.)
Sitzungsrichtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie eine temporäre Sitzung programmgesteuert erstellen. Wenn Sie eine AWS STS Verbundbenutzersitzung erstellen und Sitzungsrichtlinien übergeben, stellen die daraus resultierenden Sitzungsberechtigungen die Schnittmenge zwischen der identitätsbasierten Richtlinie des Benutzers und den Sitzungsrichtlinien dar. Sie können mit der Sitzungsrichtlinie nicht mehr Berechtigungen erteilen, als durch die identitätsbasierte Richtlinie des Benutzers, der verbunden wird, zulässig sind.
Wenn Sie also keine Richtlinie mit dem `GetFederationToken`-API-Aufruf übergeben, verfügen die resultierenden temporären Sicherheitsanmeldedaten über keine Berechtigungen. Allerdings kann eine ressourcenbasierte Richtlinie zusätzliche Berechtigungen für die Sitzung bereitstellen. Sie können auf eine Ressource mit einer ressourcenbasierten Richtlinie zugreifen, die Ihre Sitzung als zulässigen Auftraggeber angibt.
Die folgenden Abbildungen zeigen eine visuelle Darstellung der Interaktion von Richtlinien, um die Berechtigungen für die von einem `GetFederationToken`-Aufruf zurückgegebenen temporären Anmeldeinformationen zu bestimmen.
![\[IAM-Benutzer: Die folgenden Abbildungen zeigen Häkchen, um anzuzeigen, dass es sich bei den Sitzungsberechtigungen um die Schnittmenge aus der identitätsbasierten Richtlinie des Benutzers und den Sitzungsrichtlinien handelt. Sitzungsberechtigungen können auch die Schnittmenge aus identitätsbasierten Richtlinien und ressourcenbasierten Richtlinien des Benutzers sein.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## Beispiel: Zuweisen von Berechtigungen mit GetFederationToken
Sie können die `GetFederationToken`-API-Aktion mit verschiedenen Arten von Richtlinien verwenden. Nachfolgend sind einige Beispiele aufgeführt.
### Zum IAM-Benutzer angefügte Richtlinie
In diesem Beispiel verfügen Sie über eine browserbasierte Clientanwendung, die sich auf zwei Backend-Web-Services stützt. Ein Backend-Service ist Ihr eigener Authentifizierungsserver, der Ihr eigenes Identitätssystem zum Authentifizieren der Clientanwendung verwendet. Der andere Backend-Service ist ein AWS -Service, der einige Funktionalitäten der Clientanwendung bereitstellt. Die Clientanwendung wird von Ihrem Server authentifiziert und Ihr Server erstellt die entsprechende Berechtigungsrichtlinie oder ruft sie ab. Der Server ruft dann das `GetFederationToken`-API auf, um temporäre Anmeldeinformationen zu erhalten und diese Anmeldeinformationen zur Clientanwendung zurückzugeben. Die Client-Anwendung kann dann mit den temporären Sicherheitsanmeldedaten Anfragen direkt an den AWS Dienst richten. Diese Architektur ermöglicht es der Client-Anwendung, AWS Anfragen zu stellen, ohne langfristige AWS Anmeldeinformationen einzubetten.
Der Authentifizierungsserver ruft die `GetFederationToken`-API mit den langfristigen Sicherheitsanmeldedaten eines IAM-Benutzers mit dem Namen `token-app` auf. Die langfristigen IAM-Benutzeranmeldedaten bleiben jedoch auf Ihrem Server und werden unter keinen Umständen an den Client weitergegeben. Die folgende Beispielrichtlinie ist an den `token-app` IAM-Benutzer angehängt und definiert die umfassendsten Berechtigungen, die Ihre AWS STS Verbundbenutzer (Clients) benötigen. Beachten Sie, dass die `sts:GetFederationToken` Berechtigung erforderlich ist, damit Ihr Authentifizierungsdienst temporäre Sicherheitsanmeldeinformationen für die AWS STS Verbundbenutzer abrufen kann.
**Example Die dem IAM-Benutzer `token-app` angefügte Richtlinie, die `GetFederationToken` aufruft**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
Die obige Richtlinie erteilt dem IAM-Benutzer mehrere Berechtigungen. Diese Richtlinie allein gewährt dem AWS STS Verbundbenutzer jedoch keine Berechtigungen. Wenn dieser IAM-Benutzer eine Richtlinie als Parameter des API-Aufrufs aufruft `GetFederationToken` und sie nicht weitergibt, hat der daraus resultierende AWS STS Verbundbenutzer keine effektiven Berechtigungen.
### Als Parameter übergebene Sitzungsrichtlinie
Die gängigste Methode, um sicherzustellen, dass dem AWS STS Verbundbenutzer die entsprechenden Berechtigungen zugewiesen werden, besteht darin, Sitzungsrichtlinien im `GetFederationToken` API-Aufruf zu übergeben. Aufbauend auf dem vorherigen Beispiel nehmen wir an, das `GetFederationToken` mit den Anmeldedaten des IAM-Benutzers `token-app` aufgerufen wird. Angenommen, die folgende Sitzungsrichtlinie wird als Parameter des API-Aufrufs übergeben. Der resultierende AWS STS -Verbundbenutzer verfügt über die Berechtigung zum Auflisten der Inhalte des Amazon-S3-Buckets mit dem Namen `productionapp`. Der Benutzer kann die Amazon S3-Aktionen `GetObject`, `PutObject` und `DeleteObject` für Elemente im `productionapp`-Bucket nicht ausführen.
Dem Verbundbenutzer werden diese Berechtigungen zugewiesen, da die Berechtigungen die Schnittmenge der IAM-Benutzerberechtigungen und der Sitzungsrichtlinien bilden, die Sie übergeben.
Der AWS STS Verbundbenutzer konnte außer in Amazon SNS, Amazon SQS, Amazon DynamoDB oder in einem anderen S3-Bucket keine Aktionen ausführen. `productionapp` Diese Aktionen werden abgelehnt, auch wenn diese Berechtigungen dem IAM-Benutzer erteilt werden, der mit dem `GetFederationToken`-Aufruf verknüpft ist.
**Example Als Parameter im API-Aufruf `GetFederationToken` übergebene Sitzungsrichtlinie**
****
```
{
"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/*"]
}
]
}
```
### Ressourcenbasierte Richtlinien
Einige AWS Ressourcen unterstützen ressourcenbasierte Richtlinien, und diese Richtlinien bieten einen weiteren Mechanismus, um einem Verbundbenutzer direkt Berechtigungen zu erteilen. AWS STS Nur einige AWS Dienste unterstützen ressourcenbasierte Richtlinien. Amazon S3 verfügt beispielsweise über Buckets, Amazon SNS über Themen und Amazon SQS über Warteschlangen, denen Sie Richtlinien zuordnen können. Eine Liste aller Services, die ressourcenbasierte Richtlinien unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md). Überprüfen Sie die Spalte "Ressourcenbasierte Richtlinien" der Tabellen. Sie können ressourcenbasierte Richtlinien verwenden, um einem Verbundbenutzer direkt Berechtigungen zuzuweisen. AWS STS Geben Sie dazu den Amazon-Ressourcennamen (ARN) des AWS STS Verbundbenutzers im `Principal` Element der ressourcenbasierten Richtlinie an. Das folgende Beispiel veranschaulicht diesen Vorgang und ist eine Erweiterung der vorherigen Beispiele, wobei ein S3-Bucket mit dem Namen `productionapp` verwendet wird.
Die folgende ressourcenbasierte Richtlinie wird dem Bucket angefügt. Diese Bucket-Richtlinie ermöglicht einem AWS STS Verbundbenutzer namens Carol den Zugriff auf den Bucket. Wenn die zuvor beschriebene Beispielrichtlinie an den `token-app` IAM-Benutzer angehängt wird, hat der AWS STS Verbundbenutzer namens Carol die Berechtigung, die `s3:DeleteObject` Aktionen `s3:GetObject``s3:PutObject`, und für den genannten Bucket auszuführen. `productionapp` Dies gilt auch, wenn keine Sitzungsrichtlinie als Parameter im `GetFederationToken`-API-Aufruf übergeben wird. Das liegt daran, dass in diesem Fall dem AWS STS Verbundbenutzer namens Carol durch die folgende ressourcenbasierte Richtlinie ausdrücklich Berechtigungen erteilt wurden.
***Denken Sie daran, dass einem AWS STS Verbundbenutzer nur dann Berechtigungen erteilt werden, wenn diese Berechtigungen sowohl dem IAM-Benutzer als auch dem Verbundbenutzer ausdrücklich erteilt wurden.*** AWS STS Sie können (innerhalb des Kontos) auch durch eine ressourcenbasierte Richtlinie gewährt werden, die den AWS STS Verbundbenutzer explizit im `Principal` Element der Richtlinie benennt, wie im folgenden Beispiel.
**Example Bucket-Richtlinie, die dem Verbundbenutzer Zugriffsberechtigungen erteilt**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
Weitere Informationen über das Auswerten von Richtlinien finden Sie unter [Logik der Richtlinienevaluierung](reference_policies_evaluation-logic.md).
# Berechtigungen für GetSessionToken
Primärer Anlass zum Aufruf der API-Operation `GetSessionToken` oder des CLI-Befehls `get-session-token` ist, wenn ein Benutzer mit Multi-Factor Authentication (MFA) authentifiziert werden muss. Es ist möglich, eine Richtlinie zu verfassen, die bestimmte Aktionen nur dann erlaubt, wenn diese Aktionen von einem Benutzer angefordert werden, der mit MFA authentifiziert wurde. Um die MFA-Autorisierungsprüfung erfolgreich zu bestehen, muss ein Benutzer zunächst `GetSessionToken` aufrufen und die optionalen Parameter `SerialNumber` und `TokenCode` einschließen. Wenn sich der Benutzer erfolgreich bei einem MFA-Gerät authentifiziert, enthalten die von der API-Operation `GetSessionToken` zurückgegebenen Anmeldeinformationen den MFA-Kontext. Dieser Kontext gibt an, dass der Benutzer mit MFA authentifiziert und für API-Operationen autorisiert ist, für die eine MFA-Authentifizierung erforderlich ist.
## Berechtigungen erforderlich für GetSessionToken
Ein Benutzer benötigt keine Berechtigungen, um ein Sitzungstoken zu erhalten. Der Zweck der Operation `GetSessionToken` besteht darin, den Benutzer mithilfe von MFA zu authentifizieren. Richtlinien können nicht dazu verwendet werden, Authentifizierungsoperationen zu steuern.
Um Berechtigungen für die Ausführung der meisten AWS Operationen zu erteilen, fügen Sie die Aktion mit dem gleichen Namen zu einer Richtlinie hinzu. Um einen Benutzer zu erstellen, müssen Sie z. B. die API-Operation `CreateUser`, den CLI-Befehl `create-user` oder die AWS-Managementkonsole verwenden. Um diese Operationen durchführen zu können, müssen Sie über eine Richtlinie verfügen, die Ihnen Zugriff auf die Aktion `CreateUser` gewährt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
Sie können die Aktion `GetSessionToken` in Ihre Richtlinien einfügen, dies hat aber keine Auswirkungen auf die Fähigkeit des Benutzers, die Operation `GetSessionToken` auszuführen.
## Berechtigungen erteilt von GetSessionToken
Wenn `GetSessionToken` mit den Anmeldeinformationen eines IAM-Benutzers aufgerufen wird, haben die temporären Sicherheitsanmeldeinformationen dieselben Berechtigungen wie der IAM-Benutzer. In ähnlicher Weise verfügen die temporären Root-Benutzer des AWS-Kontos Sicherheitsanmeldedaten über Root-Benutzerberechtigungen, wenn `GetSessionToken` sie mit Anmeldeinformationen aufgerufen werden.
**Anmerkung**
Es wird empfohlen, `GetSessionToken` nicht mit Stammbenutzer-Anmeldeinformationen aufzurufen. Befolgen Sie stattdessen unsere [bewährten Methoden](best-practices-use-cases.md) und erstellen Sie IAM-Benutzer mit den Berechtigungen, die sie benötigen. Verwenden Sie diese IAM-Benutzer dann für die tägliche Interaktion mit AWS.
Die temporären Anmeldeinformationen, die Sie erhalten, wenn Sie `GetSessionToken` aufrufen, haben die folgenden Funktionen und Einschränkungen:
+ Sie können die Anmeldeinformationen für den Zugriff auf verwenden, AWS-Managementkonsole indem Sie die Anmeldeinformationen an den Single Sign-On-Endpunkt des Verbunds unter übergeben. `https://signin.aws.amazon.com/federation` Weitere Informationen finden Sie unter [Benutzerdefinierten Identity Broker-Zugriff auf die AWS Konsole aktivieren](id_roles_providers_enable-console-custom-url.md).
+ Sie können die Anmeldeinformationen **nicht** verwenden, um IAM- oder AWS STS -API-Operationen aufzurufen. Sie **können** sie verwenden, um API-Operationen für andere AWS Dienste aufzurufen.
Unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md) können Sie diese API-Operation und ihre Grenzen und Funktionen mit den anderen API-Operationen, die temporäre Sicherheitsanmeldeinformationen erstellen, vergleichen.
Weitere Informationen über MFA-geschützten API-Zugriff mithilfe von `GetSessionToken` finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
# Deaktivieren von Berechtigungen für temporäre Sicherheitsanmeldeinformationen
Temporäre Sicherheitsanmeldeinformationen sind bis zu ihrem Ablauf gültig. Diese Anmeldeinformationen sind für die angegebene Dauer von 900 Sekunden (15 Minuten) bis maximal 129 600 Sekunden (36 Stunden) gültig. Die Standardsitzungsdauer beträgt 43 200 Sekunden (12 Stunden). Sie können diese Anmeldeinformationen widerrufen, müssen aber auch die Berechtigungen für den IAM-Benutzer oder die IAM-Rolle ändern, um die Verwendung kompromittierter Anmeldeinformationen für bösartiger Kontoaktivitäten zu verhindern. Berechtigungen, die temporären Sicherheitsanmeldedaten zugewiesen wurden, werden jedes Mal bewertet, wenn sie für eine AWS Anfrage verwendet werden. Sobald Sie alle Berechtigungen aus den Anmeldeinformationen entfernt haben, schlagen AWS Anfragen, die sie verwenden, fehl.
Es kann einige Minuten dauern, bis Richtlinienaktualisierungen wirksam werden. Bei IAM-Rollensitzungen können Sie die temporären Sicherheits-Anmeldeinformationen der Rolle widerrufen, um alle Benutzer, die die Rolle übernehmen, zu einer erneuten Authentifizierung und Anforderung neuer Anmeldeinformationen zu zwingen. Weitere Informationen finden Sie unter [Widerrufen der temporären Sicherheitsanmeldeinformationen der Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html).
Sie können die Berechtigungen für eine nicht ändern Root-Benutzer des AWS-Kontos. Ebenso können die Berechtigungen für die temporären Sicherheitsanmeldeinformationen nicht geändert werden, die durch Aufrufen von `GetFederationToken` oder `GetSessionToken` erstellt wurden, während der Benutzer als Stammbenutzer angemeldet war. Daher empfehlen wir, dass Sie `GetFederationToken` oder `GetSessionToken` nicht als Stammbenutzer aufrufen.
Vorgehensweisen zum Ändern der Berechtigungen für einen IAM-Benutzer finden Sie unter [Ändern von Berechtigungen für einen IAM-Benutzer](id_users_change-permissions.md).
Vorgehensweisen zum Ändern der Berechtigungen für eine IAM-Rolle finden Sie unter [Berechtigungen für eine Rolle aktualisieren](id_roles_update-role-permissions.md).
**Wichtig**
Sie können in IAM keine Rollen bearbeiten, die aus Berechtigungssätzen des IAM Identity Center erstellt wurden. Sie müssen die aktive Berechtigungssatz-Sitzung für einen Benutzer im IAM Identity Center widerrufen. Weitere Informationen finden Sie unter [Widerrufen aktiver IAM-Rollensitzungen, die durch Berechtigungssätze erstellt wurden](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) im *Benutzerhandbuch zum IAM Identity Center*.
**Topics**
+ [Verweigerung des Zugriffs auf alle IAM-Rollensitzungen, die einer Rolle zugeordnet sind](#deny-access-to-all-sessions)
+ [Zugriff auf eine bestimmte IAM-Rollensitzung verweigern](#deny-access-to-specific-session)
+ [Zugriff auf Sitzungen mit temporären Sicherheits-Anmeldeinformationen mit Bedingungskontextschlüsseln verweigern](#deny-access-to-specific-session-condition-key)
+ [Zugriff auf einen bestimmten Prinzipal mit ressourcenbasierten Richtlinien verweigern](#deny-access-with-resource-based)
## Verweigerung des Zugriffs auf alle IAM-Rollensitzungen, die einer Rolle zugeordnet sind
Dieses Verfahren verweigert Berechtigungen für **alle** IAM-Rollensitzungen, die einer Rolle zugeordnet sind. Verwenden Sie diesen Ansatz, wenn Sie Bedenken hinsichtlich verdächtiger Zugriffe durch Folgendes haben:
+ Prinzipale von einem anderen Konto mit kontoübergreifendem Zugriff
+ Externe Benutzeridentitäten mit Berechtigungen für den Zugriff auf AWS Ressourcen in Ihrem Konto
+ Benutzer, die in einer mobilen oder Web-Anwendung mit einem OIDC-Anbieter authentifiziert wurden
Um die Berechtigungen zu ändern oder zu entfernen, die den temporären Sicherheitsanmeldeinformationen zugewiesen sind, die durch den Aufruf von `AssumeRole`, `AssumeRoleWithSAML` und `AssumeRoleWithWebIdentity`, `GetFederationToken`, oder `GetSessionToken` abgerufen wurden, können Sie die identitätsbasierte Richtlinie bearbeiten oder löschen, die die Berechtigungen für die Rolle definiert.
**Wichtig**
Wenn es eine ressourcenbasierte Richtlinie gibt, die dem Prinzipal Zugriff gewährt, müssen Sie auch eine explizite Ablehnung für diese Ressource hinzufügen. Details dazu finden Sie unter [Zugriff auf einen bestimmten Prinzipal mit ressourcenbasierten Richtlinien verweigern](#deny-access-with-resource-based).
**So verweigern Sie den Zugriff auf **alle** IAM-Rollensitzungen, die einer Rolle zugeordnet sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole.
1. Wählen Sie im Navigationsbereich die Option **Rollen** aus.
1. Wählen Sie den Namen der zu bearbeitenden Rolle aus. Sie können das Suchfeld verwenden, um die Liste zu filtern.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Wählen Sie die entsprechende Richtlinie zum Bearbeiten aus. Bevor Sie eine vom Kunden verwaltete Richtlinie bearbeiten, überprüfen Sie die Registerkarte **Angefügte Entitäten**, um eine Unterbrechung des Zugriffs auf andere Identitäten zu vermeiden, denen möglicherweise dieselbe Richtlinie zugeordnet ist.
1. Wählen Sie die Registerkarte **JSON** und aktualisieren Sie die Richtlinie, um alle Ressourcen und Aktionen zu verweigern.
**Anmerkung**
Diese Berechtigungen sind dieselben wie in der AWS verwalteten Richtlinie „[AWSDenyAlle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html)“. Sie können diese AWS verwaltete Richtlinie an jeden IAM-Benutzer oder jede IAM-Rolle anhängen, für die Sie jeglichen Zugriff verweigern möchten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. Überprüfen Sie auf der Seite **Review (Prüfen)** unter **Summary (Übersicht)** die Richtlinienzusammenfassung und wählen Sie dann **Save changes (Änderungen speichern)** aus, um Ihre Eingaben zu speichern.
Wenn Sie die Richtlinie aktualisieren, wirken sich die Änderungen auf die Berechtigungen aller temporären Anmeldeinformationen aus, die mit der Rolle verknüpft sind. Dies gilt auch für Anmeldeinformationen, die ausgestellt wurden, bevor Sie die Richtlinie für die Berechtigungen der Rolle geändert haben.
Nachdem Sie die Richtlinie aktualisiert haben, können Sie [die temporären Sicherheitsanmeldeinformationen der Rolle widerrufen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html), um sofort alle Berechtigungen für die ausgegebenen Anmeldeinformationen der Rolle zu entziehen.
## Zugriff auf eine bestimmte IAM-Rollensitzung verweigern
Wenn Sie IAM-Rollen mit einer „Alle verweigern“-Richtlinie aktualisieren oder die Rolle vollständig löschen, wird der Zugriff aller Benutzer auf die Rolle unterbrochen. Sie können den Zugriff verweigern, ohne die Berechtigungen aller anderen mit der Rolle verknüpften Sitzungen zu beeinträchtigen.
Dem `Principal` können mithilfe von [Bedingungskontextschlüsseln](#deny-access-to-specific-session-condition-key) oder [ressourcenbasierten Richtlinien](#deny-access-with-resource-based) Berechtigungen verweigert werden.
**Tipp**
Sie können die Anzahl der Verbundbenutzer anhand ARNs AWS CloudTrail von Protokollen ermitteln. Weitere Informationen finden Sie unter [So identifizieren Sie Ihre Verbundbenutzer auf einfache Weise mithilfe von](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/). AWS CloudTrail
## Zugriff auf Sitzungen mit temporären Sicherheits-Anmeldeinformationen mit Bedingungskontextschlüsseln verweigern
Sie können Bedingungskontextschlüssel in identitätsbasierten Richtlinien in Situationen verwenden, in denen Sie den Zugriff auf bestimmte Sitzungen mit temporären Sicherheitsanmeldeinformationen verweigern möchten, ohne die Berechtigungen des IAM-Benutzers oder der IAM-Rolle zu beeinträchtigen, die die Anmeldeinformationen erstellt hat. Für IAM-Rollen können Sie nach der Aktualisierung der Richtlinie auch die Sitzungen mit [temporären Sicherheitsanmeldeinformationen der Rolle widerrufen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html), um alle ausgestellten Anmeldeinformationen sofort zu entziehen.
Weitere Informationen zu Bedingungskontextschlüsseln finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md).
### als: PrincipalArn
Sie können den Bedingungskontextschlüssel [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) in einer identitätsbasierten Richtlinie verwenden, um einem bestimmten Prinzipal den Zugriff über seinen Amazon-Ressourcennamen (ARN) zu verweigern. Dazu geben Sie im Condition-Element einer Richtlinie den ARN des IAM-Benutzers, der Rolle oder der AWS STS Verbundbenutzersitzung an, mit der die temporären Sicherheitsanmeldedaten verknüpft sind.
**So verweigern Sie den Zugriff auf einen bestimmten Prinzipal anhand seines ARN**
1. Wählen Sie im Navigationsbereich der IAM-Konsole **Benutzer** oder **Rollen** aus.
1. Wählen Sie den Namen des zu bearbeitenden IAM-Benutzers oder der IAM-Rolle aus. Sie können das Suchfeld verwenden, um die Liste zu filtern.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Wählen Sie die entsprechende Richtlinie zum Bearbeiten aus. Bevor Sie eine vom Kunden verwaltete Richtlinie bearbeiten, überprüfen Sie die Registerkarte **Angefügte Entitäten**, um eine Unterbrechung des Zugriffs auf andere Identitäten zu vermeiden, denen möglicherweise dieselbe Richtlinie zugeordnet ist.
1. Wählen Sie die Registerkarte **JSON** und fügen Sie eine Verweigerungsanweisung für den Prinzipal-ARN hinzu, wie im folgenden Beispiel gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. Überprüfen Sie auf der Seite **Review (Prüfen)** unter **Summary (Übersicht)** die Richtlinienzusammenfassung und wählen Sie dann **Save changes (Änderungen speichern)** aus, um Ihre Eingaben zu speichern.
### aws: SourceIdentity
Sie können den Bedingungskontextschlüssel [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) in einer identitätsbasierten Richtlinie verwenden, um den Zugriff auf eine bestimmte Quellidentität zu verweigern, die einer IAM-Rollensitzung zugeordnet ist. Dies gilt, solange die Rollensitzung durch das Setzen des `SourceIdentity` Anforderungsparameters ausgelöst wurde, als der Principal mithilfe AWS STS `assume-role` beliebiger\$1 CLI-Befehle oder AWS STS `AssumeRole` \$1 API-Operationen eine Rolle annahm. Geben Sie hierzu die Quellidentität an, mit der die temporären Sicherheits-Anmeldeinformationen im `Condition`-Element einer Richtlinie verknüpft sind.
Im Gegensatz zum Kontextschlüssel [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname) kann der Wert nach Festlegung der Quellidentität nicht mehr geändert werden. Der Schlüssel `aws:SourceIdentity` ist im Anforderungskontext für alle von der Rolle ausgeführten Aktionen vorhanden. Die Quellidentität bleibt in nachfolgenden Rollensitzungen bestehen, wenn Sie die Sitzungs-Anmeldeinformationen verwenden, um eine andere Rolle zu übernehmen. Die Annahme einer Rolle von einer anderen wird als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet.
Die folgende Richtlinie zeigt ein Beispiel dafür, wie Sie den Zugriff auf temporäre Sicherheitsanmeldeinformationssitzungen mithilfe des Bedingungskontextschlüssels `aws:SourceIdentity` verweigern können. Wenn Sie die mit einer Rollensitzung verknüpfte Quellidentität angeben, werden Rollensitzungen mit der benannten Quellidentität verweigert, ohne dass die Berechtigungen der Rolle, die die Anmeldeinformationen erstellt hat, beeinträchtigt werden. In diesem Beispiel lautet die Quellidentität, die vom Prinzipal beim Ausgeben der Rollensitzung festgelegt wurde, `nikki_wolf@example.com`. Jede Anfrage einer Rollensitzung mit der Quellidentität `nikki_wolf@example.com` wird abgelehnt, da die Quellidentität in der Richtlinienbedingung enthalten ist und die Richtlinienwirkung auf `Deny` festgelegt ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
Sie können den Bedingungskontextschlüssel [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) in einer identitätsbasierten Richtlinie verwenden, um den Zugriff auf alle oder bestimmte temporäre Sicherheits-Anmeldeinformationssitzungen zu verweigern, die mit dem IAM-Benutzer oder der IAM-Rolle verknüpft sind. Dazu geben Sie im `Condition` Element einer Richtlinie die eindeutige Kennung (ID) des IAM-Benutzers, der Rolle oder der AWS STS Verbundbenutzersitzung an, mit der die temporären Sicherheitsanmeldedaten verknüpft sind.
Die folgende Richtlinie zeigt ein Beispiel dafür, wie Sie den Zugriff auf temporäre Sicherheitsanmeldeinformationssitzungen mithilfe des Bedingungskontextschlüssels `aws:userid` verweigern können.
+ `AIDAXUSER1` stellt die eindeutige Kennung für einen IAM-Benutzer dar. Wenn Sie die eindeutige ID eines IAM-Benutzers als Wert für den Kontextschlüssel `aws:userid` angeben, wird dem IAM-Benutzer der Zugriff verweigert. Dazu gehören alle temporären Sitzungen mit Sicherheits-Anmeldeinformationen, die durch den Aufruf der `GetSessionToken`-API erstellt wurden.
+ `AROAXROLE1:*` stellt die eindeutige ID für alle Sitzungen dar, die mit der IAM-Rolle verknüpft sind. Wenn Sie die eindeutige ID einer IAM-Rolle und ein Platzhalterzeichen (\$1) im Abschnitt caller-specified-role-session -name als Wert für den Kontextschlüssel angeben, `aws:userid` werden alle mit der Rolle verknüpften Sitzungen verweigert.
+ `AROAXROLE2:` stellt die eindeutige ID für eine Sitzung mit übernommener Rolle dar. Im caller-specified-role-session -name-Teil der eindeutigen ID für die angenommene Rolle können Sie einen Namen für die Rollensitzung oder ein Platzhalterzeichen angeben, wenn der Bedingungsoperator verwendet wird. StringLike Wenn Sie den Namen der Rollensitzung angeben, wird die benannte Rollensitzung verweigert, ohne dass dies Auswirkungen auf die Berechtigungen der Rolle hat, die die Anmeldeinformationen erstellt hat. Durch die Angabe eines Platzhalterzeichens für den Rollensitzungsnamen, werden alle mit der Rolle verknüpften Sitzungen abgelehnt.
**Anmerkung**
Der vom Aufrufer angegebene Rollensitzungsname, der Teil der eindeutigen Kennung für eine angenommene Rollensitzung ist, kann sich während der Rollenverkettung ändern. Eine Rollenverkettung findet statt, wenn eine Rolle eine andere Rolle übernimmt. Der Name der Rollensitzung wird mithilfe des `RoleSessionName` Anforderungsparameters festgelegt, wenn der Principal mithilfe der API-Operation eine Rolle annimmt. AWS STS `AssumeRole`
+ `account-id:`stellt die eindeutige ID für eine AWS STS Verbundbenutzersitzung dar. Ein IAM-Benutzer erstellt diese Sitzung, indem er die `GetFederationToken`-API aufruft. Durch die Angabe der eindeutigen ID für eine AWS STS -Verbundbenutzersitzung wird die benannte Verbundsitzung verweigert, ohne dass dies Auswirkungen auf die Berechtigungen des IAM-Benutzers hat, der die Anmeldeinformationen erstellt hat.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
Konkrete Beispiele für Hauptschlüsselwerte finden Sie unter [Auftraggeber-Schlüsselwerte](reference_policies_variables.md#principaltable). Informationen zu eindeutigen IAM-Identifikatoren und wie Sie diese abrufen, finden Sie unter [Eindeutige Bezeichner](reference_identifiers.md#identifiers-unique-ids).
## Zugriff auf einen bestimmten Prinzipal mit ressourcenbasierten Richtlinien verweigern
Um den Zugriff auf einen bestimmten Prinzipal mit einer ressourcenbasierten Richtlinie einzuschränken, können Sie im `Condition`-Element die Bedingungskontextschlüssel [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) oder [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) verwenden. Eine ressourcenbasierte Richtlinie ist eine Berechtigungsrichtlinie, die einer Ressource zugeordnet ist und steuert, wer auf die Ressource zugreifen und welche Aktionen damit ausgeführt werden können.
Wenn Sie den `aws:PrincipalARN` Kontextschlüssel verwenden, geben Sie den ARN des IAM-Benutzers, der Rolle oder der AWS STS Verbundbenutzersitzung an, die mit den temporären Sicherheitsanmeldedaten verknüpft ist, im Condition-Element einer Richtlinie. Die folgende Beispielrichtlinie veranschaulicht die Verwendung des `aws:PrincipalARN`-Kontextschlüssels in einer ressourcenbasierten Richtlinie:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
Wenn Sie den `aws:SourceIdentity`-Kontextschlüssel verwenden, geben Sie den Quellidentitätswert an, der den temporären Sicherheits-Anmeldeinformationen der Rolle im `Condition`-Element einer Richtlinie zugeordnet ist. Dies gilt, solange die Rollensitzung durch das Setzen des `SourceIdentity` Anforderungsparameters ausgelöst wurde, als der Principal mithilfe AWS STS `assume-role` beliebiger\$1 CLI-Befehle oder AWS STS `AssumeRole` \$1 API-Operationen eine Rolle annahm. Das folgende Beispiel zeigt, wie der `aws:SourceIdentity`-Kontextschlüssel in einer ressourcenbasierten Richtlinie verwendet wird:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
Wenn Sie nur die identitätsbasierte Richtlinie für einen Prinzipal aktualisieren, kann dieser weiterhin die in der ressourcenbasierten Richtlinie zulässigen Aktionen ausführen, es sei denn, diese Aktionen sind in der identitätsbasierten Richtlinie explizit verweigert.
**So verweigern Sie einem bestimmten Prinzipal den Zugriff in einer ressourcenbasierten Richtlinie**
1. Lesen Sie in [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) nach, ob der Service ressourcenbasierte Richtlinien unterstützt.
1. Melden Sie sich bei dem an AWS-Managementkonsole und öffnen Sie die Konsole für den Dienst. Jeder Service verfügt über einen anderen Standort in der Konsole zum Anfügen von Richtlinien.
1. Bearbeiten Sie die ressourcenbasierte Richtlinie. Fügen Sie eine Verweigerungs-Richtlinienanweisung hinzu, um die identifizierenden Informationen der Anmeldeinformationen anzugeben:
1. Geben Sie im `Principal`-Element ein Platzhalter (\$1) ein. Der Prinzipal wird im `Condition`-Element eingeschränkt.
1. Geben Sie im `Effect`-Element „Verweigern“ ein.
1. Geben Sie unter `Action` den Service-Namespace und den Namen der abzulehnenden Aktion ein. Um alle Aktionen zu verweigern, verwenden Sie das Platzhalterzeichen (\$1). Beispiel: `"s3:*"`.
1. Geben Sie im `Resource`-Element die ARN der Zielressource ein. Beispiel: `"arn:aws:s3:::amzn-s3-demo-bucket"`.
1. Geben Sie im `Condition`-Element entweder den Kontextschlüssel `aws:PrincipalARN` oder `aws:SourceIdentity` an.
Wenn Sie den `aws:PrincipalARN`-Kontextschlüssel verwenden, geben Sie die ARN des Prinzipals ein, dessen Zugriff Sie verweigern möchten.
Wenn Sie den `aws:SourceIdentity`-Kontextschlüssel verwenden, geben Sie den Quellidentitätswert ein, der in der Rollensitzung festgelegt wurde, für die der Zugriff verweigert werden soll.
1. Speichern Sie Ihre Arbeit.
# Erteilen von Berechtigungen zum Erstellen von temporären Sicherheitsanmeldeinformationen
Standardmäßig haben IAM-Benutzer keine Berechtigung zum Erstellen temporärer Sicherheitsanmeldeinformationen für AWS STS -Verbundbenutzersitzungen und Rollen. Sie müssen eine Richtlinie verwenden, um Ihren Benutzern diese Berechtigungen zu gewähren. Obwohl Sie einem Benutzer Berechtigungen direkt erteilten können, empfehlen wir dringend, die Berechtigungen einer Gruppe zu erteilen. Dadurch ist die Verwaltung der Berechtigungen wesentlich einfacher. Wenn ein Benutzer nicht mehr die berechtigten Aufgaben ausführen muss, entfernen Sie ihn einfach aus der Gruppe. Wenn diese Aufgabe von einem anderen Benutzer auszuführen ist, fügen Sie ihn der Gruppe hinzu, um die Berechtigungen zu erteilen.
Um einer IAM-Gruppe die Berechtigung zum Erstellen von temporären Sicherheitsanmeldeinformationen für AWS STS -Verbundbenutzersitzungen oder Rollen zu erteilen, fügen Sie eine Richtlinie an, die eine oder beide der folgenden Berechtigungen gewährt:
+ Damit verbundene OIDC- und SAML-Prinzipale auf eine IAM-Rolle zugreifen können, gewähren Sie Zugriff auf. AWS STS `AssumeRole`
+ Gewähren Sie AWS STS Verbundbenutzern, die keine Rolle benötigen, Zugriff auf. AWS STS `GetFederationToken`
Weitere Informationen zu den Unterschieden zwischen den API-Operationen `AssumeRole` und `GetFederationToken` finden Sie unter [Temporäre Sicherheitsanmeldeinformationen anfordern](id_credentials_temp_request.md).
IAM-Benutzer können auch [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) aufrufen, um temporäre Sicherheitsanmeldeinformationen zu erstellen. Für den Aufruf von `GetSessionToken` benötigt ein Benutzer keine Berechtigungen. Der Zweck dieser Operation besteht darin, den Benutzer mithilfe von MFA zu authentifizieren. Die Authentifizierung kann nicht über Richtlinien gesteuert werden. Dies bedeutet, dass Sie IAM-Benutzer nicht daran hindern können, zum Erstellen von temporären Anmeldeinformationen `GetSessionToken` aufzurufen.
**Example Beispiel für eine Richtlinie, die die Erlaubnis zur Übernahme einer Rolle erteilt**
Die folgende Beispielrichtlinie gewährt die Erlaubnis, die `UpdateApp` Rolle in AWS-Konto `123123123123` aufzurufen`AssumeRole`. Wenn `AssumeRole` verwendet wird, kann der Benutzer (oder die Anwendung), der die Sicherheitsanmeldeinformationen im Namen eines Verbundbenutzers erstellt, nur die explizit in der Berechtigungsrichtlinie der Rolle angegebenen Berechtigungen delegieren.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example Beispielrichtlinie, die die Erlaubnis zum Erstellen temporärer Sicherheitsnachweise für einen Verbundbenutzer erteilt**
Die folgende Beispielrichtlinie zeigt, wie Sie die Zugriffsberechtigung für `GetFederationToken` erteilen.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**Wichtig**
Wenn Sie IAM-Benutzern die Berechtigung zum Erstellen von temporären Sicherheitsanmeldeinformationen für AWS STS -Verbundbenutzer mit `GetFederationToken` erteilen, sollten Sie sich darüber im Klaren sein, dass hiermit diesen Benutzern die Delegierung ihrer eigenen Berechtigungen ermöglicht wird. Weitere Informationen zum Delegieren von Berechtigungen zwischen IAM-Benutzern und finden Sie AWS-Konten unter. [Beispiele für Richtlinien zum Delegieren des Zugriffs](id_roles_create_policy-examples.md) Weitere Informationen zum Steuern von Berechtigungen in temporären Sicherheitsanmeldeinformationen finden Sie unter [Berechtigungen für temporäre Sicherheits-Anmeldeinformationen](id_credentials_temp_control-access.md).
**Example Beispielrichtlinie, die einem Benutzer die eingeschränkte Berechtigung erteilt, temporäre Sicherheitsnachweise für Benutzer im Verbund zu erstellen**
Wenn Sie einem IAM-Benutzer ermöglichen, `GetFederationToken` aufzurufen, ist es eine bewährte Methode, die Berechtigungen einzuschränken, die der IAM-Benutzer delegieren kann. *Die folgende Richtlinie zeigt beispielsweise, wie ein IAM-Benutzer temporäre Sicherheitsanmeldeinformationen nur für AWS STS Verbundbenutzer erstellen kann, deren Namen mit Manager beginnen.*
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# Gewähren von Berechtigungen zur Verwendung von Konsolensitzungen mit verbesserter Identität
Konsolensitzungen mit verbesserter Identität ermöglichen es IDs , AWS IAM Identity Center Benutzer und Sitzung bei der Anmeldung in die AWS Konsolensitzungen der Benutzer aufzunehmen. Amazon Q Developer Pro verwendet beispielsweise Konsolensitzungen mit verbesserter Identität, um die Serviceerfahrung zu personalisieren. Weitere Informationen zu Konsolensitzungen mit verbesserter Identität finden Sie unter [Aktivieren von Konsolensitzungen mit verbesserter Identität](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) im *AWS IAM Identity Center -Benutzerhandbuch*. Informationen zum Einrichten von Amazon Q Developer finden Sie unter [Einrichtung von Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) im *Amazon-Q-Developer-Benutzerhandbuch*.
Damit einem Benutzer Konsolensitzungen mit verbesserter Identität zur Verfügung stehen, müssen Sie eine identitätsbasierte Richtlinie verwenden, um dem IAM-Prinzipal die `sts:SetContext`-Berechtigung für die Ressource zu gewähren, die seine eigene Konsolensitzung darstellt.
**Wichtig**
Standardmäßig verfügen Benutzer nicht über die Berechtigung, den Kontext für ihre Konsolensitzungen mit verbesserter Identität festzulegen. Um dies zu ermöglichen, müssen Sie dem IAM-Prinzipal die `sts:SetContext`-Berechtigung in einer identitätsbasierten Richtlinie gewähren, wie im folgenden Richtlinienbeispiel dargestellt.
Das folgende Beispiel für eine identitätsbasierte Richtlinie erteilt einem IAM-Prinzipal die `sts:SetContext` Berechtigung, sodass der Principal den Kontext für die Konsolensitzungen mit erweiterter Identität für seine eigenen Konsolensitzungen festlegen kann. AWS Die Richtlinienressource,, steht für die Sitzung des `arn:aws:sts::account-id:self` Aufrufers. AWS Das ARN-Segment `account-id` kann durch ein Platzhalterzeichen `*` ersetzt werden, wenn die gleiche Berechtigungsrichtlinie für mehrere Konten bereitgestellt wird, z. B. wenn diese Richtlinie mithilfe von Berechtigungssätzen für IAM Identity Center bereitgestellt wird.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------