AWS Identity and Access Management
ユーザーガイド

IAM JSON ポリシーの要素:NotPrincipal

NotPrincipal エレメントは、プリンシパルのリストに対して例外を指定する場合に使用します。たとえば、NotPrincipal 要素内で指定されているプリンシパルを除くすべてのプリンシパルによるアクセスを拒否することもできます。NotPrincipal を指定する場合の構文は、IAM JSON ポリシーの要素:Principal を指定する場合と同じです。

重要

NotPrincipal の使用が必要になるシナリオは非常に少ないため、NotPrincipal の使用を決定する前に、他の承認オプションを検討するようお勧めします。

NotPrincipalAllow

NotPrincipal"Effect": "Allow" と同じポリシーステートメント内で使用しないことを強くお勧めします。使用すると、NotPrincipal 要素で指定されたものを除くすべてのプリンシパルが許可されます。この操作では、ポリシーステートメントで指定されたアクセス許可が、指定されたものを除くすべてのプリンシパルに付与されるため、お勧めしません。この操作を行うと、匿名の (承認されていない) ユーザーにアクセス許可が付与される可能性があります。

NotPrincipalDeny

"Effect": "Deny" と同じポリシーステートメント内で NotPrincipal を使用すると、指定したものを除くすべてのプリンシパルに、このポリシーステートメントで指定されているアクションが明示的に拒否されます。このメソッドを使用して、一種のホワイトリストを実装できます。NotPrincipalDeny を使用する場合は、拒否されていないプリンシパルのアカウントの ARN も設定する必要があります。それ以外の場合、ポリシーでは、そのプリンシパルを含むアカウント全体へのアクセスが拒否されます。ポリシーに含めるサービスに応じて、AWS は最初にアカウントを確認し、次にユーザーを確認する場合があります。引き受けたロールのユーザー (ロールを使用しているユーザー) を評価する場合、AWS は最初にアカウントを確認し、次にロール、最後にロールを引き受けたユーザーを確認する場合があります。ロールを引き受けたユーザーは、ユーザーがロールを引き受けたときに指定されたロールセッション名で識別されます。したがって、ユーザーのアカウントの ARN、またはロールの ARN とそのロールを含むアカウントの ARN の両方を、明示的に含めることを強くお勧めします。

注記

ベストプラクティスとして、アカウントの ARN をポリシーに含めます。一部のサービスではアカウント ARN が必要ですが、すべてのケースで必要になるわけではありません。必要な ARN がない既存のポリシーは引き続き機能しますが、これらのサービスを含む新しいポリシーはこの要件を満たす必要があります。IAM はこれらのサービスを追跡しないため、常にアカウント ARN を含めることをお勧めします。

以下の例では、同じポリシーステートメント内で NotPrincipal"Effect": "Deny" を効果的に使用する方法を示しています。

例 1: 同じまたは異なるアカウントの IAM ユーザー

以下の例では、444455556666 という AWS アカウントに含まれる Bob という名前のユーザーを除いて、すべてのプリンシパルによるリソースへのアクセスが明示的に拒否されています。ベストプラクティスとして、NotPrincipal 要素には、Bob というユーザーの ARN と、Bob が属する AWS アカウント (arn:aws:iam::444455556666:root) の ARN が両方含まれています。NotPrincipal 要素に含まれているのが Bob の ARN のみであれば、このポリシーの結果として、ユーザー Bob を含む AWS アカウントへのアクセスは明示的に拒否されることになります。場合によっては、ユーザーは、親アカウントを超えるアクセス許可を得ることができないため、Bob のアカウントが明示的にアクセスを拒否されると、Bob もリソースにアクセスできなくなる可能性があります。

この例は、同じまたは異なる AWS アカウント (444455556666 ではなく) のリソースにアタッチされているリソースベースのポリシー内でポリシーステートメントに含まれている場合、意図したとおりに動作します。この例自体は Bob にアクセス許可を付与しておらず、明示的に拒否するプリンシパルのリストから Bob を除外しているだけです。リソースへのアクセスを Bob に許可するには、別のポリシーステートメントで "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/*" ] }] }

例 2: 同じまたは異なるアカウントの IAM ロール

以下の例では、444455556666 という AWS アカウントに含まれる cross-account-audit-app という名前の引き受けたロールユーザーを除いて、すべてのプリンシパルによるリソースへのアクセスが明示的に拒否されています。ベストプラクティスとして、NotPrincipal 要素には、引き受けたロールユーザー (cross-account-audit-app)、ロール (cross-account-read-only-role)、ロールが属する AWS アカウント (444455556666) の ARN が含まれています。ロールの ARN が NotPrincipal 要素に含まれていなければ、このポリシーの効果としては、このロールへのアクセスを明示的に拒否することになります。同様に、ロールが属する AWS アカウントの ARN が NotPrincipal 要素に含まれていなければ、このポリシーの結果として、AWS アカウントとそのアカウントに属するすべてのエンティティへのアクセスは明示的に拒否されることになります。場合によっては、引き受けたロールユーザーは、親ロールを超えるアクセス許可を得ることができず、ロールは、親である AWS アカウントを超えるアクセス許可を得ることができないため、ロールまたはアカウントが明示的にアクセスを拒否された場合、引き受けたロールユーザーはリソースにアクセスできなくなる可能性があります。

この例は、444455556666 ではなく別の AWS アカウントのリソースにアタッチされているリソースベースのポリシー内でポリシーステートメントに含まれている場合、意図したとおりに動作します。この例自体は引き受けたロールユーザー (cross-account-audit-app) にアクセスを許可しておらず、明示的に拒否するプリンシパルのリストから cross-account-audit-app を除外しているだけです。リソースへのアクセス許可を cross-account-audit-app に付与するには、別のポリシーステートメントで "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/*" ] }] }

このページの内容: