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. # IAM-Tutorial: Delegieren Sie den Zugriff über AWS Konten hinweg mithilfe von IAM-Rollen **Wichtig** [Bewährte IAM-Methoden](best-practices.md) empfehlen, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um mit temporären Anmeldeinformationen zuzugreifen AWS , anstatt IAM-Benutzer mit langfristigen Anmeldeinformationen zu verwenden. Wir empfehlen, IAM-Benutzer nur für [bestimmte Anwendungsfälle](gs-identities-iam-users.md) zu verwenden, die nicht von Verbundbenutzern unterstützt werden. In diesem Tutorial erfahren Sie, wie Sie mithilfe einer Rolle den Zugriff auf Ressourcen in verschiedenen AWS-Konten mit dem Namen **Ziel** und **Ursprung** delegieren. Sie teilen Ressourcen in einem Konto mit Benutzern in einem anderen Konto. Indem Sie auf diese Weise den kontoübergreifenden Zugriff einrichten, müssen Sie keine einzelnen IAM-Benutzer in jedem Konto erstellen. Darüber hinaus müssen sich Benutzer nicht von einem Konto abmelden und bei einem anderen Konto anmelden, um auf Ressourcen in unterschiedlichen AWS-Konten zuzugreifen. Nach der Konfiguration der Rolle erfahren Sie, wie Sie die Rolle über die AWS-Managementkonsole AWS CLI, und die API verwenden. In diesem Tutorial verwaltet das **Zielkonto** Anwendungsdaten, auf die von verschiedenen Anwendungen und Teams zugegriffen wird. In jedem Konto werden Anwendungsinformationen in Amazon-S3-Buckets gespeichert. Sie verwalten IAM-Benutzer im **Ursprungskonto**, wo Sie über zwei IAM-Benutzerrollen verfügen: **Entwickler** und **Analysten**. Entwickler und Analysten verwenden das **Ursprungskonto**, um Daten zu generieren, die von mehreren Microservices gemeinsam genutzt werden. Beide Rollen verfügen über die Berechtigung, im Ursprungskonto zu arbeiten und dort auf Ressourcen zuzugreifen. Von Zeit zu Zeit muss ein Entwickler die freigegebenen Daten im **Zielkonto** aktualisieren. Die Entwickler speichern diese Daten in einem Amazon S3-Bucket mit dem Namen `amzn-s3-demo-bucket-shared-container`. Am Ende dieses Tutorials ist Folgendes verfügbar: + Benutzer im **Ursprungskonto** (dem vertrauenswürdigen Konto) dürfen eine bestimmte Rolle im **Zielkonto** übernehmen. + Eine Rolle im **Zielkonto** (dem vertrauenswürdigen Konto), die den Zugriff auf einen bestimmten Amazon-S3-Bucket ermöglicht. + Der Bucket `amzn-s3-demo-bucket-shared-container` im **Zielkonto**. Entwickler können die Rolle in verwenden AWS-Managementkonsole , um auf den `amzn-s3-demo-bucket-shared-container` Bucket im **Zielkonto** zuzugreifen. Sie können auf den Bucket auch mithilfe von API-Aufrufen zugreifen, die anhand von der Rolle bereitgestellten temporären Anmeldeinformationen authentifiziert werden. Ähnliche Versuche eines Analysten, die Rolle zu verwenden, schlagen fehl. Dieser Workflow umfasst drei grundlegende Schritte: **[Rolle im Zielkonto erstellen](#tutorial_cross-account-with-roles-1)** Zunächst verwenden Sie den, AWS-Managementkonsole um eine Vertrauensstellung zwischen dem **Zielkonto** (ID-Nummer 9999999999) und dem ursprünglichen Konto (ID-Nummer **111111111111**) herzustellen. Sie erstellen *UpdateData*zunächst eine IAM-Rolle mit dem Namen. Wenn Sie die Rolle erstellen, definieren Sie das **Ursprungskonto** als vertrauenswürdige Entität und geben eine Berechtigungsrichtlinie an, die es vertrauenswürdigen Benutzern ermöglicht, den Bucket `amzn-s3-demo-bucket-shared-container` zu aktualisieren. **[Erteilen der Zugriffsberechtigung auf die Rolle](#tutorial_cross-account-with-roles-2)** In diesem Abschnitt ändern Sie die Rollenrichtlinie, um Analysten den Zugriff auf die `UpdateData`-Rolle zu verweigern. Weil Analysten in diesem Szenario PowerUser Zugriff haben und Sie die Nutzung der Rolle ausdrücklich *verweigern* müssen. **[Testen des Zugriffs durch Rollenwechsel](#tutorial_cross-account-with-roles-3)** Schließlich verwenden Sie als Entwickler die `UpdateData`-Rolle, um den Bucket `amzn-s3-demo-bucket-shared-container` im **Zielkonto** zu aktualisieren. Sie erfahren, wie Sie über die AWS Konsole, die und die AWS CLI API auf die Rolle zugreifen können. ## Überlegungen Bevor Sie IAM-Rollen verwenden, um den Ressourcenzugriff an andere zu delegieren AWS-Konten, müssen Sie Folgendes beachten: + Sie können nicht zu einer Rolle wechseln, wenn Sie sich als Root-Benutzer des AWS-Kontos anmelden. + IAM-Rollen und ressourcenbasierte Richtlinien delegieren den Zugriff auf Konten nur innerhalb einer einzelnen Partition. Nehmen wir zum Beispiel an, Sie haben ein Konto in US West (Nordkalifornien) in der Standardpartition `aws`. Sie haben auch ein Konto in China (Peking) in der `aws-cn`-Partition. Sie können keine ressourcenbasierte Amazon S3-Richtlinie in Ihrem Konto in China (Peking) verwenden, um Benutzern in Ihrem Standard-`aws`-Konto den Zugriff zu ermöglichen. + Sie können dies verwenden AWS IAM Identity Center , um Single Sign-On (SSO) für externe AWS-Konten (Konten außerhalb Ihres) mithilfe von Security Assertion Markup Language (SAML AWS Organizations) zu vereinfachen. Weitere Informationen finden Sie unter [Integrieren von extern AWS-Konten in eine AWS IAM Identity Center zentrale Zugriffsverwaltung mit unabhängiger](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en) Abrechnung mithilfe von SAML 2.0 + Sie können Rollen AWS Ressourcen wie Amazon EC2 EC2-Instances oder AWS Lambda Funktionen zuordnen. Details hierzu finden Sie unter [Erstellen Sie eine Rolle, um Berechtigungen an einen AWS Dienst zu delegieren](id_roles_create_for-service.md). + Wenn Sie möchten, dass eine Anwendung eine Rolle in einer anderen übernimmt AWS-Konto, können Sie das AWS SDK für die kontoübergreifende Rollenübernahme verwenden. Weitere Informationen finden Sie unter [Authentifizierung und Zugriff](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) im *AWS SDKs Referenzhandbuch zu Tools*. + Das Wechseln von Rollen mithilfe von funktioniert AWS-Managementkonsole nur mit Konten, für die kein Konto erforderlich ist`ExternalId`. Nehmen wir an, dass Sie Dritten Zugriff auf Ihr Konto gewähren und eine `ExternalId` in einem `Condition`-Element in Ihrer Berechtigungsrichtlinie benötigen. In diesem Fall kann der Drittanbieter nur mithilfe der AWS API oder eines Befehlszeilentools auf Ihr Konto zugreifen. Der Drittanbieter kann die Konsole nicht verwenden, da er einen Wert für `ExternalId` angeben muss. Weitere Informationen zu diesem Szenario finden Sie unter [Zugriff auf AWS-Konten Eigentum Dritter](id_roles_common-scenarios_third-party.md) und [So aktivieren Sie den kontoübergreifenden Zugriff auf den AWS-Managementkonsole](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) im AWS Sicherheitsblog. ## Voraussetzungen In diesem Tutorial wird davon ausgegangen, dass Folgendes bereits vorhanden ist: + **Zwei** separate Konten, AWS-Konten die Sie verwenden können, eines zur Darstellung **des ursprünglichen** Kontos und eines zur Darstellung des **Zielkontos**. + Benutzer und Rollen im **Ursprungskonto** wurden wie folgt erstellt und konfiguriert: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) + Sie müssen im **Zielkonto** keine Benutzer erstellen. + Ein im **Zielkonto** erstellter Amazon-S3-Bucket. In diesem Tutorial nennen wir dies `amzn-s3-demo-bucket-shared-container`, S3-Bucket-Namen sind jedoch global eindeutig, daher müssen Sie einen Bucket mit einem anderen Namen verwenden. ## Rolle im Zielkonto erstellen Sie können Benutzern von einem Konto AWS-Konto den Zugriff auf Ressourcen in einem anderen ermöglichen AWS-Konto. In diesem Tutorial tun wir dies, indem wir eine Rolle erstellen, die definiert, wer darauf zugreifen kann und welche Berechtigungen sie den Benutzern gewährt, die dorthin wechseln. In diesem Schritt des Tutorials erstellen Sie die Rolle im **Zielkonto** und geben das **Ursprungskonto** als vertrauenswürdige Entität an. Außerdem beschränken Sie die Berechtigungen der Rolle auf den Lese- und Schreibzugriff auf den Bucket `amzn-s3-demo-bucket-shared-container`. Jeder Benutzer, dem die Berechtigung zur Verwendung der Rolle erteilt wird, kann auf dem Bucket `shared-container` Lese- und Schreibvorgänge ausführen. Bevor Sie eine Rolle erstellen können, benötigen Sie die *Konto-ID* des **Originators** AWS-Konto. Jedem AWS-Konto ist eine eindeutige Konto-ID-ID zugewiesen. **Um die ursprüngliche AWS-Konto ID zu erhalten** 1. Melden Sie sich AWS-Managementkonsole als Administrator des **ursprünglichen Kontos an** und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Wählen Sie in der IAM-Konsole rechts oben auf der Navigationsleiste den Benutzernamen. Normalerweise sieht es so aus: ***username*@ *account\$1ID\$1number\$1or\$1alias***. Für dieses Szenario können Sie die Konto-ID 111111111111 für das **Ursprungskonto** verwenden. Sie sollten jedoch eine gültige Konto-ID verwenden, wenn Sie das Szenario in Ihrer Testumgebung rekonstruieren. **So erstellen Sie eine Rolle im Zielkonto, die vom Ursprungskonto verwendet werden kann** 1. Melden Sie sich AWS-Managementkonsole als Administrator des **Zielkontos** an und öffnen Sie die IAM-Konsole. 1. Bevor Sie die Rolle erstellen, richten Sie die verwaltete Richtlinie ein, die die von der Rolle benötigten Berechtigungen definiert. Diese Richtlinie fügen Sie zu einem späteren Zeitpunkt der Rolle an. Sie möchten Lese- und Schreibberechtigungen für den Bucket `amzn-s3-demo-bucket-shared-container` erteilen. Es AWS gibt zwar einige verwaltete Amazon S3 S3-Richtlinien, aber es gibt keine, die Lese- und Schreibzugriff auf einen einzelnen Amazon S3 S3-Bucket bietet. Sie können aber Ihre eigene Richtlinie erstellen. Wählen Sie im Navigationsbereich **Policies (Richtlinien)** und dann **Create policy (Richtlinie erstellen)** aus. 1. Wählen Sie die Registerkarte **JSON** aus und kopieren Sie den Text aus dem folgenden JSON-Richtliniendokument. Fügen Sie den Text in das Textfeld **JSON** ein und ersetzen Sie dabei den Ressourcen-ARN (`arn:aws:s3:::shared-container`) durch den passenden ARN für Ihren Amazon-S3-Bucket. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*" } ] } ``` ------ Die Aktion `ListAllMyBuckets` gewährt die Berechtigung zum Auflisten aller Buckets, die dem authentifizierten Sender der Anforderung gehören. Die Berechtigung `ListBucket` ermöglicht den Benutzern, Objekte im Bucket `amzn-s3-demo-bucket-shared-container` anzuzeigen. Die Berechtigungen `GetObject`, `PutObject` und `DeleteObject` ermöglichen den Benutzern, Inhalte im Bucket `amzn-s3-demo-bucket-shared-container` anzuzeigen, zu aktualisieren und zu löschen. **Anmerkung** Sie können jederzeit zwischen den Editoroptionen **Visual** und **JSON** wechseln. Wenn Sie jedoch Änderungen vornehmen oder im **Visual**-Editor **Next** (Weiter) wählen, strukturiert IAM Ihre Richtlinie möglicherweise um, um sie für den visuellen Editor zu optimieren. Weitere Informationen finden Sie unter [Umstrukturierung einer Richtlinie](troubleshoot_policies.md#troubleshoot_viseditor-restructure). 1. Geben Sie auf der Seite **Review and create** (Überprüfen und erstellen) als Richtliniennamen **read-write-app-bucket** ein. Überprüfen Sie die von ihrer Richtlinie erteilten Berechtigungen und wählen Sie dann zum Speichern Ihrer Arbeit **Create policy** (Richtlinie erstellen) aus. Die neue Richtlinie wird in der Liste der verwalteten Richtlinien angezeigt. 1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**. 1. Wählen Sie den Rollentyp ** AWS-Konto**. 1. Geben Sie als **Konto-ID** die ID des **Ursprungskontos** ein. In diesem Tutorial wird die Beispiel-Konto-ID **111111111111** für das **Ursprungskonto** verwendet. Verwenden Sie eine gültige Konto-ID. Wenn Sie eine ungültige Konto-ID verwenden, wie z. B. **111111111111**, lässt Sie IAM keine neue Rolle erstellen. Zu diesem Zeitpunkt benötigen Sie jedoch noch keine externe ID und müssen keine Multi-Faktor-Authentifizierung (MFA) von den Benutzern verlangen, um die Rolle zu übernehmen. Wählen Sie daher diese Option nicht. Weitere Informationen finden Sie unter [AWS Multi-Faktor-Authentifizierung in IAM](id_credentials_mfa.md). 1. Wählen Sie **Next: Permissions (Weiter: Berechtigungen)** aus, um die mit der Rolle verknüpften Berechtigungen einzurichten. 1. Aktivieren Sie das Kontrollkästchen neben der Richtlinie, die Sie zuvor erstellt haben. **Tipp** Klicken Sie bei **Filter** auf **Customer managed (Benutzerdefiniert)**, um nur die von Ihnen erstellten Richtlinien anzuzeigen. Dadurch werden die von AWS erstellten Richtlinien ausgeblendet und Ihnen wird das Auffinden der gesuchten Richtlinie erleichtert. Wählen Sie anschließend **Weiter**. 1. (Optional) Fügen Sie der Rolle Metadaten hinzu, indem Sie Tags als Schlüssel-Wert-Paare anfügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](id_tags.md). 1. (Optional) Geben Sie unter **Role description** (Rollenbeschreibung) eine Beschreibung für die neue Rolle ein. 1. Nachdem Sie die Rolle überprüft haben, klicken Sie auf **Create role (Rolle erstellen)**. Die Rolle `UpdateData` erscheint in der Liste der Rollen. Jetzt müssen Sie den Amazon-Ressourcennamen (ARN) ermitteln. Dabei handelt es sich um eine eindeutige Kennung der Rolle. Wenn Sie die Entwicklerrolle im Ursprungskonto ändern, geben Sie die Rollen-ARN aus dem Zielkonto an, um Berechtigungen zu gewähren oder zu verweigern. **Um den ARN zu erhalten für UpdateData** 1. Wählen Sie im Navigationsbereich der IAM Console **Roles**. 1. Wählen Sie in der Rollenliste die Rolle `UpdateData`. 1. Im Abschnitt **Summary (Übersicht)** im Detailbereich kopieren Sie den Wert **Role ARN (Rollen-ARN)**. Das Zielkonto hat die Konto-ID 999999999999, daher ist der Rollen-ARN `arn:aws:iam::999999999999:role/UpdateData`. Stellen Sie sicher, dass Sie die echte AWS-Konto ID für das Zielkonto angeben. An diesem Punkt haben Sie eine Vertrauensbeziehung zwischen dem **Ziel-** und dem **Ursprungskonto** hergestellt. Sie haben dies getan, indem Sie im **Zielkonto** eine Rolle erstellt haben, die das **Ursprungskonto** als vertrauenswürdigen Prinzipal identifiziert. Sie haben auch definiert, was die Benutzer tun dürfen, die in die `UpdateData`-Rolle wechseln. Ändern Sie als Nächstes die Berechtigungen für die Entwicklerrolle. ## Erteilen der Zugriffsberechtigung auf die Rolle Zu diesem Zeitpunkt verfügen sowohl Analysten als auch Entwickler über Berechtigungen, die es ihnen ermöglichen, Daten im **Ursprungskonto** zu verwalten. Nachstehend werden die erforderlichen Schritte zum Hinzufügen von Berechtigungen beschrieben, um zur Rolle zu wechseln. **Um die Entwicklerrolle so zu ändern, dass sie zur UpdateData Rolle wechseln können** 1. Melden Sie sich als Administrator im **Ursprungskonto** an und öffnen Sie die IAM-Konsole. 1. Wählen Sie **Rollen** und dann **Entwickler** aus. 1. Wählen Sie die Registerkarte **Berechtigungen**, wählen Sie **Berechtigungen hinzufügen** und wählen Sie dann **Inline-Richtlinie** erstellen. 1. Wählen Sie den Tab **JSON**. 1. Fügen Sie die folgende Richtlinienanweisung hinzu, um die Aktion `AssumeRole` für die Rolle `UpdateData` im Zielkonto zuzulassen. Stellen Sie sicher, dass Sie das `Resource` Element auf die tatsächliche AWS-Konto ID des Zielkontos ändern*DESTINATION-ACCOUNT-ID*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/UpdateData" } } ``` ------ Der Effekt `Allow` gewährt der Entwickler-Gruppe explizit den Zugriff auf die Rolle `UpdateData` im Zielkonto. Alle Entwickler können problemlos auf die Rolle zugreifen. 1. Wählen Sie **Richtlinie prüfen**. 1. Geben Sie einen **Namen** ein, z. B. **allow-assume-S3-role-in-destination**. 1. Wählen Sie **Richtlinie erstellen** aus. In den meisten Umgebungen ist folgende Vorgehensweise wahrscheinlich nicht erforderlich. Wenn Sie jedoch PowerUserAccess Berechtigungen verwenden, können einige Gruppen möglicherweise bereits die Rollen wechseln. Das folgende Verfahren zeigt, wie Sie der Gruppe „Analysten“ eine `"Deny"`-Berechtigung hinzufügen, um sicherzustellen, dass sie die Rolle nicht übernehmen können. Wenn dieses Verfahren in Ihrer Umgebung nicht benötigt wird, empfehlen wir Ihnen, es nicht hinzuzufügen. `"Deny"`-Berechtigungen machen die Verwaltung und das Verständnis der gesamten Berechtigungsstruktur komplizierter. Verwenden Sie `"Deny"`-Berechtigungen nur, wenn es keine bessere Option gibt. **So ändern Sie die Rolle des Analysten, um die Berechtigung zum Übernehmen der Rolle `UpdateData` zu verweigern** 1. Wählen Sie **Rollen** und dann **Analysten** aus. 1. Wählen Sie die Registerkarte **Berechtigungen**, wählen Sie **Berechtigungen hinzufügen** und wählen Sie dann **Inline-Richtlinie** erstellen. 1. Wählen Sie den Tab **JSON**. 1. Fügen Sie die folgende Richtlinienanweisung hinzu, um die Aktion `AssumeRole` in der Rolle `UpdateData` zu verweigern. Achten Sie darauf, dass Sie das `Resource` Element auf die tatsächliche AWS-Konto ID des Zielkontos ändern*DESTINATION-ACCOUNT-ID*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/UpdateData" } } ``` ------ Der Effekt `Deny` verweigert der Analysten-Gruppe explizit den Zugriff auf die Rolle `UpdateData` im Zielkonto. Jeder Analyst, der versucht, auf die Rolle zuzugreifen, erhält die Meldung „Zugriff verweigert“. 1. Wählen Sie **Richtlinie prüfen**. 1. Geben Sie einen **Namen** wie **deny-assume-S3-role-in-destination** ein. 1. Wählen Sie **Richtlinie erstellen** aus. Die Rolle der Entwickler verfügt jetzt über die Berechtigung, die Rolle `UpdateData` im Zielkonto zu verwenden. Die Rolle des Analysten kann die Rolle `UpdateData` nicht verwenden. Als Nächstes können Sie sehen, wie David, ein Entwickler, auf den Bucket `amzn-s3-demo-bucket-shared-container` im Zielkonto zugreifen kann. David kann über die AWS-Managementkonsole, die oder die AWS API auf den AWS CLI Bucket zugreifen. ## Testen des Zugriffs durch Rollenwechsel Nach Abschluss der ersten beiden Schritte dieses Tutorials verfügen Sie über eine Rolle, die Zugriff auf eine Ressource im **Zielkonto** gewährt. Sie verfügen außerdem über eine Rolle im **Ursprungskonto**, wobei die Benutzer diese Rolle verwenden dürfen. In diesem Schritt wird erläutert, wie Sie den Wechsel von der AWS-Managementkonsole, der und der AWS CLI AWS API zu dieser Rolle testen können. Hilfe zu allgemeinen Problemen, die bei der Arbeit mit IAM-Rollen auftreten können, finden Sie unter [Fehlerbehebung bei IAM-Rollen](troubleshoot_roles.md). ### Wechseln der Rollen (Konsole) Wenn David Daten im **Zielkonto** in der aktualisieren muss AWS-Managementkonsole, kann er dies mithilfe von **Switch Role** tun. Nach Angabe der Konto-ID oder des Alias und des Rollennamens erfolgt sofort der Wechsel zu den von der Rolle erteilten Berechtigungen. Er kann dann die Konsole verwenden, um mit dem Bucket `amzn-s3-demo-bucket-shared-container` zu arbeiten, kann jedoch nicht mit anderen Ressourcen im **Ziel** arbeiten. Während David die Rolle verwendet, kann er seine Poweruser-Berechtigungen im **Ursprungskonto** nicht nutzen. Dies liegt daran, dass jeweils nur eine Gruppe von Berechtigungen wirksam sein kann. IAM bietet zwei Möglichkeiten, mit denen David die Seite **Switch Role (Rolle wechseln)** aufrufen kann: + David erhält einen Link von seinem Administrator, der auf eine vordefinierte Konfiguration zum Wechseln der Rolle verweist. Der Link wird dem Administrator auf der letzten Seite des Assistenten **Create role (Rolle wechseln)** oder auf der Seite **Role Summary (Rollenübersicht)** für kontoübergreifende Rollen bereitgestellt. Wenn David diesem Link folgt, wird er zur Seite **Switch Role (Rolle wechseln)** weitergeleitet, in der die Felder **Account ID (Konto-ID)** und **Role name (Rollenname)** bereits ausgefüllt sind. David muss lediglich **Rollen wechseln** auswählen. + Der Administrator sendet nicht den Link mit der E-Mail, sondern die Werte für die **Konto-ID**-Nummer und den **Rollennamen**. Um die Rollen zu wechseln, muss David die -Werte manuell eingeben. Dies wird in der folgenden Anleitung veranschaulicht. **So übernehmen Sie eine Rolle** 1. David meldet sich AWS-Managementkonsole mit seinem normalen Benutzer im **ursprünglichen** Konto an. 1. Er wählt den Link, den ihm der Administrator per E-Mail zugeschickt hat. Dadurch wird David auf die Seite **Switch Role** (Rolle wechseln) weitergeleitet, in der die Angaben zu Konto-ID und Rollenname bereits ausgefüllt sind.  –oder – David wählt seinen Namen (im Identity-Menü) auf der Navigationsleiste aus und wählt dann **Switch Roles** (Rollen wechseln). Wenn dies das erste Mal ist, dass David versucht, auf die Seite "Switch Role" zuzugreifen, landet er zunächst auf einer initialen **Switch Role (Rolle wechseln)**-Seite. Auf dieser Seite finden Sie weitere Informationen darüber, wie durch das Wechseln von Rollen die Benutzer befähigt werden, Ressourcen in verschiedenen AWS-Konten zu verwalten. David muss auf dieser Seite auf die Schaltfläche **Switch Role (Rolle wechseln)** klicken, um den Rest des beschriebenen Verfahrens abzuschließen. 1. Um auf die Rolle zuzugreifen, muss David als Nächstes die Zielkonto-ID-Nummer (`999999999999`) und den Rollennamen (`UpdateData`) manuell eingeben. David möchte außerdem überwachen, welche Rollen und zugehörigen Berechtigungen derzeit in IAM aktiv sind. Zum Nachverfolgen dieser Informationen gibt er `Destination` in das Textfeld **Display Name (Anzeigename)** ein, wählt die Option für Rot und dann **Switch Role (Rolle wechseln)**. 1. David kann nun die Amazon S3-Konsole verwenden, um mit dem Amazon S3-Bucket oder einer anderen Ressource zu arbeiten, für die die `UpdateData`-Rolle Berechtigungen hat. 1. Sobald dies erledigt ist, kann David zu seinen ursprünglichen Berechtigungen zurückkehren. Wählen Sie dazu den Anzeigenamen der **Zielrolle** in der Navigationsleiste und dann **Zurück zu David @ 111111111111**. 1. Wenn David das nächste Mal die Rollen wechseln möchte und das Menü **Identität** in der Navigationsleiste auswählt, sieht er, dass der Eintrag „Ziel“ vom letzten Mal noch vorhanden ist. Durch Klicken auf diesen Eintrag kann er die Rolle sofort wechseln, ohne die Konto-ID und den Rollennamen erneut angeben zu müssen. ### Wechseln der Rolle (AWS CLI) Wenn David in der **Zielumgebung** in der Befehlszeile arbeiten muss, kann er dies mithilfe der [AWS CLI](https://aws.amazon.com/cli/) tun. Er führt den Befehl `aws sts assume-role` aus und übergibt den ARN der Rolle, um temporäre Sicherheitsanmeldeinformationen für diese Rolle zu erhalten. Anschließend konfiguriert er diese Anmeldeinformationen in Umgebungsvariablen, sodass nachfolgende AWS CLI Befehle mit den Berechtigungen der Rolle funktionieren. Während David die Rolle verwendet, kann er seine Poweruser-Berechtigungen im **Ursprungskonto** nicht nutzen, da jeweils nur ein Berechtigungssatz wirksam sein kann. Beachten Sie, dass alle Zugriffsschlüssel und Token nur Beispiele sind und nicht wie hier dargestellt verwendet werden können. Ersetzen Sie sie mit den entsprechenden Werten aus Ihrer Live-Umgebung. **So übernehmen Sie eine Rolle** 1. David öffnet ein Befehlszeilenfenster und bestätigt, dass der AWS CLI Client funktioniert, indem er den folgenden Befehl ausführt: ``` aws help ``` **Anmerkung** Die Standardumgebung von David verwendet die Anmeldeinformationen des Benutzers `David` aus seinem Standardprofil, das er mit dem Befehl `aws configure` erstellt hat. Weitere Informationen finden Sie unter [Konfigurieren der AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) im *AWS Command Line Interface -Leitfaden*. 1. Er beginnt mit dem Verfahren zum Rollenwechsel, indem er den folgenden Befehl ausführt, um zur Rolle `UpdateData` im **Zielkonto** zu wechseln. Der ARN der Rolle wurde ihm vom Administrator, der die Rolle erstellt hat, mitgeteilt. Der Befehl erfordert, dass Sie außerdem einen Sitzungsnamen angeben. Sie können hierfür einen beliebigen Text eingeben. ``` aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate" ``` David erhält dann die folgende Ausgabe: ``` { "Credentials": { "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e NhyDHq6ikBQ==", "Expiration": "2014-12-11T23:08:07Z", "AccessKeyId": "AKIAIOSFODNN7EXAMPLE" } } ``` 1. David sieht die drei Teile im Anmeldeinformationen-Abschnitt der Ausgabe, die er benötigt. + `AccessKeyId` + `SecretAccessKey` + `SessionToken` David muss die AWS CLI Umgebung so konfigurieren, dass diese Parameter bei nachfolgenden Aufrufen verwendet werden. Weitere Informationen zu den verschiedenen Möglichkeiten zum Konfigurieren Ihrer Anmeldeinformationen finden Sie unter [Konfigurieren der AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Den Befehl `aws configure` können Sie nicht verwenden, da er nicht die Erfassung des Sitzungs-Token unterstützt. Sie können jedoch die Informationen manuell in eine Konfigurationsdatei eingeben. Da die Ablaufzeit dieser temporären Anmeldeinformationen relativ kurz ist, fügen Sie sie besser der Umgebung Ihrer aktuellen Befehlszeilensitzung hinzu. 1. Um die drei Werte zur Umgebung hinzuzufügen, kopiert David die Ausgabe aus dem vorherigen Schritt und fügt sie in die folgenden Befehle ein. Fügen Sie die Ausgabe in einen einfachen Texteditor ein, um Probleme mit Zeilenumbrüchen in der Ausgabe des Sitzungs-Token zu vermeiden. Er muss als eine einzige lange Zeichenfolge hinzugefügt werden, auch wenn er hier aus Darstellungsgründen mit Zeilenumbrüchen angezeigt wird. Das folgende Beispiel zeigt Befehle in der Windows-Umgebung, wobei „set“ der Befehl zum Erstellen einer Umgebungsvariablen ist. Auf einem Linux- oder macOS-Computer würden Sie stattdessen den Befehl für „Exportieren“ verwenden. Alle anderen Teile des Beispiels sind in allen drei Umgebungen gültig. Details zur Verwendung von Tools für Windows PowerShell finden Sie hier: [Zu einer IAM-Rolle wechseln (Tools für Windows PowerShell)](id_roles_use_switch-role-twp.md) ``` set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen DHq6ikBQ== ``` Ab diesem Zeitpunkt werden alle folgenden Befehle mit den Berechtigungen der von diesen Anmeldeinformationen identifizierten Rolle ausgeführt. Im Fall von David handelt es sich um die Rolle `UpdateData`. **Wichtig** Sie können Ihre häufig verwendeten Konfigurationseinstellungen und Anmeldeinformationen in Dateien speichern, die von der AWS CLI verwaltet werden. Weitere Informationen finden Sie unter [Verwendung vorhandener Konfigurations- und Anmeldeinformationsdateien](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) im *AWS Command Line Interface -Benutzerhandbuch*. 1. Führen Sie den Befehl aus, um Zugriff auf die Ressourcen im Zielkonto zu erhalten. In diesem Beispiel listet David mit dem folgenden Befehl den Inhalt seines S3-Buckets auf. ``` aws s3 ls s3://shared-container ``` Da die Namen von Amazon-S3-Buckets universell eindeutig sind, muss die ID des Kontos, in dem der Bucket enthalten ist, nicht angegeben werden. Wenn Sie auf Ressourcen für andere AWS Dienste zugreifen möchten, finden Sie in der AWS CLI Dokumentation zu diesem Dienst die Befehle und die Syntax, die zum Verweisen auf seine Ressourcen erforderlich sind. ### Verwenden von AssumeRole (AWS API) Wenn David über den Code eine Aktualisierung des **Zielkontos** vornehmen muss, tätigt er einen `AssumeRole`-Aufruf, um die Rolle `UpdateData` zu übernehmen. Der Aufruf gibt temporäre Anmeldeinformationen zurück, mit denen er auf den Bucket `amzn-s3-demo-bucket-shared-container` im **Zielkonto** zugreifen kann. Mit diesen Anmeldeinformationen kann David API-Aufrufe ausführen, um den Bucket `amzn-s3-demo-bucket-shared-container` zu aktualisieren. Er kann jedoch keine API-Aufrufe tätigen, um auf andere Ressourcen im **Zielkonto** zuzugreifen, obwohl er im **Ursprungskonto** über Poweruser-Berechtigungen verfügt. **So übernehmen Sie eine Rolle** 1. David ruft `AssumeRole` als Teil einer Anwendung auf. Er muss den `UpdateData`-ARN angeben: `arn:aws:iam::999999999999:role/UpdateData`. Die Antwort auf den `AssumeRole`-Aufruf enthält die temporären Anmeldeinformationen mit einem `AccessKeyId` und einem `SecretAccessKey`. Sie enthält auch eine `Expiration`-Zeit, die angibt, wann die Anmeldeinformationen ablaufen und neue angefordert werden müssen. Wenn Sie die Rollenverkettung mit dem AWS SDK einrichten, aktualisieren viele Anbieter von Anmeldeinformationen die Anmeldeinformationen automatisch, bevor sie ablaufen. 1. Mit den temporären Anmeldeinformationen führt David einen Aufruf `s3:PutObject` aus, um den Bucket `amzn-s3-demo-bucket-shared-container` zu aktualisieren. Er übergibt die Anmeldeinformationen als `AuthParams`-Parameter an den API-Aufruf. Da die Anmeldeinformationen der temporären Rolle nur über Lese- und Schreibzugriff auf den Bucket `amzn-s3-demo-bucket-shared-container` verfügen, werden alle anderen Aktionen im Zielkonto verweigert. Ein Code-Beispiel (mit Python) finden Sie unter [Zu einer IAM-Rolle (AWS API) wechseln](id_roles_use_switch-role-api.md). ## Weitere Ressourcen Die folgenden Ressourcen können Ihnen dabei helfen, mehr über die Themen in diesem Tutorial zu erfahren: + Weitere Informationen zu IAM-Benutzern finden Sie unter [IAM-Identitäten](id.md). + Weitere Informationen über Amazon-S3-Buckets finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.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). ## Zusammenfassung Sie haben das Tutorial für den kontoübergreifenden API-Zugriff abgeschlossen. Sie haben eine Rolle zum Einrichten einer Vertrauensstellung mit einem anderen Konto und zur Definition der Aktionen erstellt, zu deren Ausführung die vertrauenswürdigen Entitäten berechtigt sind. Anschließend haben Sie eine Rollenrichtlinie geändert, um zu steuern, welche IAM-Benutzer auf die Rolle zugreifen können. Dadurch können Entwickler vom **Ursprungskonto** aus mithilfe temporärer Anmeldeinformationen Aktualisierungen am Bucket `amzn-s3-demo-bucket-shared-container` im **Zielkonto** vornehmen.