Zugriff für einen IAM-Benutzer auf ein anderes AWS-Konto gewähren, das Sie besitzen
Sie können Ihren IAM-Benutzern die Berechtigung erteilen, zu Rollen in Ihrem AWS-Konto oder in anderen AWS-Konten, die Sie besitzen, zu wechseln.
Anmerkung
Wenn Sie den Zugriff auf ein Konto gewähren möchten, das Sie nicht besitzen oder kontrollieren, finden Sie weitere Informationen unter Zugriffs auf im Besitz von Drittanbietern befindlichen AWS-Konten 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 mithilfe der AWS Management Console zur Rolle wechseln oder die Rolle mithilfe der AWS CLI- oder der AWS-API annehmen.
-
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.
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, 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?.
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
Angenommen, Ihre Organisation verfügt über mehrere AWS-Konten, um die Entwicklungsumgebung von der Produktionsumgebung zu trennen. 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.
-
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 alsPrincipal
angegeben wird, was bedeutet, dass autorisierte Benutzer aus dem Development-Konto die RolleUpdateApp
verwenden dürfen. Der Administrator definiert auch eine Berechtigungsrichtlinie für die Rolle, die festlegt, welche Rollenbenutzer Lese- und Schreibberechtigungen für den Amazon S3productionapp
-Bucket namens erhalten.Der Administrator gibt die entsprechenden Informationen dann an Benutzer weiter, die die Rolle übernehmen müssen. Bei diesen Informationen handelt es sich um die Kontonummer und den Namen der Rolle (für AWS-Konsolenbenutzer) oder den Amazon-Ressourcennamen (ARN, für AWS CLI- oder AWS-API-Zugriff). Der Rollen-ARN könnte wie
arn:aws:iam::123456789012:role/UpdateApp
aussehen, wobei die RolleUpdateApp
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.
-
Der Administrator gewährt den Mitgliedern der Entwicklergruppe im Entwicklungskonto die Berechtigungen, um zur betreffenden Rolle wechseln zu können. Dies erfolgt, indem der Entwickler-Gruppe die Berechtigung zum Aufrufen der AWS Security Token Service (AWS STS)-API
AssumeRole
für die RolleUpdateApp
erteilt wird. Alle IAM-Benutzer der Entwickler-Gruppe im Development-Konto können nun zur RolleUpdateApp
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. -
Der Benutzer fordert den Wechsel zur Rolle an:
-
AWS-Konsole: Der Benutzer wählt den Kontonamen auf der Navigationsleiste und dann Switch Role (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 Entwicklergruppe des Entwicklungskontos ruft die Funktion
AssumeRole
auf, um Anmeldeinformationen für dieUpdateApp
-Rolle zu erhalten. Der Benutzer übergibt den ARN der RolleUpdateApp
als Teil des Aufrufs. Eine vom Benutzer in der Tester-Gruppe gestellte gleiche Anforderung schlägt fehl, weil die Tester keine Berechtigung zum Aufruf vonAssumeRole
für den ARN der RolleUpdateApp
haben.
-
-
AWS STS gibt temporäre Anmeldeinformationen zurück:
-
AWS-Konsole: AWS STS prüft die Anforderung mit der Vertrauensrichtlinie der Rolle, um sicherzustellen, dass die Rolle von einer vertrauenswürdigen Entität (d. h. vom Development-Konto) gestellt wurde. Nach der Überprüfung gibt AWS STS temporäre Sicherheitsanmeldeinformationen an die AWS-Konsole zurück.
-
API/CLI: AWS STS prüft die Anforderung mit der Vertrauensrichtlinie der Rolle, um sicherzustellen, dass die Rolle von einer vertrauenswürdigen Entität (d. h. vom Development-Konto) gestellt wurde. Nach der Überprüfung gibt AWS STS temporäre Sicherheitsanmeldeinformationen an die Anwendung zurück.
-
-
Die temporären Anmeldeinformationen gewähren den Zugriff auf die AWS-Ressource:
-
AWS-Konsole: Die AWS-Konsole verwendet für alle nachfolgenden Aktionen der Konsole die temporären Anmeldeinformationen im Namen des Benutzers, um Lese- und Schreibvorgänge im Bucket
productionapp
auszuführen. 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 Bucketproductionapp
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: