AWS-JSON-Richtlinienelemente: NotPrincipal - AWS Identity and Access Management

AWS-JSON-Richtlinienelemente: NotPrincipal

Verwenden Sie das Element NotPrincipal zum Angeben des IAM-Benutzers, des Verbundbenutzers, der IAM-Rolle, des AWS-Kontos, des AWS-Service oder eines anderen Auftraggebers, dem der Zugriff auf eine Ressource nicht gewährt oder verweigert wird. Das Element NotPrincipal ermöglicht Ihnen, eine Ausnahme zu einer Auftraggeberliste hinzuzufügen. Verwenden Sie dieses Element, um den Zugriff auf alle Auftraggeber mit Ausnahme des im Element NotPrincipal genannten zu verweigern. Die Syntax zur Angabe von NotPrincipal entspricht der Syntax zur Angabe von AWS-JSON-Richtlinienelemente: Principal.

Sie können das Element NotPrincipal nicht in einer identitätsbasierten IAM-Richtlinie verwenden. Sie können es in den Vertrauensrichtlinien für IAM-Rollen und in ressourcenbasierten Richtlinien verwenden. Ressourcenbasierte Richtlinien sind Richtlinien, die Sie direkt in eine IAM-Ressource einbinden.

Wichtig

NotPrincipal ist nur in sehr seltenen Fällen erforderlich. Wir empfehlen, andere Autorisierungsoptionen in Erwägung zu ziehen, bevor Sie entscheiden, NotPrincipal zu verwenden.

NotPrincipal mit Allow

Es wird ausdrücklich empfohlen, dass Sie NotPrincipal und "Effect": "Allow" nicht in derselben Richtlinienanweisung verwenden. Auf diese Weise werden alle Auftraggeber mit Ausnahme des im NotPrincipal-Element genannten zugelassen. Dies ist nicht empfehlenswert, da die in der Richtlinienanweisung aufgeführten Berechtigungen allen Auftraggeber gewährt werden, mit Ausnahme der angegebenen. Dadurch erteilen Sie möglicherweise anonymen (nicht authentifizierten) Benutzern eine Zugriffsberechtigung.

NotPrincipal mit Deny

Wenn Sie NotPrincipal in der gleichen Richtlinienanweisung wie "Effect": "Deny" verwenden, werden die in der Richtlinienanweisung aufgeführten Aktionen ausdrücklich allen Auftraggeber außer den angegebenen verweigert. Wenn Sie NotPrincipal mit Deny verwenden, müssen Sie auch den Konto-ARN des zugelassenen Auftraggebers angeben. Andernfalls könnte durch die Richtlinie der Zugriff auf das gesamte Konto mit dem Auftraggeber verweigert werden. Abhängig vom Service, den Sie in Ihre Richtlinien einschließen, validiert AWS möglicherweise erst das Konto und dann den Benutzer. Wenn ein Benutzer mit übernommener Rolle (also ein Benutzer, der eine Rolle verwendet) bewertet wird, prüft AWS möglicherweise zunächst das Konto und anschließend den Benutzer mit übernommener Rolle. Der Benutzer mit übernommener Rolle wird anhand des Namens der Rollensitzung identifiziert, die bei der Übernahme der Rolle durch den Benutzer angegeben wurde. Aus diesem Grund empfehlen wir dringend, dass Sie den ARN für das Konto eines Benutzers oder sowohl den ARN einer Rolle als auch den ARN für das Konto, das die Rolle enthält, mit aufnehmen.

Anmerkung

Es hat sich bewährt, die ARNs für das Konto in die Richtlinie aufzunehmen. Einige Services erfordern den Konto-ARN, auch wenn dies nicht immer erforderlich ist. Alle vorhandenen Richtlinien ohne den erforderlichen ARN bleiben funktionsfähig, neue Richtlinien aber, die diese Services enthalten, müssen die Anforderung erfüllen. IAM verfolgt diese Services nicht und empfiehlt daher, dass Sie diese immer in den Konto-ARN einschließen.

Die folgenden Beispiele zeigen die effektive Verwendung von NotPrincipal und "Effect": "Deny" in derselben Richtlinienanweisung.

Beispiel eines IAM-Benutzers in demselben oder einem anderen Konto

