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-Tutorials In den folgenden Tutorials end-to-end werden vollständige Verfahren für allgemeine Aufgaben für AWS Identity and Access Management (IAM) vorgestellt. Sie sind für Laborumgebungen mit fiktiven Unternehmensnamen, Benutzernamen usw. vorgesehen. In den Tutorials finden Sie allgemeine Anleitungen. Ohne die sorgfältige Prüfung und Anpassung an die besonderen Gegebenheiten der Umgebung Ihrer Organisation sind sie nicht zur direkten Verwendung in einer Produktionsumgebung bestimmt. **Topics** + [Delegieren Sie den Zugriff mithilfe von Rollen AWS-Konten](tutorial_cross-account-with-roles.md) + [Erstellen einer kundenverwalteten Richtlinie](tutorial_managed-policies.md) + [Verwenden der attributbasierten Zugriffssteuerung (ABAC)](tutorial_attribute-based-access-control.md) + [Zulassen, dass Ihre Benutzer ihre eigenen Anmeldeinformationen und MFA-Einstellungen konfigurieren können](tutorial_users-self-manage-mfa-and-creds.md) + [SAML-IdP erstellen mit CloudFormation](tutorial_saml-idp.md) + [Erstellen Sie eine SAML-Verbundrolle mit CloudFormation](tutorial_saml-federated-role.md) + [Erstellen Sie einen SAML-IdP und eine Verbundrolle mit CloudFormation](tutorial_saml-idp-and-federated-role.md) # 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. # IAM-Anleitung: Erstellen und Anfügen Ihrer ersten vom Kunden verwalteten Richtlinie In diesem Tutorial verwenden Sie die, AWS-Managementkonsole um eine vom [Kunden verwaltete Richtlinie](access_policies_managed-vs-inline.md#customer-managed-policies) zu erstellen und diese Richtlinie dann einem IAM-Benutzer in Ihrem anzuhängen. AWS-Konto Die von Ihnen erstellte Richtlinie ermöglicht es einem IAM-Testbenutzer, sich direkt AWS-Managementkonsole mit Leseberechtigungen bei der anzumelden. Dieser Workflow umfasst drei grundlegende Schritte: **[Schritt 1: Erstellen der Richtlinie](#step1-create-policy)** Standardmäßig haben IAM-Benutzer keine Berechtigungen zum Durchführen von Aktionen. Sie können nur auf die AWS -Managementkonsole zugreifen oder Daten darin verwalten, wenn Sie dies erlauben. In diesem Schritt erstellen Sie eine vom Kunden verwaltete Richtlinie, mit der sich angefügte Benutzer bei der Konsole anmelden können. **[Schritt 2: Anfügen der Richtlinie](#step2-attach-policy)** Wenn Sie eine Richtlinie an einen Benutzer anfügen, übernimmt dieser alle Zugriffsberechtigungen, die mit dieser Richtlinie verbunden sind. In diesem Schritt fügen Sie die neue Richtlinie an einen Testbenutzer an. **[Schritt 3: Testen des Benutzerzugriffs](#step3-test-access)** Nachdem die Richtlinie angefügt wurde, können Sie sich als Benutzer anmelden und die Richtlinie testen. ## Voraussetzungen Um die Schritte in dieser praktischen Anleitung auszuführen, müssen Sie bereits über Folgendes verfügen: + Eine AWS-Konto , bei der Sie sich als IAM-Benutzer mit Administratorrechten anmelden können. + Ein IAM-Testbenutzer, dem keine Berechtigungen zugewiesen wurden oder der über folgende Gruppenmitgliedschaften verfügt: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_managed-policies.html) ## Schritt 1: Erstellen der Richtlinie In diesem Schritt erstellen Sie eine vom Kunden verwaltete Richtlinie, die es allen verbundenen Benutzern ermöglicht, sich AWS-Managementkonsole mit Lesezugriff auf IAM-Daten anzumelden. **So erstellen Sie die Richtlinie für Ihren Testbenutzer** 1. Melden Sie sich [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)mit Ihrem Benutzer, der über Administratorrechte verfügt, bei der IAM-Konsole an. 1. Wählen Sie im Navigationsbereich **Policies**. 1. Wählen Sie im Inhaltsbereich die Option **Create policy (Richtlinie erstellen)**. 1. Wählen Sie die Option **JSON** aus und kopieren Sie den Text aus dem folgenden JSON-Richtliniendokument. Fügen Sie den folgenden Text in das **JSON**-Eingabefeld ein. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GenerateCredentialReport", "iam:Get*", "iam:List*" ], "Resource": "*" } ] } ``` ------ 1. Beheben Sie alle Sicherheitswarnungen, Fehler oder allgemeinen Warnungen, die während der [Richtlinien-Validierung](access_policies_policy-validator.md) erzeugt wurden, und wählen Sie dann **Weiter**. **Anmerkung** Sie können jederzeit zwischen den Editoroptionen **Visual** und **JSON** wechseln. Wenn Sie jedoch Änderungen vornehmen oder auf der Registerkarte **Visual editor** die Option **Review policy** auswählen, strukturiert IAM möglicherweise Ihre Richtlinie neu, 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 **UsersReadOnlyAccessToIAMConsole** 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 und ist bereit. ## Schritt 2: Anfügen der Richtlinie Als Nächstes fügen Sie die soeben erstellte Richtlinie an Ihren IAM-Testbenutzer an. **So fügen Sie die Richtlinie an Ihren Testbenutzer an** 1. Wählen Sie im Navigationsbereich der IAM-Konsole die Option **Policies**. 1. Beginnen Sie oben in der Richtlinienliste im Suchfeld mit der Eingabe von **UsersReadOnlyAccesstoIAMConsole**, bis Sie Ihre Richtlinie sehen. Wählen Sie dann das Optionsfeld neben **UsersReadOnlyAccessToIAMConsole**in der Liste aus. 1. Wählen Sie die Schaltfläche **Actions** (Aktionen) und dann **Attach** (Anfügen). 1. Wählen Sie bei den IAM-Entitäten die Option zum Filtern nach **Users** (Benutzer). 1. Beginnen Sie im Suchfeld mit der Eingabe von **PolicyUser**, bis dieser Benutzer in der Liste angezeigt wird. Aktivieren Sie dann in der Liste das Kontrollkästchen neben diesem Benutzer. 1. Wählen Sie **Richtlinie anfügen** aus. Sie haben die Richtlinie an Ihren IAM-Testbenutzer angefügt, was bedeutet, dass dieser Benutzer nun Lesezugriff auf die IAM-Konsole hat. ## Schritt 3: Testen des Benutzerzugriffs Für dieses Tutorial empfehlen wir Ihnen, den Zugriff zu testen, indem Sie sich als Testbenutzer anmelden, sodass Sie das potenzielle Erlebnis Ihrer Benutzer nachvollziehen können. **So testen Sie den Zugriff, indem Sie sich mit Ihrem Testbenutzer anmelden** 1. Melden Sie sich [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)mit Ihrem `PolicyUser` Testbenutzer unter bei der IAM-Konsole an. 1. Navigieren Sie durch die Seiten der Konsole und versuchen Sie, einen neuen Benutzer oder eine neue Gruppe zu erstellen. Beachten Sie, dass der Testbenutzer `PolicyUser` zwar Daten anzeigen, aber keine IAM-Daten erstellen bzw. vorhandenen IAM-Daten ändern kann. ## Zugehörige Ressourcen Weitere Informationen finden Sie in den folgenden Ressourcen: + [Verwaltete Richtlinien und eingebundene Richtlinien](access_policies_managed-vs-inline.md) + [Steuern Sie den IAM-Benutzerzugriff auf die AWS-Managementkonsole](console_controlling-access.md) ## Zusammenfassung Sie haben nun erfolgreich alle Schritte abgeschlossen, die zum Erstellen und Anfügen einer vom Kunden verwalteten Richtlinie erforderlich sind. Dadurch können Sie sich mit Ihrem Testkonto bei der IAM-Konsole anmelden, um zu sehen, wie die Erfahrung für Ihre Benutzer aussieht. # IAM-Tutorial: Berechtigungen für den Zugriff auf AWS Ressourcen auf der Grundlage von Tags definieren Die attributbasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, bei der Berechtigungen basierend auf Attributen definiert werden. In AWS werden diese Attribute als *Tags* bezeichnet. Sie können Tags an IAM-Ressourcen, einschließlich IAM-Entitäten (Benutzer oder Rollen), und an AWS Ressourcen anhängen. Sie können Richtlinien definieren, die Tag-Bedingungsschlüssel verwenden, um Ihren Auftraggeber basierend auf ihren Tags Berechtigungen zu erteilen. Wenn Sie Tags verwenden, um den Zugriff auf Ihre AWS Ressourcen zu kontrollieren, ermöglichen Sie es Ihren Teams und Ressourcen, mit weniger Änderungen an den Richtlinien zu AWS wachsen. ABAC-Richtlinien sind flexibler als herkömmliche AWS Richtlinien, bei denen Sie jede einzelne Ressource auflisten müssen. Weitere Informationen zu ABAC und seinen Vorteilen gegenüber herkömmlichen Richtlinien finden Sie unter [Berechtigungen basierend auf Attributen mit ABAC-Autorisierung definieren](introduction_attribute-based-access-control.md). **Anmerkung** Sie müssen für jedes Sitzungs-Tag einen einzelnen Wert übergeben. AWS -Security-Token-Service unterstützt keine mehrwertigen Sitzungs-Tags. **Topics** + [ ## Tutorial-Übersicht ](#tutorial_attribute-based-access-control-overview) + [ ## Voraussetzungen ](#tutorial_abac_prereqs) + [ ## Schritt 1: Erstellen von Testbenutzern ](#tutorial_abac_step1) + [ ## Schritt 2: Erstellen der ABAC-Richtlinie ](#tutorial_abac_step2) + [ ## Schritt 3: Erstellen von Rollen ](#tutorial_abac_step3) + [ ## Schritt 4: Testen der Erstellung von Secrets ](#tutorial_abac_step4) + [ ## Schritt 5: Testen der Anzeige von Secrets ](#tutorial_abac_step5) + [ ## Schritt 6: Testen der Skalierbarkeit ](#tutorial_abac_step6) + [ ## Schritt 7: Testen des Aktualisierens und Löschens von Secrets ](#tutorial_abac_step7) + [ ## Zusammenfassung ](#tutorial-abac-summary) + [ ## Zugehörige Ressourcen ](#tutorial_abac_related) + [ # IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC ](tutorial_abac-saml.md) ## Tutorial-Übersicht In diesem Tutorial wird gezeigt, wie Sie eine Richtlinie erstellen und testen, die es IAM-Rollen mit Auftraggeber-Tags ermöglicht, auf Ressourcen mit übereinstimmenden Tags zuzugreifen. Wenn ein Auftraggeber eine Anforderung an AWS stellt, werden seine Berechtigungen basierend auf der Tatsache erstellt, ob die Auftraggeber- und Ressourcen-Tags übereinstimmen. Diese Strategie ermöglicht es Einzelpersonen, nur die AWS Ressourcen anzuzeigen oder zu bearbeiten, die für ihre Arbeit erforderlich sind. **Szenario** Nehmen wir an, Sie sind leitender Entwickler bei einem großen Unternehmen mit dem Namen Example Corporation und erfahrener IAM-Administrator. Sie sind mit dem Erstellen und Verwalten von IAM-Benutzern, -Rollen und -Richtlinien vertraut. Sie möchten sicherstellen, dass Ihre Entwicklungsingenieure und die Mitarbeiter des Qualitätssicherungsteams auf die benötigten Ressourcen zugreifen können. Sie benötigen außerdem eine Strategie, die sich an das Wachstum Ihres Unternehmens anpassen lässt. Sie entscheiden sich dafür, AWS Ressourcen-Tags und IAM-Rollenprinzipal-Tags zu verwenden, um eine ABAC-Strategie für Dienste zu implementieren, die diese unterstützen, beginnend mit. AWS Secrets Manager Informationen dazu, welche Services eine Autorisierung basierend auf Tags unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md). Informationen darüber, welche Tagging-Bedingungsschlüssel Sie in einer Richtlinie mit den Aktionen und Ressourcen der einzelnen Dienste verwenden können, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel](reference_policies_actions-resources-contextkeys.html) für Dienste. AWS Sie können Ihren SAML-basierten Identitätsanbieter oder Webidentitätsanbieter so konfigurieren, dass [Sitzungs-Tags](id_session-tags.md) an AWSübergeben werden. Wenn sich Ihre Mitarbeiter zusammenschließen AWS, werden ihre Attribute auf den daraus resultierenden Principal in angewendet. AWS Sie können dann ABAC verwenden, um Berechtigungen basierend auf diesen Attributen zuzulassen oder abzulehnen. Weitere Informationen dazu, wie die Verwendung von Sitzungs-Tags mit einer SAML-Verbundidentität von diesem Lernprogramm abweicht, finden Sie unter [IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC](tutorial_abac-saml.md). Ihre Mitarbeiter im Bereich Engineering und Qualitätssicherung arbeiten entweder am **Pegasus**- oder am **Unicorn**-Projekt. Sie wählen die folgenden 3-stelligen Projekt- und Team-Tag-Werte aus: + `access-project` = `peg` für das **Pegasus**-Projekt + `access-project` = `uni` für das **Unicorn**-Projekt + `access-team` = `eng` für das Engineering-Team + `access-team` = `qas` für das Qualitätssicherungsteam Darüber hinaus legen Sie fest, dass das Tag „`cost-center`Kostenzuweisung“ erforderlich sein soll, um benutzerdefinierte AWS Abrechnungsberichte zu aktivieren. Weitere Informationen finden Sie unter [Verwendung von Kostenzuordnungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) im *AWS Fakturierung und Kostenmanagement Leitfaden*. **Zusammenfassung der wichtigsten Entscheidungen** + Mitarbeiter melden sich mit IAM-Benutzeranmeldeinformationen an und übernehmen dann die IAM-Rolle für ihr Team und ihr Projekt. Wenn Ihr Unternehmen über ein eigenes Identitätssystem verfügt, können Sie einen Verbund einrichten, damit Mitarbeiter eine Rolle ohne IAM-Benutzer übernehmen können. Weitere Informationen finden Sie unter [IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC](tutorial_abac-saml.md). + Es wird an allen Rollen dieselbe Richtlinie angefügt. Aktionen werden basierend auf Tags zugelassen oder verweigert. + Mitarbeiter können neue Ressourcen erstellen, aber nur, wenn sie der Ressource dieselben Tags zuweisen, die auf ihre Rolle angewendet werden. Auf diese Weise wird sichergestellt, dass Mitarbeiter die Ressource anzeigen können, nachdem sie sie erstellt haben. Administratoren müssen Richtlinien nicht mehr mit dem ARN neuer Ressourcen aktualisieren. + Mitarbeiter können unabhängig vom Projekt die Ressourcen lesen, die ihrem Team gehören. + Mitarbeiter können Ressourcen aktualisieren und löschen, die zu ihrem Team und Projekt gehören. + IAM-Administratoren können eine neue Rolle für neue Projekte hinzufügen. Sie können einen neuen IAM-Benutzer erstellen und markieren, um den Zugriff auf die entsprechende Rolle zu ermöglichen. Administratoren müssen keine Richtlinie bearbeiten, um ein neues Projekt oder Teammitglied zu unterstützen. In diesem Tutorial markieren Sie alle Ressourcen sowie Ihre Projektrollen und fügen Richtlinien zu den Rollen hinzu, um das zuvor beschriebene Verhalten zuzulassen. Die resultierende Richtlinie erlaubt den Rollen `Create`, `Read`, `Update` und `Delete` den Zugriff auf Ressourcen, die mit denselben Projekt- und Team-Tags markiert sind. Die Richtlinie erlaubt auch einen projektübergreifenden `Read`-Zugriff auf Ressourcen, die mit demselben Team markiert sind. ![\[Das Diagramm zeigt zwei Projekte, bei denen die Rollen außerhalb ihres Projekts nur über Lesezugriff verfügen, in ihrem eigenen Projekt jedoch über die Berechtigung zum Erstellen, Lesen, Aktualisieren und Löschen von Ressourcen verfügen.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## Voraussetzungen Um die Schritte in dieser praktischen Anleitung auszuführen, müssen Sie bereits über Folgendes verfügen: + Und AWS-Konto bei dem Sie sich als Benutzer mit Administratorrechten anmelden können. + Ihre 12-stellige Konto-ID, mit der Sie die Rollen in Schritt 3 erstellen. Um Ihre AWS Konto-ID-Nummer mithilfe von zu finden AWS-Managementkonsole, wählen Sie in der Navigationsleiste oben rechts **Support** und dann **Support Center** aus. Die Kontonummer (ID) wird im Navigationsbereich auf der linken Seite angezeigt. ![\[Support Mittelseite mit der Kontonummer.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/account-id-support-center.console.png) + Erfahrung mit dem Erstellen und Bearbeiten von IAM-Benutzern, -Rollen und Richtlinien in der AWS-Managementkonsole. Wenn Sie jedoch Hilfe benötigen, um sich an einen IAM-Verwaltungsprozess zu erinnern, finden Sie in diesem Tutorial Links, über die Sie step-by-step Anweisungen einsehen können. ## Schritt 1: Erstellen von Testbenutzern Erstellen Sie zum Testen vier IAM-Benutzer mit Berechtigungen zum Übernehmen von Rollen mit denselben Tags. Dies erleichtert das Hinzufügen weiterer Benutzer zu Ihren Teams. Wenn Sie die Benutzer markieren, erhalten diese automatisch Zugriff, um die richtige Rolle übernehmen zu können. Sie müssen die Benutzer nicht zur Vertrauensrichtlinie der Rolle hinzufügen, wenn sie nur an einem Projekt und nur in einem Team arbeiten. 1. Erstellen Sie die folgende vom Kunden verwaltete Richtlinie namens `access-assume-role`. Weitere Informationen zum Erstellen einer JSON-Richtlinie finden Sie unter [Erstellen von IAM-Richtlinien](access_policies_create-console.md#access_policies_create-start). **ABAC-Richtlinie: Übernehmen einer beliebigen ABAC-Rolle, aber nur, wenn die Benutzer- und Rollen-Tags übereinstimmen** Mit der folgenden Richtlinie kann ein Benutzer eine beliebige Rolle in Ihrem Konto mit dem `access-`-Namenspräfix übernehmen. Die Rolle muss mit denselben Projekt-, Team- und Kostenstellen-Tags wie der Benutzer markiert sein. Um diese Richtlinie zu verwenden, ersetzen Sie den *kursiv gedruckten Platzhaltertext* durch Ihre eigenen Kontoinformationen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/access-*", "Condition": { "StringEquals": { "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" } } } ] } ``` ------ Damit sich dieses Tutorial für eine große Anzahl von Benutzern eignet, können Sie die Richtlinie einer Gruppe anfügen und alle Benutzer zur Gruppe hinzufügen. Weitere Informationen erhalten Sie unter [Erstellen von IAM-Gruppen](id_groups_create.md) und [Bearbeiten von Benutzern in IAM-Gruppen](id_groups_manage_add-remove-users.md). 1. Erstellen Sie die folgenden IAM-Benutzer und fügen Sie die `access-assume-role`-Berechtigungsrichtlinie an. Stellen Sie sicher, dass Sie **Benutzerzugriff auf AWS-Managementkonsole bereitstellen** auswählen, und fügen Sie dann die folgenden Tags hinzu. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Schritt 2: Erstellen der ABAC-Richtlinie Erstellen Sie die folgende Richtlinie namens **access-same-project-team**. Sie fügen diese Richtlinie den Rollen in einem späteren Schritt hinzu. Weitere Informationen zum Erstellen einer JSON-Richtlinie finden Sie unter [Erstellen von IAM-Richtlinien](access_policies_create-console.md#access_policies_create-start). Weitere Richtlinien, die Sie für dieses Tutorial anpassen können, finden Sie auf den folgenden Seiten: + [Zugriffssteuerung für IAM-Auftraggeber](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2: Ermöglicht es, die von einem Benutzer markierten EC2-Instances programmgesteuert und in der Konsole zu starten oder zu stoppen](reference_policies_examples_ec2_tag-owner.md) + [EC2: Starten oder Stoppen von Instances basierend auf übereinstimmenden Auftraggeber- und Ressourcen-Tags](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2: Instances basierend auf Tags starten oder stoppen](reference_policies_examples_ec2-start-stop-tags.md) + [IAM: Übernehmen von Rollen, die ein bestimmtes Tag haben](reference_policies_examples_iam-assume-tagged-role.md) **ABAC-Richtlinie: Zugriff nur auf Access Secrets Manager-Ressourcen, wenn die Auftraggeber- und Ressourcen-Tags übereinstimmen** Die folgende Richtlinie erlaubt es Auftraggeber, Ressourcen zu erstellen, zu lesen, zu bearbeiten und zu löschen, aber nur, wenn diese Ressourcen mit denselben Schlüssel-Wert-Paaren wie der Auftraggeber markiert sind. Wenn ein Auftraggeber eine Ressource erstellt, muss er die Tags `access-project`, `access-team` und `cost-center` mit Werten hinzufügen, die mit den Tags des Auftraggebers übereinstimmen. Die Richtlinie erlaubt auch das Hinzufügen optionaler `Name`- oder `OwnedBy`-Tags. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllActionsSecretsManagerSameProjectSameTeam", "Effect": "Allow", "Action": "secretsmanager:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "access-project", "access-team", "cost-center", "Name", "OwnedBy" ] }, "StringEqualsIfExists": { "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}", "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}", "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}" } } }, { "Sid": "AllResourcesSecretsManagerNoTags", "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Sid": "ReadSecretsManagerSameTeam", "Effect": "Allow", "Action": [ "secretsmanager:Describe*", "secretsmanager:Get*", "secretsmanager:List*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}" } } }, { "Sid": "DenyUntagSecretsManagerReservedTags", "Effect": "Deny", "Action": "secretsmanager:UntagResource", "Resource": "*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "access-*" } } }, { "Sid": "DenyPermissionsManagement", "Effect": "Deny", "Action": "secretsmanager:*Policy", "Resource": "*" } ] } ``` ------ **Was macht diese Richtlinie?** + Die `AllActionsSecretsManagerSameProjectSameTeam`-Anweisung erlaubt alle Aktionen dieses Services für alle verwandten Ressourcen, aber nur, wenn die Ressourcen-Tags mit den Auftraggeber-Tags übereinstimmen. Durch Hinzufügen von `"Action": "secretsmanager:*"` zur Richtlinie wächst die Richtlinie, wenn Secrets Manager wächst. Wenn Secrets Manager eine neue API-Operation hinzufügt, müssen Sie diese Aktion nicht zur Anweisung hinzufügen. Die Anweisung implementiert ABAC mithilfe von drei Bedingungsblöcken. Die Anforderung ist nur zulässig, wenn alle drei Blöcke "true" zurückgeben. + Der erste Bedingungsblock dieser Anweisung gibt "true" zurück, wenn die angegebenen Tag-Schlüssel in der Ressource vorhanden sind und ihre Werte mit den Tags des Auftraggebers übereinstimmen. Dieser Block gibt „false“ zurück, wenn die Tags nicht übereinstimmen oder wenn Aktionen das Ressourcen-Tagging nicht unterstützen. Welche Aktionen in diesem Block nicht zulässig sind, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html) für. AWS Secrets Manager Diese Seite zeigt, dass Aktionen, die für den [**Secret**-Ressourcentyp](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) durchgeführt werden, den `secretsmanager:ResourceTag/tag-key`-Bedingungsschlüssel unterstützen. Einige [Secrets Manager-Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) unterstützen diesen Ressourcentyp nicht, einschließlich `GetRandomPassword` und `ListSecrets`. Sie müssen zusätzliche Anweisungen erstellen, um diese Aktionen zuzulassen. + Der zweite Bedingungsblock gibt "true" zurück, wenn jeder Tag-Schlüssel, der in der Anforderung übergeben wurde, in der angegebenen Liste enthalten ist. Dies erfolgt unter Verwendung von `ForAllValues` mit dem `StringEquals`-Bedingungsoperator. Wenn keine Schlüssel oder keine Teilmenge des Schlüsselsatzes übergeben werden, gibt die Bedingung „true“ zurück. Dies ermöglicht `Get*`-Operationen, die keine Übergabe von Tags in der Anforderung zulassen. Wenn der Anforderer einen Tag-Schlüssel enthält, der nicht in der Liste enthalten ist, gibt die Bedingung "false" zurück. Jeder Tag-Schlüssel, der in der Anforderung übergeben wird, muss mit einem Mitglied dieser Liste übereinstimmen. Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). + Der dritte Bedingungsblock gibt „true“ zurück, wenn die Anforderung die Übergabe von Tags unterstützt, wenn alle drei Tags vorhanden sind und wenn sie mit den Auftraggeber-Tag-Werten übereinstimmen. Dieser Block gibt auch "true" zurück, wenn die Anforderung die Übergabe von Tags nicht unterstützt. Dies liegt an [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) im Bedingungsoperator. Der Block gibt "false" zurück, wenn während einer Aktion, die das unterstützt, kein Tag übergeben wird oder wenn die Tag-Schlüssel und -Werte nicht übereinstimmen. + Die `AllResourcesSecretsManagerNoTags`-Anweisung erlaubt die Aktionen `ListSecrets` und `GetRandomPassword`, die von der ersten Anweisung nicht zugelassen werden. + Die `ReadSecretsManagerSameTeam`-Anweisung erlaubt schreibgeschützte Operationen, wenn der Auftraggeber mit demselben access-team-Tag wie die Ressource markiert ist. Dies ist unabhängig vom Projekt- oder Kostenstellen-Tag zulässig. + Die `DenyUntagSecretsManagerReservedTags`-Anweisung lehnt Anforderungen zum Entfernen von Tags mit Schlüsseln, die mit "access-" beginnen, aus Secrets Manager ab. Diese Tags werden verwendet, um den Zugriff auf Ressourcen zu steuern. Das Entfernen von Tags kann daher dazu führen, dass auch Berechtigungen entfernt werden. + Die `DenyPermissionsManagement`-Anweisung verweigert den Zugriff zum Erstellen, Bearbeiten oder Löschen von ressourcenbasierten Secrets Manager-Richtlinien. Diese Richtlinien können verwendet werden, um die Berechtigungen des Secrets zu ändern. **Wichtig** Diese Richtlinie verwendet eine Strategie, bei der alle Aktionen für einen Service zugelassen werden, es sei denn, es handelt sich um Aktionen, durch die Berechtigungen geändert werden. Wird eine Aktion verweigert, wird jede andere Richtlinie außer Kraft gesetzt, die es dem Auftraggeber erlaubt, diese Aktion auszuführen. Dies kann unerwünschte Ergebnisse nach sich ziehen. Es hat sich bewährt, explizite Zugriffsverweigerungen nur einzusetzen, wenn es keine Umstände gibt, die dazu führen, dass diese Aktion zugelassen werden sollte. Lassen Sie andernfalls eine Liste einzelner Aktionen zu, und die unerwünschten Aktionen werden standardmäßig verweigert. ## Schritt 3: Erstellen von Rollen Erstellen Sie die folgenden IAM-Rollen und fügen Sie die **access-same-project-team**-Richtlinie an, die Sie im vorherigen Schritt erstellt haben. Weitere Informationen zum Erstellen einer IAM-Rolle finden Sie unter [Erstellen einer Rolle zum Erteilen von Berechtigungen an einen IAM-Benutzer](id_roles_create_for-user.md). Informationen zur Verwendung eines Verbunds anstelle von IAM-Benutzern und -Rollen finden Sie unter [IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC](tutorial_abac-saml.md). | Auftragsfunktion | Rollenname | Rollen-Tags | Rollenbeschreibung | | --- | --- | --- | --- | | Projekt Pegasus Engineering | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | Ermöglicht es Ingenieuren, alle Engineering-Ressourcen zu lesen und Pegasus-Engineering-Ressourcen zu erstellen und zu verwalten. | | Qualitätssicherung für das Pegasus-Projekt | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | Ermöglicht dem QA-Team, alle QA-Ressourcen zu lesen und alle QA-Ressourcen des Pegasus-Projekts zu erstellen und zu verwalten. | | Projekt Unicorn Engineering | access-uni-engineering | access-project = `uni` access-team = `eng` cost-center = `123456` | Ermöglicht es Ingenieuren, alle Engineering-Ressourcen zu lesen und alle Engineering-Ressourcen des Unicorn-Projekts zu erstellen und zu verwalten. | | Qualitätssicherung für Project Unicorn | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | Ermöglicht dem QA-Team, alle QA-Ressourcen zu lesen und alle QA-Ressourcen des Unicorn-Projekts zu erstellen und zu verwalten. | ## Schritt 4: Testen der Erstellung von Secrets Die Berechtigungsrichtlinie, die den Rollen angefügt ist, ermöglicht es den Mitarbeitern, Secrets zu erstellen. Dies ist nur zulässig, wenn das Secret mit dem Projekt, dem Team und der Kostenstelle markiert ist. Vergewissern Sie sich, dass Ihre Berechtigungen wie erwartet funktionieren, indem Sie sich als Ihre Benutzer anmelden, die richtige Rolle übernehmen und Aktivitäten in Secrets Manager testen. **So testen Sie das Erstellen eines Secrets mit und ohne die erforderlichen Tags** 1. Bleiben Sie im Hauptbrowserfenster als Administratorbenutzer angemeldet, sodass Sie Benutzer, Rollen und Richtlinien in IAM überprüfen können. Verwenden Sie ein Browser-Inkognito-Fenster oder einen separaten Browser für Ihre Tests. Melden Sie sich dort als `access-Arnav-peg-eng` IAM-Benutzer an und öffnen Sie die Secrets Manager Manager-Konsole unter [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Versuchen Sie, zur `access-uni-engineering`-Rolle zu wechseln. Diese Operation schlägt fehl, da die `access-project`- und `cost-center`-Tag-Werte für den Benutzer `access-Arnav-peg-eng` und die Rolle `access-uni-engineering` nicht übereinstimmen. Weitere Informationen zum Rollenwechsel in der finden Sie AWS-Managementkonsole unter [Von einem Benutzer zu einer IAM-Rolle wechseln (Konsole)](id_roles_use_switch-role-console.md) 1. Wechseln Sie zur `access-peg-engineering`-Rolle. 1. Speichern Sie ein neues Secret mit den folgenden Informationen. Weitere Informationen zum Speichern eines Secrets finden Sie unter [Erstellen eines Basis-Secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) im *AWS Secrets Manager -Leitfaden*. **Wichtig** Secrets Manager zeigt Warnmeldungen an, da Sie keine Berechtigungen für zusätzliche AWS -Services haben, die mit Secrets Manager funktionieren. Um beispielsweise Anmeldeinformationen für eine Amazon RDS-Datenbank zu erstellen, benötigen Sie die Berechtigung zum Beschreiben von RDS-Instances, sowie RDS- und Amazon Redshift-Clustern. Sie können diese Benachrichtigungen ignorieren, da Sie diese speziellen AWS Dienste in diesem Tutorial nicht verwenden. 1. Wählen Sie im Abschnitt **Select secret type (Secret-Typ auswählen)** die Option **Other type of secrets (Andere Secret-Typen)**. Geben Sie in die beiden Textfelder `test-access-key` und `test-access-secret` ein. 1. Geben Sie `test-access-peg-eng` in das Feld **Secret name (Secret-Name)** ein. 1. Fügen Sie verschiedene Tag-Kombinationen aus der folgenden Tabelle hinzu und überprüfen Sie das erwartete Verhalten. 1. Wählen Sie **Store (Speichern)** aus, um zu versuchen, das Secret zu erstellen. Kehren Sie zu den vorherigen Seiten der Secrets Manager-Konsole zurück, wenn das Speichern fehlschlägt, und verwenden Sie den nächsten Tag-Satz aus der folgenden Tabelle. Der letzte Tag-Satz ist zulässig und erstellt erfolgreich das Secret. Die folgende Tabelle zeigt ABAC-Tag-Kombinationen für die Rolle `test-access-peg-eng`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Melden Sie sich ab und wiederholen Sie die ersten drei Schritte dieses Verfahrens für alle folgenden Rollen und Tag-Werte. Testen Sie im vierten Schritt dieses Verfahrens alle von Ihnen ausgewählten fehlenden Tags, optionalen Tags, unzulässigen Tags und ungültigen Tag-Werte. Verwenden Sie dann die erforderlichen Tags, um ein Secret mit den folgenden Tags und dem folgenden Namen zu erstellen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Schritt 5: Testen der Anzeige von Secrets Die Richtlinie, die Sie an die einzelnen Rollen angefügt haben, ermöglicht den Mitarbeitern unabhängig vom Projekt, alle Secrets anzuzeigen, die mit ihrem Teamnamen markiert sind. Vergewissern Sie sich, dass Ihre Berechtigungen wie erwartet funktionieren, indem Sie Ihre Rollen in Secrets Manager testen. **So testen Sie die Anzeige eines Secrets mit und ohne die erforderlichen Tags** 1. Melden Sie sich als einer der folgenden IAM-Benutzer an: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` 1. Wechseln Sie zur übereinstimmenden Rolle: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-uni-quality-assurance` Weitere Informationen zum Rollenwechsel in der finden Sie AWS-Managementkonsole unter. [Von einem Benutzer zu einer IAM-Rolle wechseln (Konsole)](id_roles_use_switch-role-console.md) 1. Klicken Sie im Navigationsbereich auf der linken Seite auf das Menüsymbol, um das Menü zu erweitern, und wählen Sie dann **Secrets** aus. 1. Sie sollten alle vier Secrets in der Tabelle sehen, unabhängig von Ihrer aktuellen Rolle. Das wird erwartet, da die Richtlinie namens `access-same-project-team` die Aktion `secretsmanager:ListSecrets` für alle Ressourcen zulässt. 1. Wählen Sie den Namen eines der Secrets. 1. Auf der Detailseite für das Secret bestimmen die Tags Ihrer Rolle, ob Sie den Seiteninhalt anzeigen können. Vergleichen Sie den Namen Ihrer Rolle mit dem Namen Ihres Secrets. Wenn sie denselben Teamnamen haben, stimmen die `access-team`-Tags überein. Wenn sie nicht übereinstimmen, wird der Zugriff verweigert. Die folgende Tabelle zeigt das Anzeigeverhalten von ABAC-Geheimnissen für jede Rolle. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Wählen Sie aus den Breadcrumbs oben auf der Seite **Secrets** aus, um zur Liste der Secrets zurückzukehren. Wiederholen Sie die Schritte in diesem Verfahren mit verschiedenen Rollen, um zu testen, ob Sie alle Secrets anzeigen können. ## Schritt 6: Testen der Skalierbarkeit Ein wichtiger Grund für die Verwendung der attributbasierten Zugriffskontrolle (ABAC) anstelle der rollenbasierten Zugriffskontrolle (RBAC) ist die Skalierbarkeit. Wenn Ihr Unternehmen neue Projekte, Teams oder Mitarbeiter hinzufügt AWS, müssen Sie Ihre ABAC-basierten Richtlinien nicht aktualisieren. Nehmen wir beispielsweise an, dass Example Company ein neues Projekt mit dem Namen **Centaur** finanziert. Eine Ingenieurin namens Saanvi Sarkar wird die leitende Ingenieurin für das **Centaur**-Projekt sein, aber weiterhin am **Unicorn**-Projekt mitarbeiten. Saanvi wird auch die Arbeiten für das **Peg**-Projekt überprüfen. Es gibt auch mehrere neu eingestellte Ingenieure, darunter Nikhil Jayashankar, die nur am **Centaur**-Projekt arbeiten werden. **Um das neue Projekt hinzuzufügen AWS** 1. Melden Sie sich als IAM-Administratorbenutzer an und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 1. Wählen Sie links im Navigationsbereich **Roles (Rollen)** aus und fügen Sie eine IAM-Rolle namens `access-cen-engineering` hinzu. Fügen Sie die **access-same-project-team**-Berechtigungsrichtlinie an die Rolle an und fügen Sie folgenden Rollen-Tags hinzu: + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Wählen Sie im Navigationsbereich auf der linken Seite **Users (Benutzer)**. 1. Fügen Sie einen neuen Benutzer mit dem Namen `access-Nikhil-cen-eng` hinzu, fügen Sie die Richtlinie namens `access-assume-role` an und fügen Sie die folgenden Benutzer-Tags hinzu. + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Verwenden Sie die Verfahren in [Schritt 4: Testen der Erstellung von Secrets](#tutorial_abac_step4) und [Schritt 5: Testen der Anzeige von Secrets](#tutorial_abac_step5). Vergewissern Sie sich in einem anderen Browserfenster, dass Nikhil nur **Centaur**-Engineering-Secrets erstellen kann und dass er alle Engineering-Secrets anzeigen kann. 1. Wählen Sie im Hauptfenster des Browsers, in dem Sie sich als Administrator angemeldet haben, den Benutzer `access-Saanvi-uni-eng`. 1. Entfernen Sie auf der Registerkarte ****access-assume-role**Berechtigungen** die Berechtigungsrichtlinie. 1. Fügen Sie die folgende Inlinerichtlinie namens `access-assume-specific-roles` hinzu. Weitere Informationen zum Hinzufügen einer Inlinerichtlinie zu einem Benutzer finden Sie unter [So betten Sie eine eingebundene Richtlinie für einen Benutzer oder eine Rolle ein (Konsole)](access_policies_manage-attach-detach.md#embed-inline-policy-console). **ABAC-Richtlinie: Nur bestimmte Rollen übernehmen** Diese Richtlinie erlaubt Saanvi, die Engineering-Rollen für das **Pegasus**- oder **Centaur**-Projekt anzunehmen. Diese benutzerdefinierte Richtlinie muss erstellt werden, da IAM keine mehrwertigen Tags unterstützt. Sie können den Benutzernamen von Saanvi nicht mit `access-project` = `peg` und `access-project` = `cen` markieren. Darüber hinaus kann das AWS Autorisierungsmodell nicht beiden Werten entsprechen. Weitere Informationen finden Sie unter [Regeln für das Tagging in IAM und AWS STS](id_tags.md#id_tags_rules). Stattdessen müssen Sie die beiden Rollen, die sie übernehmen kann, manuell angeben. Um diese Richtlinie zu verwenden, ersetzen Sie den *kursiv gedruckten Platzhaltertext* durch Ihre eigenen Kontoinformationen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. Verwenden Sie die Verfahren in [Schritt 4: Testen der Erstellung von Secrets](#tutorial_abac_step4) und [Schritt 5: Testen der Anzeige von Secrets](#tutorial_abac_step5). Bestätigen Sie in einem anderen Browserfenster, dass Saanvi beide Rollen übernehmen kann. Stellen Sie sicher, dass sie je nach den Tags der Rolle nur für ihr Projekt, ihr Team und ihre Kostenstelle Secrets erstellen kann. Bestätigen Sie auch, dass sie Details zu allen Secrets des Engineering-Teams anzeigen kann, einschließlich der Secrets, die sie gerade erstellt hat. ## Schritt 7: Testen des Aktualisierens und Löschens von Secrets Die `access-same-project-team`-Richtlinie, die den Rollen angefügt ist, ermöglicht es den Mitarbeitern, alle Secrets zu aktualisieren und zu löschen, die mit ihrem Projekt, ihrem Team und ihrer Kostenstelle markiert sind. Vergewissern Sie sich, dass Ihre Berechtigungen wie erwartet funktionieren, indem Sie Ihre Rollen in Secrets Manager testen. **So testen Sie das Aktualisieren und Löschen eines Secrets mit und ohne die erforderlichen Tags** 1. Melden Sie sich als einer der folgenden IAM-Benutzer an: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` + `access-Nikhil-cen-eng` 1. Wechseln Sie zur übereinstimmenden Rolle: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-peg-quality-assurance` + `access-cen-engineering` Weitere Informationen zum Rollenwechsel finden Sie AWS-Managementkonsole unter[Von einem Benutzer zu einer IAM-Rolle wechseln (Konsole)](id_roles_use_switch-role-console.md). 1. Versuchen Sie für jede Rolle, die Secret-Beschreibung zu aktualisieren, und versuchen Sie dann, die folgenden Secrets zu löschen. Weitere Informationen finden Sie unter [Ändern eines Secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) und [Löschen und Wiederherstellen eines Secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) im *AWS Secrets Manager -Leitfaden*. Die folgende Tabelle zeigt das Aktualisierungs- und Löschverhalten von ABAC-Geheimnissen für jede Rolle. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Zusammenfassung Sie haben nun alle erforderlichen Schritte zur Verwendung von Tags für die attributbasierte Zugriffskontrolle (ABAC) erfolgreich abgeschlossen. Sie haben gelernt, wie Sie eine Tagging-Strategie definieren. Sie haben diese Strategie auf Ihre Auftraggeber und Ressourcen angewendet. Sie haben eine Richtlinie erstellt und angewendet, die die Strategie für Secrets Manager durchsetzt. Sie haben auch gelernt, dass ABAC einfach skaliert werden kann, wenn Sie neue Projekte und Teammitglieder hinzufügen möchten. Daher können Sie sich mit Ihren Testrollen bei der IAM-Konsole anmelden und erfahren, wie Sie Tags für ABAC in AWS verwenden. **Anmerkung** Sie haben Richtlinien hinzugefügt, die Aktionen nur unter bestimmten Bedingungen zulassen. Wenn Sie eine andere Richtlinie auf Ihre Benutzer oder Rollen anwenden, die über breitere Berechtigungen verfügen, sind die Aktionen möglicherweise nicht auf Tagging beschränkt. Wenn Sie einem Benutzer beispielsweise mithilfe der `AdministratorAccess` AWS verwalteten Richtlinie vollständige Administratorrechte gewähren, wird dieser Zugriff durch diese Richtlinien nicht eingeschränkt. Weitere Informationen dazu, wie Berechtigungen festgelegt werden, wenn mehrere Richtlinien beteiligt sind, finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md). ## Zugehörige Ressourcen Weitere Informationen finden Sie in den folgenden Ressourcen: + [Berechtigungen basierend auf Attributen mit ABAC-Autorisierung definieren](introduction_attribute-based-access-control.md) + [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md) + [Erstellen einer Rolle zum Erteilen von Berechtigungen an einen IAM-Benutzer](id_roles_create_for-user.md) + [Tags für AWS Identity and Access Management Ressourcen](id_tags.md) + [Steuern des Zugriffs auf AWS Ressourcen mithilfe von Tags](access_tags.md) + [Von einem Benutzer zu einer IAM-Rolle wechseln (Konsole)](id_roles_use_switch-role-console.md) + [IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC](tutorial_abac-saml.md) Informationen zur Überwachung der Tags in Ihrem Konto finden Sie unter [Überwachen von Tag-Änderungen auf AWS Ressourcen mit serverlosen Workflows und Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/). # IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC Die attributbasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, bei der Berechtigungen basierend auf Attributen definiert werden. In AWS werden diese Attribute als Tags bezeichnet. Sie können Tags an IAM-Ressourcen, einschließlich IAM-Entitäten (Benutzer oder Rollen), und an AWS Ressourcen anhängen. Wenn die Entitäten für Anfragen verwendet werden, werden sie zu Principals AWS, und diese Principals enthalten Tags. Sie können [Sitzungs-Tags](id_session-tags.md) auch übergeben, wenn Sie eine Rolle übernehmen oder einen Benutzer in einen Verbund aufnehmen. Anschließend können Sie Richtlinien definieren, die Tag-Bedingungsschlüssel verwenden, um Ihren Auftraggeber basierend auf ihren Tags Berechtigungen zu erteilen. Wenn Sie Tags verwenden, um den Zugriff auf Ihre AWS -Ressourcen zu steuern, erlauben Sie Ihren Teams und Ressourcen das Wachsen, ohne dass viele Änderungen an AWS -Richtlinien vorgenommen werden müssen. ABAC-Richtlinien sind flexibler als herkömmliche AWS Richtlinien, bei denen Sie jede einzelne Ressource auflisten müssen. Weitere Informationen zu ABAC und seinen Vorteilen gegenüber herkömmlichen Richtlinien finden Sie unter [Berechtigungen basierend auf Attributen mit ABAC-Autorisierung definieren](introduction_attribute-based-access-control.md). Wenn Ihr Unternehmen einen SAML-basierten Identitätsanbieter (IdP) verwendet, um Unternehmens-Benutzeridentitäten zu verwalten, können Sie SAML-Attribute für eine differenzierte Zugriffskontrolle in AWS verwenden. Zu den Attributen können Kostenstellenkennungen, Benutzer-E-Mail-Adressen, Abteilungsklassifizierungen und Projektzuweisungen gehören. Wenn Sie diese Attribute als Sitzungs-Tags übergeben, können Sie den Zugriff auf AWS basierend auf diesen Sitzungs-Tags steuern. Um zum Abschluss des [ABAC-Tutorials](tutorial_attribute-based-access-control.md) SAML-Attribute an den Sitzungsauftraggeber zu übergeben, führen Sie die Aufgaben in [IAM-Tutorial: Berechtigungen für den Zugriff auf AWS Ressourcen auf der Grundlage von Tags definieren](tutorial_attribute-based-access-control.md) mit den in diesem Thema enthaltenen Änderungen. ## Voraussetzungen Um die Schritte zur Verwendung von SAML-Sitzungs-Tags für ABAC durchzuführen, müssen Sie bereits über Folgendes verfügen: + Zugriff auf einen SAML-basierten Identitätsanbieter, bei dem Sie Testbenutzer mit bestimmten Attributen erstellen können. + Die Fähigkeit zum Anmelden als ein Benutzer mit Administratorberechtigung. + Erfahrung mit dem Erstellen und Bearbeiten von IAM-Benutzern, -Rollen und Richtlinien in der AWS-Managementkonsole. Wenn Sie jedoch Hilfe benötigen, um sich an einen IAM-Verwaltungsprozess zu erinnern, finden Sie im ABAC-Tutorial Links, über die Sie Anweisungen einsehen können. step-by-step + Erfahrung mit dem Einrichten eines SAML-basierten Identitätsanbieters in IAM. Weitere Details und Links zur ausführlichen IAM-Dokumentation finden Sie unter [Übergabe von Sitzungs-Tags mithilfe von AssumeRoleWith SAML](id_session-tags.md#id_session-tags_adding-assume-role-saml). ## Schritt 1: Erstellen von Testbenutzern Überspringen Sie die Anweisungen in [Schritt 1: Erstellen von Testbenutzern](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Da Ihre Identitäten bei Ihrem Anbieter definiert sind, müssen Sie keine IAM-Benutzer für Ihre Mitarbeiter hinzufügen. ## Schritt 2: Erstellen der ABAC-Richtlinie Befolgen Sie die Anweisungen unter [Schritt 2: Erstellen der ABAC-Richtlinie](tutorial_attribute-based-access-control.md#tutorial_abac_step2), um die angegebene verwaltete Richtlinie in IAM zu erstellen. ## Schritt 3: Erstellen und Konfigurieren der SAML-Rolle Wenn Sie das ABAC-Tutorial für SAML verwenden, müssen Sie zusätzliche Schritte ausführen, um die Rolle zu erstellen, den SAML-IdP zu konfigurieren und den Zugriff zu aktivieren. AWS-Managementkonsole Weitere Informationen finden Sie unter [Schritt 3: Erstellen von Rollen](tutorial_attribute-based-access-control.md#tutorial_abac_step3). ### Schritt 3A: Erstellen der SAML-Rolle Erstellen Sie eine einzelne Rolle, die Ihrem SAML-Identitätsanbieter und dem IAM-Benutzer `test-session-tags` vertraut, den Sie in Schritt 1 erstellt haben. Das ABAC-Tutorial verwendet separate Rollen mit unterschiedlichen Rollen-Tags. Da Sie Sitzungs-Tags von Ihrem SAML-Identitätsanbieter übergeben, benötigen Sie nur eine Rolle. Informationen zum Erstellen einer SAML-basierten Rolle finden Sie unter [Rollen für den SAML 2.0-Verbund erstellen (Konsole)](id_roles_create_for-idp_saml.md). Benennen Sie die Rolle `access-session-tags`. Fügen Sie die Berechtigungsrichtlinie `access-same-project-team` der Rolle an. Bearbeiten Sie die Rollenvertrauensrichtlinie, um die folgende Richtlinie zu verwenden. Ausführliche Anweisungen zum Bearbeiten der Vertrauensstellung einer Rolle finden Sie unter [Rollenvertrauensrichtlinie aktualisieren](id_roles_update-role-trust-policy.md). Mit der folgenden Rollenvertrauensrichtlinie können Ihr SAML-Identitätsanbieter und der `test-session-tags`-Benutzer die Rolle übernehmen. Wenn sie die Rolle übernehmen, müssen sie die drei angegebenen Sitzungs-Tags übergeben. Die `sts:TagSession`-Aktion ist erforderlich, um die Übergabe von Sitzungs-Tags zu ermöglichen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] } ``` ------ Die `AllowSamlIdentityAssumeRole` Erklärung ermöglicht es Mitgliedern der Engineering- und Qualitätssicherungsteams, diese Rolle zu übernehmen, wenn sie sich zum IdP AWS der Example Corporation zusammenschließen. Der SAML-Anbieter `ExampleCorpProvider` ist in IAM definiert. Der Administrator hat die SAML-Zusicherung bereits so eingerichtet, dass die drei erforderlichen Sitzungs-Tags übergeben werden. Die Zusicherung kann zusätzliche Tags übergeben, aber diese drei müssen vorhanden sein. Die Attribute der Identität können einen beliebigen Wert für die Tags`cost-center` und `access-project` haben. Der Wert des Attributs `access-team` muss jedoch `eng` oder `qas` entsprechen, um anzugeben, dass sich die Identität im Engineering- oder Qualitätssicherungsteam befindet. ### Schritt 3B: Konfigurieren des SAML-Identitätsanbieters Konfigurieren Sie Ihren SAML-Identitätsanbieter so, dass die Attribute `cost-center`, `access-project` und`access-team` als Sitzungs-Tags übergeben werden. Weitere Informationen finden Sie unter [Übergabe von Sitzungs-Tags mithilfe von AssumeRoleWith SAML](id_session-tags.md#id_session-tags_adding-assume-role-saml). Um diese Attribute als Sitzungs-Tags zu übergeben, schließen Sie die folgenden Elemente in Ihre SAML-Zusicherung ein. ``` 987654 peg eng ``` ### Schritt 3C: Aktivieren des Konsolenzugriffs Aktivieren Sie den Konsolenzugriff für Ihre verbundenen SAML-Benutzer. Weitere Informationen finden Sie unter [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md). ## Schritt 4: Testen der Erstellung von Secrets Schließen Sie sich der Rolle an, die diese Rolle AWS-Managementkonsole verwendet. `access-session-tags` Weitere Informationen finden Sie unter [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md). Folgen Sie dann den Anweisungen in [Schritt 4: Testen der Erstellung von Secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step4), um Secrets zu erstellen. Verwenden Sie verschiedene SAML-Identitäten mit Attributen, um den im ABAC-Tutorial angegebenen Tags zu entsprechen. Weitere Informationen finden Sie unter [Schritt 4: Testen der Erstellung von Secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step4). ## Schritt 5: Testen der Anzeige von Secrets Folgen Sie den Anweisungen in [Schritt 5: Testen der Anzeige von Secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step5), um die Secrets anzuzeigen, die Sie im vorherigen Schritt erstellt haben. Verwenden Sie verschiedene SAML-Identitäten mit Attributen, um den im ABAC-Tutorial angegebenen Tags zu entsprechen. ## Schritt 6: Testen der Skalierbarkeit Befolgen Sie die Anweisungen in [Schritt 6: Testen der Skalierbarkeit](tutorial_attribute-based-access-control.md#tutorial_abac_step6), um die Skalierbarkeit zu testen. Fügen Sie dazu eine neue Identität mit den folgenden Attributen bei Ihrem SAML-basierten Identitätsanbieter hinzu: + `cost-center = 101010` + `access-project = cen` + `access-team = eng` ## Schritt 7: Testen des Aktualisierens und Löschens von Secrets Folgen Sie den Anweisungen in [Schritt 7: Testen des Aktualisierens und Löschens von Secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step7), um Secrets zu aktualisieren und zu löschen. Verwenden Sie verschiedene SAML-Identitäten mit Attributen, um den im ABAC-Tutorial angegebenen Tags zu entsprechen. **Wichtig** Löschen Sie alle Secrets, die Sie erstellt haben, um Abrechnungsgebühren zu vermeiden. Informationen zu den Preisen in Secrets Manager finden Sie unter [AWS Secrets Manager -Preise](https://aws.amazon.com/secrets-manager/pricing/). ## Zusammenfassung Sie haben nun alle Schritte erfolgreich abgeschlossen, die erforderlich sind, um SAML-Sitzungstags und Ressourcen-Tags für die Berechtigungsverwaltung verwenden zu können. **Anmerkung** Sie haben Richtlinien hinzugefügt, die Aktionen nur unter bestimmten Bedingungen zulassen. Wenn Sie eine andere Richtlinie auf Ihre Benutzer oder Rollen anwenden, die über breitere Berechtigungen verfügen, sind die Aktionen möglicherweise nicht auf Tagging beschränkt. Wenn Sie einem Benutzer beispielsweise mithilfe der `AdministratorAccess` AWS verwalteten Richtlinie vollständige Administratorrechte gewähren, wird dieser Zugriff durch diese Richtlinien nicht eingeschränkt. Weitere Informationen dazu, wie Berechtigungen festgelegt werden, wenn mehrere Richtlinien beteiligt sind, finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md). # IAM-Tutorial: Zulassen, dass Ihre Benutzer ihre eigenen Anmeldeinformationen und MFA-Einstellungen konfigurieren können Sie können Ihren Benutzern ermöglichen, ihre eigenen Multi-Faktor-Authentifizierungsgeräte (MFA) und Anmeldeinformationen auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. Sie können den verwenden, AWS-Managementkonsole um Anmeldeinformationen (Zugriffsschlüssel, Passwörter, Signaturzertifikate und öffentliche SSH-Schlüssel) zu konfigurieren, nicht benötigte Anmeldeinformationen zu löschen oder zu deaktivieren und MFA-Geräte für Ihre Benutzer zu aktivieren. Dies ist für eine kleine Anzahl von Benutzern nützlich, diese Aufgabe kann jedoch schnell zeitaufwändig werden, wenn die Anzahl der Benutzer zunimmt. Ziel dieses Tutorials ist es, Ihnen zu zeigen, wie Sie diese bewährten Methoden umsetzen, ohne Ihre Administratoren zu belasten. In diesem Tutorial wird gezeigt, wie Sie Benutzern den Zugriff auf AWS Dienste ermöglichen, jedoch **nur**, wenn sie sich mit MFA anmelden. Wenn sie nicht mit einem MFA-Gerät angemeldet sind, können Benutzer nicht auf andere Services zugreifen. Dieser Workflow umfasst drei grundlegende Schritte. **[Schritt 1: Erstellen einer Richtlinie zum Erzwingen der MFA-Anmeldung](#tutorial_mfa_step1)** Erstellen einer vom Kunden verwalteten Richtlinie, die alle Aktionen verbietet ***außer*** die wenigen IAM-Aktionen. Diese Ausnahmen ermöglichen es einem Benutzer, seine eigenen Anmeldeinformationen zu ändern und seine MFA-Geräte auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. Weitere Informationen zum Zugriff auf diese Seite finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **[Schritt 2: Zuweisen von Richtlinien zu Ihrer Testgruppe](#tutorial_mfa_step2)** Erstellen Sie eine Gruppe, deren Mitglieder vollen Zugriff auf alle Amazon EC2-Aktionen haben, wenn sie sich mit MFA anmelden. Um eine solche Benutzergruppe zu erstellen, fügen Sie sowohl die aufgerufene AWS verwaltete Richtlinie als `AmazonEC2FullAccess` auch die vom Kunden verwaltete Richtlinie hinzu, die Sie im ersten Schritt erstellt haben. **[Schritt 3: Testen des Benutzerzugriffs](#tutorial_mfa_step3)** Melden Sie sich als Testbenutzer an, um zu überprüfen, ob der Zugriff auf Amazon EC2 blockiert ist, *bis* der Benutzer ein MFA-Gerät erstellt. Der Benutzer kann sich dann mit diesem Gerät anmelden. ## Voraussetzungen Um die Schritte in dieser praktischen Anleitung auszuführen, müssen Sie bereits über Folgendes verfügen: + Und AWS-Konto bei der Sie sich als IAM-Benutzer mit Administratorrechten anmelden können. + Ihre Konto-ID, die Sie in Schritt 1 in die Richtlinie eingeben. Um Ihre Konto-ID-Nummer zu finden, wählen Sie auf der Navigationsleiste oben auf der Seite die Option **Support** aus und klicken Sie dann auf **Support Center**. Sie finden Ihre Konto-ID im Menü **Support** dieser Seite. + Ein [virtuelles (softwarebasiertes) MFA-Gerät](id_credentials_mfa_enable_virtual.md), [FIDO-Sicherheitsschlüssel](id_credentials_mfa_enable_fido.md) oder [hardwarebasiertes MFA-Gerät](id_credentials_mfa_enable_physical.md). + Ein IAM-Testbenutzer, der ein Mitglied einer Gruppe wie folgt ist: | Benutzername | Anweisungen zum Benutzernamen | Benutzergruppenname | Hinzufügen des Benutzers als Mitglied | Anweisungen zu Benutzergruppen | | --- | --- | --- | --- | --- | | MFAUser | Wählen Sie nur die Option für Enable console access – optional (Konsolenzugriff aktivieren – optional aus und weisen Sie ein Passwort zu. | EC2MFA | MFAUser | Ordnen Sie dieser Gruppe KEINE Richtlinien zu und erteilen Sie anderweitig Berechtigungen. | ## Schritt 1: Erstellen einer Richtlinie zum Erzwingen der MFA-Anmeldung Sie beginnen mit dem Erstellen einer vom Kunden verwalteten IAM-Richtlinie, die alle Berechtigungen verweigert, mit Ausnahme derer, die erforderlich sind, damit IAM-Benutzer ihre eigenen Anmeldeinformationen und MFA-Geräte verwalten können. 1. Melden Sie sich als Benutzer mit Administratoranmeldedaten bei der AWS Management Console an. Melden Sie sich nicht mit Ihren Root-Benutzer des AWS-Kontos Anmeldeinformationen an, um sich an die Best Practices für IAM zu halten. **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. 1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole. 1. Wählen Sie im Navigationsbereich **Policies (Richtlinien)** und dann **Create policy (Richtlinie erstellen)**. 1. Wählen Sie die Registerkarte **JSON** aus und kopieren Sie den Text aus dem folgenden JSON-Richtliniendokument: [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md). 1. Fügen Sie den folgenden Text in das **JSON**-Eingabefeld ein. Beheben Sie alle Sicherheitswarnungen, Fehler oder allgemeinen Warnungen, die während der Richtlinien-Validierung erzeugt wurden, und wählen Sie dann **Next** (Weiter) aus. **Anmerkung** Sie können jederzeit zwischen den Optionen **Visual-Editor** und **JSON** wechseln. Die Richtlinie oben enthält jedoch das `NotAction`-Element, welches im visuellen Editor nicht unterstützt wird. Für diese Richtlinie wird eine Benachrichtigung auf der Registerkarte **Visual-Editor (Visueller Editor)** angezeigt. Kehren Sie zu **JSON** zurück, um weiter mit dieser Richtlinie zu arbeiten. Diese Beispielrichtlinie erlaubt es Benutzern nicht, ein Passwort zurückzusetzen, wenn sie sich zum ersten Mal bei AWS-Managementkonsole anmelden. Wir empfehlen, dass Sie neuen Benutzern keine Berechtigungen erteilen, bis sie sich angemeldet haben. 1. Geben Sie auf der Seite **Review and create** (Überprüfen und erstellen) als Richtliniennamen **Force\$1MFA** ein. Geben Sie für die Richtlinienbeschreibung im Abschnitt **Tags** **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.** ein. Optional können Sie Tag-Schlüssel-Wert-Paare zur vom Kunden verwalteten Richtlinie hinzufügen. Ü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 und ist bereit. ## Schritt 2: Zuweisen von Richtlinien zu Ihrer Testgruppe Als Nächstes ordnen Sie der Test-IAM-Benutzergruppe zwei Richtlinien zu, die für die Erteilung der MFA-geschützten Berechtigungen verwendet werden. 1. Klicken Sie im Navigationsbereich auf **Groups oder Users**. 1. Geben Sie **`EC2MFA`** in das Suchfeld ein und wählen Sie dann den Gruppennamen (nicht das Kontrollkästchen) in der Liste aus. 1. Wählen Sie die Registerkarte **Permissions (Berechtigungen)**, wählen Sie **Add permissions (Berechtigungen hinzufügen)** und wählen Sie dann **Attach policies (Richtlinien anhängen)**. 1. Geben **EC2Full** Sie auf der Seite **Berechtigungsrichtlinien an EC2 MFA-Gruppe anhängen** in das Suchfeld den Text ein. Wählen Sie dann das Kontrollkästchen neben **Amazon EC2 FullAccess** in der Liste aus. Speichern Sie Ihre Änderungen noch nicht. 1. Geben Sie **Force** in das Suchfeld ein und aktivieren Sie dann das Kontrollkästchen neben **Force\$1MFA** in der Liste. 1. Wählen Sie **Attach Policies (Richtlinien hinzufügen)**. ## Schritt 3: Testen des Benutzerzugriffs In diesem Teil des Tutorials melden Sie sich als Testbenutzer an und überprüfen, ob die Richtlinie wie vorgesehen funktioniert. 1. Melden Sie sich **MFAUser** mit dem Passwort, das Sie im vorherigen Abschnitt vergeben haben, bei Ihrer AWS-Konto Anzeige an. Verwenden Sie die URL: `https://.signin.aws.amazon.com/console` 1. Wählen Sie **EC2**, um die Amazon EC2-Konsole zu öffnen und zu überprüfen, dass der Benutzer hat keine Berechtigungen für das Durchführen von Aktivitäten hat. 1. Wählen Sie auf der Navigationsleiste rechts oben den `MFAUser`-Benutzernamen und **Security Credentials (Sicherheitsanmeldeinformationen)**. ![\[AWS Link zu den Sicherheitsanmeldedaten der Management-Konsole.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png) 1. Fügen Sie nun ein MFA-Gerät hinzu. Wählen Sie im Abschnitt **Multi-Factor Authentication (MFA)** die Option **Assign MFA device (MFA-Gerät zuweisen)**. **Anmerkung** Sie könnten eine Fehlermeldung erhalten, die darauf hinweist, dass Sie für die Ausführung von `iam:DeleteVirtualMFADevice` nicht autorisiert sind. Dies kann passieren, wenn jemand zuvor damit begonnen hat, ein virtuelles MFA-Gerät zu diesem Benutzern zuzuweisen und den Prozess dann abgebrochen hat. Damit Sie fortfahren können, müssen Sie oder ein anderer Administrator das vorhandene nicht zugewiesene, virtuelle MFA-Gerät des Benutzers löschen. Weitere Informationen finden Sie unter [Ich bin nicht berechtigt, Folgendes aufzuführen: iam: DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). 1. Für dieses Tutorial verwenden wir ein virtuelles (softwarebasiertes) MFA-Gerät, wie z. B. die Google Authenticator-App auf einem Mobiltelefon. Wählen Sie die **Authenticator-App** und klicken Sie dann auf **Next (Weiter)**. IAM generiert Konfigurationsinformationen für das virtuelle MFA-Gerät und zeigt diese einschließlich eines QR-Codes an. Dieser Code ist eine grafische Darstellung des geheimen Konfigurationsschlüssels, der für die manuelle Eingabe auf Geräte zur Verfügung steht, die keine QR-Codes unterstützen. 1. Öffnen Sie Ihre virtuelle MFA-App. (Eine Liste der Anwendungen, die Sie zum Hosten von virtuellen MFA-Geräten verwenden können, finden Sie unter [Virtuelle MFA-Anwendungen](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications).) Wenn die virtuelle MFA-App mehrere Konten (mehrere virtuelle MFA-Geräte) unterstützt, wählen Sie die Option zum Erstellen eines neuen Kontos (eines neues virtuellen MFA-Geräts). 1. Stellen Sie fest, ob die MFA-App QR-Codes unterstützt, und führen Sie dann einen der folgenden Schritte aus: + Wählen Sie im Assistenten **Show QR-Code (QR-Code anzeigen)**. Verwenden Sie dann die App, um den QR-Code zu scannen. Sie können beispielsweise das Kamerasymbol oder eine Anwendung wie z. B. **Scan Code (Code scannen)** auswählen und dann mit der Kamera des Geräts den Code scannen. + Wählen Sie im Assistenten **zum Einrichten des Geräts** die Option **Show secret key (Geheimen Schlüssel anzeigen)** aus und geben Sie dann den geheimen Schlüssel in Ihre MFA-App ein. Wenn Sie fertig sind, beginnt das virtuelle MFA-Gerät, einmalige Passwörter zu generieren. 1. Geben Sie im Assistenten zum **Einrichten eines Geräts** im Feld **Authentication Code 1** das aktuell am virtuellen MFA-Gerät angezeigte einmalige Passwort ein. Wählen Sie die Option **Register MFA (MFA registrieren)**. **Wichtig** Senden Sie die Anforderung direkt nach der Erzeugung der Codes. Wenn Sie die Codes generieren und zu lange mit der Anforderung warten, wird das MFA-Gerät erfolgreich mit dem Benutzer verknüpft. Allerdings ist das MFA-Gerät nicht synchronisiert. Dies liegt daran, weil die zeitgesteuerten Einmalpasswörter (TOTP) nach einer kurzen Zeit ungültig werden. In diesem Fall können Sie das [Gerät neu synchronisieren](id_credentials_mfa_sync.md). Das virtuelle MFA-Gerät ist jetzt einsatzbereit. AWS 1. Melden Sie sich bei der Konsole ab und anschließend erneut als **MFAUser** an. Diesmal AWS werden Sie aufgefordert, einen MFA-Code von Ihrem Telefon einzugeben. Wenn Sie ihn erhalten, geben Sie den Code in das Feld ein und wählen Sie dann **Submit (Absenden)**. 1. Wählen Sie **EC2**, um die Amazon EC2-Konsole erneut zu öffnen. Beachten Sie, dass Sie jetzt alle Informationen sehen und alle gewünschten Aktionen ausführen können. Wenn Sie als dieser Benutzer zu einer anderen Konsole wechseln, erhalten Sie Meldungen, die besagen, dass der Zugriff verweigert wurde. Der Grund dafür ist, dass die Richtlinien in diesem Tutorial nur Zugriff auf Amazon EC2 gewähren. ## Zugehörige Ressourcen Weitere Informationen finden Sie unter den folgenden Themen: + [AWS Multi-Faktor-Authentifizierung in IAM](id_credentials_mfa.md) + [Anmeldung mit MFA](console_sign-in-mfa.md) # IAM-Tutorial: Verwenden Sie eine CloudFormation Vorlage, um einen SAML Identity Provider (IdP) zu erstellen Um den SAML-Verbund für Ihr AWS Konto einzurichten, müssen Sie einen SAML Identity Provider (IdP) erstellen. In diesem Tutorial erfahren Sie, wie Sie mithilfe einer CloudFormation Vorlage einen SAML-IdP erstellen, der Vertrauen zwischen Ihrem externen IdP AWS und Ihrem externen IdP herstellt. Die Vorlage erstellt einen SAML-IDP, der mit dem Metadatendokument Ihres IDP konfiguriert ist. Föderierte IAM-Rollen können dann auf diesen IdP verweisen, um authentifizierten Benutzern von Ihrem externen IdP den Zugriff auf Ressourcen zu ermöglichen. AWS Die bereitgestellte Ressource besteht aus einem SAML-IDP, der mit dem Metadatendokument Ihres IDP und optionalen Verschlüsselungseinstellungen konfiguriert ist. ## Voraussetzungen In diesem Tutorial wird davon ausgegangen, dass Folgendes bereits vorhanden ist: + Python 3.6 oder höher ist auf Ihrem lokalen Computer installiert, um den Python-Befehl auszuführen, der in diesem Tutorial zum Formatieren der XML-Datei für die SAML-Metadaten Ihres IDP verwendet wird. + Ein SAML-Metadatendokument von Ihrem externen IDP, das als XML-Datei gespeichert wurde. ## Erstellen Sie einen SAML-IdP mit CloudFormation Um den SAML-IdP zu erstellen, erstellen Sie eine CloudFormation Vorlage und verwenden sie, um einen Stack zu erstellen, der die IdP-Ressource enthält. ### Erstellen der -Vorlage Erstellen Sie zunächst die Vorlage. CloudFormation 1. Klicken Sie im Abschnitt „[Vorlage](#tutorial_saml-idp-template)“ auf das Kopiersymbol auf der Registerkarte **JSON** oder **YAML**, um den Inhalt der Vorlage zu kopieren. 1. Fügen Sie den Inhalt der Vorlage in eine neue Datei ein. 1. Speichern Sie die Datei lokal. ### Erstellen Sie den -Stack Verwenden Sie als Nächstes die Vorlage, die Sie gespeichert haben, um einen CloudFormation Stack bereitzustellen. 1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Auf der Seite **Stacks** wählen Sie im Menü **Stack erstellen** die Option **Mit neuen Ressourcen (Standard)** aus. 1. Legen Sie die Vorlage fest: 1. Wählen Sie unter **Voraussetzung** die Option **Vorhandene Vorlage wählen** aus. 1. Wählen Sie unter **Vorlage angeben** die Option **Eine Vorlagendatei hochladen** aus. 1. Klicken Sie auf **Datei auswählen**, navigieren Sie zur gewünschten Vorlagendatei und wählen Sie diese aus. 1. Wählen Sie **Weiter** aus. 1. Geben Sie die folgenden Stack-Details an: 1. Geben Sie einen Stack-Namen ein. 1. Denn Sie können dieses Feld leer lassen **IdentityProviderName**, um automatisch einen Namen basierend auf dem Stacknamen zu generieren, oder einen benutzerdefinierten Namen für Ihren SAML-IdP eingeben. Benutzerdefinierte Namen dürfen nur alphanumerische Zeichen, Punkte, Unterstriche und Bindestriche enthalten. 1. Für **IdentityProviderSAMLMetadataDocument** müssen Sie Ihre SAML-Metadaten-XML-Datei als eine einzelne Zeile formatieren, bevor Sie sie in dieses Feld einfügen. Dies ist erforderlich, da die CloudFormation Konsole erfordert, dass XML-Inhalt als eine einzelne Zeile formatiert wird, wenn er über Konsolenparameter übergeben wird. Formatieren Sie Ihre XML-Datei mit dem folgenden Python-Befehl neu: ``` python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml ``` **Anmerkung** Das SAML-Metadatendokument des IDP muss für die Eingabe von Konsolenparametern als einzelne Zeile formatiert werden. Der Python-Befehl entfernt Zeilenumbrüche und überflüssige Leerzeichen, um das erforderliche Format zu erstellen und gleichzeitig den ursprünglichen Inhalt und die ursprüngliche Struktur beizubehalten. Kopieren Sie die Ausgabe des Python-Befehls und fügen Sie sie in das Feld **IdentityProviderSAMLMetadataDokument** ein. Beispiel eines formatierten SAML-Metadatendokuments (gekürzt): ``` MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent ``` 1. Akzeptieren Sie für andere Parameter die Standardwerte oder geben Sie je nach Ihren Anforderungen Ihre eigenen ein: + **IdentityProviderAddPrivateKey**- Optionaler privater Schlüssel zum Entschlüsseln von SAML-Assertionen + **IdentityProviderAssertionEncryptionMode**— Optional, legt den Verschlüsselungsmodus für SAML-Assertionen fest (Zulässig, Erforderlich oder leer) 1. Wählen Sie **Weiter** aus. 1. Konfigurieren Sie die Stack-Optionen: 1. Wählen Sie unter **Optionen für Stack-Fehler** die Option **Löschen aller neu erstellten Ressourcen** aus. **Anmerkung** Durch Auswahl dieser Option vermeiden Sie möglicherweise anfallende Kosten für Ressourcen, deren Löschrichtlinie deren Beibehaltung auch bei einem Fehler bei der Stack-Erstellung vorsieht. 1. Akzeptieren Sie alle anderen Standardwerte. 1. Markieren Sie unter **Funktionen** das Kästchen, um zu bestätigen, dass dadurch IAM-Ressourcen in Ihrem Konto erstellt werden CloudFormation könnten. 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie die Stack-Details und klicken Sie auf **Absenden**. CloudFormation erstellt den Stack. Sobald die Stack-Erstellung abgeschlossen ist, können die Stack-Ressourcen verwendet werden. Auf der Registerkarte **Ressourcen** der Stack-Detailseite können Sie die in Ihrem Konto bereitgestellten Ressourcen anzeigen. Der Stack gibt die folgenden Werte aus, die Sie auf der Registerkarte **Ausgaben** einsehen können: + **ProviderARN**: der ARN des erstellten SAML-IDP (z. B. `arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Sie benötigen diesen ARN, wenn Sie Rollen erstellen, die diesem Anbieter vertrauen. + **ProviderName**: Der Name des erstellten SAML-IdP (z. B. `CompanyIdP` wenn Sie einen benutzerdefinierten Namen angegeben haben oder `my-saml-stack-saml-provider` wenn Sie die Standardbenennung verwendet haben). Diese Ausgaben werden ebenfalls exportiert, sodass sie mithilfe der `Fn::ImportValue`-Funktion von anderen CloudFormation -Stacks importiert werden können. ## Überprüfen des SAML-IDP Sobald der SAML-IDP erstellt wurde, können Sie dessen Konfiguration überprüfen und dessen ARN für die Verwendung mit verbundenen Rollen notieren. 1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole. 1. Wählen Sie im Navigationsbereich **Identitätsanbieter**. Ihr neu erstellter SAML-IDP sollte in der Liste angezeigt werden. 1. Wählen Sie den IDP-Namen aus, um die Details anzuzeigen. Auf der IDP-Detailseite sehen Sie das SAML-Metadatendokument und weitere Konfigurationsdetails. 1. Notieren Sie sich den auf der Detailseite angezeigten **Provider-ARN**. Sie benötigen diesen ARN, wenn Sie verbundene IAM-Rollen erstellen, die diesem IDP vertrauen. 1. Überprüfen Sie das Metadatendokument, um sicherzustellen, dass es mit den Angaben übereinstimmt, die Sie von Ihrem externen IDP erhalten haben. Ihr SAML-IDP kann jetzt von IAM-Rollen verwendet werden. Sie können Rollen erstellen, die diesem IdP vertrauen, damit authentifizierte Benutzer Ihres externen IdP diese Rollen übernehmen und auf Ressourcen zugreifen können. AWS ## Bereinigung: Ressourcen löschen Im letzten Schritt löschen Sie den Stack und die darin enthaltenen Ressourcen. 1. Öffnen Sie die Konsole. CloudFormation 1. Wählen Sie auf der Seite **Stacks** den aus der Vorlage erstellten Stack aus und klicken Sie auf **Löschen**. Bestätigen Sie dann **Löschen**. CloudFormation initiiert das Löschen des Stacks und aller darin enthaltenen Ressourcen. ## CloudFormation Details zur Vorlage ### Ressourcen Die CloudFormation Vorlage für dieses Tutorial erstellt die folgende Ressource in Ihrem Konto: [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): Ein SAML-IdP, der Vertrauen zwischen AWS und Ihrem externen IdP herstellt. ### Konfiguration Die Vorlage enthält die folgenden konfigurierbaren Parameter: + **IdentityProviderName**- Der Name für Ihren SAML-IdP (leer lassen für den automatisch generierten Namen) Beispiel: `CompanyIdP` oder `EnterpriseSSO` + **IdentityProviderSAMLMetadataDokument** — Das SAML-Metadatendokument von Ihrem externen IdP (als einzelne Zeile formatiert) + **IdentityProviderAddPrivateKey**- Optionaler privater Schlüssel zum Entschlüsseln von SAML-Assertionen + **IdentityProviderAssertionEncryptionMode**— Optional, legt den Verschlüsselungsmodus für SAML-Assertionen fest ## CloudFormation Vorlage Speichern Sie den folgenden JSON- oder YAML-Code als separate Datei, um ihn als CloudFormation Vorlage für dieses Tutorial zu verwenden. ------ #### [ JSON ] ``` { "AWSTemplateFormatVersion": "2010-09-09", "Description": "[AWSDocs] IAM: tutorial_saml-idp", "Parameters": { "IdentityProviderName": { "Type": "String", "Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')", "Default": "", "AllowedPattern": "^$|^[a-zA-Z0-9._-]+$", "ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens" }, "IdentityProviderSAMLMetadataDocument": { "Type": "String", "Description": "SAML metadata document from identity provider" }, "IdentityProviderAddPrivateKey": { "Type": "String", "Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.", "Default": "" }, "IdentityProviderAssertionEncryptionMode": { "Type": "String", "Description": "Optional, sets encryption mode for SAML assertions", "Default": "", "AllowedValues": ["", "Allowed", "Required"] } }, "Conditions": { "HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]}, "HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}, "HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]} }, "Resources": { "SAMLProvider": { "Type": "AWS::IAM::SAMLProvider", "Properties": { "Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]}, "SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"}, "Tags": [ { "Key": "Name", "Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]} } ], "AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]}, "AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]} } } }, "Outputs": { "ProviderARN": { "Description": "ARN of the created SAML Identity Provider", "Value": {"Ref": "SAMLProvider"}, "Export": { "Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"} } }, "ProviderName": { "Description": "Name of the SAML Identity Provider", "Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}, "Export": { "Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"} } } } } ``` ------ #### [ YAML ] ``` AWSTemplateFormatVersion: '2010-09-09' Description: '[AWSDocs] IAM: tutorial_saml-idp' Parameters: IdentityProviderName: Type: String Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}') Default: "" AllowedPattern: '^$|^[a-zA-Z0-9._-]+$' ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens' IdentityProviderSAMLMetadataDocument: Type: String Description: SAML metadata document from identity provider IdentityProviderAddPrivateKey: Type: String Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions. Default: "" IdentityProviderAssertionEncryptionMode: Type: String Description: Optional, sets encryption mode for SAML assertions Default: "" AllowedValues: - "" - "Allowed" - "Required" Conditions: HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]] HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]] HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]] Resources: SAMLProvider: Type: 'AWS::IAM::SAMLProvider' Properties: Name: !If - HasCustomName - !Ref IdentityProviderName - !Ref AWS::NoValue SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument Tags: - Key: Name Value: !If - HasCustomName - !Ref IdentityProviderName - !Sub '${AWS::StackName}-saml-provider' AddPrivateKey: !If - HasPrivateKey - !Ref IdentityProviderAddPrivateKey - !Ref AWS::NoValue AssertionEncryptionMode: !If - HasEncryptionMode - !Ref IdentityProviderAssertionEncryptionMode - !Ref AWS::NoValue Outputs: ProviderARN: Description: 'ARN of the created SAML Identity Provider' Value: !Ref SAMLProvider Export: Name: !Sub '${AWS::StackName}-ProviderARN' ProviderName: Description: 'Name of the SAML Identity Provider' Value: !If - HasCustomName - !Ref IdentityProviderName - !Sub '${AWS::StackName}-saml-provider' Export: Name: !Sub '${AWS::StackName}-ProviderName' ``` ------ # IAM-Tutorial: Verwenden Sie eine CloudFormation Vorlage, um eine SAML-föderierte IAM-Rolle zu erstellen Wenn Sie in Ihrem AWS Konto einen vorhandenen SAML Identity Provider (IdP) konfiguriert haben, können Sie föderierte IAM-Rollen erstellen, die diesem IdP vertrauen. In diesem Tutorial erfahren Sie, wie Sie mithilfe einer CloudFormation Vorlage eine SAML-Verbund-IAM-Rolle erstellen, die von Benutzern übernommen werden kann, die über Ihren externen IdP authentifiziert wurden. Die Vorlage erstellt eine verbundene IAM-Rolle mit einer Vertrauensrichtlinie, die es Ihrem SAML-IDP ermöglicht, die Rolle anzunehmen. Benutzer, die von Ihrem externen IDP authentifiziert wurden, können diese Rolle übernehmen, um auf AWS -Ressourcen zuzugreifen, basierend auf den mit der Rolle verknüpften Berechtigungen. Die bereitgestellte Ressource enthält Folgendes: + Eine verbundene IAM-Rolle, die Ihrem vorhandenen SAML-IDP vertraut. + Konfigurierbare verwaltete Richtlinien, die der Rolle zugeordnet werden können, um bestimmte Berechtigungen zu gewähren. + Optionale Einstellungen für die Berechtigungsgrenze und die Sitzungsdauer. ## Voraussetzungen In diesem Tutorial wird davon ausgegangen, dass Folgendes bereits vorhanden ist: + Ein vorhandener SAML-IdP, der in Ihrem AWS Konto konfiguriert ist. Wenn dies nicht der Fall ist, können Sie ihn mithilfe des [IAM-Tutorial: Verwenden Sie eine CloudFormation Vorlage, um einen SAML Identity Provider (IdP) zu erstellen](tutorial_saml-idp.md)-Tutorials erstellen. + Der ARN Ihres SAML-IDP, den Sie bei der Erstellung des Stacks als Parameter angeben müssen. + Python 3.6 oder höher ist auf Ihrem lokalen Computer installiert, um den Python-Befehl auszuführen, der in diesem Tutorial zum Formatieren der XML-Datei für die SAML-Metadaten Ihres IDP verwendet wird. ## Erstellen Sie eine SAML-Verbundrolle mit CloudFormation Um die SAML-Verbundrolle zu erstellen, erstellen Sie eine CloudFormation Vorlage und verwenden sie, um einen Stack zu erstellen, der die Rolle enthält. ### Erstellen der -Vorlage Erstellen Sie zunächst die CloudFormation Vorlage. 1. Klicken Sie im Abschnitt „[Vorlage](#tutorial_saml-federated-role-template)“ auf das Kopiersymbol auf der Registerkarte **JSON** oder **YAML**, um den Inhalt der Vorlage zu kopieren. 1. Fügen Sie den Inhalt der Vorlage in eine neue Datei ein. 1. Speichern Sie die Datei lokal. ### Erstellen Sie den -Stack Verwenden Sie als Nächstes die Vorlage, die Sie gespeichert haben, um einen CloudFormation Stack bereitzustellen. 1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Auf der Seite **Stacks** wählen Sie im Menü **Stack erstellen** die Option **Mit neuen Ressourcen (Standard)** aus. 1. Legen Sie die Vorlage fest: 1. Wählen Sie unter **Voraussetzung** die Option **Vorhandene Vorlage wählen** aus. 1. Wählen Sie unter **Vorlage angeben** die Option **Eine Vorlagendatei hochladen** aus. 1. Klicken Sie auf **Datei auswählen**, navigieren Sie zur gewünschten Vorlagendatei und wählen Sie diese aus. 1. Wählen Sie **Weiter** aus. 1. Geben Sie die folgenden Stack-Details an: 1. Geben Sie einen Stack-Namen ein. 1. Geben Sie für **SAMLProviderARN** den ARN Ihres vorhandenen SAML-IdP ein. Dies sollte im Format `arn:aws:iam::123456789012:saml-provider/YourProviderName` sein. Beispiel: `arn:aws:iam::123456789012:saml-provider/CompanyIdP` **Anmerkung** Wenn Sie Ihren SAML-IdP mithilfe des [IAM-Tutorial: Verwenden Sie eine CloudFormation Vorlage, um einen SAML Identity Provider (IdP) zu erstellen](tutorial_saml-idp.md) Tutorials erstellt haben, finden Sie den Provider-ARN auf der Registerkarte Ausgaben dieses CloudFormation Stacks. 1. Denn Sie können dieses Feld leer lassen **RoleName**, um automatisch einen Namen basierend auf dem Stacknamen zu generieren, oder einen benutzerdefinierten Namen für die IAM-Rolle eingeben. Beispiel: `SAML-Developer-Access` oder `SAML-ReadOnly-Role` 1. Akzeptieren Sie für andere Parameter die Standardwerte oder geben Sie je nach Ihren Anforderungen Ihre eigenen ein: + **RoleSessionDuration**- Maximale Sitzungsdauer in Sekunden (3600-43200, Standard 7200) Beispiel: `14400` (4 Stunden) + **RolePermissionsBoundary**- Optionaler ARN einer Berechtigungsgrenzrichtlinie Beispiel: `arn:aws:iam::123456789012:policy/DeveloperBoundary` + **RolePath**— Pfad für die IAM-Rolle (Standard ist/) Beispiel: `/saml-roles/` + **ManagedPolicy1-5** — Optional können bis ARNs zu 5 verwaltete Richtlinien angehängt werden Beispiel für ManagedPolicy 1: `arn:aws:iam::aws:policy/ReadOnlyAccess` Beispiel für ManagedPolicy 2: `arn:aws:iam::123456789012:policy/CustomPolicy` 1. Wählen Sie **Weiter** aus. 1. Konfigurieren Sie die Stack-Optionen: 1. Wählen Sie unter **Optionen für Stack-Fehler** die Option **Löschen aller neu erstellten Ressourcen** aus. **Anmerkung** Durch Auswahl dieser Option vermeiden Sie möglicherweise anfallende Kosten für Ressourcen, deren Löschrichtlinie deren Beibehaltung auch bei einem Fehler bei der Stack-Erstellung vorsieht. 1. Akzeptieren Sie alle anderen Standardwerte. 1. Markieren Sie unter **Funktionen** das Kästchen, um zu bestätigen, dass CloudFormation dadurch IAM-Ressourcen in Ihrem Konto erstellt werden könnten. 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie die Stack-Details und klicken Sie auf **Absenden**. CloudFormation erstellt den Stack. Sobald die Stack-Erstellung abgeschlossen ist, können die Stack-Ressourcen verwendet werden. Auf der Registerkarte **Ressourcen** der Stack-Detailseite können Sie die in Ihrem Konto bereitgestellten Ressourcen anzeigen. Der Stack gibt den folgenden Wert aus, den Sie auf der Registerkarte **Ausgaben** einsehen können: + **RoleARN**: Der ARN der erstellten IAM-Rolle (z. B. `arn:aws:iam::123456789012:role/SAML-Developer-Access` oder `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` bei Verwendung eines automatisch generierten Namens). Sie benötigen diesen Rollen-ARN, um Ihren IDP so zu konfigurieren, dass er die entsprechenden SAML-Attribute für die Rollenübernahme sendet. ## Testen der verbundenen SAML-Rolle Nachdem die verbundene SAML-Rolle erstellt wurde, können Sie ihre Konfiguration überprüfen und die Verbundeinrichtung testen. 1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole. 1. Wählen Sie im Navigationsbereich **Rollen**. 1. Suchen Sie Ihre neu erstellte verbundene Rolle und wählen Sie sie aus. Wenn Sie einen benutzerdefinierten Rollennamen angegeben haben, suchen Sie nach diesem Namen. Wenn Sie den RoleName Parameter leer gelassen haben, hat die Rolle einen automatisch generierten Namen, der auf dem Stacknamen und einer eindeutigen Kennung basiert. 1. Wählen Sie die Registerkarte **Vertrauensstellungen**, um die Vertrauensrichtlinie zu überprüfen. Die Vertrauensrichtlinie sollte anzeigen, dass Ihr SAML-IDP berechtigt ist, diese Rolle zu übernehmen, sofern die SAML-Zielgruppe (`SAML:aud`) mit `https://signin.aws.amazon.com/saml` übereinstimmt. 1. Wählen Sie die Registerkarte **Berechtigungen** aus, um die zugeordneten Richtlinien zu überprüfen. Hier sehen Sie alle verwalteten Richtlinien, die der Rolle bei der Erstellung zugeordnet wurden. 1. Beachten Sie die auf der Seite mit der Zusammenfassung der Rolle angezeigte **Rollen-ARN**. Sie benötigen diesen ARN, um Ihren externen IDP so zu konfigurieren, dass Benutzer diese Rolle übernehmen können. Ihre verbundene SAML-Rolle ist jetzt einsatzbereit. Konfigurieren Sie Ihren externen IdP so, dass er den ARN dieser Rolle in SAML-Assertionen einbezieht, und authentifizierte Benutzer können diese Rolle übernehmen, um auf Ressourcen zuzugreifen. AWS ## Bereinigung: Ressourcen löschen Im letzten Schritt löschen Sie den Stack und die darin enthaltenen Ressourcen. 1. Öffnen Sie die Konsole. CloudFormation 1. Wählen Sie auf der Seite **Stacks** den aus der Vorlage erstellten Stack aus und klicken Sie auf **Löschen**. Bestätigen Sie dann **Löschen**. CloudFormation initiiert das Löschen des Stacks und aller darin enthaltenen Ressourcen. ## CloudFormation Details zur Vorlage ### Ressourcen Die CloudFormation Vorlage für dieses Tutorial erstellt die folgende Ressource in Ihrem Konto: + [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): Eine verbundene IAM-Rolle, die von Benutzern übernommen werden kann, die sich über Ihren SAML-IDP authentifiziert haben. ### Konfiguration Die Vorlage enthält die folgenden konfigurierbaren Parameter: + **RoleName**- Name der IAM-Rolle (leer lassen für den automatisch generierten Namen) + **SAMLProviderARN** — ARN des SAML-IdP (erforderlich) + **RoleSessionDuration**- Maximale Sitzungsdauer in Sekunden (3600-43200, Standard 7200) + **RolePermissionsBoundary**- Optionaler ARN der Grenzrichtlinie für Berechtigungen + **RolePath**— Pfad für die IAM-Rolle (Standard/) + **ManagedPolicy1-5** — Optional können bis ARNs zu 5 verwaltete Richtlinien angehängt werden ## CloudFormation Vorlage Speichern Sie den folgenden JSON- oder YAML-Code als separate Datei, um ihn als CloudFormation Vorlage für dieses Tutorial zu verwenden. ------ #### [ JSON ] ``` { "AWSTemplateFormatVersion": "2010-09-09", "Description": "[AWSDocs] IAM: tutorial_saml-federated-role", "Parameters": { "RoleName": { "Type": "String", "Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')", "Default": "", "AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$", "ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-" }, "SAMLProviderARN": { "Type": "String", "Description": "ARN of the SAML Identity Provider", "AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$", "ConstraintDescription": "Must be a valid SAML provider ARN" }, "RoleSessionDuration": { "Type": "Number", "Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)", "MinValue": 3600, "MaxValue": 43200, "Default": 7200 }, "RolePermissionsBoundary": { "Type": "String", "Description": "Optional ARN of the permissions boundary policy (leave empty for none)", "Default": "" }, "RolePath": { "Type": "String", "Description": "Path for the IAM role (must start and end with /)", "Default": "/", "AllowedPattern": "^\/.*\/$|^\/$", "ConstraintDescription": "Role path must start and end with forward slash (/)" }, "RoleManagedPolicy1": { "Type": "String", "Description": "Optional managed policy ARN 1", "Default": "" }, "RoleManagedPolicy2": { "Type": "String", "Description": "Optional managed policy ARN 2", "Default": "" }, "RoleManagedPolicy3": { "Type": "String", "Description": "Optional managed policy ARN 3", "Default": "" }, "RoleManagedPolicy4": { "Type": "String", "Description": "Optional managed policy ARN 4", "Default": "" }, "RoleManagedPolicy5": { "Type": "String", "Description": "Optional managed policy ARN 5", "Default": "" } }, "Conditions": { "HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]}, "HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]}, "HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]}, "HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]}, "HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]}, "HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]}, "HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]} }, "Resources": { "SAMLFederatedRole": { "Type": "AWS::IAM::Role", "Properties": { "RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]}, "Description": "IAM role with SAML provider trust", "MaxSessionDuration": {"Ref": "RoleSessionDuration"}, "PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]}, "Path": {"Ref": "RolePath"}, "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": {"Ref": "SAMLProviderARN"} }, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] }, "ManagedPolicyArns": { "Fn::Split": [ ",", { "Fn::Join": [ ",", [ {"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]} ] ] } ] } } } }, "Outputs": { "RoleARN": { "Description": "ARN of the created IAM Role", "Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]}, "Export": { "Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"} } } } } ``` ------ #### [ YAML ] ``` AWSTemplateFormatVersion: '2010-09-09' Description: '[AWSDocs] IAM: tutorial_saml-federated-role' Parameters: RoleName: Type: String Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')' Default: "" AllowedPattern: '^$|^[\w+=,.@-]{1,64}$' ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-' SAMLProviderARN: Type: String Description: 'ARN of the SAML Identity Provider' AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$' ConstraintDescription: 'Must be a valid SAML provider ARN' RoleSessionDuration: Type: Number Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)' MinValue: 3600 MaxValue: 43200 Default: 7200 RolePermissionsBoundary: Type: String Description: Optional ARN of the permissions boundary policy (leave empty for none) Default: "" RolePath: Type: String Description: 'Path for the IAM role (must start and end with /)' Default: "/" AllowedPattern: '^\/.*\/$|^\/$' ConstraintDescription: 'Role path must start and end with forward slash (/)' RoleManagedPolicy1: Type: String Description: Optional managed policy ARN 1 Default: "" RoleManagedPolicy2: Type: String Description: Optional managed policy ARN 2 Default: "" RoleManagedPolicy3: Type: String Description: Optional managed policy ARN 3 Default: "" RoleManagedPolicy4: Type: String Description: Optional managed policy ARN 4 Default: "" RoleManagedPolicy5: Type: String Description: Optional managed policy ARN 5 Default: "" Conditions: HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]] HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]] HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]] HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]] HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]] HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]] HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]] Resources: SAMLFederatedRole: Type: 'AWS::IAM::Role' Properties: RoleName: !If - HasCustomRoleName - !Ref RoleName - !Ref AWS::NoValue Description: 'IAM role with SAML provider trust' MaxSessionDuration: !Ref RoleSessionDuration PermissionsBoundary: !If - HasPermissionsBoundary - !Ref RolePermissionsBoundary - !Ref AWS::NoValue Path: !Ref RolePath AssumeRolePolicyDocument: Version: '2012-10-17 ' Statement: - Effect: Allow Principal: Federated: !Ref SAMLProviderARN Action: 'sts:AssumeRoleWithSAML' Condition: StringEquals: 'SAML:aud': 'https://signin.aws.amazon.com/saml' ManagedPolicyArns: !Split - ',' - !Join - ',' - - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue'] - !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue'] - !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue'] - !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue'] - !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue'] Outputs: RoleARN: Description: 'ARN of the created IAM Role' Value: !GetAtt SAMLFederatedRole.Arn Export: Name: !Sub '${AWS::StackName}-RoleARN' ``` ------ # IAM-Tutorial: Verwenden Sie eine CloudFormation Vorlage, um einen SAML Identity Provider (IdP) und eine SAML-Verbund-IAM-Rolle zu erstellen Um sich mit dem SAML-Verbund und seinen Funktionen vertraut zu machen, verwenden Sie eine CloudFormation Vorlage, um einen SAML Identity Provider (IdP) und die zugehörige föderierte IAM-Rolle einzurichten. In diesem Tutorial erfahren Sie, wie Sie beide Ressourcen zusammen in einem einzigen Stack erstellen. Die Vorlage erstellt einen SAML-IdP, der für den Verbundzugriff auf AWS Ressourcen verwendet werden kann, zusammen mit einer IAM-Rolle, die dem SAML-Anbieter vertraut. Benutzer, die von Ihrem externen IdP authentifiziert wurden, können diese Rolle für den Zugriff auf AWS Ressourcen übernehmen. Die bereitgestellten Ressourcen enthalten Folgendes: + Einen SAML-IDP, der mit dem Metadatendokument Ihres IDP konfiguriert wurde. + Eine verbundene IAM-Rolle, die dem SAML-IDP vertraut und von authentifizierten Benutzern übernommen werden kann. + Konfigurierbare verwaltete Richtlinien, die der Rolle zugeordnet werden können, um bestimmte Berechtigungen zu gewähren. ## Voraussetzungen In diesem Tutorial wird davon ausgegangen, dass Folgendes bereits vorhanden ist: + Python 3.6 oder höher ist auf Ihrem lokalen Computer installiert, um den Python-Befehl auszuführen, der in diesem Tutorial zum Formatieren der XML-Datei für die SAML-Metadaten Ihres IDP verwendet wird. + Ein SAML-Metadatendokument von Ihrem externen IDP, das als XML-Datei gespeichert wurde. ## Erstellen Sie einen SAML-IdP und eine Rolle mit CloudFormation Um den SAML-IdP und die Verbundrolle zu erstellen, erstellen Sie eine CloudFormation Vorlage und verwenden sie, um einen Stack zu erstellen, der beide Ressourcen enthält. ### Erstellen der -Vorlage Erstellen Sie zunächst die Vorlage. CloudFormation 1. Klicken Sie im Abschnitt „[Vorlage](#tutorial_saml-idp-and-federated-role-template)“ auf das Kopiersymbol auf der Registerkarte **JSON** oder **YAML**, um den Inhalt der Vorlage zu kopieren. 1. Fügen Sie den Inhalt der Vorlage in eine neue Datei ein. 1. Speichern Sie die Datei lokal. ### Erstellen Sie den -Stack Verwenden Sie als Nächstes die Vorlage, die Sie gespeichert haben, um einen CloudFormation Stack bereitzustellen. 1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Auf der Seite **Stacks** wählen Sie im Menü **Stack erstellen** die Option **Mit neuen Ressourcen (Standard)** aus. 1. Legen Sie die Vorlage fest: 1. Wählen Sie unter **Voraussetzung** die Option **Vorhandene Vorlage wählen** aus. 1. Wählen Sie unter **Vorlage angeben** die Option **Eine Vorlagendatei hochladen** aus. 1. Klicken Sie auf **Datei auswählen**, navigieren Sie zur gewünschten Vorlagendatei und wählen Sie diese aus. 1. Wählen Sie **Weiter** aus. 1. Geben Sie die folgenden Stack-Details an: 1. Geben Sie einen Stack-Namen ein. 1. Denn Sie können dieses Feld leer lassen **IdentityProviderName**, um automatisch einen Namen basierend auf dem Stacknamen zu generieren, oder einen benutzerdefinierten Namen für Ihren SAML-IdP eingeben. Beispiel: `CompanyIdP` oder `EnterpriseSSO` 1. Für **IdentityProviderSAMLMetadataDocument** müssen Sie Ihre SAML-Metadaten-XML-Datei als eine einzelne Zeile formatieren, bevor Sie sie in dieses Feld einfügen. Dies ist erforderlich, da die CloudFormation Konsole erfordert, dass XML-Inhalt als eine einzelne Zeile formatiert wird, wenn er über Konsolenparameter übergeben wird. Formatieren Sie Ihre XML-Datei mit dem folgenden Python-Befehl neu: ``` python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml ``` **Anmerkung** Das SAML-Metadatendokument des IDP muss für die Eingabe von Konsolenparametern als einzelne Zeile formatiert werden. Der Python-Befehl entfernt Zeilenumbrüche und überflüssige Leerzeichen, um das erforderliche Format zu erstellen und gleichzeitig den ursprünglichen Inhalt und die ursprüngliche Struktur beizubehalten. Kopieren Sie die Ausgabe des Python-Befehls und fügen Sie sie in das Feld **IdentityProviderSAMLMetadataDokument** ein. Beispiel eines formatierten SAML-Metadatendokuments (gekürzt): ``` MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent ``` 1. Denn Sie können dieses Feld leer lassen **RoleName**, um automatisch einen Namen basierend auf dem Stacknamen zu generieren, oder einen benutzerdefinierten Namen für die föderierte IAM-Rolle eingeben. Beispiel: `SAML-Developer-Access` oder `SAML-ReadOnly-Role` 1. Akzeptieren Sie für andere Parameter die Standardwerte oder geben Sie je nach Ihren Anforderungen Ihre eigenen ein: + **IdentityProviderAddPrivateKey**— Optionaler privater Schlüssel zum Entschlüsseln von SAML-Assertionen + **IdentityProviderAssertionEncryptionMode**- Verschlüsselungsmodus für SAML-Assertionen Beispielwerte: `Allowed`, `Required` oder leer lassen für keine Verschlüsselung + **RoleSessionDuration**- Maximale Sitzungsdauer in Sekunden (3600-43200, Standard 7200) Beispiel: `14400` (4 Stunden) + **RolePermissionsBoundary**- Optionaler ARN einer Berechtigungsgrenzrichtlinie Beispiel: `arn:aws:iam::123456789012:policy/DeveloperBoundary` + **RolePath**— Pfad für die IAM-Rolle (Standard ist/) Beispiel: `/saml-roles/` + **RoleManagedPolicy1-5** — Optional können bis ARNs zu 5 verwaltete Richtlinien angehängt werden Beispiel für RoleManagedPolicy 1: `arn:aws:iam::aws:policy/ReadOnlyAccess` Beispiel für RoleManagedPolicy 2: `arn:aws:iam::123456789012:policy/CustomPolicy` 1. Wählen Sie **Weiter** aus. 1. Konfigurieren Sie die Stack-Optionen: 1. Wählen Sie unter **Optionen für Stack-Fehler** die Option **Löschen aller neu erstellten Ressourcen** aus. **Anmerkung** Durch Auswahl dieser Option vermeiden Sie möglicherweise anfallende Kosten für Ressourcen, deren Löschrichtlinie deren Beibehaltung auch bei einem Fehler bei der Stack-Erstellung vorsieht. 1. Akzeptieren Sie alle anderen Standardwerte. 1. Markieren Sie unter **Funktionen** das Kästchen, um zu bestätigen, dass CloudFormation dadurch IAM-Ressourcen in Ihrem Konto erstellt werden könnten. 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie die Stack-Details und klicken Sie auf **Absenden**. CloudFormation erstellt den Stack. Sobald die Stack-Erstellung abgeschlossen ist, können die Stack-Ressourcen verwendet werden. Auf der Registerkarte **Ressourcen** der Stack-Detailseite können Sie die in Ihrem Konto bereitgestellten Ressourcen anzeigen. Der Stack gibt die folgenden Werte aus, die Sie auf der Registerkarte **Ausgaben** einsehen können: + **RoleARN**: Der ARN der erstellten IAM-Rolle (z. B. `arn:aws:iam::123456789012:role/SAML-Developer-Access` oder `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` bei Verwendung eines automatisch generierten Namens). + **IdentityProviderARN**: Der ARN des erstellten SAML-IdP (zum Beispiel`arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Sie benötigen beide, ARNs wenn Sie Ihren IdP so konfigurieren, dass er die entsprechenden SAML-Attribute für die Rollenübernahme sendet. ## Testen des SAML-Verbunds Nachdem der SAML-IDP und die Verbundrolle erstellt wurden, können Sie die Verbundeinrichtung testen. 1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole. 1. Wählen Sie im Navigationsbereich **Identitätsanbieter**. Ihr neu erstellter SAML-IDP sollte in der Liste angezeigt werden. 1. Wählen Sie den IDP-Namen aus, um die Details anzuzeigen. Auf der IDP-Detailseite sehen Sie das SAML-Metadatendokument und weitere Konfigurationsdetails. 1. Wählen Sie im Navigationsbereich **Rollen**. 1. Suchen Sie Ihre neu erstellte verbundene Rolle und wählen Sie sie aus. Auf der Rollendetailseite sehen Sie die Vertrauensrichtlinie, die es dem SAML-IDP ermöglicht, diese Rolle zu übernehmen. 1. Wählen Sie die Registerkarte **Vertrauensstellungen**, um die Vertrauensrichtlinie zu überprüfen. Die Vertrauensrichtlinie sollte anzeigen, dass der SAML-IDP berechtigt ist, diese Rolle zu übernehmen, sofern die SAML-Zielgruppe (`SAML:aud`) mit `https://signin.aws.amazon.com/saml` übereinstimmt. ## Bereinigung: Ressourcen löschen Im letzten Schritt löschen Sie den Stack und die darin enthaltenen Ressourcen. 1. Öffnen Sie die Konsole CloudFormation . 1. Wählen Sie auf der Seite **Stacks** den aus der Vorlage erstellten Stack aus und klicken Sie auf **Löschen**. Bestätigen Sie dann **Löschen**. CloudFormation initiiert das Löschen des Stacks und aller darin enthaltenen Ressourcen. ## CloudFormation Details zur Vorlage ### Ressourcen Mit der CloudFormation Vorlage für dieses Tutorial werden die folgenden Ressourcen in Ihrem Konto erstellt: + [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): Ein SAML-IdP, der Vertrauen zwischen AWS und Ihrem externen IdP herstellt. + [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): Eine verbundene IAM-Rolle, die von Benutzern übernommen werden kann, die sich über den SAML-IDP authentifiziert haben. ### Konfiguration Die Vorlage enthält die folgenden konfigurierbaren Parameter: + **IdentityProviderName**- Name des SAML-IdP (leer lassen für den automatisch generierten Namen) + **IdentityProviderSAMLMetadataDokument** — SAML-Metadatendokument von Ihrem IdP (erforderlich) + **IdentityProviderAddPrivateKey**- Optionaler privater Schlüssel zum Entschlüsseln von SAML-Assertionen + **IdentityProviderAssertionEncryptionMode**- Verschlüsselungsmodus für SAML-Assertionen + **RoleName**- Name der IAM-Rolle (leer lassen für den automatisch generierten Namen) + **RolePath**— Pfad für die IAM-Rolle (Standard/) + **RolePermissionsBoundary**- Optionaler ARN der Grenzrichtlinie für Berechtigungen + **RoleSessionDuration**- Maximale Sitzungsdauer in Sekunden (3600-43200, Standard 7200) + **RoleManagedPolicy1-5** — Optional können bis zu 5 ARNs verwaltete Richtlinien angehängt werden ## CloudFormation Vorlage Speichern Sie den folgenden JSON- oder YAML-Code als separate Datei, um ihn als CloudFormation Vorlage für dieses Tutorial zu verwenden. ------ #### [ JSON ] ``` { "AWSTemplateFormatVersion": "2010-09-09", "Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role", "Parameters": { "IdentityProviderName": { "Type": "String", "Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')", "Default": "", "AllowedPattern": "^$|^[a-zA-Z0-9._-]+$", "ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens" }, "IdentityProviderSAMLMetadataDocument": { "Type": "String", "Description": "SAML metadata document from identity provider" }, "IdentityProviderAddPrivateKey": { "Type": "String", "Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.", "Default": "" }, "IdentityProviderAssertionEncryptionMode": { "Type": "String", "Description": "Optional, sets encryption mode for SAML assertions", "Default": "", "AllowedValues": ["", "Allowed", "Required"] }, "RoleName": { "Type": "String", "Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')", "Default": "", "AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$", "ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-" }, "RolePath": { "Type": "String", "Description": "Path for the IAM Role", "AllowedPattern": "(^\\/$)|(^\\/.*\\/$)", "Default": "/" }, "RolePermissionsBoundary": { "Type": "String", "Description": "Optional ARN of the permissions boundary policy (leave empty for none)", "Default": "" }, "RoleSessionDuration": { "Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)", "Type": "Number", "MinValue": 3600, "MaxValue": 43200, "Default": 7200 }, "RoleManagedPolicy1": { "Type": "String", "Description": "Optional managed policy ARN 1", "Default": "" }, "RoleManagedPolicy2": { "Type": "String", "Description": "Optional managed policy ARN 2", "Default": "" }, "RoleManagedPolicy3": { "Type": "String", "Description": "Optional managed policy ARN 3", "Default": "" }, "RoleManagedPolicy4": { "Type": "String", "Description": "Optional managed policy ARN 4", "Default": "" }, "RoleManagedPolicy5": { "Type": "String", "Description": "Optional managed policy ARN 5", "Default": "" } }, "Conditions": { "HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}, "HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]}, "HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]}, "HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]}, "HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]}, "HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]}, "HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]}, "HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}, "HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]}, "HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]} }, "Resources": { "SAMLProvider": { "Type": "AWS::IAM::SAMLProvider", "Properties": { "Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]}, "SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"}, "AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]}, "AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]} } }, "SAMLFederatedRole": { "Type": "AWS::IAM::Role", "Properties": { "RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]}, "Path": {"Ref": "RolePath"}, "Description": "SAML federated IAM role for SSO access with specified permissions", "MaxSessionDuration": {"Ref": "RoleSessionDuration"}, "PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]}, "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": {"Ref": "SAMLProvider"} }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] }, "ManagedPolicyArns": { "Fn::Split": [ ",", { "Fn::Join": [ ",", [ {"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]}, {"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]} ] ] } ] } } } }, "Outputs": { "RoleARN": { "Description": "ARN of the created IAM Role", "Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]}, "Export": { "Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"} } }, "IdentityProviderARN": { "Description": "ARN of the created SAML Identity Provider", "Value": {"Ref": "SAMLProvider"}, "Export": { "Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"} } } } } ``` ------ #### [ YAML ] ``` AWSTemplateFormatVersion: '2010-09-09' Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role' Parameters: IdentityProviderName: Type: String Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}') Default: "" AllowedPattern: '^$|^[a-zA-Z0-9._-]+$' ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens IdentityProviderSAMLMetadataDocument: Type: String Description: SAML metadata document from identity provider IdentityProviderAddPrivateKey: Type: String Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions. Default: "" IdentityProviderAssertionEncryptionMode: Type: String Description: Optional, sets encryption mode for SAML assertions Default: "" AllowedValues: - "" - "Allowed" - "Required" RoleName: Type: String Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}') Default: "" AllowedPattern: '^$|^[\w+=,.@-]{1,64}$' ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-" RolePath: Type: String Description: Path for the IAM Role AllowedPattern: (^\/$)|(^\/.*\/$) Default: "/" RolePermissionsBoundary: Type: String Description: Optional ARN of the permissions boundary policy (leave empty for none) Default: "" RoleSessionDuration: Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200) Type: Number MinValue: 3600 MaxValue: 43200 Default: 7200 RoleManagedPolicy1: Type: String Description: Optional managed policy ARN 1 Default: "" RoleManagedPolicy2: Type: String Description: Optional managed policy ARN 2 Default: "" RoleManagedPolicy3: Type: String Description: Optional managed policy ARN 3 Default: "" RoleManagedPolicy4: Type: String Description: Optional managed policy ARN 4 Default: "" RoleManagedPolicy5: Type: String Description: Optional managed policy ARN 5 Default: "" Conditions: HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]] HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]] HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]] HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]] HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]] HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]] HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]] HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]] HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]] HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]] Resources: SAMLProvider: Type: AWS::IAM::SAMLProvider Properties: Name: !If - HasCustomProviderName - !Ref IdentityProviderName - !Ref AWS::NoValue SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument AddPrivateKey: !If - HasPrivateKey - !Ref IdentityProviderAddPrivateKey - !Ref AWS::NoValue AssertionEncryptionMode: !If - HasAssertionEncryptionMode - !Ref IdentityProviderAssertionEncryptionMode - !Ref AWS::NoValue SAMLFederatedRole: Type: AWS::IAM::Role Properties: RoleName: !If - HasCustomRoleName - !Ref RoleName - !Ref AWS::NoValue Path: !Ref RolePath Description: "SAML federated IAM role for SSO access with specified permissions" MaxSessionDuration: !Ref RoleSessionDuration PermissionsBoundary: !If - HasPermissionsBoundary - !Ref RolePermissionsBoundary - !Ref AWS::NoValue AssumeRolePolicyDocument: Version: '2012-10-17 ' Statement: - Effect: Allow Principal: Federated: !Ref SAMLProvider Action: - 'sts:AssumeRole' - 'sts:SetSourceIdentity' - 'sts:TagSession' Condition: StringEquals: 'SAML:aud': 'https://signin.aws.amazon.com/saml' ManagedPolicyArns: !Split - ',' - !Join - ',' - - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"] - !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"] - !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"] - !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"] - !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"] Outputs: RoleARN: Description: ARN of the created IAM Role Value: !GetAtt SAMLFederatedRole.Arn Export: Name: !Sub '${AWS::StackName}-RoleARN' IdentityProviderARN: Description: ARN of the created SAML Identity Provider Value: !Ref SAMLProvider Export: Name: !Sub '${AWS::StackName}-IdentityProviderARN' ``` ------