IAM-Tutorial: Berechtigungen für den Zugriff auf AWS Ressourcen auf der Grundlage von Tags definieren - AWS Identitäts- und Zugriffsverwaltung

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 Wofür ist ABAC? AWS.

Anmerkung

Sie müssen für jedes Sitzungs-Tag einen einzelnen Wert übergeben. AWS Security Token Service unterstützt keine mehrwertigen Sitzungs-Tags.

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. 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 für Dienste. AWS Sie können Ihren SAML-basierten Identitätsanbieter oder Webidentitätsanbieter so konfigurieren, dass Sitzungs-Tags 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.

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-centerKostenzuweisung“ erforderlich sein soll, um benutzerdefinierte AWS Abrechnungsberichte zu aktivieren. Weitere Informationen finden Sie unter Verwendung von Kostenzuordnungs-Tags im AWS Billing and Cost Management 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.

  • 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.

ABAC Tutorial – Berechtigungsdesign

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 Management Console, 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.

  • Erfahrung mit dem Erstellen und Bearbeiten von IAM-Benutzern, -Rollen und Richtlinien in der AWS Management Console. 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.

    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.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::account-ID-without-hyphens: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 finden Sie unter IAM-Benutzergruppen erstellen und Hinzufügen und Entfernen von Benutzern in einer IAM-Gruppe.

  2. Erstellen Sie die folgenden IAM-Benutzer und fügen Sie die access-assume-role-Berechtigungsrichtlinie an. Stellen Sie sicher, dass Sie Benutzerzugriff auf AWS Management Console bereitstellen auswählen, und fügen Sie dann die folgenden Tags hinzu. Weitere Informationen zum Erstellen und Markieren eines neuen Benutzers finden Sie unter Erstellen von IAM-Benutzern (Konsole).

    ABAC-Benutzer
    Benutzername Benutzer-Tag-Schlüssel Benutzer-Tag-Wert

    access-Arnav-peg-eng

    access-project

    access-team

    cost-center

    peg

    eng

    987654

    access-Mary-peg-qas

    access-project

    access-team

    cost-center

    peg

    qas

    987654

    access-Saanvi-uni-eng

    access-project

    access-team

    cost-center

    uni

    eng

    123456

    access-Carlos-uni-qas

    access-project

    access-team

    cost-center

    uni

    qas

    123456

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.

Weitere Richtlinien, die Sie für dieses Tutorial anpassen können, finden Sie auf den folgenden Seiten:

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.

