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.
# Gängige Szenarien für IAM-Rollen
Wie bei den meisten AWS Funktionen haben Sie generell zwei Möglichkeiten, eine Rolle zu verwenden: interaktiv in der IAM-Konsole oder programmgesteuert mit den AWS CLI Tools für Windows PowerShell oder der API.
+ IAM-Benutzer in Ihrem Konto können mithilfe der IAM-Konsole eine Rolle *wechseln*, um vorübergehend die Berechtigungen der Rolle in der Konsole zu verwenden. Die Benutzer verlieren ihre ursprünglichen Berechtigungen und übernehmen die Berechtigungen der zugewiesenen Rolle. Wenn der Benutzer die Rolle verlässt, werden die ursprünglichen Berechtigungen wiederhergestellt.
+ Eine Anwendung oder ein Service, der von AWS (wie Amazon EC2) angeboten wird, kann eine Rolle *übernehmen*, indem sie temporäre Sicherheitsanmeldedaten für eine Rolle anfordert, an die programmatische Anfragen gestellt werden können. AWS Wenn Sie eine Rolle auf diese Weise verwenden, müssen Sie keine langfristigen Anmeldeinformationen für jede Entität teilen oder pflegen (indem Sie beispielsweise einen IAM-Benutzer erstellen), die Zugriff auf eine Ressource benötigt.
**Anmerkung**
In diesem Handbuch stellen die Ausdrücke *zu einer Rolle wechseln* und *eine Rolle übernehmen* Synonyme dar.
Die einfachste Möglichkeit zur Verwendung von Rollen besteht darin, Ihren IAM-Benutzern Berechtigungen zum Wechseln der Rollen zu gewähren, die Sie in Ihrem oder einem anderen AWS-Konto erstellen. Sie können Rollen auf einfache Weise mit der IAM-Konsole wechseln, um Berechtigungen zu verwenden, über die die Rollen normalerweise nicht verfügen sollen, und dann die Rolle verlassen, um diese Berechtigungen zu entziehen. So können Sie den *versehentlichen* Zugriff auf oder die Änderung von sensible Ressourcen vermeiden.
Für komplexere Verwendungen von Rollen, z. B. Gewähren des Zugriffs auf externe Anwendungen und Services, rufen Sie das `AssumeRole`-API auf. Dieser API-Aufruf gibt einen Satz temporärer Anmeldeinformationen zurück, die die Anwendung in nachfolgenden API-Aufrufen verwenden kann. Aktionen, die mit den temporären Anmeldeinformationen aufgerufen werden, verfügen nur über die von der zugewiesenen Rolle gewährten Berechtigungen. Eine Anwendung muss die Rolle nicht wie der Benutzer über die Konsole "verlassen". Die Anwendung verwendet einfach nicht mehr die temporären Anmeldeinformationen und führt die Aufrufe nunmehr mit den ursprünglichen Anmeldeinformationen durch.
Verbundbenutzer melden sich mit den Anmeldeinformationen eines Identitätsanbieters (IdP) an. AWS stellt dann dem vertrauenswürdigen IdP temporäre Anmeldeinformationen zur Verfügung, die an den Benutzer weitergegeben werden, damit er sie in nachfolgende AWS Ressourcenanfragen einbezieht. Diese Anmeldeinformationen enthalten die Berechtigungen für die zugewiesene Rolle.
Dieser Abschnitt enthält eine Übersicht über die folgenden Szenarien:
+ [Gewähren Sie einem IAM-Benutzer in einem Konto AWS-Konto , das Sie besitzen, Zugriff auf Ressourcen in einem anderen Konto, das Sie besitzen](id_roles_common-scenarios_aws-accounts.md)
+ [Bereitstellen des Zugriffs auf nicht- AWS -Workloads](id_roles_common-scenarios_non-aws.md)
+ [Gewähren Sie den IAM-Benutzern in AWS-Konten von Dritten Zugriff](id_roles_common-scenarios_third-party.md)
+ [Ermöglichen Sie den Zugriff auf Dienste, die von AWS to AWS resources angeboten werden](id_roles_common-scenarios_services.md)
+ [Gewähren Sie den Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](id_roles_common-scenarios_federated-users.md)
# Zugriff für einen IAM-Benutzer in einem anderen AWS-Konto , den Sie besitzen
Sie können Ihren IAM-Benutzern die Erlaubnis erteilen, zu Rollen innerhalb Ihrer eigenen AWS-Konto oder zu Rollen zu wechseln, die in anderen Rollen definiert sind AWS-Konten , die Ihnen gehören.
**Anmerkung**
Wenn Sie den Zugriff auf ein Konto gewähren möchten, das Sie nicht besitzen oder kontrollieren, finden Sie weitere Informationen unter [Zugriff auf AWS-Konten Eigentum Dritter](id_roles_common-scenarios_third-party.md) im weiteren Verlauf in diesem Thema.
Angenommen, Sie haben Amazon EC2-Instances, die für die Organisation sehr wichtig sind. Statt Benutzern die Berechtigung zu erteilen, solche Instances zu beenden, können Sie eine Rolle mit diesen Berechtigungen erstellen. Erlauben Sie dann den Administratoren, zu jener Rolle zu wechseln, wenn sie eine Instance beenden müssen. Dadurch werden den Instances folgende Schutzebenen hinzugefügt:
+ Sie müssen Ihren Benutzern explizit die Berechtigung zur Übernahme der Rolle erteilen.
+ Ihre Benutzer müssen aktiv zu der Rolle wechseln, indem sie die AWS-Managementkonsole oder AWS API verwenden, AWS CLI oder die Rolle übernehmen.
+ Sie können die Multi-Factor Authentication (MFA) zur Rolle hinzufügen, sodass nur die Benutzer, die sich mit einem MFA-Gerät anmelden, die Rolle übernehmen können. Weitere Informationen dazu, wie Sie eine Rolle konfigurieren, sodass von den Benutzern, die die Rolle übernehmen müssen, zunächst eine Multi-Factor Authentication (MFA) verlangt wird, finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
Wir empfehlen diese Herangehensweise, um das das *Prinzip der geringsten Zugriffsrechte* durchzusetzen. Das bedeutet, dass erweiterte Berechtigungen nur in Zeiten gewährt werden, in denen diese zur Durchführung bestimmter Aufgaben benötigt werden. Mit den Rollen können Sie versehentliche Änderungen an sensiblen Umgebungen verhindern, vor allem in Verbindung mit der [-Überwachung](cloudtrail-integration.md), um sicherzustellen, dass Rollen nur bei Bedarf verwendet werden.
Wenn Sie eine Rolle für diesen Zweck erstellen, geben Sie in der Vertrauensrichtlinie der Rolle im `Principal`-Element die IDs der Konten an, für deren Benutzer Sie Zugriffsberechtigungen erteilen müssen. Anschließend können Sie bestimmten Benutzern in den anderen Konten Berechtigungen erteilen, um zu dieser Rolle zu wechseln. 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).
Ein Benutzer in einem Konto kann zu einer Rolle in demselben oder einem anderen Konto wechseln. Während die Rolle verwendet wird, können die Benutzer nur die Aktionen durchführen und auf die Ressourcen zugreifen, die von der Rolle zugelassen sind. Die ursprünglichen Berechtigungen der Benutzer sind ausgesetzt. Wenn der Benutzer die Rolle verlässt, werden die ursprünglichen Benutzerberechtigungen wiederhergestellt.
## Beispielszenario mit getrennten Entwicklungs- und Produktionskonten
Stellen Sie sich vor, Ihr Unternehmen verfügt über mehrere AWS-Konten , um eine Entwicklungsumgebung von einer Produktionsumgebung zu isolieren. Benutzer im Entwicklungskonto müssen gelegentlich auf Ressourcen im Produktionskonto zugreifen. Sie benötigen beispielsweise kontoübergreifenden Zugriff, wenn Sie ein Update aus der Entwicklungsumgebung in die Produktionsumgebung übernehmen wollen. Auch wenn Sie verschiedene Identitäten (und Passwörter) für die Benutzer, die in beiden Konten arbeiten, erstellen könnten, erschwert das Verwalten von Anmeldeinformationen für mehrere Konten die Identitätsverwaltung. In der folgenden Abbildung werden alle Benutzer im Development-Konto verwaltet. Einige Entwickler benötigen jedoch eingeschränkten Zugriff auf das Production-Konto. Das Development-Konto verfügt über zwei Gruppen: Tester und Entwickler und jede Gruppe hat ihre eigene Richtlinie.
![\[Verwenden Sie eine Rolle zum Delegieren von Berechtigungen für einen Benutzer in einem anderen Konto\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. Im Produktionskonto verwendet ein Administrator IAM, um die `UpdateApp`-Rolle in diesem Konto zu erstellen. Der Administrator definiert in der Rolle eine Vertrauensrichtlinie, in der das Development-Konto als `Principal` angegeben wird, was bedeutet, dass autorisierte Benutzer aus dem Development-Konto die Rolle `UpdateApp` verwenden dürfen. Der Administrator definiert auch eine Berechtigungsrichtlinie für die Rolle, die festlegt, welche Rollenbenutzer Lese- und Schreibberechtigungen für den Amazon S3`productionapp`-Bucket namens erhalten.
Der Administrator gibt die entsprechenden Informationen dann an Benutzer weiter, die die Rolle übernehmen müssen. Diese Informationen sind die Kontonummer und der Name der Rolle (für AWS Konsolenbenutzer) oder der Amazon-Ressourcenname (ARN) (für AWS CLI unseren AWS API-Zugriff). Der Rollen-ARN könnte wie `arn:aws:iam::123456789012:role/UpdateApp` aussehen, wobei die Rolle `UpdateApp` benannt ist und die Rolle unter der Kontonummer 123456789012 erstellt wurde.
**Anmerkung**
Der Administrator kann optional die Rolle konfigurieren, sodass von den Benutzern, die die Rolle übernehmen müssen, zunächst eine Multi-Factor Authentication (MFA) verlangt wird. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
1. Der Administrator gewährt den Mitgliedern der Entwicklergruppe im Entwicklungskonto die Berechtigungen, um zur betreffenden Rolle wechseln zu können. Dazu wird der Entwicklergruppe die Erlaubnis erteilt, die AWS -Security-Token-Service (AWS STS) `AssumeRole` -API für die `UpdateApp` Rolle aufzurufen. Alle IAM-Benutzer der Entwickler-Gruppe im Development-Konto können nun zur Rolle `UpdateApp` im Production-Konto wechseln. Andere Benutzer, die sich nicht in der Entwickler-Gruppe befinden, haben keine Berechtigung, um zur Rolle zu wechseln, und sind folglich nicht in der Lage, auf den S3-Bucket im Production-Konto zuzugreifen.
1. Der Benutzer fordert den Wechsel zur Rolle an:
+ AWS Konsole: Der Benutzer wählt den Kontonamen in der Navigationsleiste und wählt „**Rolle wechseln**“. Der Benutzer gibt die Konto-ID (oder Alias) und den Namen der Rolle an. Alternativ kann der Benutzer auf einen Link in der vom Administrator gesendeten E-Mail klicken. Der Link leitet den Benutzer zur Seite **Switch Role (Rolle wechseln)** weiter, in der die Details bereits ausgefüllt sind.
+ AWS API/AWS CLI: Ein Benutzer in der Gruppe Entwickler des Entwicklungskontos ruft die `AssumeRole` Funktion auf, um Anmeldeinformationen für die `UpdateApp` Rolle abzurufen. Der Benutzer übergibt den ARN der Rolle `UpdateApp` als Teil des Aufrufs. Eine vom Benutzer in der Tester-Gruppe gestellte gleiche Anforderung schlägt fehl, weil die Tester keine Berechtigung zum Aufruf von `AssumeRole` für den ARN der Rolle `UpdateApp` haben.
1. AWS STS gibt temporäre Anmeldeinformationen zurück:
+ AWS Konsole: AWS STS überprüft die Anfrage anhand der Vertrauensrichtlinie der Rolle, um sicherzustellen, dass die Anfrage von einer vertrauenswürdigen Entität stammt (was es ist: das Entwicklungskonto). AWS STS Gibt nach der Überprüfung [temporäre Sicherheitsanmeldedaten](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) an die AWS Konsole zurück.
+ API/CLI: AWS STS überprüft die Anfrage anhand der Vertrauensrichtlinie der Rolle, um sicherzustellen, dass die Anfrage von einer vertrauenswürdigen Entität stammt (was es ist: das Entwicklungskonto). AWS STS Gibt nach der Überprüfung [temporäre Sicherheitsanmeldedaten an die Anwendung](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) zurück.
1. Die temporären Anmeldeinformationen ermöglichen den Zugriff auf die AWS Ressource:
+ AWS Konsole: Die AWS Konsole verwendet die temporären Anmeldeinformationen im Namen des Benutzers für alle nachfolgenden Konsolenaktionen, in diesem Fall zum Lesen und Schreiben in den `productionapp` Bucket. Die Konsole kann auf keine anderen Ressourcen im Production-Konto zurückgreifen. Wenn der Benutzer die Rolle verlässt, erhält er seine ursprünglichen Berechtigungen, über die er vor dem Wechseln der Rolle verfügt hat, zurück.
+ API/CLI: Die Anwendung verwendet die temporären Anmeldeinformationen, um den Bucket `productionapp` zu aktualisieren. Mit den temporären Sicherheitsanmeldeinformationen kann die Anwendung nur Lese- und Schreibvorgänge im Bucket `productionapp` ausführen und auf keine anderen Ressourcen im Production-Konto zugreifen. Die Anwendung muss die Rolle nicht verlassen, sondern unterlässt stattdessen die Verwendung der temporären Anmeldeinformationen und verwendet in den nachfolgenden API-Aufrufen die ursprünglichen Anmeldeinformationen.
## Weitere Ressourcen
Weitere Informationen finden Sie hier:
+ [IAM-Tutorial: Delegieren Sie den Zugriff über AWS Konten hinweg mithilfe von IAM-Rollen](tutorial_cross-account-with-roles.md)
# Zugriff für AWS Nicht-Workloads
[Eine [IAM-Rolle](id_roles.md) ist ein Objekt in AWS Identity and Access Management (IAM), dem Berechtigungen zugewiesen wurden.](access_policies.md) 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 temporäre Sicherheitsanmeldedaten für Ihre Rollensitzung. Möglicherweise laufen Workloads in Ihrem Rechenzentrum oder einer anderen Infrastruktur außerhalb dieser Infrastruktur AWS , die auf Ihre AWS Ressourcen zugreifen muss. Anstatt langfristige Zugriffsschlüssel zu erstellen, zu verteilen und zu verwalten, können Sie Roles Anywhere (IAM AWS Identity and Access Management Roles Anywhere) verwenden, um Ihre Nicht-Workloads zu authentifizieren. AWS IAM Roles Anywhere verwendet X.509-Zertifikate Ihrer Zertifizierungsstelle (CA), um Identitäten zu authentifizieren und den Zugriff auf sichere Weise AWS-Services mit den temporären Anmeldeinformationen zu ermöglichen, die von einer IAM-Rolle bereitgestellt werden.
**So verwenden Sie IAM Roles Anywhere**
1. Richten Sie eine CA mit [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) ein oder verwenden Sie eine CA aus Ihrer eigenen PKI-Infrastruktur.
1. Nachdem Sie eine Zertifizierungsstelle eingerichtet haben, erstellen Sie in IAM Roles Anywhere ein Objekt, das *Vertrauensanker* genannt wird. Dieser Anker stellt für die Authentifizierung Vertrauen zwischen IAM Roles Anywhere und Ihrer Zertifizierungsstelle her.
1. Anschließend können Sie Ihre vorhandenen IAM-Rollen konfigurieren oder neue Rollen erstellen, die dem IAM-Roles-Anywhere-Dienst vertrauen.
1. Authentifizieren Sie Ihre AWS Nicht-Workloads mit IAM Roles Anywhere mithilfe des Trust Anchor. AWS gewährt der IAM-Rolle, die Zugriff auf Ihre Ressourcen hat, temporäre Anmeldeinformationen, die keine AWS Workloads sind. AWS
## Weitere Ressourcen
In den folgenden Ressourcen erfahren Sie mehr über die Bereitstellung des Zugriffs auf Workloads, die nicht von AWS stammen.
+ Weitere Informationen zum Konfigurieren von IAM Roles Anywhere finden Sie unter [Was ist AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) im *IAM-Roles-Anywhere-Benutzerhandbuch*.
+ Informationen zum Einrichten einer Infrastruktur für öffentliche Schlüssel (PKI) für IAM Roles Anywhere finden Sie unter [IAM Roles Anywhere mit einer externen Zertifizierungsstelle](https://aws.amazon.com/blogs/) im *AWS -Sicherheits-Blog*.
# Zugriff auf AWS-Konten Eigentum Dritter
Wenn Dritte Zugriff auf die AWS Ressourcen Ihrer Organisation benötigen, können Sie Rollen verwenden, um den Zugriff auf diese Ressourcen zu delegieren. Zum Beispiel könnte ein externer Benutzer einen Service zur Verwaltung Ihrer AWS -Ressourcen anbieten. Mit IAM-Rollen können Sie diesen Dritten Zugriff auf Ihre AWS Ressourcen gewähren, ohne Ihre AWS Sicherheitsanmeldedaten weitergeben zu müssen. Stattdessen kann der Drittanbieter auf Ihre AWS Ressourcen zugreifen, indem er eine Rolle übernimmt, die Sie in Ihrem AWS-Konto erstellen. 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).
Externe Benutzer müssen Ihnen die folgenden Informationen bereitstellen, damit Sie eine von ihnen übernehmbare Rolle erstellen können:
+ **Die AWS-Konto ID des Drittanbieters**. Sie legen diese AWS-Konto -ID als Prinzipal fest, wenn Sie die Vertrauensrichtlinie für die Rolle definieren.
+ **Eine externe ID zur eindeutigen Zuordnung der Rolle**. Die externe ID kann eine beliebige geheime Kennung sein, die Ihnen und dem Drittanbieter bekannt ist. Sie können beispielsweise eine Rechnungs-ID zwischen Ihnen und dem externen Benutzer verwenden. Benutzen Sie aber keine leicht zu erratenden Zeichenfolgen wie den Namen oder die Telefonnummer des externen Benutzers. Sie müssen diese ID festlegen, wenn Sie die Vertrauensrichtlinie für die Rolle definieren. Der externe Benutzer muss diese ID angeben, wenn er die Rolle übernimmt.
+ **Die Berechtigungen, die der externe Benutzer benötigt, um mit Ihren AWS -Ressourcen arbeiten zu können**. Sie müssen diese Berechtigungen festlegen, wenn Sie die Berechtigungsrichtlinie für die Rolle definieren. Diese Richtlinie bestimmt, welche Aktionen der externe Benutzer ausführen darf und auf welche Ressourcen er Zugriff hat.
Nachdem Sie die Rolle erstellt haben, müssen Sie dem externen Benutzer den Amazon Resource Name (ARN) der Rolle mitteilen. Dieser benötigt den ARN der Rolle, um sie übernehmen zu können.
**Wichtig**
Wenn Sie Dritten Zugriff auf Ihre AWS Ressourcen gewähren, können diese auf jede Ressource zugreifen, die Sie in der Richtlinie angeben. Die vom externen Benutzer genutzten Ressourcen werden Ihnen in Rechnung gestellt. Stellen Sie sicher, dass Sie die Nutzung Ihrer Ressourcen sinnvoll einschränken.
## Extern IDs für den Zugriff durch Dritte
Eine externe ID ermöglicht dem Benutzer, der die Rolle übernimmt, die Umstände anzugeben, unter denen er agiert. Außerdem kann der Kontoinhaber die Umstände festlegen, unter denen die Rolle angenommen werden kann. Die primäre Funktion des externen Ausweises besteht darin, [Das Confused-Deputy-Problem](confused-deputy.md) zu lösen und zu verhindern.
**Wichtig**
AWS behandelt die externe ID nicht als geheim. Nachdem Sie ein Geheimnis wie ein Zugriffsschlüsselpaar oder ein Passwort erstellt haben AWS, können Sie es nicht erneut anzeigen. Die externe ID für eine Rolle kann von jedem gesehen werden, der berechtigt ist, die Rolle anzusehen.
## Wann sollte ich die externe ID verwenden?
Verwenden Sie in folgenden Situationen eine externe ID:
+ Sie sind AWS-Konto Eigentümer und haben eine Rolle für einen Drittanbieter konfiguriert, der zusätzlich zu Ihrer Rolle AWS-Konten auf andere zugreift. Sie sollten den Dritten um eine externe ID bitten, die er mit angeben muss, wenn er Ihre Rolle annimmt. Dann führen Sie eine Prüfung durch, um zu testen, ob diese externe ID in der Vertrauensrichtlinie Ihrer Rolle vorhanden ist. Auf diese Weise wird sichergestellt, dass die externe Partei Ihre Rolle nur annehmen kann, wenn sie in Ihrem Namen handelt.
+ Sie sind wie Beispielunternehmen in unserem vorherigen Szenario in einer Position, in der Sie Rollen für verschiedene Kunden annehmen, Sie sollten jedem Kunden eine eindeutige externe ID zuweisen und Ihre Kunden anweisen, die externe ID in die Vertrauensrichtlinie ihrer Rolle aufzunehmen. Anschließend müssen Sie in allen Anforderungen, in der Sie Rollen annehmen möchten, die korrekte externe ID angeben.
Sie verfügen wahrscheinlich bereits über eine eindeutige ID für jeden Kunden, die Sie als externe ID verwenden können. Bei der externen ID handelt es sich nicht um einen Wert, den Sie explizit erstellen oder separat nur für diesen Zweck nachverfolgen müssen.
Geben Sie die externe ID in allen `AssumeRole`-API-Aufrufen an. Wenn Sie von einem Kunden einen Rollen-ARN erhalten, testen Sie darüber hinaus mit und ohne die korrekte externe ID, ob Sie die Rolle annehmen können. Wenn Sie die Rolle ohne die korrekte externe ID annehmen können, speichern Sie den Rollen-ARN des Kunden nicht in Ihrem System. Warten Sie, bis der Kunde die Vertrauensrichtlinie der Rolle aktualisiert hat und eine Überprüfung der externen ID vornimmt. So helfen Sie Ihren Kunden, sich korrekt zu verhalten und sich selbst und Ihr Unternehmen vor dem Problem des verwirrten Stellvertreters zu schützen.
## Beispielszenario mit Verwendung einer externen ID
Nehmen wir zum Beispiel an, Sie beschließen, ein Drittanbieter namens Example Corp mit der Überwachung Ihrer Kosten AWS-Konto und der Kostenoptimierung zu beauftragen. Um Ihre täglichen Ausgaben verfolgen zu können, muss Example Corp auf Ihre AWS Ressourcen zugreifen. Example Corp überwacht zudem viele weitere AWS -Konten anderer Kunden.
Gewähren Sie Example Corp keinen Zugriff auf einen IAM-Benutzer und dessen langfristige Anmeldeinformationen in Ihrem AWS -Konto. Verwenden Sie stattdessen eine IAM-Rolle und deren temporäre Sicherheitsanmeldeinformationen. Eine IAM-Rolle bietet einen Mechanismus, mit dem Dritte auf Ihre AWS Ressourcen zugreifen können, ohne langfristige Anmeldeinformationen (z. B. einen IAM-Benutzerzugriffsschlüssel) weitergeben zu müssen.
Etablieren Sie mithilfe einer IAM-Rolle eine Vertrauensbeziehung zwischen Ihrem AWS-Konto und dem Konto von Example Corp. Nachdem diese Beziehung hergestellt wurde, kann ein Mitglied des Example Corp-Kontos die AWS -Security-Token-Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API aufrufen, um temporäre Sicherheitsanmeldedaten zu erhalten. Die Mitglieder von Example Corp können die Anmeldeinformationen dann verwenden, um auf AWS Ressourcen in Ihrem Konto zuzugreifen.
**Anmerkung**
Weitere Informationen zu den AssumeRole und anderen AWS API-Vorgängen, die Sie aufrufen können, um temporäre Sicherheitsanmeldedaten zu erhalten, finden Sie unter[AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md).
Nachfolgend ist dieses Szenario detaillierter aufgeschlüsselt:
1. Sie beauftragen Beispielunternehmen und diese erstellen eine eindeutige Kunden-ID für Sie. Sie stellen Ihnen diese eindeutige Kunden-ID und ihre AWS-Konto Nummer zur Verfügung. Sie benötigen diese Informationen, um im nächsten Schritt eine IAM-Rolle zu erstellen.
**Anmerkung**
Example Corp kann einen beliebigen Zeichenkettenwert für die verwenden ExternalId, sofern dieser für jeden Kunden eindeutig ist. Es kann sich dabei um eine Kundenkontonummer oder eine zufällige Zeichenfolge handeln, solange nicht für zwei Kunden derselbe Wert verwendet wird. Diese Nummer muss nicht geheim gehalten werden. Example Corp muss den ExternalId Wert jedem Kunden zur Verfügung stellen. Wichtig dabei ist, dass diese ID von Unternehmen XY und ***nicht*** von den Kunden generiert wird, um sicherzustellen, dass jede externe ID einzigartig ist.
1. Sie melden sich an AWS und erstellen eine IAM-Rolle, die Example Corp Zugriff auf Ihre Ressourcen gewährt. Wie bei allen IAM-Rollen verfügt die Rolle über zwei Richtlinien, eine Berechtigungsrichtlinie und eine Vertrauensrichtlinie. Über die Vertrauensrichtlinie der Rolle wird festgelegt, wer die Rolle annehmen kann. In unserem Beispielszenario gibt die Richtlinie die AWS-Konto Anzahl von Example Corp als an`Principal`. Dies ermöglicht Identitäten dieses Kontos, die Rolle anzunehmen. Außerdem fügen Sie der Vertrauensrichtlinie ein `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)`-Element hinzu. Mit diesem `Condition` wird der Kontextschlüssel `ExternalId` getestet, um sicherzustellen, dass er mit der eindeutigen Kunden-ID von Beispielunternehmen übereinstimmt.
```
"Principal": {"AWS": "Example Corp's AWS-Konto ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. In der Berechtigungsrichtlinie der Rolle ist festgelegt, welche Berechtigungen mit der Rolle verliehen werden. Sie können zum Beispiel festlegen, dass die Rolle nur die Verwaltung Ihrer Amazon EC2- und Amazon RDS-Ressourcen erlaubt, nicht aber die Verwaltung Ihrer IAM-Benutzer oder -Gruppen. In unserem Beispielszenario können Sie Beispielunternehmen über die Berechtigungsrichtlinie schreibgeschützten Zugriff auf sämtliche Ressourcen in Ihrem Konto gewähren.
1. Nachdem Sie die Rolle erstellt haben, stellen Sie Beispielunternehmen den Amazon-Ressourcennamen (ARN) der Rolle bereit.
1. Wenn Example Corp auf Ihre AWS Ressourcen zugreifen muss, ruft jemand aus dem Unternehmen die AWS `sts:AssumeRole` API auf. Der Aufruf beinhaltet den ARN der Rolle, die übernommen werden soll, und den ExternalId Parameter, der ihrer Kunden-ID entspricht.
Wenn die Anfrage von jemandem stammt, der Example Corp's verwendet AWS-Konto, und wenn der Rollen-ARN und die externe ID korrekt sind, ist die Anfrage erfolgreich. Anschließend werden temporäre Sicherheitsanmeldedaten bereitgestellt, mit denen Example Corp auf die AWS Ressourcen zugreifen kann, die Ihre Rolle zulässt.
Anders ausgedrückt, wenn eine Rollenrichtlinie eine externe ID enthält, muss jemand, der die Rolle annehmen möchte, als Auftraggeber in der Rolle angegeben sein und muss die korrekte externe ID angeben.
## Wichtige Punkte für externe IDs
+ In einer Umgebung mit mehreren Mandanten, in der Sie mehrere Kunden mit unterschiedlichen AWS Konten unterstützen, empfehlen wir, jeweils eine externe ID zu verwenden. AWS-Konto Diese ID sollte eine zufällige Zeichenfolge sein, die von der Drittpartei generiert wird.
+ Um zu verlangen, dass der Drittanbieter beim Übernehmen einer Rolle eine externe ID bereitstellt, aktualisieren Sie die Vertrauensrichtlinie der Rolle mit der externen ID Ihrer Wahl.
+ Wenn Sie eine externe ID angeben möchten, wenn Sie eine Rolle übernehmen, verwenden Sie die AWS API AWS CLI oder, um diese Rolle anzunehmen. Weitere Informationen finden Sie unter [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)STS-API-Vorgang oder [STS-Befehlsübernahme-CLI-Vorgang](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html).
+ Der Wert `ExternalId` muss mindestens 2 Zeichen und darf höchstens 1.224 Zeichen lang sein. Der Wert muss alphanumerisch sein ohne Leerzeichen. Er kann auch die folgenden Zeichen enthalten: Pluszeichen (\$1), Gleichheitszeichen (=), Komma (,), Punkt (.), At-Zeichen (@), Doppelpunkt (:), Schrägstrich (/) und Bindestrich (-).
## Weitere Ressourcen
Die folgenden Ressourcen können Ihnen dabei helfen, mehr über die Bereitstellung des Zugriffs auf AWS-Konten im Besitz von Drittanbieter zu erfahren.
+ Informationen darüber, wie Sie anderen erlauben können, Aktionen in Ihrem System auszuführen AWS-Konto, finden Sie unter. [Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien erstellen](id_roles_create_for-custom.md)
+ Informationen dazu, wie Sie die Berechtigung zum Wechseln zu einer Rolle gewähren, finden Sie unter [Gewähren von Berechtigungen an einen Benutzer zum Rollenwechsel](id_roles_use_permissions-to-switch.md)
+ Informationen dazu, wie Sie temporäre Sicherheitsanmeldedaten erstellen und vertrauenswürdigen Benutzern zur Verfügung stellen, [Berechtigungen für temporäre Sicherheits-Anmeldeinformationen](id_credentials_temp_control-access.md).
# Zugang zu einem AWS Service
Bei vielen AWS Diensten müssen Sie mithilfe von Rollen steuern, auf welche Dienste zugreifen können. Eine Rolle, die ein Service übernimmt, um Aktionen in Ihrem Namen durchzuführen, wird als [Servicerolle](id_roles.md#iam-term-service-role) bezeichnet. Wenn eine Rolle einem speziellen Zweck für einen Service dient, kann sie als [serviceverknüpfte Rolle](id_roles.md#iam-term-service-linked-role) kategorisiert werden. In der [AWS -Dokumentation](https://docs.aws.amazon.com/) für die einzelnen Services finden Sie Informationen dazu, ob der jeweilige Service Rollen verwendet und wie dem Service eine Rolle zur Nutzung zugewiesen wird.
Einzelheiten zum Erstellen einer Rolle zur Delegierung des Zugriffs auf einen von angebotenen Dienst finden Sie AWS unter[Erstellen Sie eine Rolle, um Berechtigungen an einen AWS Dienst zu delegieren](id_roles_create_for-service.md).
# Zugriff für extern authentifizierte Benutzer gewähren (Identitätsverbund)
Ihre Benutzer haben möglicherweise bereits Identitäten außerhalb von AWS, z. B. in Ihrem Unternehmensverzeichnis. Wenn diese Benutzer mit AWS Ressourcen arbeiten müssen (oder mit Anwendungen arbeiten müssen, die auf diese Ressourcen zugreifen), benötigen diese Benutzer auch AWS Sicherheitsanmeldeinformationen. Sie können mithilfe einer IAM-Rolle Berechtigungen für Benutzer festlegen, deren Identität in einem Verbund Ihres Unternehmens oder eines externen Identitätsanbieters (IdP) vereinigt ist.
**Anmerkung**
Als bewährte Sicherheitsmethode empfehlen wir, den Benutzerzugriff in [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) mit einem Identitätsverbund zu verwalten, anstatt IAM-Benutzer zu erstellen. Informationen zu bestimmten Situationen, in denen ein IAM-Benutzer erforderlich ist, finden Sie unter [Wann sollte ein IAM-Benutzer (anstelle einer Rolle) erstellt werden?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose).
## Zusammenführung von Benutzern einer mobilen oder webbasierten Anwendung mit Amazon Cognito
Wenn Sie eine mobile oder webbasierte App erstellen, die auf AWS Ressourcen zugreift, benötigt die App Sicherheitsanmeldedaten, um programmatische Anfragen an sie stellen zu können. AWS Für die meisten mobilen Anwendungsszenarien empfehlen wir die Verwendung von [Amazon Cognito](https://aws.amazon.com/cognito/). Sie können diesen Dienst mit dem [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) und dem [AWS Mobile SDK for Android und Fire OS](https://aws.amazon.com/sdkforandroid/) verwenden, um eindeutige Identitäten für Benutzer zu erstellen und sie für einen sicheren Zugriff auf Ihre AWS Ressourcen zu authentifizieren. Amazon Cognito unterstützt die Identitätsanbieter, die im nächsten Abschnitt aufgeführt werden, sowie die [vom Entwickler authentifizierten Identitäten](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) und nicht authentifizierten Zugriff (Gast). 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 [Amazon Cognito für mobile Apps](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito).
## Vereinigen von Benutzern in einem Verbund mit öffentlichen Identitätsdienstanbietern oder OpenID Connect
Verwenden Sie möglichst Amazon Cognito für mobile und webbasierte Anwendungsszenarien. Amazon Cognito erledigt den Großteil der behind-the-scenes Arbeit mit öffentlichen Identitätsanbieterdiensten für Sie. Es funktioniert mit den gleichen Drittanbieterservices und unterstützt auch anonyme Anmeldungen. Bei anspruchsvolleren Szenarien können Sie jedoch direkt mit einem Drittanbieterservice arbeiten, wie Login with Amazon, Facebook, Google oder einem mit OpenID Connect (OIDC) kompatiblen Identitätsanbieter. Weitere Informationen zur Verwendung des OIDC-Verbunds mithilfe eines dieser Services finden Sie unter [OIDC-Verbund](id_roles_providers_oidc.md).
## Vereinigen von Benutzern in einem Verbund mit SAML 2.0
Wenn Ihre Organisation bereits ein Identity Provider-Softwarepaket verwendet, das SAML 2.0 (Security Assertion Markup Language 2.0) unterstützt, können Sie Vertrauen zwischen Ihrer Organisation als Identity Provider (IdP) und AWS als Service Provider aufbauen. Anschließend können Sie SAML verwenden, um Ihren Benutzern föderiertes Single Sign-On (SSO) AWS-Managementkonsole oder Verbundzugriff zum Aufrufen von API-Vorgängen bereitzustellen. AWS Wenn Ihr Unternehmen beispielsweise Microsoft Active Directory und Active Directory Federation Services verwendet, können Sie dies mit SAML 2 in einem Verbund vereinigen. Weitere Informationen zum Verbund von Benutzern mit SAML 2.0 finden Sie unter [SAML 2.0-Föderation](id_roles_providers_saml.md).
## Vereinigen von Benutzern in einem Verbund durch Erstellen einer benutzerdefinierten Identity Broker-Anwendung
Wenn Ihre Identitätsquelle nicht mit SAML 2.0 kompatibel ist, können Sie eine benutzerdefinierte Identity Broker-Anwendung erstellen, um eine ähnliche Funktion durchzuführen. Die Brokeranwendung authentifiziert Benutzer, fordert temporäre Anmeldeinformationen für Benutzer an und stellt sie dann dem AWS Benutzer für den Zugriff auf Ressourcen zur Verfügung. AWS
Beispielsweise hat Example Corp. viele Mitarbeiter, die interne Anwendungen ausführen müssen, die auf die Ressourcen des AWS Unternehmens zugreifen. Die Mitarbeiter verfügen bereits über Identitäten im Identitäts- und Authentifizierungssystem des Unternehmens und das Beispielunternehmen möchte keinen separaten IAM-Benutzer für jeden Mitarbeiter erstellen.
Bob ist Entwickler bei Example Corp. Um internen Anwendungen von Example Corp. den Zugriff auf die AWS Ressourcen des Unternehmens zu ermöglichen, entwickelt Bob eine benutzerdefinierte Identity Broker-Anwendung. Die Anwendung überprüft, ob Mitarbeiter beim vorhandenen Identitäts- und Authentifizierungssystem des Beispielunternehmens angemeldet sind, das möglicherweise LDAP, Active Directory oder ein anderes System nutzt. Die Identity Broker-Anwendung ruft dann die temporären Anmeldeinformationen für die Mitarbeiter ab. Dieses Szenario ähnelt dem vorherigen Szenario (eine mobile App, die ein benutzerdefiniertes Authentifizierungssystem verwendet), mit der Ausnahme, dass die Anwendungen, die Zugriff auf AWS Ressourcen benötigen, alle innerhalb des Unternehmensnetzwerks ausgeführt werden und das Unternehmen über ein vorhandenes Authentifizierungssystem verfügt.
Zum Abrufen von temporären Sicherheitsanmeldeinformationen ruft die Identity Broker-Anwendung entweder `AssumeRole` oder `GetFederationToken` auf, je nachdem, wie Bob die Richtlinien für die Benutzer verwalten möchte und wann die temporären Anmeldeinformationen ablaufen sollen. (Weitere Informationen zu den Unterschieden zwischen diesen API-Operationen finden Sie unter [Temporäre IAM Sicherheitsanmeldeinformationen](id_credentials_temp.md) und [Berechtigungen für temporäre Sicherheits-Anmeldeinformationen](id_credentials_temp_control-access.md).) Der Aufruf gibt temporäre Sicherheitsanmeldeinformationen zurück, die aus einer AWS Zugriffsschlüssel-ID, einem geheimen Zugriffsschlüssel und einem Sitzungstoken bestehen. Die Identity Broker-Anwendung stellt diese temporären Sicherheitsanmeldeinformationen der internen Unternehmensanwendung zur Verfügung. Die Anwendung kann dann die temporären Anmeldeinformationen für direkte Aufrufe an AWS verwenden. Die Anwendung speichert die Anmeldeinformationen bis zum Ablaufdatum zwischen und fordert dann einen neuen Satz temporärer Anmeldeinformationen an. Die folgende Abbildung veranschaulicht dieses Szenario.
![\[Beispiel für einen Workflow mit einer benutzerdefinierten Identity Broker-Anwendung\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
Dieses Szenario hat folgende Attribute:
+ Die Identity Broker-Anwendung hat die Berechtigung, auf die STS-API (Security Token Service) von IAM zuzugreifen, um temporäre Sicherheitsanmeldeinformationen zu erstellen.
+ Die Identity Broker-Anwendung kann überprüfen, ob die Mitarbeiter im vorhandenen Authentifizierungssystem authentifiziert sind.
+ Benutzer können eine temporäre URL abrufen, über die sie auf die AWS Managementkonsole zugreifen können (was als Single Sign-On bezeichnet wird).
Weitere Informationen zum Erstellen von temporären Sicherheitsanmeldeinformationen finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md). Weitere Informationen zu SAML-Verbundprinzipalen, die Zugriff auf die AWS Management Console erhalten, finden Sie unter. [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md)