Im folgenden Beispiel wird allen Auftraggeber mit Ausnahme des Benutzers Bob im AWS-Konto 444455556666 der Zugriff auf eine Ressource explizit verweigert. Beachten Sie, dass im Zuge bewährter Methoden das NotPrincipal-Element den ARN des Benutzers Bob sowie des AWS-Kontos, zu dem Bob gehört (arn:aws:iam::444455556666:root), enthält. Wenn das NotPrincipal-Element nur den ARN von Bob enthielte, würde die Richtlinie den Zugriff auf das AWS-Konto, das den Benutzer Bob enthält, möglicherweise explizit verweigern. In einen Fällen dürfen die Berechtigungen eines Benutzers nicht umfangreicher als die des übergeordneten Kontos sein. Wenn folglich dem Konto von Bob der Zugriff explizit verweigert wird, kann Bob möglicherweise nicht auf die Ressource zugreifen.

Dieses Beispiel funktioniert wie beabsichtigt, wenn es Teil einer Richtlinienanweisung in einer ressourcenbasierten Richtlinie ist, die mit einer Ressource im gleichen oder einem anderen AWS-Konto (nicht 444455556666) verknüpft ist. Dieses Beispiel allein gewährt Bob noch keinen Zugriff, Bob wird lediglich aus der Liste der Auftraggeber ausgenommen, deren Zugriffsberechtigung explizit verweigert wird. Um Bob den Zugriff auf die Ressource zu gewähren, muss eine andere Richtlinienanweisung mithilfe von die Zugriffsberechtigung explizit erteilen "Effect": "Allow".

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:iam::444455556666:user/Bob", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::BUCKETNAME", "arn:aws:s3:::BUCKETNAME/*" ] }] }

Beispiel einer IAM-Rolle in demselben oder einem anderen Konto

Im folgenden Beispiel wird allen Auftraggeber mit Ausnahme des Benutzers mit übernommener Rolle mit dem Namen "cross-account-audit-app" im AWS-Konto 444455556666 der Zugriff auf eine Ressource explizit verweigert. Im Zuge bewährter Methoden enthält das NotPrincipal-Element den ARN des Benutzers mit übernommener Rolle (cross-account-audit-app), der Rolle (cross-account-read-only-role) und des AWS-Kontos, zu dem die Rolle gehört (444455556666). Wenn der ARN der Rolle nicht im NotPrincipal-Element enthalten wäre, würde dies vermutlich zu einer Zugriffsverweigerung der Rolle durch die Richtlinie führen. Wenn der ARN des NotPrincipal-Kontos, zu dem die Rolle gehört, nicht im Element AWS enthalten wäre, könnte dies gleichermaßen zu einer Verweigerung des Zugriffs auf das AWS-Konto und alle Entitäten darin durch die Richtlinie führen. In einigen Fällen dürfen Benutzer mit übernommener Rolle keine umfangreicheren Berechtigungen als ihre übergeordnete Rolle haben, und die Berechtigungen der Rollen dürfen nicht umfangreicher als die des übergeordnete AWS-Kontos sein. Wenn folglich der Rolle oder dem Konto der Zugriff verweigert wird, kann der Benutzer mit der übernommenen Rolle möglicherweise nicht auf die Ressource zugreifen.

Dieses Beispiel funktioniert wie vorgesehen, wenn es Teil einer Richtlinienanweisung in einer ressourcenbasierten Richtlinie ist, die einer Ressource in einem anderen AWS-Konto (nicht 444455556666) zugeordnet ist. Dieses Beispiel allein gewährt dem Benutzer mit übernommener Rolle "cross-account-audit-app" keine Zugriffsberechtigung, "cross-account-audit-app" wird lediglich aus der Liste der Auftraggeber ausgenommen, denen der Zugriff explizit verweigert wird. Um "cross-account-audit-app" den Zugriff auf die Ressource zu gewähren, muss eine andere Richtlinienanweisung mithilfe von die Zugriffsberechtigung explizit erteilen "Effect": "Allow".

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:sts::444455556666:assumed-role/cross-account-read-only-role/cross-account-audit-app", "arn:aws:iam::444455556666:role/cross-account-read-only-role", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::Bucket_AccountAudit", "arn:aws:s3:::Bucket_AccountAudit/*" ] }] }

Wenn Sie eine Sitzung mit übernommener Rolle in einem NotPrincipal-Element angeben, können Sie keinen Platzhalter (*) verwenden, der "alle Sitzungen" bedeutet. Auftraggeber müssen immer eine bestimmte Sitzung benennen.