{ "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. Informationen darüber, welche Aktionen in diesem Block nicht zulässig sind, finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS Secrets Manager. Diese Seite zeigt, dass Aktionen, die für den Secret-Ressourcentyp durchgeführt werden, den secretsmanager:ResourceTag/tag-key-Bedingungsschlüssel unterstützen. Einige Secrets Manager-Aktionen 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 Mehrwertige Kontextschlüssel.

    • 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 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 Delegieren von Berechtigungen an einen IAM-Benutzer. Informationen zur Verwendung eines Verbunds anstelle von IAM-Benutzern und -Rollen finden Sie unter IAM-Tutorial: Verwenden von SAML-Sitzungs-Tags für ABAC.

ABAC-Rollen
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 und öffnen Sie die Secrets Manager Konsole unterhttps://console.aws.amazon.com/secretsmanager/.

  2. 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 finden Sie in AWS Management ConsoleWechseln zu einer Rolle (Konsole)

  3. Wechseln Sie zur access-peg-engineering-Rolle.

  4. Speichern Sie ein neues Secret mit den folgenden Informationen. Weitere Informationen zum Speichern eines Secrets finden Sie unter Erstellen eines Basis-Secrets 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.

    2. Geben Sie test-access-peg-eng in das Feld Secret name (Secret-Name) ein.

    3. Fügen Sie verschiedene Tag-Kombinationen aus der folgenden Tabelle hinzu und überprüfen Sie das erwartete Verhalten.

    4. 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.

    ABAC-Tag-Kombinationen für die test-access-peg-eng-Rolle
    access-project-Tag-Wert access-team-Tag-Wert cost-center-Tag-Wert Zusätzliche Tags Erwartetes Verhalten
    (Keine) (Keine) (Keine) (Keine) Verweigert, da der access-project-Tag-Wert nicht mit dem Wert der Rolle von peg übereinstimmt.
    uni eng 987654 (Keine) Verweigert, da der access-project-Tag-Wert nicht mit dem Wert der Rolle von peg übereinstimmt.
    peg qas 987654 (Keine) Verweigert, da der access-team-Tag-Wert nicht mit dem Wert der Rolle von eng übereinstimmt.
    peg eng 123456 (Keine) Verweigert, da der cost-center-Tag-Wert nicht mit dem Wert der Rolle von 987654 übereinstimmt.
    peg eng 987654 owner = Jane Verweigert, da die Richtlinie das zusätzliche Tag owner nicht zulässt, auch wenn alle drei erforderlichen Tags vorhanden sind und ihre Werte mit den Werten der Rolle übereinstimmen.
    peg eng 987654 Name = Jane Zulässig, da alle drei erforderlichen Tags vorhanden sind und ihre Werte mit den Werten der Rolle übereinstimmen. Sie können auch das optionale Name-Tag mit einschließen.
  5. 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.

    ABAC-Rollen und -Tags
    Benutzername Rollenname Secret-Name Secret-Tags

    access-Mary-peg-qas

    access-peg-quality-assurance

    test-access-peg-qas

    access-project = peg

    access-team = qas

    cost-center = 987654

    access-Saanvi-uni-eng

    access-uni-engineering

    test-access-uni-eng

    access-project = uni

    access-team = eng

    cost-center = 123456

    access-Carlos-uni-qas

    access-uni-quality-assurance

    test-access-uni-qas

    access-project = uni

    access-team = qas

    cost-center = 123456

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

  2. 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 AWS Management Console finden Sie unterWechseln zu einer Rolle (Konsole).

  3. Klicken Sie im Navigationsbereich auf der linken Seite auf das Menüsymbol, um das Menü zu erweitern, und wählen Sie dann Secrets aus.

  4. 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.

  5. Wählen Sie den Namen eines der Secrets.

  6. 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.

    ABAC-Secret-Anzeigeverhalten für die einzelnen Rollen
    Rollenname Secret-Name Erwartetes Verhalten
    access-peg-engineering test-access-peg-eng Zulässig
    test-access-peg-qas Nicht zulässig
    test-access-uni-eng Zulässig
    test-access-uni-qas Nicht zulässig
    access-peg-quality-assurance test-access-peg-eng Nicht zulässig
    test-access-peg-qas Zulässig
    test-access-uni-eng Nicht zulässig
    test-access-uni-qas Zulässig
    access-uni-engineering test-access-peg-eng Zulässig
    test-access-peg-qas Nicht zulässig
    test-access-uni-eng Zulässig
    test-access-uni-qas Nicht zulässig
    access-uni-quality-assurance test-access-peg-eng Nicht zulässig
    test-access-peg-qas Zulässig
    test-access-uni-eng Nicht zulässig
    test-access-uni-qas Zulässig
  7. 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 -Konsole unterhttps://console.aws.amazon.com/iam/.

  2. 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

  3. Wählen Sie im Navigationsbereich auf der linken Seite Users (Benutzer).

  4. 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

  5. Verwenden Sie die Verfahren in Schritt 4: Testen der Erstellung von Secrets und Schritt 5: Testen der Anzeige von Secrets. Vergewissern Sie sich in einem anderen Browserfenster, dass Nikhil nur Centaur-Engineering-Secrets erstellen kann und dass er alle Engineering-Secrets anzeigen kann.

  6. Wählen Sie im Hauptfenster des Browsers, in dem Sie sich als Administrator angemeldet haben, den Benutzer access-Saanvi-uni-eng.

  7. Entfernen Sie auf der Registerkarte access-assume-roleBerechtigungen die Berechtigungsrichtlinie.

  8. 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).

    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. 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.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering", "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering" ] } ] }
  9. Verwenden Sie die Verfahren in Schritt 4: Testen der Erstellung von Secrets und Schritt 5: Testen der Anzeige von Secrets. 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

  2. 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 Management Console unterWechseln zu einer Rolle (Konsole).

  3. 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 und Löschen und Wiederherstellen eines Secrets im AWS Secrets Manager -Leitfaden.

    Aktualisierungs- und Löschverhalten eines ABAC-Secrets für die einzelnen Rollen
    Rollenname Secret-Name Erwartetes Verhalten

    access-peg-engineering

    test-access-peg-eng

    Zulässig
    test-access-uni-eng Nicht zulässig
    test-access-uni-qas Nicht zulässig

    access-peg-quality-assurance

    test-access-peg-qas Zulässig
    test-access-uni-eng Nicht zulässig

    access-uni-engineering

    test-access-uni-eng Zulässig
    test-access-uni-qas Nicht zulässig

    access-peg-quality-assurance

    test-access-uni-qas Zulässig

Übersicht

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 Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird.

Weitere Informationen finden Sie in den folgenden Ressourcen:

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.