Beispiel für SCPs zum Markieren von Ressourcen - AWS Organizations

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.

Beispiel für SCPs zum Markieren von Ressourcen

Benötigen Sie ein Tag für angegebene erstellte Ressourcen

Die folgende SCP verhindert, dass IAM-Benutzer und -Rollen in den betroffenen Konten bestimmte Ressourcentypen erstellen, wenn die Anforderung die angegebenen Tags nicht enthält.

Wichtig

Denken Sie daran, verweigerungsbasierte Richtlinien mit den Services zu testen, die Sie in Ihrer Umgebung verwenden. Das folgende Beispiel ist ein einfacher Block zum Erstellen unmarkierter Geheimnisse oder zum Ausführen von nicht markierten Amazon-EC2-Instances und enthält keine Ausnahmen.

Die folgende Beispielrichtlinie ist wie beschrieben nicht mit AWS CloudFormation kompatibel, da dieser Service ein Geheimnis erstellt und es dann als zwei separate Schritte kennzeichnet. Diese Beispielrichtlinie blockiert AWS CloudFormation effektiv daran, ein Geheimnis als Teil eines Stacks zu erstellen, da eine solche Aktion, wenn auch kurz, zu einem Geheimnis führen würde, das nicht wie erforderlich gekennzeichnet ist.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyCreateSecretWithNoProjectTag", "Effect": "Deny", "Action": "secretsmanager:CreateSecret", "Resource": "*", "Condition": { "Null": { "aws:RequestTag/Project": "true" } } }, { "Sid": "DenyRunInstanceWithNoProjectTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*" ], "Condition": { "Null": { "aws:RequestTag/Project": "true" } } }, { "Sid": "DenyCreateSecretWithNoCostCenterTag", "Effect": "Deny", "Action": "secretsmanager:CreateSecret", "Resource": "*", "Condition": { "Null": { "aws:RequestTag/CostCenter": "true" } } }, { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*" ], "Condition": { "Null": { "aws:RequestTag/CostCenter": "true" } } } ] }

Eine Liste aller Services und Aktionen, die diese sowohl in AWS Organizations-SCPs als auch in IAM-Berechtigungsrichtlinien unterstützen, finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS-Services im IAM-Benutzerhandbuch.

Verhindern, dass Tags geändert werden, außer von autorisierten Prinzipalen

Der folgende SCP zeigt, wie eine Richtlinie nur autorisierte Prinzipale erlauben kann, die Tags zu ändern, die Ihren Ressourcen zugeordnet sind. Dies ist ein wichtiger Bestandteil der attributbasierten Zugriffskontrolle (Attribute-based Access Control, ABAC) als Teil Ihrer AWS-Cloud-Sicherheitsstrategie. Die Richtlinie ermöglicht es einem Aufrufer, die Tags nur auf den Ressourcen zu ändern, bei denen das Autorisierungs-Tag (in diesem Beispiel access-project) genau mit dem gleichen Autorisierungs-Tag übereinstimmt, der an den Benutzer oder die Rolle angehängt ist, die die Anforderung stellt. Die Richtlinie verhindert auch, dass der autorisierte Benutzer den Wert des Tags ändert, der für die Autorisierung verwendet wird. Der aufrufende Prinzipal muss über das Autorisierungs-Tag verfügen, um Änderungen überhaupt vornehmen zu können.

Diese Richtlinie blockiert nur nicht autorisierte Benutzer daran, Tags zu ändern. Ein autorisierter Benutzer, der nicht durch diese Richtlinie blockiert wird, muss dennoch über eine separate IAM-Richtlinie verfügen, die die Allow-Berechtigung für die entsprechenden Tagging-APIs explizit erteilt. Wenn Ihr Benutzer beispielsweise eine Administratorrichtlinie mit Allow */* hat (alle Services und alle Operationen zulassen), führt die Kombination dazu, dass der Administratorbenutzer nur die Tags ändern darf, deren Autorisierungs-Tag-Wert mit dem angehängten Autorisierungs-Tag-Wert übereinstimmt an den Auftraggeber des Benutzers. Dies liegt daran, dass die explizite Deny in dieser Richtlinie die explizite Allow in der Administratorrichtlinie überschreibt.

Wichtig

Dies ist keine vollständige Richtlinienlösung und sollte nicht wie hier gezeigt verwendet werden. Dieses Beispiel soll nur einen Teil einer ABAC-Strategie veranschaulichen und muss für Produktionsumgebungen angepasst und getestet werden.

Die vollständige Richtlinie mit einer detaillierten Analyse ihrer Funktionsweise finden Sie unter Sichern von Ressourcen-Tags, die für die Autorisierung verwendet werden, mithilfe einer Service-Kontrollrichtlinie in AWS Organizations

Denken Sie daran, verweigerungsbasierte Richtlinien mit den Services zu testen, die Sie in Ihrer Umgebung verwenden.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ec2:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ec2:ResourceTag/access-project": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}", "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "access-project" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/access-project": true } } } ] }