Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # IAM-Tutorial: 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).