AWS JSON ポリシーの要素: NotPrincipal

NotPrincipal 要素は "Effect":"Deny" を使用して、NotPrincipal 要素で指定されたプリンシパルを除くすべてのプリンシパルへのアクセスを拒否します。プリンシパルは、IAM ユーザー、フェデレーションユーザー、IAM ロール、引き受けたロールセッション、AWS アカウント、AWS サービス、またはその他のプリンシパルタイプにすることができます。プリンシパルの詳細については、「AWS JSON ポリシーの要素: Principal」を参照してください。

NotPrincipal は "Effect":"Deny" とともに使用する必要があります。"Effect":"Allow" とともに使用することはサポートされていません。

重要

セキュリティおよび認可戦略の一環として、新しいリソースベースのポリシーに NotPrincipal を使用することはお勧めしません。NotPrincipal を使用すると、複数のポリシータイプの影響をトラブルシューティングすることが難しい場合があります。代わりに ARN 条件演算子で aws:PrincipalArn コンテキストキーを使用することをおすすめします。

重要ポイント

• NotPrincipal 要素は、VPC エンドポイントを含む一部の AWS サービスのリソースベースのポリシーでサポートされています。リソースベースのポリシーは、リソースに直接埋め込むポリシーです。IAM のアイデンティティベースのポリシーでも IAM ロールの信頼ポリシーでも NotPrincipal 要素は使用できません。

• アクセス許可の境界ポリシーがアタッチされている IAM ユーザーまたはロールに対する Deny 効果を持つ NotPrincipal ポリシー要素を含むリソースベースのポリシーステートメントは使用しないでください。Deny 効果のある NotPrincipal 要素は、NotPrincipal 要素で指定されている値に関係なく、アクセス許可の境界ポリシーがアタッチされている IAM プリンシパルを常に拒否します。これにより、本来であればリソースにアクセスできたはずの IAM ユーザーまたはロールの一部がアクセスを失うことになります。リソースベースのポリシーステートメントを変更して、NotPrincipal 要素ではなく aws:PrincipalArn コンテキストキーで条件演算子 ArnNotEquals を使用してアクセスを制限することをおすすめします。アクセス許可の境界の詳細については、「IAM エンティティのアクセス許可境界」を参照してください。

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

• NotPrincipal 要素は、サービスコントロールポリシー (SCP) およびリソースコントロールポリシー (RCP) ではサポートされていません。

NotPrincipal 要素の代替方法

AWS でアクセスコントロールを管理する場合、指定した 1 つまたは複数のプリンシパルは例外とし、リソースへのすべてのプリンシパルアクセスを明示的に拒否する必要があるシナリオがあります。AWS では、より正確な制御とトラブルシューティングを容易にするために、グローバル条件コンテキストキーを持つ Deny ステートメントを使用することをお勧めします。次の例は、 StringNotEquals や ArnNotEquals などの条件演算子を使用して、Condition 要素で指定されたものを除くすべてのプリンシパルへのアクセスを拒否する代替アプローチを示しています。

IAM ロールを使用したシナリオ例

Deny ステートメントを含むリソースベースのポリシーを使用すると、すべての IAM ロール (Condition 要素で指定されたロールを除く) がリソースにアクセスしたり操作したりすることを防ぐことができます。このアプローチは、明示的な拒否が常に許可ステートメントよりも優先されるという AWS セキュリティ原則に従い、AWS インフラストラクチャ全体で最小特権の原則を維持するのに役立ちます。

NotPrincipal を使用する代わりに、グローバル条件コンテキストキーと ArnNotEquals のような条件演算子を含む Deny ステートメントを使用して、IAMロールがリソースにアクセスできるように明示的に許可することをお勧めします。次の例では、aws:PrincipalArn を使用して、ロール Bucket_Account_Audit が read-only-role フォルダ内の Amazon S3 バケットにアクセスすることを許可します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCrossAuditAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::Bucket_Account_Audit",
        "arn:aws:s3:::Bucket_Account_Audit/*"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:sts::444455556666:role/read-only-role"
        }
      }
    }
  ]
}

サービスプリンシパルを使用するシナリオ例

Deny ステートメントを使用して、 Condition 要素で指定されたものを除くすべてのサービスプリンシパルがリソースにアクセスまたは操作できないようにすることができます。このアプローチは、きめ細かなアクセスコントロールを実装する必要がある場合や、AWS 環境内のさまざまなサービスとアプリケーション間のセキュリティ境界を確立する必要がある場合に特に役立ちます。

NotPrincipal を使用する代わりに、グローバル条件コンテキストキーと条件演算子 StringNotEquals を含む Deny ステートメントを使用して、サービスプリンシパルにリソースへのアクセスを明示的に許可することをお勧めします。次の例では、aws:PrincipalServiceName を使用して、AWS CodeBuild サービスプリンシパルが BUCKETNAME フォルダ内の Amazon S3 バケットにアクセスすることを明示的に許可します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNotCodeBuildAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::BUCKETNAME",
        "arn:aws:s3:::BUCKETNAME/*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalServiceName": "codebuild.amazonaws.com"
        }
      }
    }
  ]
}