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. # Temporäre IAM Sicherheitsanmeldeinformationen Mit AWS -Security-Token-Service (AWS STS) können Sie temporäre Sicherheitsanmeldedaten erstellen und vertrauenswürdigen Benutzern zur Verfügung stellen, mit denen der Zugriff auf Ihre AWS Ressourcen gesteuert werden kann. Temporäre Sicherheitsanmeldeinformationen funktionieren fast genauso wie die langfristigen Zugriffsschlüssel-Anmeldeinformationen, mit folgenden Unterschieden: + Temporäre Sicherheitsanmeldeinformationen sind über einen *kurzen Zeitraum* gültig, wie der Name schon sagt. Sie können mit einer Gültigkeitsdauer von wenigen Minuten bis mehrere Stunden konfiguriert werden. Wenn die Anmeldeinformationen abgelaufen sind, werden sie nicht AWS mehr erkannt und es ist auch kein Zugriff mehr über API-Anfragen möglich, die mit ihnen gestellt wurden. + Temporäre Sicherheitsanmeldeinformationen werden nicht mit dem Benutzer gespeichert, sondern auf Anforderung des Benutzers dynamisch generiert und bereitgestellt. Wenn (oder sogar bevor) die temporären Anmeldeinformationen ablaufen, kann der Benutzer neue Anmeldeinformationen anfordern, solange der anfordernde Benutzer weiterhin dazu berechtigt ist. Daher haben temporäre Anmeldeinformationen die folgenden Vorteile gegenüber langfristigen Anmeldeinformationen: + Sie müssen keine langfristigen AWS Sicherheitsnachweise verteilen oder in eine Anwendung einbetten. + Sie können Benutzern Zugriff auf Ihre AWS Ressourcen gewähren, ohne eine AWS Identität für sie definieren zu müssen. Temporäre Anmeldeinformationen sind die Grundlage für [Rollen](id_roles.md) und den [Identitätsverbund](id_roles_providers.md). + Die temporären Anmeldeinformationen haben eine begrenzte Nutzungsdauer. Somit müssen Sie sie aktualisieren oder explizit widerrufen, wenn Sie sie nicht mehr benötigen. Nachdem die temporären Anmeldeinformationen abgelaufen sind, können sie nicht erneut verwendet werden. Sie können die Gültigkeit der Anmeldeinformationen bis zu einem bestimmten Höchstwert festlegen. ## AWS STS und AWS Regionen Temporäre Sicherheitsanmeldeinformationen werden von AWS STS generiert. Standardmäßig AWS STS ist dies ein globaler Dienst mit einem einzigen Endpunkt bei`https://sts.amazonaws.com`. Sie können sich jedoch auch dafür entscheiden, AWS STS API-Aufrufe an Endpunkte in jeder anderen unterstützten Region zu tätigen. Dies kann die Latenz (Serververzögerung) verringern, indem die Anforderungen an Server in einer Region in Ihrer Nähe gesendet werden. Ihre Anmeldeinformationen sind unabhängig von der Region, in der sie generiert werden, weltweit gültig. Weitere Informationen finden Sie unter [Verwalte AWS STS in einem AWS-Region](id_credentials_temp_enable-regions.md). ## Gängige Szenarien für temporäre Anmeldeinformationen Temporäre Anmeldeinformationen sind in Szenarien mit Identitätsverbund, Delegierung, kontoübergreifenden Zugriff und IAM-Rollen nützlich. ### Identitätsverbund Sie können Ihre Benutzeridentitäten in einem externen System außerhalb von verwalten AWS und Benutzern, die sich von diesen Systemen aus anmelden, Zugriff gewähren, um AWS Aufgaben auszuführen und auf Ihre AWS Ressourcen zuzugreifen. IAM unterstützt zwei Arten von Identitätsverbund. In beiden Fällen werden die Identitäten außerhalb von gespeichert. AWS Der Unterschied liegt darin, wo Ihr externes System angesiedelt ist &endash in Ihrem Rechenzentrum oder bei einem Anbieter im Internet. Einen Vergleich der Features temporärer Sicherheitsanmeldedaten für den Identitätsverbund finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md). Weitere Informationen zu externen Identitätsanbietern erhalten Sie unter [Identitätsanbieter und Verbund zu AWS](id_roles_providers.md). + **OpenID Connect (OIDC)-Identitätsverbund** – Sie können Benutzern die Anmeldung über einen bekannten Identitätsanbieter eines Drittanbieters wie Login mit Amazon, Facebook, Google oder einem beliebigen OIDC 2.0-kompatiblen Anbieter für Ihre Mobil- oder Web-Anwendung ermöglichen. Sie müssen keinen benutzerdefinierten Anmelde-Code erstellen oder Ihre eigenen Benutzeridentitäten verwalten. Die Verwendung des OIDC-Verbunds hilft Ihnen dabei, Ihre AWS-Konto Sicherheit zu gewährleisten, da Sie keine langfristigen Sicherheitsanmeldedaten wie IAM-Benutzerzugriffsschlüssel mit Ihrer Anwendung verteilen müssen. Weitere Informationen finden Sie unter [OIDC-Verbund](id_roles_providers_oidc.md). AWS STS Der OIDC-Verbund unterstützt die Login with Amazon, Facebook, Google und jedem OpenID Connect (OIDC) -kompatiblen Identitätsanbieter. **Anmerkung** Für mobile Anwendungen empfehlen wir die Verwendung von Amazon Cognito. Sie können diesen Service für die mobile Entwicklung verwenden, um eindeutige Identitäten AWS SDKs für Benutzer zu erstellen und sie für den sicheren Zugriff auf Ihre Ressourcen zu authentifizieren. AWS Amazon Cognito unterstützt dieselben Identitätsanbieter wie AWS STS und unterstützt auch nicht authentifizierten (Gast-) Zugriff. Außerdem können Sie Benutzerdaten migrieren, wenn sich ein Benutzer anmeldet. Amazon Cognito stellt auch API-Operationen für die Synchronisierung von Benutzerdaten bereit, sodass diese erhalten bleiben, wenn die Benutzer zwischen Geräten wechseln. Weitere Informationen finden Sie unter [Authentifizierung mit Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) in der *Amplify-Dokumentation*. + **SAML-Verbund** — Sie können Benutzer im Netzwerk Ihrer Organisation authentifizieren und diesen Benutzern dann Zugriff gewähren, AWS ohne neue AWS Identitäten für sie zu erstellen und von ihnen zu verlangen, dass sie sich mit anderen Anmeldeinformationen anmelden müssen. Dies wird als *Single-Sign-On-Ansatz* für temporären Zugriff bezeichnet. AWS STS unterstützt offene Standards wie Security Assertion Markup Language (SAML) 2.0, mit der Sie Microsoft AD FS verwenden können, um Ihr Microsoft Active Directory zu nutzen. Sie können mit SAML 2.0 auch Ihre eigene Lösung zum Verbinden von Benutzeridentitäten verwalten. Weitere Informationen finden Sie unter [SAML 2.0-Föderation](id_roles_providers_saml.md). + **Benutzerdefinierter Federation Broker** — Sie können das Authentifizierungssystem Ihrer Organisation verwenden, um Zugriff auf Ressourcen zu gewähren. AWS Ein Beispielszenario finden Sie unter [Benutzerdefinierten Identity Broker-Zugriff auf die AWS Konsole aktivieren](id_roles_providers_enable-console-custom-url.md). + **Verbund mit SAML 2.0** – Verwenden Sie das Authentifizierungssystem Ihrer Organisation und SAML, um Zugriff auf AWS -Ressourcen zu gewähren. Weitere Informationen sowie ein Beispielszenario finden Sie unter [SAML 2.0-Föderation](id_roles_providers_saml.md). ### Rollen für den kontoübergreifenden Zugriff Viele Organisationen verfügen über mehrere AWS-Konto. Mithilfe von Rollen und dem kontoübergreifenden Zugriff können Sie Benutzeridentitäten in einem Konto definieren und diese Identitäten für den Zugriff auf AWS -Ressourcen in anderen Konten Ihrer Organisation verwenden. Dies wird als *Delegierung* für den temporären Zugriff bezeichnet. Weitere Informationen zum Erstellen kontenübergreifender Rollen finden Sie unter [Erstellen einer Rolle zum Erteilen von Berechtigungen an einen IAM-Benutzer](id_roles_create_for-user.md). Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Was ist IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). ### IAM-Rollen für Amazon EC2 Wenn Sie Anwendungen auf Amazon EC2-Instances ausführen und diese Anwendungen auf AWS -Ressourcen zugreifen müssen, können Sie temporäre Sicherheitsanmeldeinformationen für Ihre Instances bereitstellen, wenn Sie sie starten. Diese temporären Sicherheitsanmeldeinformationen sind für alle Anwendungen verfügbar, die in der Instance ausgeführt werden. Sie müssen daher keine langfristigen Anmeldeinformationen in der Instance speichern. Weitere Informationen finden Sie unter [Verwendung einer IAM-Rolle zur Gewährung von Berechtigungen für Anwendungen, die in Amazon-EC2-Instances ausgeführt werden](id_roles_use_switch-role-ec2.md). Weitere Informationen zu den IAM-Amazon-EC2-Rollen-Anmeldeinformationen finden Sie unter [IAM-Rollen für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) im *Benutzerhandbuch zur Amazon Elastic Compute Cloud*. ### Andere AWS Dienste Für den Zugriff auf die meisten AWS Dienste können Sie temporäre Sicherheitsanmeldedaten verwenden. Eine Liste der Services, die temporäre Sicherheitsanmeldeinformationen zulassen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md). ## Beispielanwendungen, für die temporäre Anmeldeinformationen verwendet werden Sie können AWS -Security-Token-Service (AWS STS) verwenden, um temporäre Sicherheitsanmeldeinformationen für vertrauenswürdige Benutzer zu erstellen und ihnen 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). Um zu erfahren, wie Sie temporäre Sicherheitsanmeldeinformationen verwalten können, können Sie die folgenden Beispielanwendungen herunterladen, die vollständige Beispielszenarien implementieren: AWS STS + [Aktivierung des Verbunds für die AWS Verwendung von Windows Active Directory, ADFS und SAML 2.0](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/). Demonstriert, wie der Zugriff mithilfe von Enterprise Federation auf die AWS Verwendung von Windows Active Directory (AD), Active Directory Federation Services (ADFS) 2.0 und SAML (Security Assertion Markup Language) 2.0 delegiert wird. + [Benutzerdefinierten Identity Broker-Zugriff auf die AWS Konsole aktivieren](id_roles_providers_enable-console-custom-url.md): Zeigt, wie Sie einen benutzerdefinierten Verbund-Proxy erstellen, um Single Sign-On (SSO) zu aktivieren und es vorhandenen Active Directory-Benutzern zu ermöglichen, sich bei der AWS-Managementkonsole anzumelden. + [So verwenden Sie Shibboleth für Single Sign-On auf dem. AWS-Managementkonsole](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/) . Zeigt, wie Sie mithilfe von [Shibboleth](http://shibboleth.net/) und [SAML](id_roles_providers_saml.md) Benutzern SSO-Zugriff (Single Sign-On) auf die AWS-Managementkonsole gewähren. ### Beispiele für den OIDC-Verbund Die folgenden Beispielanwendungen veranschaulichen die Verwendung OIDCfederation mit Anbietern wie Login with Amazon, Amazon Cognito, Facebook oder Google. Sie können die Authentifizierung dieser Anbieter gegen temporäre AWS Sicherheitsanmeldedaten für den Zugriff auf AWS Dienste eintauschen. + [Amazon Cognito-Tutorials](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) — Wir empfehlen Ihnen, Amazon Cognito mit dem AWS SDKs für die mobile Entwicklung zu verwenden. Amazon Cognito ist die einfachste Methode zur Identitätsverwaltung für mobile Apps. Außerdem werden hier zusätzliche Funktionen wie die Synchronisierung und geräteübergreifende Identitäten unterstützt. Weitere Informationen zu Amazon Cognito finden Sie unter [Authentifizierung mit Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) in der *Amplify-Dokumentation*. ## Zusätzliche Ressourcen für temporäre Sicherheitsanmeldeinformationen Folgende Szenarien und Anwendungen führen Sie durch die Verwendungsmöglichkeiten von temporären Sicherheitsanmeldeinformationen: + [So integrieren Sie sich AWS STS SourceIdentity mit Ihrem Identitätsanbieter](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). In diesem Beitrag erfahren Sie, wie Sie das AWS STS `SourceIdentity` Attribut einrichten, wenn Sie Okta, Ping oder OneLogin als Ihren IdP verwenden. + [OIDC-Verbund](id_roles_providers_oidc.md). In diesem Abschnitt wird erläutert, wie Sie IAM-Rollen konfigurieren, wenn Sie den OIDC-Verbund und die `AssumeRoleWithWebIdentity`-API verwenden. + [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md). In diesem Thema wird erläutert, wie Sie mithilfe von Rollen die Multi-Factor Authentication (MFA) verlangen können, um die sensiblen API-Aktionen in Ihrem Konto zu schützen. Weitere Informationen zu Richtlinien und Berechtigungen AWS finden Sie in den folgenden Themen: + [Zugriffsmanagement für AWS Ressourcen](access.md) + [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md). + [Verwalten von Zugriffsberechtigungen für Ihre Amazon-S3-Ressourcen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) im *Benutzerhandbuch für Amazon Simple Storage Service*. + Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Was ist IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). # AWS STS Referenzen vergleichen In der folgenden Tabelle werden die Funktionen der API-Operationen verglichen AWS STS , bei denen temporäre Sicherheitsanmeldedaten zurückgegeben werden. Weitere Informationen zu den verschiedenen Methoden, die Sie verwenden können, um temporäre Anmeldeinformationen anzufordern, indem Sie eine Rolle übernehmen, finden Sie unter [Methoden, um eine Rolle zu übernehmen](id_roles_manage-assume.md). Weitere Informationen zu den verschiedenen AWS STS API-Vorgängen, mit denen Sie Sitzungs-Tags übergeben können, finden Sie unter[Sitzungs-Tags übergeben AWS STS](id_session-tags.md). **Anmerkung** Sie können AWS STS API-Aufrufe entweder an einen globalen Endpunkt oder an einen der regionalen Endpunkte senden. Wenn Sie einen Endpunkt näher bei Ihnen wählen, können Sie die Latenz verringern und verbessern Sie die Leistung Ihrer API-Aufrufe verbessern. Sie können Ihre Aufrufe auch an einen alternativen regionalen Endpunkt richten, wenn Sie nicht mehr mit dem ursprünglichen Endpunkt kommunizieren können. Wenn Sie eine der verschiedenen Methoden verwenden AWS SDKs, verwenden Sie diese SDK-Methode, um eine Region anzugeben, bevor Sie den API-Aufruf ausführen. Wenn Sie HTTP-API-Anforderungen manuell konstruieren, müssen Sie die Anforderung selbst an den korrekten Endpunkt richten. Weitere Informationen finden Sie im [AWS STS -Abschnitt von *Regionen und Endpunkte*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) und [Verwalte AWS STS in einem AWS-Region](id_credentials_temp_enable-regions.md). | **AWS STS API** | **Wer kann aufrufen?** | **Lebensdauer der Anmeldeinformationen (min \$1 max \$1 Standard)** | **MFA-Unterstützung**¹ | **Sitzungsrichtlinienunterstützung**² | **Einschränkungen bei den sich ergebenden temporären Anmeldeinformationen** | | --- | --- | --- | --- | --- | --- | | [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | IAM-Benutzer oder IAM-Rolle mit vorhandenen temporären Sicherheitsanmeldeinformationen | 15 Min. \$1 Maximale Sitzungsdauer³ \$1 1 Std. | Ja | Ja | Kein Aufruf von `GetFederationToken` oder `GetSessionToken`. | | [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Jeder user;-Anrufer muss eine SAML-Authentifizierungsantwort übergeben, die die Authentifizierung von einem bekannten Identitätsanbieter angibt | 15 Min. \$1 Maximale Sitzungsdauer³ \$1 1 Std. | Nein | Ja | Kein Aufruf von `GetFederationToken` oder `GetSessionToken`. | | [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Jeder Benutzer; der Anrufer muss ein OIDC-kompatibles JWT-Token übergeben, das die Authentifizierung von einem bekannten Identitätsanbieter anzeigt | 15 Min. \$1 Maximale Sitzungsdauer³ \$1 1 Std. | Nein | Ja | Kein Aufruf von `GetFederationToken` oder `GetSessionToken`. | | [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | IAM-Benutzer oder Root-Benutzer des AWS-Kontos | IAM-Benutzer: 15 m \$1 36 h \$1 12 h Stammbenutzer: 15 Min. \$1 1 Stunde \$1 1 Stunde | Nein | Ja | IAM-Operationen können nicht mit der AWS CLI oder AWS API aufgerufen werden. Diese Beschränkung gilt nicht für Konsolensitzungen. Es können keine AWS STS Operationen außer `GetCallerIdentity` .³ aufgerufen werden SSO an Konsole ist erlaubt.⁵ | | [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | IAM-Benutzer oder Root-Benutzer des AWS-Kontos | IAM-Benutzer: 15 m \$1 36 h \$1 12 h Stammbenutzer: 15 Min. \$1 1 Stunde \$1 1 Stunde | Ja | Nein | IAM-API-Operationen können nur aufgerufen werden, wenn MFA-Informationen in der Anforderung enthalten sind. AWS STS API-Operationen außer `AssumeRole` oder `GetCallerIdentity` können nicht aufgerufen werden. SSO an Konsole ist nicht erlaubt.⁶ | ¹ **MFA-Unterstützung**. Sie können Informationen über ein Gerät mit Multi-Faktor-Authentifizierung (MFA) angeben, wenn Sie die AssumeRole und GetSessionToken API-Operationen aufrufen. Auf diese Weise wird sichergestellt, dass die temporären Sicherheitsanmeldeinformationen, die sich aus dem API-Aufruf ergeben, nur von Benutzern verwendet werden, die mit einem MFA-Gerät authentifiziert werden. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md). ² **Sitzungsrichtlinienunterstützung**. Sitzungsrichtlinien sind Richtlinien, die Sie als Parameter übergeben, wenn Sie programmgesteuert eine temporäre Sitzung für eine Rolle oder AWS STS eine Verbundbenutzersitzung erstellen. Diese Richtlinie beschränkt die Berechtigungen der identitätsbasierten Richtlinie der Rolle oder des Benutzers, die bzw. der der Sitzung zugeordnet ist. Die resultierenden Sitzungsberechtigungen bilden die Schnittmenge der auf der Identität der Entity 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). ³ **Einstellung der maximalen Sitzungsdauer**. Verwenden Sie den `DurationSeconds`-Parameter, um die Dauer Ihrer Rollensitzung von 900 Sekunden (15 Minuten) bis zur maximalen Sitzungsdauer für die Rolle anzugeben. Weitere Informationen dazu, wie Sie den maximalen Wert für Ihre Rolle anzeigen, finden Sie unter [Aktualisieren der maximalen Sitzungsdauer für eine Rolle](id_roles_update-role-settings.md#id_roles_update-session-duration). ⁴. **GetCallerIdentity** Für diese Operation sind keine Berechtigungen erforderlich. Wenn ein Administrator Ihrem IAM-Benutzer oder Ihrer IAM-Rolle eine Richtlinie hinzufügt, die den Zugriff auf die `sts:GetCallerIdentity`-Aktion explizit verweigert, können Sie diese Operation trotzdem ausführen. Berechtigungen sind nicht erforderlich, da dieselben Informationen zurückgegeben werden, wenn einem IAM-Benutzer oder einer -Rolle der Zugriff verweigert wird. Eine Beispielantwort finden Sie unter [Ich bin nicht berechtigt, Folgendes aufzuführen: iam: DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). ⁵ **Single Sign-On (SSO) an der Konsole**. Um SSO zu unterstützen, AWS können Sie einen Verbundendpunkt (`https://signin.aws.amazon.com/federation`) aufrufen und temporäre Sicherheitsanmeldedaten übergeben. Der Endpunkt gibt ein Token zurück, das Sie verwenden können, um eine URL zu erstellen, die einen Benutzer direkt an der Konsole anmeldet, ohne dass ein Passwort erforderlich ist. Weitere Informationen finden Sie unter [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md) und [So aktivieren Sie den kontoübergreifenden Zugriff auf die AWS Managementkonsole](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) im AWS Sicherheitsblog. ⁶ Nach dem Abrufen der temporären Anmeldedaten können Sie nicht auf die AWS-Managementkonsole zugreifen, indem Sie die Anmeldedaten an den Single-Sign-On-Verbund-Endpunkt übergeben. Weitere Informationen finden Sie unter [Benutzerdefinierten Identity Broker-Zugriff auf die AWS Konsole aktivieren](id_roles_providers_enable-console-custom-url.md). # Service-Inhaber-Token Für einige AWS Dienste benötigen Sie die Erlaubnis, ein AWS STS Service-Bearer-Token abzurufen, bevor Sie programmgesteuert auf ihre Ressourcen zugreifen können. Diese Services unterstützen ein Protokoll, das die Verwendung eines Inhaber-Tokens anstelle eines herkömmlichen [AWS Signaturversion 4 für API-Anfragen](reference_sigv.md) erfordert. Wenn Sie AWS API-Operationen ausführen AWS CLI , für die Inhaber-Token erforderlich sind, fordert der AWS Service in Ihrem Namen ein Inhaber-Token an. Der Service stellt Ihnen das Token zur Verfügung, mit dem Sie anschließend nachfolgende Vorgänge in diesem Service ausführen können. AWS STS Service-Bearer-Token enthalten Informationen aus Ihrer ursprünglichen Prinzipalauthentifizierung, die sich auf Ihre Berechtigungen auswirken könnten. Diese Informationen können Auftraggeber-Tags, Sitzungs-Tags und Sitzungsrichtlinien enthalten. Die Zugriffsschlüssel-ID des Tokens beginnt mit dem Präfix `ABIA`. Auf diese Weise können Sie Vorgänge identifizieren, die mithilfe von Service-Bearertoken in Ihren CloudTrail-Protokollen ausgeführt wurden. **Wichtig** Das Bearertoken kann nur für Aufrufe an den Service verwendet werden, der es generiert hat, und in der Region, in der es generiert wurde. Sie können das Bearertoken nicht verwenden, um Operationen in anderen Services oder Regionen auszuführen. Ein Beispiel für einen Dienst, der Inhabertoken unterstützt, ist. AWS CodeArtifact Bevor Sie AWS CodeArtifact mit einem Paketmanager wie NPM, Maven oder PIP interagieren können, müssen Sie den Vorgang aufrufen. `aws codeartifact get-authorization-token` Dieser Vorgang gibt ein Bearer-Token zurück, mit dem Sie Operationen ausführen können. AWS CodeArtifact Alternativ können Sie den Befehl `aws codeartifact login` verwenden, der denselben Vorgang ausführt und den Client dann automatisch konfiguriert. Wenn Sie eine Aktion in einem AWS Dienst ausführen, der ein Bearer-Token für Sie generiert, müssen Sie in Ihrer IAM-Richtlinie über die folgenden Berechtigungen verfügen: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowServiceBearerToken", "Effect": "Allow", "Action": "sts:GetServiceBearerToken", "Resource": "*" } ] } ``` ------ Ein Beispiel für Service Bearer-Token finden Sie unter [ Verwenden von identitätsbasierten Richtlinien für AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) im *AWS CodeArtifact*-Benutzerhandbuch. # Temporäre Sicherheitsanmeldeinformationen anfordern Um temporäre Sicherheitsanmeldedaten anzufordern, können Sie AWS -Security-Token-Service (AWS STS) -Operationen in der AWS API verwenden. Dazu gehören Operationen zur Erstellung und Bereitstellung temporärer Sicherheitsanmeldedaten für vertrauenswürdige Benutzer, 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). Weitere Informationen zu den verschiedenen Methoden, die Sie verwenden können, um temporäre Anmeldeinformationen anzufordern, indem Sie eine Rolle übernehmen, finden Sie unter [Methoden, um eine Rolle zu übernehmen](id_roles_manage-assume.md). Um die API-Operationen aufzurufen, können Sie einen der folgenden verwenden [AWS SDKs](https://aws.amazon.com/tools/). Sie SDKs sind für eine Vielzahl von Programmiersprachen und Umgebungen verfügbar, darunter Java, .NET, Python, Ruby, Android und iOS. SDKs Sie kümmern sich um Aufgaben wie das kryptografische Signieren Ihrer Anfragen, das Wiederholen von Anfragen, falls erforderlich, und die Behandlung von Fehlerantworten. [Sie können auch die AWS STS Query API verwenden, die in der AWS -Security-Token-Service API-Referenz beschrieben wird.](https://docs.aws.amazon.com/STS/latest/APIReference/) Schließlich unterstützen zwei Befehlszeilentools die AWS STS Befehle: the [AWS Command Line Interface](https://aws.amazon.com/documentation/cli), und the [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell). Die AWS STS API-Operationen erstellen eine neue Sitzung mit temporären Sicherheitsanmeldeinformationen, die ein Zugriffsschlüsselpaar und ein Sitzungstoken enthalten. Das Zugriffschlüsselpaar besteht aus einer Zugriffsschlüssel-ID und einem geheimen Schlüssel. Benutzer (oder eine Anwendung, die vom Benutzer ausgeführt wird) können diese Anmeldeinformationen verwenden, um auf Ihre Ressourcen zuzugreifen. Sie können eine Rollensitzung erstellen und Sitzungsrichtlinien und Sitzungs-Tags mithilfe von AWS STS API-Vorgängen programmgesteuert übergeben. Die resultierenden Sitzungsberechtigungen sind eine Schnittmenge der Identität des Benutzers oder der auf die Rolle basierenden Richtlinien und der Sitzungssrichtlinien. Weitere Informationen zu Sitzungsrichtlinien finden Sie unter [Sitzungsrichtlinien](access_policies.md#policies_session). Weitere Hinweise zu Sitzungs-Tags finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). **Anmerkung** Die Größe des Sitzungstokens, das AWS STS API-Operationen zurückgeben, ist nicht festgelegt. Es wird ausdrücklich empfohlen, dass Sie keine Annahmen über die maximale Größe machen. Die typische Tokengröße ist kleiner als 4096 Bytes, diese kann jedoch variieren. ## Verwendung AWS STS mit AWS Regionen Sie können AWS STS API-Aufrufe entweder an einen globalen Endpunkt oder an einen der regionalen Endpunkte senden. Wenn Sie einen Endpunkt näher bei Ihnen wählen, können Sie die Latenz verringern und verbessern Sie die Leistung Ihrer API-Aufrufe verbessern. Sie können Ihre Aufrufe auch an einen alternativen regionalen Endpunkt richten, wenn Sie nicht mehr mit dem ursprünglichen Endpunkt kommunizieren können. Wenn Sie eine der verschiedenen Methoden verwenden AWS SDKs, verwenden Sie diese SDK-Methode, um eine Region anzugeben, bevor Sie den API-Aufruf ausführen. Wenn Sie HTTP-API-Anforderungen manuell konstruieren, müssen Sie die Anforderung selbst an den korrekten Endpunkt richten. Weitere Informationen finden Sie im [AWS STS -Abschnitt von *Regionen und Endpunkte*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) und [Verwalte AWS STS in einem AWS-Region](id_credentials_temp_enable-regions.md). Im Folgenden sind die API-Operationen aufgeführt, mit denen Sie temporäre Anmeldeinformationen für die Verwendung in Ihrer AWS Umgebung und Ihren Anwendungen abrufen können. ## Anfordern von Anmeldeinformationen für die kontounabhängige Delegierung und den Verbund über einen benutzerdefinierten Identity Broker Der [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html)API-Vorgang ist nützlich, um bestehenden IAM-Benutzern den Zugriff auf AWS Ressourcen zu ermöglichen, auf die sie noch keinen Zugriff haben. Beispielsweise benötigt der Benutzer möglicherweise Zugriff auf Ressourcen in einem anderen AWS-Konto. Es ist auch nützlich, um vorübergehend privilegierten Zugang zu erhalten – zum Beispiel, um eine Multi-Faktor-Authentifizierung (MFA) zu ermöglichen. Sie müssen diese API mit den vorhandenen Benutzeranmeldeinformationen aufrufen. Um zu erfahren, wer diesen Vorgang aufrufen kann, siehe [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md). Weitere Informationen erhalten Sie unter [Erstellen einer Rolle zum Erteilen von Berechtigungen an einen IAM-Benutzer](id_roles_create_for-user.md) und [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md). **So fordern Sie temporäre Anmeldeinformationen für die kontounabhängige Delegierung und den Verbund über einen benutzerdefinierten Identity Broker an** 1. Authentifizieren Sie sich mit Ihren AWS Sicherheitsanmeldedaten. Dieser Aufruf muss unter Verwendung von gültigen AWS -Sicherheitsanmeldeinformationen gemacht werden. 1. Rufen Sie den Vorgang [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) auf. Im folgenden Beispiel wird eine Beispielanforderung und -antwort mit `AssumeRole` gezeigt. In dieser Beispielanforderung wird die `demo`-Rolle für die angegebene Dauer mit der enthaltenen [Sitzungsrichtlinie](access_policies.md#policies_session), den [Sitzungs-Tags](id_session-tags.md) und der [externen ID](id_roles_common-scenarios_third-party.md) und [Quellidentität](id_credentials_temp_control-access_monitor.md) übernommen. Die resultierende Sitzung wird als `John-session` bezeichnet. **Example Beispielanforderung** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=AssumeRole &RoleSessionName=John-session &RoleArn=arn:aws::iam::123456789012:role/demo &Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &ExternalId=123ABC &SourceIdentity=DevUser123 &AUTHPARAMS ``` Der im vorherigen Beispiel gezeigte Richtlinienwert ist die URL-codierte Version der folgenden Richtlinie: ------ #### [ JSON ] **** ``` {"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]} ``` ------ Der `AUTHPARAMS`-Parameter in diesem Beispiel ist ein Platzhalter für Ihre *Signatur*. Eine Signatur ist die Authentifizierungsinformation, die Sie AWS HTTP-API-Anfragen beifügen müssen. Wir empfehlen die Verwendung von, [AWS SDKs](https://aws.amazon.com/tools/)um API-Anfragen zu erstellen. Ein Vorteil dabei ist, dass sie die SDKs Anforderungssignierung für Sie übernimmt. Wenn Sie API-Anfragen manuell erstellen und signieren müssen, erfahren Sie unter [Signieren von AWS Anfragen mithilfe von Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) in der *Allgemeine Amazon Web Services-Referenz*, wie Sie eine Anfrage signieren. Zusätzlich zu den temporären Sicherheitsanmeldeinformationen, enthält die Antwort den Amazon-Ressourcennamen (ARN) für den Verbundbenutzer und die Ablaufzeit der Anmeldeinformationen. **Example Beispielantwort** ``` DevUser123 AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-07-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE arn:aws:sts::123456789012:assumed-role/demo/John ARO123EXAMPLE123:John 8 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **Anmerkung** Bei einer AWS Konvertierung werden die übergebenen Sitzungsrichtlinien und Sitzungs-Tags in ein gepacktes Binärformat komprimiert, für das ein separates Limit gilt. Ihre Anforderung kann für diese Begrenzung fehlschlagen, selbst wenn Ihr Nur-Text-Inhalt die übrigen Anforderungen erfüllt. Das `PackedPolicySize`-Antwortelement gibt in Prozent an, wie nah die Richtlinien und Tags für Ihre Anforderung an der oberen Größengrenze liegen. ## Anmeldeinformationen über einen OIDC-Anbieter anfordern Die [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)-API-Operation gibt einen Satz temporärer AWS -Sicherheits-Anmeldeinformationen im Austausch gegen ein JSON Web Token (JWT) zurück. Dazu gehören öffentliche Identitätsanbieter wie Login with Amazon, Facebook, Google und Anbieter, deren Probleme JWTs mit OpenID Connect (OIDC) Discovery kompatibel sind, wie GitHub Actions oder Azure DevOps. Weitere Informationen finden Sie unter [OIDC-Verbund](id_roles_providers_oidc.md). **Anmerkung** `AssumeRoleWithWebIdentity`-Anfragen sind nicht signiert und erfordern keine AWS -Anmeldeinformationen. **Anmeldeinformationen über einen OIDC-Anbieter anfordern** 1. Rufen Sie den Vorgang [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) auf. Wenn Sie anrufen`AssumeRoleWithWebIdentity`, AWS validiert das vorgelegte Token, indem es die digitale Signatur anhand von öffentlichen Schlüsseln überprüft, die über das JSON-Web-Keyset (JWKS) Ihres IdP zur Verfügung gestellt werden. Wenn das Token gültig ist und alle in der IAM-Rollenvertrauensrichtlinie festgelegten Bedingungen erfüllt sind, AWS werden Ihnen die folgenden Informationen zurückgegeben: + Einen Satz temporärer Sicherheitsanmeldeinformationen. Diese bestehen aus einer Zugriffsschlüssel-ID, einem geheimen Zugriffsschlüssel und einem Sitzungs-Token. + Die Rollen-ID und den ARN der übernommenen Rolle. + Ein `SubjectFromWebIdentityToken`-Wert mit der eindeutigen Benutzer-ID. 1. Ihre Anwendung kann dann die temporären Sicherheitsanmeldedaten, die in der Antwort zurückgegeben wurden, für AWS API-Aufrufe verwenden. Dies ist derselbe Vorgang wie bei einem AWS API-Aufruf mit langfristigen Sicherheitsanmeldedaten. Der Unterschied besteht darin, dass Sie das Sitzungstoken angeben müssen, mit dem AWS überprüft werden kann, ob die temporären Sicherheitsanmeldedaten gültig sind. Ihre Anwendung sollte die von zurückgegebenen Anmeldeinformationen zwischenspeichern AWS STS und bei Bedarf aktualisieren. Wenn Ihre Anwendung mit einem SDK erstellt wurde, verfügt das AWS SDK über Anmeldeinformationsanbieter, die das Aufrufen `AssumeRoleWithWebIdentity` und Aktualisieren von AWS Anmeldeinformationen übernehmen können, bevor sie ablaufen. Weitere Informationen finden Sie unter [AWS SDKs Tools standardisierte Credential Providers](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) im *AWS SDKs Tools-Referenzhandbuch*. ## Anfordern von Anmeldeinformationen über einen SAML 2.0-Identitätsanbieter Der [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)-API-Vorgang gibt einen Satz an temporären Sicherheitsanmeldeinformationen für SAML-Verbundprinzipale zurück, die über das bestehende Identitätssystem Ihrer Organisation authentifiziert werden. Die Benutzer müssen auch [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0 (Security Assertion Markup Language) verwenden, um Authentifizierungs- und Autorisierungsinformationen an AWS zu übergeben. Diese API-Operation ist hilfreich für Organisationen, die ihre Identitätssysteme (z. B. Windows Active Directory oder OpenLDAP) in Software integriert haben, die SAML-Assertionen produzieren können. Eine solche Integration bietet Informationen über Benutzeridentität und Berechtigungen (wie Active Directory Federation Services oder Shibboleth). Weitere Informationen finden Sie unter [SAML 2.0-Föderation](id_roles_providers_saml.md). 1. Rufen Sie den Vorgang [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) auf. Dies ist ein unsignierter Anruf, was bedeutet, dass Sie keine AWS Sicherheitsanmeldedaten authentifizieren müssen, bevor Sie die Anfrage stellen. **Anmerkung** Ein Aufruf an `AssumeRoleWithSAML` ist nicht signiert (verschlüsselt). Daher sollten Sie diese optionale Sitzungsrichtlinie nur einschließen, wenn die Anforderung über einen vertrauenswürdigen Vermittler übertragen wird. In diesem Fall könnte jemand die Richtlinie ändern, um die Beschränkungen zu entfernen. 1. Wenn Sie anrufen`AssumeRoleWithSAML`, AWS wird die Echtheit der SAML-Assertion überprüft. Unter der Annahme, dass der Identitätsanbieter die Assertion validiert, werden Ihnen die folgenden AWS Informationen zurückgegeben: + Einen Satz temporärer Sicherheitsanmeldeinformationen. Diese bestehen aus einer Zugriffsschlüssel-ID, einem geheimen Zugriffsschlüssel und einem Sitzungs-Token. + Die Rollen-ID und den ARN der übernommenen Rolle. + Einen `Audience`-Wert, der den Wert des `Recipient`-Attributs des `SubjectConfirmationData`-Elements der SAML-Zusicherung enthält. + Einen `Issuer`-Wert, der den Wert des `Issuer`-Elements der SAML-Zusicherung enthält. + Ein `NameQualifier` Element, das einen Hashwert enthält, der aus dem `Issuer` Wert, der AWS-Konto ID und dem Anzeigenamen des SAML-Anbieters besteht. In Kombination mit dem `Subject`-Element können sie den SAML-Verbundprinzipal eindeutig identifizieren. + Ein `Subject`-Element, das den Wert des `NameID`-Elements im `Subject`-Element der SAML-Zusicherung enthält. + Ein `SubjectType`-Element, das das Format des `Subject`-Elements angibt. Der Wert kann `persistent`, `transient`oder die vollständige `Format`-URI aus den `Subject`- und `NameID`-Elementen sein, die in Ihrer SAML-Zusicherung verwendet wurden. Weitere Informationen zum `NameID`-Attribut des `Format`-Elements finden Sie unter [Konfigurieren von SAML-Assertionen für die Authentifizierungsreaktion](id_roles_providers_create_saml_assertions.md). 1. Verwenden Sie die temporären Sicherheitsanmeldedaten, die in der Antwort zurückgegeben wurden, um AWS API-Aufrufe zu tätigen. Dies ist derselbe Vorgang wie bei einem AWS API-Aufruf mit langfristigen Sicherheitsanmeldedaten. Der Unterschied besteht darin, dass Sie das Sitzungstoken einschließen müssen, mit dem AWS überprüfen kann, dass die temporären Sicherheitsanmeldeinformationen gültig sind. Ihre App sollte die Anmeldeinformationen zwischenspeichern. Standardmäßig laufen die Anmeldeinformationen nach einer Stunde ab. Wenn Sie die [Amazon STSCredentials Provider-Aktion](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) im AWS SDK nicht verwenden, liegt es an Ihnen und Ihrer App, `AssumeRoleWithSAML` erneut anzurufen. Rufen Sie diese Operation auf, um einen neuen Satz an temporären Sicherheitsanmeldeinformationen zu erhalten, bevor die alten ablaufen. ## Anfordern von Anmeldeinformationen über einen benutzerdefinierten Identity Broker Der [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API-Vorgang gibt einen Satz temporärer Sicherheitsanmeldeinformationen für AWS STS föderierte Benutzerprinzipale zurück. Diese API unterscheidet sich von `AssumeRole` dahingehend, dass der Standard-Ablaufzeitraum wesentlich länger ist (zwölf Stunden anstelle von einer Stunde). Außerdem können Sie den `DurationSeconds`- Parameter verwenden, um eine Dauer anzugeben, in der die temporären Sicherheitsanmeldeinformationen gültig bleiben. Die ausgegebenen Anmeldeinformationen sind für die angegebene Dauer zwischen 900 Sekunden (15 Minuten) und 129 600 Sekunden (36 Stunden) gültig. Der längere Ablaufzeitraum kann dazu beitragen, die Anzahl der Aufrufe zu reduzieren AWS , da Sie nicht so oft neue Anmeldeinformationen abrufen müssen. 1. Authentifizieren Sie sich mit den AWS Sicherheitsanmeldedaten Ihres spezifischen IAM-Benutzers. Dieser Anruf muss mit gültigen AWS Sicherheitsanmeldedaten erfolgen. 1. Rufen Sie den Vorgang [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) auf. Der `GetFederationToken`-Aufruf gibt temporäre Sicherheitsanmeldeinformationen zurück, die aus dem Sitzungstoken, dem Zugriffsschlüssel, dem geheimen Schlüssel und dem Ablaufdatum bestehen. Sie können `GetFederationToken` verwenden, wenn Sie Berechtigungen in Ihrer Organisation verwalten möchten (z. B. mithilfe der Proxy-Anwendung für die Zuweisung von Berechtigungen). Im folgenden Beispiel wird eine Beispielanforderung und -antwort mit `GetFederationToken` gezeigt. In dieser Beispielanforderung wird der aufrufende Benutzer für die angegebene Dauer mit dem ARN der [Sitzungsrichtlinie](access_policies.md#policies_session) und den [Sitzungs-Tags](id_session-tags.md)verbunden. Die resultierende Sitzung wird als `Jane-session` bezeichnet. **Example Beispielanforderung** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetFederationToken &Name=Jane-session &PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &AUTHPARAMS ``` Der Richtlinien-ARN im vorherigen Beispiel enthält den folgenden URL-kodierten ARN: `arn:aws:iam::123456789012:policy/Role1policy` Beachten Sie außerdem, dass der `&AUTHPARAMS`-Parameter im Beispiel als Platzhalter für die Authentifizierungsinformationen gedacht ist. Dies ist die *Signatur*, die Sie den AWS HTTP-API-Anfragen beifügen müssen. Wir empfehlen die Verwendung von, [AWS SDKs](https://aws.amazon.com/tools/)um API-Anfragen zu erstellen. Ein Vorteil dabei ist, dass sie die SDKs Anforderungssignierung für Sie übernimmt. Wenn Sie API-Anfragen manuell erstellen und signieren müssen, erfahren Sie unter [Signieren von AWS Anfragen mithilfe von Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) in der *Allgemeine Amazon Web Services-Referenz*, wie Sie eine Anfrage signieren. Zusätzlich zu den temporären Sicherheitsanmeldeinformationen, enthält die Antwort den Amazon-Ressourcennamen (ARN) für den Verbundbenutzer und die Ablaufzeit der Anmeldeinformationen. **Example Beispielantwort** ``` AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-04-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE; arn:aws:sts::123456789012:federated-user/Jean 123456789012:Jean 4 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **Anmerkung** Bei einer AWS Konvertierung werden die übergebenen Sitzungsrichtlinien und Sitzungs-Tags in ein gepacktes Binärformat komprimiert, für das ein separates Limit gilt. Ihre Anforderung kann für diese Begrenzung fehlschlagen, selbst wenn Ihr Nur-Text-Inhalt die übrigen Anforderungen erfüllt. Das `PackedPolicySize`-Antwortelement gibt in Prozent an, wie nah die Richtlinien und Tags für Ihre Anforderung an der oberen Größengrenze liegen. AWS empfiehlt, dass Sie Berechtigungen auf Ressourcenebene gewähren (wenn Sie beispielsweise eine ressourcenbasierte Richtlinie an einen Amazon S3 S3-Bucket anhängen). Sie können den Parameter weglassen. `Policy` Wenn Sie jedoch keine Richtlinie für den AWS STS Verbundbenutzerprinzipal angeben, gewähren die temporären Sicherheitsanmeldedaten keine Berechtigungen. In diesem Fall *müssen* Sie Ressourcenrichtlinien verwenden, um dem Verbundbenutzer Zugriff auf Ihre AWS -Ressourcen zu gewähren. Nehmen wir zum Beispiel an, Ihre AWS-Konto Nummer ist 111122223333 und Sie haben einen Amazon S3 S3-Bucket, auf den Sie Susan Zugriff gewähren möchten. Susans temporäre Sicherheitsanmeldeinformationen enthalten keine Richtlinie für den Bucket. In diesem Fall müssen Sie sicherstellen, dass der Bucket eine Richtlinie mit einem ARN hat, der mit Susans ARN übereinstimmt, z. B. `arn:aws:sts::111122223333:federated-user/Susan`. ## Anfordern von Anmeldeinformationen für Benutzer in nicht vertrauenswürdigen Umgebungen Der [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html)-API-Vorgang gibt einen Satz an temporären Sicherheitsanmeldeinformationen an einen vorhandenen IAM-Benutzer zurück. Dies ist nützlich, um mehr Sicherheit zu bieten, z. B. AWS Anfragen nur zuzulassen, wenn MFA für den IAM-Benutzer aktiviert ist. Da die Anmeldedaten temporär sind, bieten sie erweiterte Sicherheit, wenn ein IAM-Benutzer über eine weniger sichere Umgebung auf Ihre Ressourcen zugreift. Beispiele für weniger sicheren Umgebungen sind ein mobiles Gerät oder ein Webbrowser. 1. Authentifizieren Sie sich mit den AWS Sicherheitsanmeldedaten Ihres spezifischen IAM-Benutzers. Dieser Anruf muss mit gültigen AWS Sicherheitsanmeldedaten erfolgen. 1. Rufen Sie den Vorgang [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) auf. 1. `GetSessionToken` gibt temporäre Sicherheitsanmeldeinformationen bestehend aus einem Sitzungstoken, einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel zurück. Standardmäßig sind temporäre Sicherheitsanmeldeinformationen für einen IAM-Benutzer für maximal zwölf Stunden gültig. Sie können jedoch mit dem `DurationSeconds`-Parameter die Dauer beliebig zwischen 15 Minuten und 36 Stunden festlegen. Aus Sicherheitsgründen Root-Benutzer des AWS-Kontos ist ein Token für einen auf eine Dauer von einer Stunde beschränkt. Im folgenden Beispiel wird eine Beispielanforderung und -antwort mit `GetSessionToken` gezeigt. Die Antwort umfasst auch die Ablaufzeit der temporären Sicherheitsanmeldeinformationen. **Example Beispielanforderung** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=1800 &AUTHPARAMS ``` Der `AUTHPARAMS`-Parameter in diesem Beispiel ist ein Platzhalter für Ihre *Signatur*. Eine Signatur ist die Authentifizierungsinformation, die Sie AWS HTTP-API-Anfragen beifügen müssen. Wir empfehlen die Verwendung von, [AWS SDKs](https://aws.amazon.com/tools/)um API-Anfragen zu erstellen. Ein Vorteil dabei ist, dass sie die SDKs Anforderungssignierung für Sie übernimmt. Wenn Sie API-Anfragen manuell erstellen und signieren müssen, erfahren Sie unter [Signieren von AWS Anfragen mithilfe von Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) in der *Allgemeine Amazon Web Services-Referenz*, wie Sie eine Anfrage signieren. **Example Beispielantwort** ``` AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2011-07-11T19:55:29.611Z AKIAIOSFODNN7EXAMPLE 58c5dbae-abef-11e0-8cfe-09039844ac7d ``` Optional kann die `GetSessionToken` Anfrage `TokenCode` Werte für die Überprüfung der AWS Multi-Faktor-Authentifizierung (MFA) enthalten`SerialNumber`. Wenn die angegebenen Werte gültig sind, werden temporäre Sicherheitsanmeldeinformationen AWS STS bereitgestellt, die den Status der MFA-Authentifizierung enthalten. Die temporären Sicherheitsanmeldedaten können dann für den Zugriff auf die MFA-geschützten API-Operationen oder AWS Websites verwendet werden, solange die MFA-Authentifizierung gültig ist. Das folgende Beispiel zeigt eine `GetSessionToken`-Anforderung, die einen MFA-Verifizierungscode und die Seriennummer des Geräts enthält. ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=7200 &SerialNumber=YourMFADeviceSerialNumber &TokenCode=123456 &AUTHPARAMS ``` **Anmerkung** Der Anruf an AWS STS kann an den globalen Endpunkt oder an einen der regionalen Endpunkte erfolgen, den Sie aktivieren. AWS-Konto Weitere Informationen finden Sie im [AWS STS -Abschnitt von *Regionen und Endpunkte*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region). Der `AUTHPARAMS`-Parameter in diesem Beispiel ist ein Platzhalter für Ihre *Signatur*. Eine Signatur ist die Authentifizierungsinformation, die Sie AWS HTTP-API-Anfragen beifügen müssen. Wir empfehlen die Verwendung von, [AWS SDKs](https://aws.amazon.com/tools/)um API-Anfragen zu erstellen. Ein Vorteil dabei ist, dass sie die SDKs Anforderungssignierung für Sie übernimmt. Wenn Sie API-Anfragen manuell erstellen und signieren müssen, erfahren Sie unter [Signieren von AWS Anfragen mithilfe von Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) in der *Allgemeine Amazon Web Services-Referenz*, wie Sie eine Anfrage signieren. # Verwenden Sie temporäre Anmeldeinformationen mit AWS Ressourcen Sie können temporäre Sicherheitsanmeldedaten verwenden, um programmatische Anfragen nach AWS Ressourcen mithilfe der AWS CLI oder AWS -API (mithilfe der) zu stellen. [AWS SDKs](https://aws.amazon.com/tools/) Die temporären Anmeldeinformationen bieten die gleichen Berechtigungen wie langfristige Sicherheitsanmeldeinformationen, z. B. IAM-Benutzer-Anmeldeinformationen. Es gibt jedoch einige Unterschiede: + Wenn Sie einen Anruf mit temporären Sicherheitsanmeldeinformationen tätigen, muss der Aufruf ein Sitzungstoken enthalten, das zusammen mit diesen temporären Anmeldeinformationen zurückgegeben wird. AWS verwendet das Sitzungstoken, um die temporären Sicherheitsanmeldedaten zu validieren. + Die temporären Anmeldeinformationen laufen nach einem bestimmten Intervall ab. Nach Ablauf der temporären Anmeldeinformationen schlagen alle Aufrufe, die Sie mit diesen Anmeldeinformationen tätigen, fehl, so dass Sie einen neuen Satz temporärer Anmeldeinformationen generieren müssen. Temporäre Anmeldeinformationen können nicht über das ursprünglich angegebene Intervall hinaus erweitert oder aktualisiert werden. + Wenn Sie zur Erstellung einer Anforderung temporäre Anmeldeinformationen verwenden, enthält Ihr Auftraggeber möglicherweise eine Reihe von Tags. Diese Tags stammen von Sitzungs-Tags und Tags, die der von Ihnen angenommenen Rolle angefügt sind. Weitere Hinweise zu Sitzungs-Tags finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). Wenn Sie die Tools [AWS SDKs](https://aws.amazon.com/tools), die [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/)(AWS CLI) oder die [Tools für Windows](https://aws.amazon.com/powershell) verwenden, unterscheidet sich die Art und Weise PowerShell, wie temporäre Sicherheitsanmeldeinformationen abgerufen und verwendet werden, je nach Kontext. Wenn Sie Code- oder Tools for PowerShell Windows-Befehle innerhalb einer EC2-Instance ausführen, können Sie Rollen für Amazon EC2 nutzen. AWS CLI Andernfalls können Sie eine [AWS STS -API](https://docs.aws.amazon.com/STS/latest/APIReference/) aufrufen, um die temporären Anmeldeinformationen abzurufen, und sie dann explizit verwenden, um Aufrufe an AWS -Services auszuführen. **Anmerkung** Sie können AWS -Security-Token-Service (AWS STS) verwenden, um vertrauenswürdige Benutzer zu erstellen und ihnen temporäre Sicherheitsanmeldedaten 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). AWS STS ist ein globaler Dienst mit einem Standardendpunkt bei`https://sts.amazonaws.com`. Dieser Endpunkt befindet sich zwar in der Region USA Ost (Nord-Virginia), die Anmeldedaten, die Sie von diesem und anderen Endpunkten erhalten, sind jedoch weltweit gültig. Diese Anmeldeinformationen funktionieren mit Services und Ressourcen in jeder Region. Sie können sich auch dafür entscheiden, AWS STS API-Aufrufe an Endpunkte in einer der unterstützten Regionen zu tätigen. Dies kann die Latenz verringern, indem die Anforderungen an Server in einer Region in Ihrer Nähe gesendet werden. Ihre Anmeldeinformationen sind unabhängig von der Region, in der sie generiert werden, weltweit gültig. Weitere Informationen finden Sie unter [Verwalte AWS STS in einem AWS-Region](id_credentials_temp_enable-regions.md). **Contents** + [ ## Verwenden von temporären Anmeldeinformationen in Amazon EC2-Instances ](#using-temp-creds-sdk-ec2-instances) + [ ## Verwenden temporärer Sicherheitsanmeldedaten mit dem AWS SDKs ](#using-temp-creds-sdk) + [ ## Verwenden Sie temporäre Sicherheitsanmeldedaten mit AWS CLI ](#using-temp-creds-sdk-cli) + [ ## Verwenden von temporären Sicherheitsanmeldeinformationen mit API-Operationen ](#RequestWithSTS) + [ ## Weitere Informationen ](#using-temp-creds-more-info) ## Verwenden von temporären Anmeldeinformationen in Amazon EC2-Instances Wenn Sie AWS CLI Befehle oder Code innerhalb einer EC2-Instance ausführen möchten, empfiehlt es sich, [Rollen für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) zu verwenden, um Anmeldeinformationen abzurufen. Sie erstellen eine IAM-Rolle, die die Berechtigungen angibt, die Sie Anwendungen zuweisen möchten, die auf EC2-Instances ausgeführt werden. Wenn Sie die Instance starten, weisen Sie die Rolle der Instance zu. Anwendungen und Tools for PowerShell Windows-Befehle AWS CLI, die auf der Instance ausgeführt werden, können dann automatische temporäre Sicherheitsanmeldedaten aus den Instance-Metadaten abrufen. Sie müssen die temporären Anmeldeinformationen nicht explizit abrufen. Die AWS SDKs Befehle AWS CLI, und Tools für Windows rufen die Anmeldeinformationen PowerShell automatisch vom EC2 Instance Metadata Service (IMDS) ab und verwenden sie. Die temporären Anmeldeinformationen verfügen über die Berechtigungen, die Sie für die Rolle definieren, die mit der Instance verknüpft ist. Weitere Informationen und Beispiele finden Sie in den folgenden Themen: + [Verwenden von IAM-Rollen, um Zugriff auf AWS Ressourcen in Amazon Elastic Compute Cloud zu gewähren](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK für Java + [Zugriff mithilfe einer IAM-Rolle gewähren](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK für .NET + [Erstellen einer IAM-Rolle](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) - AWS SDK für Ruby ## Verwenden temporärer Sicherheitsanmeldedaten mit dem AWS SDKs Um temporäre Sicherheitsanmeldedaten im Code zu verwenden, rufen Sie programmgesteuert eine AWS STS API auf `AssumeRole` und extrahieren die resultierenden Anmeldeinformationen und das Sitzungstoken. Anschließend verwenden Sie diese Werte als Anmeldeinformationen für nachfolgende Aufrufe von. AWS Das folgende Beispiel zeigt Pseudocode für die Verwendung temporärer Sicherheitsanmeldedaten, wenn Sie ein AWS SDK verwenden: ``` assumeRoleResult = AssumeRole(role-arn); tempCredentials = new SessionAWSCredentials( assumeRoleResult.AccessKeyId, assumeRoleResult.SecretAccessKey, assumeRoleResult.SessionToken); s3Request = CreateAmazonS3Client(tempCredentials); ``` Ein Beispiel, das in Python geschrieben wurde (mit der[AWS SDK für Python (Boto)](https://aws.amazon.com/sdk-for-python/)), finden Sie unter [Zu einer IAM-Rolle (AWS API) wechseln](id_roles_use_switch-role-api.md). In diesem Beispiel wird veranschaulicht, wie Sie mit `AssumeRole` temporäre Anmeldeinformationen abrufen und dann diese Anmeldeinformationen verwenden, um einen Aufruf von Amazon S3 durchzuführen. Einzelheiten über den Aufruf von `AssumeRole`, `GetFederationToken` und anderen API-Vorgängen finden Sie in der [AWS -Security-Token-Service -API-Referenz](https://docs.aws.amazon.com/STS/latest/APIReference/). Informationen dazu, wie die temporären Sicherheitsanmeldeinformationen und das Sitzungstoken aus dem Ergebnis abgerufen werden, finden Sie in der Dokumentation für das SDK, mit dem Sie arbeiten. Sie finden die Dokumentation für alle AWS SDKs auf der [AWS Hauptdokumentationsseite](https://aws.amazon.com/documentation) im Abschnitt **SDKs und Toolkits**. Sie müssen sicherstellen, dass Sie neue Anmeldeinformationen erhalten, bevor die alten ablaufen. In einigen Fällen können Sie einen Anbieter verwenden SDKs, der den Prozess der Aktualisierung der Anmeldeinformationen für Sie verwaltet. Schauen Sie in der Dokumentation für das von Ihnen verwendete SDK nach. ## Verwenden Sie temporäre Sicherheitsanmeldedaten mit AWS CLI Sie können temporäre Sicherheitsanmeldeinformationen mit der AWS CLI verwenden. Dies kann nützlich für das Testen von Richtlinien sein. Unter Verwendung der [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/) können Sie eine [AWS STS -API](https://docs.aws.amazon.com/STS/latest/APIReference/) wie `AssumeRole` oder `GetFederationToken` aufrufen und dann die resultierende Ausgabe erfassen. Das folgende Beispiel zeigt einen Aufruf an `AssumeRole`, durch den die Ausgabe an eine Datei gesendet wird. In dem Beispiel wird davon ausgegangen, dass es sich bei dem `profile` Parameter um ein Profil in der AWS CLI Konfigurationsdatei handelt. Es wird auch davon ausgegangen, dass Anmeldeinformationen für einen IAM-Benutzer referenziert werden, der über Berechtigungen verfügt, um die Rolle zu übernehmen. ``` aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt ``` Wenn der Befehl abgeschlossen ist, können Sie die Zugriffsschlüssel-ID, den geheimen Zugriffsschlüssel und den Sitzungs-Token unabhängig von deren Routingziel extrahieren. Sie können dies entweder manuell oder mithilfe eines Skripts tun. Anschließend können Sie diese Werte Umgebungsvariablen zuweisen. Wenn Sie AWS CLI Befehle ausführen, AWS CLI sucht der in einer bestimmten Reihenfolge nach Anmeldeinformationen — zuerst in den Umgebungsvariablen und dann in der Konfigurationsdatei. Nachdem Sie die temporären Anmeldeinformationen in Umgebungsvariablen eingegeben haben, werden diese Anmeldeinformationen daher standardmäßig AWS CLI verwendet. (Wenn Sie im Befehl einen `profile` Parameter angeben, werden die Umgebungsvariablen AWS CLI übersprungen. Stattdessen wird in AWS CLI der Konfigurationsdatei gesucht, sodass Sie die Anmeldeinformationen in den Umgebungsvariablen bei Bedarf überschreiben können.) Das folgende Beispiel zeigt, wie Sie die Umgebungsvariablen für temporäre Sicherheitsanmeldedaten festlegen und dann einen AWS CLI Befehl aufrufen können. Da der AWS CLI Befehl keinen `profile` Parameter enthält, AWS CLI sucht der zuerst in Umgebungsvariablen nach Anmeldeinformationen und verwendet daher die temporären Anmeldeinformationen. **Linux** ``` $ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE $ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY $ export AWS_SESSION_TOKEN=AQoDYXdzEJr... $ aws ec2 describe-instances --region us-west-1 ``` **Windows** ``` C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr... C:\> aws ec2 describe-instances --region us-west-1 ``` ## Verwenden von temporären Sicherheitsanmeldeinformationen mit API-Operationen Wenn Sie direkte HTTPS-API-Anfragen an stellen AWS, können Sie diese Anfragen mit den temporären Sicherheitsanmeldedaten signieren, die Sie von AWS -Security-Token-Service (AWS STS) erhalten. Dazu verwenden Sie die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel, die Sie von erhalten AWS STS. Verwenden Sie dazu die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel auf dieselbe Weise, wie Sie langfristige Anmeldeinformationen zum Signieren einer Anforderung verwenden würden. Sie fügen Ihrer API-Anfrage auch das Sitzungstoken hinzu, von dem Sie es erhalten AWS STS. Fügen Sie den Sitzungs-Token zu einem HTTP-Header oder zu einem Abfragezeichenfolgeparameter mit dem Namen `X-Amz-Security-Token` hinzu. Fügen Sie den Sitzungs-Token zum HTTP-Header *oder* zum Abfragezeichenfolgeparameter hinzu, jedoch nicht zu beiden. Weitere Informationen zum Signieren von HTTPS-API-Anfragen finden Sie unter [Signieren von AWS API-Anfragen](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) in der *Allgemeine AWS-Referenz*. ## Weitere Informationen Weitere Informationen zur Verwendung AWS STS mit anderen AWS Diensten finden Sie unter den folgenden Links: + **Amazon S3**. Siehe [Anforderungen mit temporären IAM-Benutzeranmeldeinformationen stellen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) oder [Anforderungen mit temporären Benutzeranmeldeinformationen im Verbund stellen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html) im *Benutzerhandbuch für Amazon Simple Storage Service*. + **Amazon SNS**. Weitere Informationen finden Sie unter [Verwenden identitätsbasierter Richtlinien mit Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS) im *Entwicklerhandbuch für Amazon Simple Notification Service*. + **Amazon SQS**. Weitere Informationen finden Sie unter [Identitäts- und Zugriffsverwaltung in Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS) im *Entwicklerhandbuch für Amazon Simple Queue Service*. + **Amazon SimpleDB**. Siehe [Using Temporary Security Credentials](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html) im *Developer Guide für Amazon SimpleDB*. # 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" } ] } ``` ------ # Verwalte AWS STS in einem AWS-Region Ein regionaler Endpunkt ist die URL des Einstiegspunkts innerhalb einer bestimmten Region für einen AWS Webdienst. AWS empfiehlt die Verwendung von regionalen AWS -Security-Token-Service (AWS STS) Endpunkten anstelle des globalen Endpunkts, um die Latenz zu reduzieren, Redundanz zu gewährleisten und die Gültigkeit von Sitzungstoken zu erhöhen. Obwohl der globale (ältere) AWS STS Endpunkt hochverfügbar `https://sts.amazonaws.com` ist, wird er in einer einzigen AWS Region, USA Ost (Nord-Virginia), gehostet und bietet wie andere Endpunkte kein automatisches Failover für Endpunkte in anderen Regionen. + **Latenz reduzieren** — Indem Sie Ihre AWS STS Anrufe an einen Endpunkt tätigen, der geografisch näher an Ihren Diensten und Anwendungen liegt, können Sie auf AWS STS Dienste mit geringerer Latenz und besseren Reaktionszeiten zugreifen. + **Integrierte Redundanz** – Sie können die Auswirkungen eines Fehlers innerhalb eines Workloads auf eine begrenzte Anzahl von Komponenten mit einem vorhersehbaren Umfang der Auswirkungen einschränken. Durch die Verwendung regionaler AWS STS Endpunkte können Sie den Umfang Ihrer Komponenten an den Umfang Ihrer Sitzungstoken anpassen. Weitere Informationen zu dieser Zuverlässigkeitssäule finden Sie unter [Verwendung der Fehlerisolierung zum Schutz Ihres Workloads](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) im *AWS -Well-Architected-Framework*. + **Erhöhen Sie die Gültigkeit** von Sitzungstoken — Sitzungstoken von regionalen AWS STS Endpunkten sind insgesamt gültig. AWS-Regionen Sitzungstoken vom globalen STS-Endpunkt sind nur gültig AWS-Regionen , wenn sie standardmäßig aktiviert sind. Wenn Sie beabsichtigen, eine neue Region für Ihr Konto zu aktivieren, können Sie Sitzungstoken von regionalen AWS STS Endpunkten verwenden. Wenn Sie den globalen Endpunkt verwenden möchten, müssen Sie die Regionskompatibilität der AWS STS Sitzungstoken für den globalen Endpunkt ändern. Dadurch wird sichergestellt, dass alle Tokens gültig sind AWS-Regionen. Eine Liste der AWS STS Regionen und ihrer Endpunkte finden Sie unter[AWS STS Regionen und Endpunkte](id_credentials_temp_region-endpoints.md). **Anmerkung** AWS hat Änderungen am globalen Endpunkt AWS -Security-Token-Service (AWS STS) (`https://sts.amazonaws.com`) in Regionen vorgenommen, die [standardmäßig aktiviert](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) sind, um dessen Stabilität und Leistung zu verbessern. AWS STS Anfragen an den globalen Endpunkt werden automatisch in denselben Workloads bearbeitet AWS-Region wie Ihre Workloads. Diese Änderungen werden nicht in Opt-in-Regionen bereitgestellt. Wir empfehlen, dass Sie die entsprechenden AWS STS regionalen Endpunkte verwenden. Weitere Informationen finden Sie unter [AWS STS globale Änderungen an den Endpunkten](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes). **Topics** + [ ## Aktivierung und Deaktivierung AWS STS in einem AWS-Region ](#sts-regions-activate-deactivate) + [ ## Code zur Verwendung von AWS STS Regionen schreiben ](#id_credentials_temp_enable-regions_writing_code) + [ ## Verwalten von Sitzungstoken des globalen Endpunkts ](#sts-regions-manage-tokens) ## Aktivierung und Deaktivierung AWS STS in einem AWS-Region Wenn Sie AWS STS Endgeräte für eine Region aktivieren, AWS STS kann temporäre Anmeldeinformationen für Benutzer und Rollen in Ihrem Konto ausgestellt werden, die eine AWS STS Anfrage stellen. Diese Anmeldedaten können dann in einer beliebigen Region verwendet werden, die standardmäßig oder manuell aktiviert ist. Für Regionen, die standardmäßig aktiviert sind, müssen Sie den regionalen AWS STS Endpunkt in dem Konto aktivieren, in dem die temporären Anmeldeinformationen generiert werden. Es spielt beim Senden der Anforderung keine Rolle, ob ein Benutzer bei diesem oder einem anderen Konto angemeldet ist. Wenn Sie AWS-Konto mithilfe einer manuell aktivierten Region temporäre Anmeldeinformationen für eine Rolle in einer anderen Rolle anfordern, muss das Zielkonto (das Konto, das die Rolle enthält) diese Region für den AWS STS Betrieb aktivieren. Dadurch wird sichergestellt, dass die temporären Sicherheitsanmeldeinformationen korrekt generiert werden können. Beispiel: Ein Benutzer aus Konto A möchte die API-Anforderung `sts:AssumeRole` an den [regionalen AWS STS -Endpunkt](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com` senden. Die Anforderung gilt für die temporären Anmeldeinformationen für die Rolle `Developer` in Konto B. Da die Anforderung zum Erstellen von Anmeldeinformationen für eine Entität des Kontos B gesendet wird, muss Konto B die Region `ap-southeast-3` aktiviert haben. Benutzer aus Konto A (oder einem anderen Konto) können den Endpunkt `ap-southeast-3` AWS STS aufrufen, um Anmeldeinformationen für Konto B anzufordern. Dabei spielt es keine Rolle, ob die Region in ihren Konten aktiviert ist oder nicht. Weitere Informationen finden Sie unter [AWS-Regionen In Ihrem Konto aktivieren oder deaktivieren](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). **Anmerkung** Aktive Regionen stehen allen Benutzern zur Verfügung, die temporäre Anmeldedaten in diesem Konto verwendet. Um zu steuern, welche IAM-Benutzer oder Rollen auf die Region zugreifen können, verwenden Sie den Bedingungsschlüssel `aws:RequestedRegion` in Ihren Berechtigungsrichtlinien. **So aktivierst oder deaktivierst du sie AWS STS in einer Region, die standardmäßig aktiviert ist (Konsole)** 1. Melden Sie sich als Root-Benutzer oder als IAM-Benutzer mit der Berechtigung zur Durchführung von IAM-Verwaltungsaufgaben an. 1. Öffnen Sie die [IAM-Konsole](https://console.aws.amazon.com/iam/home?#home) und wählen Sie im Navigationsbereich [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings). 1. Suchen Sie im Abschnitt **Security Token Service (STS)** **Endpunkte** nach der Region, die Sie konfigurieren möchten, und wählen Sie dann in der Spalte **STS-Status** **Aktiv** oder **Inaktiv** aus. 1. Wählen Sie in dem sich öffnenden Dialogfeld **Activate (Aktivieren)** oder **Deactivate (Deaktivieren)**. Regionen, die aktiviert werden müssen, werden AWS STS automatisch aktiviert, wenn Sie die Region aktivieren. Nachdem Sie eine Region aktiviert haben, AWS STS ist sie immer für die Region aktiv und Sie können sie nicht deaktivieren. Weitere Informationen zur Aktivierung von Regionen, die standardmäßig deaktiviert sind, finden Sie im *AWS -Kontenverwaltung Referenzhandbuch* [unter Spezifizieren, welche Regionen für AWS-Regionen Ihr Konto verwendet werden können](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). ## Code zur Verwendung von AWS STS Regionen schreiben Nachdem Sie eine Region aktiviert haben, können Sie AWS STS API-Aufrufe an diese Region weiterleiten. Der folgende Java-Codeausschnitt zeigt, wie ein `AWSSecurityTokenService`-Objekt so konfiguriert wird, dass es Anfragen an die Region Europa (Mailand) (eu-south-1) stellt. ``` EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1"); AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard() .withCredentials(credentials) .withEndpointConfiguration(regionEndpointConfig) .build(); ``` AWS STS empfiehlt, dass Sie Aufrufe an einen regionalen Endpunkt tätigen. Informationen zur manuellen Aktivierung einer Region finden Sie unter unter [Festlegen der AWS-Regionen , die Ihr Konto verwenden kann](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) im *AWS -Kontenverwaltung -Referenzhandbuch*. In diesem Beispiel instanziiert die erste Zeile ein `EndpointConfiguration`-Objekt namens `regionEndpointConfig`, wobei die URL des Endpunkts und die AWS-Region als Parameter übergeben werden. Informationen zum Einrichten AWS STS regionaler Endpunkte mithilfe einer Umgebungsvariablen für AWS SDKs finden Sie unter [AWS STS Regionalisierte Endpunkte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) im Referenzhandbuch zu *Tools AWS SDKs und Tools*. Angaben zu allen anderen Sprach- und Programmierumgebungskombinationen finden Sie in der [Dokumentation des entsprechenden SDK](https://aws.amazon.com/tools/). ## Verwalten von Sitzungstoken des globalen Endpunkts Die meisten AWS-Regionen sind standardmäßig für alle AWS-Services Operationen aktiviert. Diese Regionen werden automatisch für die Verwendung mit aktiviert AWS STS. Einige Regionen, wie z. B. Asien-Pazifik (Hongkong), müssen manuell aktiviert werden. Weitere Informationen zum Aktivieren und Deaktivieren von AWS-Regionen finden Sie unter [Festlegen, welche AWS-Regionen Ihr Konto verwenden kann](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) im *AWS -Kontenverwaltung -Referenzhandbuch*. Wenn Sie diese AWS Regionen aktivieren, werden sie automatisch für die Verwendung mit aktiviert AWS STS. Sie können den AWS STS Endpunkt nicht für eine Region aktivieren, die deaktiviert ist. Sitzungstoken, die in allen Fällen gültig sind, AWS-Regionen enthalten mehr Zeichen als Token, die in Regionen gültig sind, die standardmäßig aktiviert sind. Das Ändern dieser Einstellung kann sich auf vorhandene Systeme auswirken, in denen Sie Token vorübergehend speichern. Sie können diese Einstellung mithilfe der AWS API AWS-Managementkonsole AWS CLI, oder ändern. **So ändern Sie die Vereinbarkeit der Region für die Sitzungstoken des globalen Endpunkts (Konsole)** 1. Melden Sie sich als Root-Benutzer oder als IAM-Benutzer mit der Berechtigung zur Durchführung von IAM-Verwaltungsaufgaben an. Um die Vereinbarkeit der Sitzungstoken zu ändern, benötigen Sie eine Richtlinie, die die `iam:SetSecurityTokenServicePreferences`-Aktion zulässt. 1. Öffnen Sie die [IAM-Konsole](https://console.aws.amazon.com/iam/home?#home). Wählen Sie im Navigationsbereich **Account Settings (Kontoeinstellungen)**. 1. Im Abschnitt **Security Token Service (STS)** finden Sie **Sitzungstoken von den STS-Endpunkten**. Der **globale Endpunkt** gibt `Valid only in AWS-Regionen enabled by default` an. Wählen Sie **Change**. 1. Wählen **Sie im Dialogfeld „Regionskompatibilität ändern**“ die Option **Alle** aus AWS-Regionen. Wählen Sie dann **Save changes (Änderungen speichern)**. **Anmerkung** Sitzungstoken, die in allen Fällen gültig sind, AWS-Region enthalten mehr Zeichen als Token, die in Regionen gültig sind, die standardmäßig aktiviert sind. Das Ändern dieser Einstellung kann sich auf vorhandene Systeme auswirken, in denen Sie Token vorübergehend speichern. **So ändern Sie die Vereinbarkeit der Region für die Sitzungstoken des globalen Endpunkts (AWS CLI)** Legen Sie die Version des Sitzungs-Tokens fest. Token der Version 1 sind nur gültig AWS-Regionen , wenn sie standardmäßig verfügbar sind. Diese Token funktionieren icht in manuell aktivierten Regionen, wie z. B. Asien-Pazifik (Hongkong), nicht. Token der Version 2 sind in allen Regionen gültig. Token der Version 2 enthalten jedoch mehr Zeichen und können sich auf Systeme auswirken, in denen Sie Token vorübergehend speichern. + [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html) **Um die Regionskompatibilität von Sitzungstoken für den globalen Endpunkt (AWS API) zu ändern** Legen Sie die Version des Sitzungs-Tokens fest. Tokens der Version 1 sind nur gültig AWS-Regionen , wenn sie standardmäßig verfügbar sind. Diese Token funktionieren icht in manuell aktivierten Regionen, wie z. B. Asien-Pazifik (Hongkong), nicht. Token der Version 2 sind in allen Regionen gültig. Token der Version 2 enthalten jedoch mehr Zeichen und können sich auf Systeme auswirken, in denen Sie Token vorübergehend speichern. + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) # AWS STS Regionen und Endpunkte **Anmerkung** AWS hat Änderungen am globalen Endpunkt AWS -Security-Token-Service (AWS STS`https://sts.amazonaws.com`) in Regionen vorgenommen, die [standardmäßig aktiviert](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) sind, um dessen Stabilität und Leistung zu verbessern. AWS STS Anfragen an den globalen Endpunkt werden automatisch in denselben Workloads bearbeitet AWS-Region wie Ihre Workloads. Diese Änderungen werden nicht in Opt-in-Regionen bereitgestellt. Wir empfehlen, dass Sie die entsprechenden AWS STS regionalen Endpunkte verwenden. Weitere Informationen finden Sie unter [AWS STS globale Änderungen an den Endpunkten](#reference_sts_global_endpoint_changes). In der folgenden Tabelle sind die Regionen und deren Endpunkte aufgelistet. Es wird angegeben, welche standardmäßig aktiviert sind und welche Sie selbst aktivieren oder deaktivieren können. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) ¹Sie müssen [die Region aktivieren](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html), um sie nutzen zu können. Dies aktiviert AWS STS automatisch. Sie können AWS STS in diesen Regionen nicht manuell aktivieren oder deaktivieren. ²Für die Nutzung AWS in China benötigen Sie ein Konto und spezielle Anmeldeinformationen für AWS China. ## AWS STS globale Änderungen an den Endpunkten AWS hat Änderungen am globalen Endpunkt AWS -Security-Token-Service (AWS STS`https://sts.amazonaws.com`) in [standardmäßig aktivierten](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) Regionen vorgenommen, um dessen Stabilität und Leistung zu verbessern. Bisher wurden alle Anfragen an den AWS STS globalen Endpunkt von einem einzigen Server AWS-Region, USA Ost (Nord-Virginia), bedient. In Regionen, die [standardmäßig aktiviert](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) sind, werden Anfragen an den AWS STS globalen Endpunkt jetzt automatisch in derselben Region bearbeitet, aus der die Anfrage stammt, und nicht in der Region USA Ost (Nord-Virginia). Diese Änderungen werden nicht in Opt-in-Regionen bereitgestellt. Mit dieser Änderung AWS STS wird Ihre Anfrage auf der Grundlage der ursprünglichen Region und des verwendeten DNS-Resolvers bearbeitet. Anfragen an den AWS STS globalen Endpunkt werden in derselben Region wie Ihr AWS bereitgestellter Workload bearbeitet, wenn die DNS-Anfrage für den AWS STS globalen Endpunkt vom Amazon DNS-Server in Regionen bearbeitet wird, die standardmäßig aktiviert sind. Anfragen an den globalen Endpunkt von AWS STS werden weiterhin in der Region USA Ost (Nord-Virginia) verarbeitet, wenn Ihre Anfrage aus einer Opt-in-Region stammt oder mit einem anderen DNS-Auflöser als dem Amazon-DNS-Server aufgelöst wurde. Weitere Informationen zu Amazon DNS finden Sie im *Benutzerhandbuch zu Amazon Virtual Private Cloud* unter [Amazon-DNS-Server](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS). Die folgende Tabelle zeigt, wie Anfragen an den AWS STS globalen Endpunkt je nach Ihrem DNS-Anbieter weitergeleitet werden. | DNS-Auflöser | Werden Anfragen an den AWS STS globalen Endpunkt an den lokalen weitergeleitet? AWS-Region | | --- | --- | | Amazon-DNS-Resolver in einer Amazon VPC in einer standardmäßig aktivierten Region | Ja | | Amazon-DNS-Resolver in einer Amazon VPC in einer Opt-in-Region | Nein, die Anfrage wird an die Region USA Ost (Nord-Virginia) weitergeleitet. | | DNS-Resolver Ihres ISP, eines öffentlichen DNS-Anbieters oder eines anderen DNS-Anbieters | Nein, die Anfrage wird an die Region USA Ost (Nord-Virginia) weitergeleitet. | Um sicherzustellen, dass Ihre bestehenden Prozesse so wenig wie möglich gestört werden, AWS hat das Unternehmen die folgenden Maßnahmen ergriffen: + AWS CloudTrail Protokolle für Anfragen an den AWS STS globalen Endpunkt werden an die Region USA Ost (Nord-Virginia) gesendet. CloudTrail Protokolle für Anfragen, die von AWS STS regionalen Endpunkten bedient werden, werden weiterhin in CloudTrail der jeweiligen Region protokolliert. + CloudTrail Protokolle für Operationen, die vom AWS STS globalen Endpunkt und den regionalen Endpunkten ausgeführt werden, enthalten zusätzliche Felder`endpointType`, in denen angegeben wird`awsServingRegion`, welcher Endpunkt und welche Region die Anfrage bearbeitet haben. Beispiele für CloudTrail Protokolle finden Sie unter[Beispiel für ein AWS STS API-Ereignis, das den globalen Endpunkt in der Protokolldatei verwendet CloudTrail](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint). + Anfragen an den AWS STS globalen Endpunkt haben `us-east-1` für den `aws:RequestedRegion` Bedingungsschlüssel den Wert von, unabhängig davon, welche Region die Anfrage bearbeitet hat. + Anfragen, die vom AWS STS globalen Endpunkt bearbeitet werden, teilen sich nicht die Quote für Anfragen pro Sekunde mit regionalen AWS STS Endpunkten. Wenn Sie Workloads in einer Opt-in-Region haben und trotzdem den AWS STS globalen Endpunkt verwenden, empfehlen wir Ihnen, zur Verbesserung der Ausfallsicherheit und Leistung auf AWS STS regionale Endpunkte zu migrieren. *Weitere Informationen zur Konfiguration regionaler AWS STS Endpunkte finden Sie unter Regionale Endpunkte im Referenzhandbuch und im [AWS STS Tools-Referenzhandbuch](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html).AWS SDKs * ## AWS CloudTrail und regionale Endpunkte Anrufe an regionale und globale Endpunkte werden im `tlsDetails`-Feld in AWS CloudTrail angemeldet. Anrufe an regionale Endpunkte, z. B.`us-east-2.amazonaws.com`, werden in der CloudTrail entsprechenden Region angemeldet. Aufrufe des globalen Endpunkts, z. B. `sts.amazonaws.com`, werden als Aufrufe eines globalen Services protokolliert. Ereignisse für globale AWS STS Endpunkte werden in us-east-1 protokolliert. **Anmerkung** `tlsDetails` kann nur für Services eingesehen werden, die dieses Feld unterstützen. [https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html) Weitere Informationen finden Sie unter [Protokollierung von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail](cloudtrail-integration.md). # Benutzerdefinierten Identity Broker-Zugriff auf die AWS Konsole aktivieren Sie können Code schreiben und ausführen, um eine URL zu erstellen, über die Benutzer, die sich beim Netzwerk Ihrer Organisation anmelden, sicheren Zugriff auf die AWS-Managementkonsole haben. Die URL enthält ein Anmeldetoken, das Sie erhalten AWS und das den Benutzer authentifiziert. AWS Die daraus resultierende Konsolensitzung kann aufgrund eines Verbunds eine eindeutige `AccessKeyId` enthalten. [Informationen zur Verwendung des Zugriffsschlüssels für die Verbundanmeldung anhand verwandter CloudTrail Ereignisse finden Sie unter [Protokollierung von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail](cloudtrail-integration.md) und AWS-Managementkonsole unter Anmeldeereignisse.](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html) **Anmerkung** Wenn Ihre Organisation einen Identitätsanbieter (IdP) verwendet, der mit SAML kompatibel ist, können Sie den Zugriff auf die Konsole einrichten, ohne dass Code geschrieben werden muss. Dies funktioniert mit Anbietern wie Microsoft Active Directory Federation Services oder Open-Source-Shibboleth. Details hierzu finden Sie unter [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md). Um den Benutzern Ihrer Organisation den Zugriff auf zu ermöglichen AWS-Managementkonsole, können Sie einen benutzerdefinierten *Identity Broker* erstellen, der die folgenden Schritte ausführt: 1. Überprüfen Sie, ob der Benutzer von Ihrem lokalen Identitätssystem authentifiziert ist. 1. Rufen Sie die Operationen AWS -Security-Token-Service (AWS STS) [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)(empfohlen) oder [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API auf, um temporäre Sicherheitsanmeldeinformationen für den Benutzer abzurufen. Weitere Informationen zu den unterschiedlichen Methoden, die Sie zum Übernehmen einer Rolle verwenden können, finden Sie unter [Methoden, um eine Rolle zu übernehmen](id_roles_manage-assume.md). Weitere Informationen zur Übergabe optionaler Sitzungs-Tags bei Erhalt Ihrer Sicherheitsanmeldeinformationen finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). + Wenn Sie eine der `AssumeRole*` API-Operationen verwenden, um die temporären Sicherheitsanmeldeinformationen für eine Rolle zu erhalten, können Sie den Parameter `DurationSeconds` in Ihren Aufruf einschließen. Dieser Parameter gibt die Dauer Ihrer Rollensitzung von 900 Sekunden (15 Minuten) bis zur maximalen Sitzungsdauer für die Rolle an. Wenn Sie `DurationSeconds` in einer `AssumeRole*`-Operation verwenden, müssen Sie das als IAM-Benutzer mit langfristigen Anmeldeinformationen aufrufen. Andernfalls schlägt der Aufruf des Verbund-Endpunkts in Schritt 3 fällt. Weitere Informationen dazu, wie Sie den maximalen Wert für eine Rolle anzeigen oder ändern können, finden Sie unter [Aktualisieren der maximalen Sitzungsdauer für eine Rolle](id_roles_update-role-settings.md#id_roles_update-session-duration). + Wenn Sie die `GetFederationToken`-API-Operation verwenden, um die Anmeldeinformationen zu erhalten, können Sie den `DurationSeconds`-Parameter in Ihre Aufruf aufnehmen. Dieser Parameter gibt die Dauer Ihrer Rollensitzung an. Der Wert kann im Bereich zwischen 900 Sekunden (15 Minuten) und 129 600 Sekunden (36 Stunden) liegen. Sie können diesen API-Aufruf nur mit den langfristigen AWS Sicherheitsanmeldedaten eines IAM-Benutzers ausführen. Sie können diese Aufrufe auch mit Root-Benutzer des AWS-Kontos Anmeldeinformationen tätigen, wir empfehlen dies jedoch nicht. Wenn Sie diesen Aufruf als Stammbenutzer tätigen, dauert die Standardsitzung eine Stunde. Sie können auch eine Sitzung zwischen 900 Sekunden (15 Minuten) und 3 600 Sekunden (eine Stunde) festlegen. 1. Rufen Sie den AWS Verbundendpunkt auf und geben Sie die temporären Sicherheitsanmeldedaten ein, um ein Anmeldetoken anzufordern. 1. Erstellen Sie eine URL für die Konsole, die das Token enthält: + Wenn Sie eine der `AssumeRole*`-API-Operationen in Ihrer URL verwenden, können Sie den `SessionDuration`-HTTP-Parameter einschließen. Dieser Parameter gibt die Dauer der Konsolensitzung an, von 900 Sekunden (15 Minuten) bis 43 200 Sekunden (12 Stunden). + Wenn Sie die `GetFederationToken`-API-Operation in Ihrer URL verwenden, können Sie den `DurationSeconds`-Parameter einschließen. Dieser Parameter gibt die Dauer der verbundenen Konsolensitzung an. Der Wert kann im Bereich zwischen 900 Sekunden (15 Minuten) und 129 600 Sekunden (36 Stunden) liegen. **Anmerkung** Ihr `SessionDuration` darf nicht größer oder gleich der Einstellung für die maximale Sitzungsdauer für die von Ihnen übernommene Rolle sein. Sie haben beispielsweise die maximale Sitzungsdauer für die Rolle, die Sie übernehmen möchten, auf 5 Stunden festgelegt. Ihr `SessionDuration`-Parameter kann 16 524 Sekunden oder 4 Stunden und 59 Sekunden betragen. Verwenden Sie nicht den HTTP-Parameter `SessionDuration`, wenn Sie temporäre Anmeldeinformationen mit `GetFederationToken` abrufen. Der Vorgang schlägt fehl. Die Verwendung der Anmeldeinformationen für eine Rolle zur Übernahme einer anderen Rolle wird als [*Verketten von Rollen*](id_roles.md#iam-term-role-chaining) bezeichnet. Wenn Sie die Verkettung von Rollen verwenden, sind Ihre neuen Anmeldeinformationen auf eine maximale Dauer von einer Stunde begrenzt. Wenn Sie Rollen verwenden, um [Berechtigungen für Anwendungen zu erteilen, die auf EC2-Instances ausgeführt werden](id_roles_use_switch-role-ec2.md), unterliegen diese Anwendungen nicht dieser Einschränkung. Verwenden Sie nicht den HTTP-Parameter `SessionDuration`, wenn Sie temporäre Anmeldeinformationen über Rollenverkettung abrufen. Der Vorgang schlägt fehl. 1. Geben Sie die URL an den Benutzer weiter oder rufen Sie sie im Namen des Benutzers auf. Die vom Verbund-Endpunkt bereitgestellte URL ist 15 Minuten lang gültig, nachdem sie erstellt wurde. Dies unterscheidet sich von der Dauer (in Sekunden) der Sitzung mit temporären Sicherheitsanmeldeinformationen, die mit der URL verbunden ist. Diese Anmeldeinformationen sind für die Dauer gültig, die Sie beim Erstellen angegeben haben, beginnend ab dem Zeitpunkt der Erstellung. **Wichtig** Die URL gewährt Zugriff auf Ihre AWS Ressourcen über die, AWS-Managementkonsole sofern Sie in den zugehörigen temporären Sicherheitsanmeldedaten die entsprechenden Berechtigungen aktiviert haben. Aus diesem Grund sollten Sie die URL geheim halten. Wir empfehlen, die URL über eine sichere Umleitung zurückzugeben, z. B. mittels eines HTTP-Antwortstatuscodes 302 über eine SSL-Verbindung. Weitere Informationen über den HTTP-Antwortstatuscode 302 finden Sie unter [RFC 2616, section 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3). Um diese Aufgaben zu erledigen, können Sie die [HTTPS Query API für AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) und die [AWS -Security-Token-Service (AWS STS) verwenden](https://docs.aws.amazon.com/STS/latest/APIReference/). Sie können aber auch Programmiersprachen, wie Java, Ruby oder C\$1, zusammen mit dem entsprechenden [AWS -SDK](https://aws.amazon.com/tools/), verwenden. Jede dieser Methoden wird in den folgenden Themen beschrieben. **Topics** + [ ## Beispielcode unter Verwendung von IAM-Abfrage-API-Operationen ](#STSConsoleLink_manual) + [ ## Beispielcode unter Verwendung von Python ](#STSConsoleLink_programPython) + [ ## Beispielcode unter Verwendung von Java ](#STSConsoleLink_programJava) + [ ## Beispiel für das Erstellen einer URL (Ruby) ](#STSConsoleLink_programRuby) ## Beispielcode unter Verwendung von IAM-Abfrage-API-Operationen Sie können eine URL erstellen, die Rollen und Verbundprinzipalen direkten Zugriff auf die AWS-Managementkonsole gewährt. Diese Aufgabe verwendet die IAM- und AWS STS HTTPS-Abfrage-API. Weitere Informationen zum Erstellen von Abfrageanforderungen finden Sie unter [Erstellen von Abfrageanforderungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html). **Anmerkung** Das folgende Verfahren enthält Beispiele für Textzeichenfolgen. Zur Erhöhung der Lesbarkeit wurden Zeilenumbrüche zu einigen der längeren Beispiele hinzugefügt. Wenn Sie diese Zeichenfolgen zur eigenen Verwendung erstellen, sollten Sie keine Zeilenumbrüche setzen. **Um Rollen und Verbundprinzipalen Zugriff auf Ihre Ressourcen zu gewähren AWS-Managementkonsole** 1. Authentifizieren Sie den Benutzer in Ihrem Identitäts- und Autorisierungssystem. 1. Rufen Sie temporäre Sicherheitsanmeldeinformationen für den Benutzer ab. Die temporären Anmeldeinformationen bestehen aus einer Zugriffsschlüssel-ID, einem geheimen Zugriffsschlüssel und einem Sitzungs-Token. Weitere Informationen über das Erstellen temporärer Anmeldeinformationen finden Sie unter [Temporäre IAM Sicherheitsanmeldeinformationen](id_credentials_temp.md). Um temporäre Anmeldeinformationen zu erhalten, rufen Sie entweder die AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API (empfohlen) oder die [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API auf. Weitere Informationen zu den Unterschieden zwischen diesen API-Vorgängen finden Sie im AWS Sicherheitsblog unter [Grundlegendes zu den API-Optionen für die sichere Delegierung des Zugriffs auf Ihr AWS Konto](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account). **Wichtig** Wenn Sie die [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API verwenden, um temporäre Sicherheitsanmeldedaten zu erstellen, müssen Sie die Berechtigungen angeben, die die Anmeldeinformationen dem Benutzer gewähren, der die Rolle übernimmt. Für alle API-Operationen, die mit `AssumeRole*` beginnen, verwenden Sie eine IAM-Rolle, um Berechtigungen zuzuweisen. Für die anderen API-Operationen hängt der Mechanismus von der API ab. Weitere Details finden Sie unter [Berechtigungen für temporäre Sicherheits-Anmeldeinformationen](id_credentials_temp_control-access.md). Wenn Sie die `AssumeRole*`-API-Operationen verwenden, müssen Sie sie außerdem als IAM-Benutzer mit langfristigen Anmeldeinformationen aufrufen. Andernfalls schlägt der Aufruf des Verbund-Endpunkts in Schritt 3 fällt. 1. Nachdem Sie die temporären Sicherheitsanmeldeinformationen abgerufen haben, integrieren Sie sie in eine JSON-Sitzungs-Zeichenfolge, um sie geben ein Anmelde-Token zu tauschen. Im folgenden Beispiel wird gezeigt, wie Sie die Anmeldeinformationen codieren. Ersetzen Sie den Platzhaltertext durch die entsprechenden Werte aus den Anmeldeinformationen, die Sie im vorherigen Schritt erhalten haben. ``` {"sessionId":"*** temporary access key ID ***", "sessionKey":"*** temporary secret access key ***", "sessionToken":"*** session token ***"} ``` 1. Führen Sie eine [URL-Codierung](https://en.wikipedia.org/wiki/Percent-encoding) der Sitzungs-Zeichenfolge aus dem vorherigen Schritt durch. Da die Informationen, die Sie codieren, sensibel sind, raten wir davon ab, einen Webservice für diese Codierung zu verwenden. Verwenden Sie stattdessen ein lokal installiertes Feature in Ihrem Entwicklungs-Toolkits, um diese Informationen sicher zu codieren. Sie können die Funktion `urllib.quote_plus` in Python, die Funktion `URLEncoder.encode`in Java oder die Funktion `CGI.escape` in Ruby verwenden. Beispiele finden Sie an späterer Stelle in diesem Thema. 1. **Anmerkung** AWS unterstützt hier POST-Anfragen. Senden Sie Ihre Anfrage an den AWS Föderationsendpunkt: `https://region-code.signin.aws.amazon.com/federation` Eine Liste möglicher *region-code* Werte finden Sie in der Spalte **Region** unter [AWS Anmelde-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Sie können optional den standardmäßigen AWS Anmeldendpunkt für den Verbund verwenden: `https://signin.aws.amazon.com/federation` Die Anforderung muss die `Action`- und `Session`-Parameter enthalten und (optional) – wenn Sie eine [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)-API-Operation verwendet haben – einen `SessionDuration`-HTTP-Parameter, wie im folgenden Beispiel gezeigt. ``` Action = getSigninToken SessionDuration = time in seconds Session = *** the URL encoded JSON string created in steps 3 & 4 *** ``` **Anmerkung** Die folgenden Anweisungen in diesem Schritt funktionieren nur mithilfe von GET-Anforderungen. Der `SessionDuration`-HTTP-Parameter gibt die Dauer der Konsolensitzung an. Dies ist von der Dauer der temporären Anmeldeinformationen, die Sie mit dem `DurationSeconds`-Parameter angeben, unabhängig. Sie können für `SessionDuration` einen maximalen Wert von 43200 (12 Stunden) festlegen. Wenn der `SessionDuration` Parameter fehlt, wird für die Sitzung standardmäßig die Dauer der Anmeldeinformationen verwendet, die Sie AWS STS in Schritt 2 abgerufen haben (standardmäßig eine Stunde). Details zur Festlegung der Dauer unter Verwendung des Parameters `DurationSeconds` finden Sie in der [-Dokumentation für die `AssumeRole`-API](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html). Die Möglichkeit zum Erstellen einer Konsolensitzung, die länger als eine Stunde dauert, ist eine intrinsische `getSigninToken`-Operation des Verbund-Endpunkts. **Anmerkung** Ihr `SessionDuration` darf nicht größer oder gleich der Einstellung für die maximale Sitzungsdauer für die von Ihnen übernommene Rolle sein. Sie haben beispielsweise die maximale Sitzungsdauer für die Rolle, die Sie übernehmen möchten, auf 5 Stunden festgelegt. Ihr `SessionDuration`-Parameter kann 16 524 Sekunden oder 4 Stunden und 59 Sekunden betragen. Verwenden Sie nicht den HTTP-Parameter `SessionDuration`, wenn Sie temporäre Anmeldeinformationen mit `GetFederationToken` abrufen. Der Vorgang schlägt fehl. Die Verwendung der Anmeldeinformationen für eine Rolle zur Übernahme einer anderen Rolle wird als [*Verketten von Rollen*](id_roles.md#iam-term-role-chaining) bezeichnet. Wenn Sie die Verkettung von Rollen verwenden, sind Ihre neuen Anmeldeinformationen auf eine maximale Dauer von einer Stunde begrenzt. Wenn Sie Rollen verwenden, um [Berechtigungen für Anwendungen zu erteilen, die auf EC2-Instances ausgeführt werden](id_roles_use_switch-role-ec2.md), unterliegen diese Anwendungen nicht dieser Einschränkung. Verwenden Sie nicht den HTTP-Parameter `SessionDuration`, wenn Sie temporäre Anmeldeinformationen über Rollenverkettung abrufen. Der Vorgang schlägt fehl. Wenn Sie Konsolensitzungen mit einer erweiterten Dauer aktivieren, erhöhen Sie das Risiko einer Aufdeckung der Anmeldeinformationen. Um dieses Risiko zu minimieren, können Sie die aktiven Konsolensitzungen für jede Rolle direkt deaktivieren, indem Sie **Revoke Sessions** (Sitzungen aufheben) auf der Seite **Role Summary** (Rollenübersicht) in der IAM-Konsole wählen. Weitere Informationen finden Sie unter [Temporäre Sicherheitsanmeldeinformationen der IAM-Rolle widerrufen](id_roles_use_revoke-sessions.md). Das folgende Beispiel zeigt, wie die Anforderung aussehen kann. Die Zeilen sind hier für bessere Lesbarkeit gebrochen, die Zeichenfolge sollte aber in einer Zeile übermittelt werden. ``` https://signin.aws.amazon.com/federation ?Action=getSigninToken &SessionDuration=1800 &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22 %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2 2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8 FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5 PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D ``` Die Antwort des Verbund-Endpunkts ist ein JSON-Dokument mit einem `SigninToken`-Wert. Er sollte wie im folgenden Beispiel aussehen. ``` {"SigninToken":"*** the SigninToken string ***"} ``` 1. **Anmerkung** AWS unterstützt hier POST-Anfragen. Schließlich erstellen Sie die URL, die Ihre Benutzer für den Zugriff auf die AWS-Managementkonsole verwenden können. Die URL ist derselbe Verbund-URL-Endpunkt, den Sie in [Step 5](#STSConsoleLink_manual_step5) verwendet haben, plus die folgenden Parameter: ``` ?Action = login &Issuer = *** the form-urlencoded URL for your internal sign-in page *** &Destination = *** the form-urlencoded URL to the desired AWS console page *** &SigninToken = *** the value of SigninToken received in the previous step *** ``` **Anmerkung** Die folgenden Anweisungen in diesem Schritt funktionieren nur mithilfe von GET-API. Das folgende Beispiel zeigt, wie die endgültige URL aussehen könnte. Die URL ist ab dem Zeitpunkt, zu dem sie erstellt wurde, 15 Minuten lang gültig. Die temporären Sicherheitsanmeldeinformationen und die in der URL eingebettete Konsolensitzung ist für die Dauer gültig, die Sie bei der ersten Anforderung im `SessionDuration`-HTTP-Parameter angegeben haben. ``` https://signin.aws.amazon.com/federation ?Action=login &Issuer=https%3A%2F%2Fexample.com &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1 WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u 3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv 9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm 0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC RNhujg ``` ## Beispielcode unter Verwendung von Python Das folgende Beispiel zeigt, wie Sie mit Python programmgesteuert eine URL erstellen können, die Benutzern direkten Zugriff auf die AWS-Managementkonsole gewährt. Es gibt zwei Beispiele: + Föderieren Sie über GET-Anfragen an AWS + Verbinden Sie sich über POST-Anfragen an AWS Beide Beispiele verwenden die [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API [AWS SDK für Python (Boto3)](https://aws.amazon.com/tools/)und, um temporäre Sicherheitsanmeldedaten abzurufen. Geben Sie `SessionDuration` nicht an, wenn Ihre `AssumeRoleSession`-Anmeldeinformationen aus einer Rollenverkettung stammen. Wenn Sie `SessionDuration` angeben, schlägt der Vorgang fehl. ### GET-Anforderungen verwenden ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your AWS-Konto, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = "?Action=getSigninToken" request_parameters += "&SessionDuration=43200" if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials) request_url = "https://signin.aws.amazon.com/federation" + request_parameters r = requests.get(request_url) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create URL where users can use the sign-in token to sign in to # the console. This URL must be used within 15 minutes after the # sign-in token was issued. request_parameters = "?Action=login" request_parameters += "&Issuer=Example.org" request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/") request_parameters += "&SigninToken=" + signin_token["SigninToken"] request_url = "https://signin.aws.amazon.com/federation" + request_parameters # Send final URL to stdout print (request_url) ``` ### GET-Anforderungen verwenden ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' import os from selenium import webdriver # 'pip install selenium', 'brew install chromedriver' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your A AWS-Konto, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleDemoSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = {} request_parameters['Action'] = 'getSigninToken' request_parameters['SessionDuration'] = '43200' request_parameters['Session'] = json_string_with_temp_credentials request_url = "https://signin.aws.amazon.com/federation" r = requests.post( request_url, data=request_parameters) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create a POST request where users can use the sign-in token to sign in to # the console. The POST request must be made within 15 minutes after the # sign-in token was issued. request_parameters = {} request_parameters['Action'] = 'login' request_parameters['Issuer']='Example.org' request_parameters['Destination'] = 'https://console.aws.amazon.com/' request_parameters['SigninToken'] =signin_token['SigninToken'] jsrequest = ''' var form = document.createElement('form'); form.method = 'POST'; form.action = '{request_url}'; request_parameters = {request_parameters} for (var param in request_parameters) {{ if (request_parameters.hasOwnProperty(param)) {{ const hiddenField = document.createElement('input'); hiddenField.type = 'hidden'; hiddenField.name = param; hiddenField.value = request_parameters[param]; form.appendChild(hiddenField); }} }} document.body.appendChild(form); form.submit(); '''.format(request_url=request_url, request_parameters=request_parameters) driver = webdriver.Chrome() driver.execute_script(jsrequest) input("Press Enter to close the browser window...") ``` ## Beispielcode unter Verwendung von Java Das folgende Beispiel zeigt, wie Sie mit Java programmgesteuert eine URL erstellen können, die Benutzern direkten Zugriff auf die AWS-Managementkonsole gewährt. Das folgende Codefragment verwendet das [AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/). ``` import java.net.URLEncoder; import java.net.URL; import java.net.URLConnection; import java.io.BufferedReader; import java.io.InputStreamReader; // Available at http://www.json.org/java/index.html import org.json.JSONObject; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.BasicAWSCredentials; import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient; import com.amazonaws.services.securitytoken.model.Credentials; import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest; import com.amazonaws.services.securitytoken.model.GetFederationTokenResult; /* Calls to AWS STS API operations must be signed using the access key ID and secret access key of an IAM user or using existing temporary credentials. The credentials should not be embedded in code. For this example, the code looks for the credentials in a standard configuration file. */ AWSCredentials credentials = new PropertiesCredentials( AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties")); AWSSecurityTokenServiceClient stsClient = new AWSSecurityTokenServiceClient(credentials); GetFederationTokenRequest getFederationTokenRequest = new GetFederationTokenRequest(); getFederationTokenRequest.setDurationSeconds(1800); getFederationTokenRequest.setName("UserName"); // A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console. String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," + "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}"; getFederationTokenRequest.setPolicy(policy); GetFederationTokenResult federationTokenResult = stsClient.getFederationToken(getFederationTokenRequest); Credentials federatedCredentials = federationTokenResult.getCredentials(); // The issuer parameter specifies your internal sign-in // page, for example https://mysignin.internal.mycompany.com/. // The console parameter specifies the URL to the destination console of the // AWS Management Console. This example goes to Amazon SNS. // The signin parameter is the URL to send the request to. String issuerURL = "https://mysignin.internal.mycompany.com/"; String consoleURL = "https://console.aws.amazon.com/sns"; String signInURL = "https://signin.aws.amazon.com/federation"; // Create the sign-in token using temporary credentials, // including the access key ID, secret access key, and session token. String sessionJson = String.format( "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}", "sessionId", federatedCredentials.getAccessKeyId(), "sessionKey", federatedCredentials.getSecretAccessKey(), "sessionToken", federatedCredentials.getSessionToken()); // Construct the sign-in request with the request sign-in token action, a // 12-hour console session duration, and the JSON document with temporary // credentials as parameters. String getSigninTokenURL = signInURL + "?Action=getSigninToken" + "&DurationSeconds=43200" + "&SessionType=json&Session=" + URLEncoder.encode(sessionJson,"UTF-8"); URL url = new URL(getSigninTokenURL); // Send the request to the AWS federation endpoint to get the sign-in token URLConnection conn = url.openConnection (); BufferedReader bufferReader = new BufferedReader(new InputStreamReader(conn.getInputStream())); String returnContent = bufferReader.readLine(); String signinToken = new JSONObject(returnContent).getString("SigninToken"); String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8"); // The issuer parameter is optional, but recommended. Use it to direct users // to your sign-in page when their session expires. String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8"); // Finally, present the completed URL for the AWS console session to the user String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8"); String loginURL = signInURL + "?Action=login" + signinTokenParameter + issuerParameter + destinationParameter; ``` ## Beispiel für das Erstellen einer URL (Ruby) Das folgende Beispiel zeigt, wie Sie mit Ruby programmgesteuert eine URL erstellen können, die Benutzern direkten Zugriff auf die AWS-Managementkonsole gewährt. Dieses Codefragment verwendet das [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/). ``` require 'rubygems' require 'json' require 'open-uri' require 'cgi' require 'aws-sdk' # Create a new STS instance # # Note: Calls to AWS STS API operations must be signed using an access key ID # and secret access key. The credentials can be in EC2 instance metadata # or in environment variables and will be automatically discovered by # the default credentials provider in the AWS Ruby SDK. sts = Aws::STS::Client.new() # The following call creates a temporary session that returns # temporary security credentials and a session token. # The policy grants permissions to work # in the AWS SNS console. session = sts.get_federation_token({ duration_seconds: 1800, name: "UserName", policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}", }) # The issuer value is the URL where users are directed (such as # to your internal sign-in page) when their session expires. # # The console value specifies the URL to the destination console. # This example goes to the Amazon SNS console. # # The sign-in value is the URL of the AWS STS federation endpoint. issuer_url = "https://mysignin.internal.mycompany.com/" console_url = "https://console.aws.amazon.com/sns" signin_url = "https://signin.aws.amazon.com/federation" # Create a block of JSON that contains the temporary credentials # (including the access key ID, secret access key, and session token). session_json = { :sessionId => session.credentials[:access_key_id], :sessionKey => session.credentials[:secret_access_key], :sessionToken => session.credentials[:session_token] }.to_json # Call the federation endpoint, passing the parameters # created earlier and the session information as a JSON block. # The request returns a sign-in token that's valid for 15 minutes. # Signing in to the console with the token creates a session # that is valid for 12 hours. get_signin_token_url = signin_url + "?Action=getSigninToken" + "&SessionType=json&Session=" + CGI.escape(session_json) returned_content = URI.parse(get_signin_token_url).read # Extract the sign-in token from the information returned # by the federation endpoint. signin_token = JSON.parse(returned_content)['SigninToken'] signin_token_param = "&SigninToken=" + CGI.escape(signin_token) # Create the URL to give to the user, which includes the # sign-in token and the URL of the console to open. # The "issuer" parameter is optional but recommended. issuer_param = "&Issuer=" + CGI.escape(issuer_url) destination_param = "&Destination=" + CGI.escape(console_url) login_url = signin_url + "?Action=login" + signin_token_param + issuer_param + destination_param ```