ポリシーの評価論理

プリンシパルが AWS Management Console、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS にリクエストを送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。

リクエストコンテキストの処理

AWS はリクエストを処理して、以下の情報をリクエストコンテキスト内に取り込みます。

次に、AWS は以上の情報を使用してリクエストコンテキストに適用するポリシーを見つけます。

単一アカウント内のポリシーを評価する

AWS によるポリシーの評価方法は、リクエストコンテキストに適用するポリシーのタイプによって異なります。以下のポリシータイプ (使用頻度の高い順に表示) は、単一の AWS アカウント で使用することができます。これらのポリシータイプの詳細については、「AWS Identity and Access Management でのポリシーとアクセス許可」をご参照ください。AWS がクロスアカウントアクセスのポリシーを評価する方法については、「クロスアカウントポリシーの評価論理」を参照してください。

これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になる点に注意してください。

リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価

アイデンティティのポリシーとリソースベースのポリシーは、それらが関連付けられているアイデンティティまたはリソースにアクセス許可を付与します。IAM エンティティ (ユーザーまたはロール) が同じアカウントのリソースへのアクセスをリクエストした場合、AWS は、アイデンティティのポリシーおよびリソースベースのポリシーによって付与されているすべてのアクセス許可を評価します。結果として、合計 2 種類のアクセス許可が付与されます。アクションがアイデンティティのポリシーかリソースベースのポリシー、または両方で許可されている場合、AWS はそのアクションを許可します。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

アクセス許可の境界を使用したアイデンティティベースのポリシーの評価

AWS でユーザーのアイデンティティベースのポリシーとアクセス許可の境界を評価する場合は、2 つのカテゴリーの共通部分に基づいてアクセス許可が決定されます。つまり、既存のアイデンティティベースのポリシーを使用してアクセス許可の境界をユーザーに追加すると、ユーザーが実行できるアクションが制限される場合があります。逆に、ユーザーからアクセス許可の境界を削除すると、ユーザーが実行できるアクションが増える場合があります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。他のポリシータイプがアクセス許可の境界で評価される方法について確認するには、「境界を設定した場合の有効なアクセス許可の評価」を参照してください。

SCP を使用したアイデンティティベースのポリシーの評価

ユーザーが組織のメンバーであるアカウントに所属している場合、結果として得られるアクセス許可はユーザーのポリシーと SCP の共通部分です。つまり、アクションは、アイデンティティベースのポリシーと SCP の両方で許可されます。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

自分のアカウントが AWS Organizations の組織のメンバーであるかどうかを確認できます。組織のメンバーは、SCP による影響を受ける可能性があります。AWS CLI コマンドまたは AWS API オペレーションを使用してこのデータを表示するには、Organizations エンティティに対する organizations:DescribeOrganization アクションのアクセス許可が必要です。Organizations コンソールでオペレーションを実行するには、追加のアクセス許可が必要です。SCP が特定のリクエストへのアクセスを拒否しているかどうかを確認する、または有効なアクセス権限を変更するには、AWS Organizations 管理者に連絡してください。

アカウント内でのリクエストの許可または拒否の決定

プリンシパルが、プリンシパルのエンティティと同じアカウントのリソースにアクセスするためのリクエストを AWS に送信するとします。AWS エンフォースメントコードは、リクエストを許可するか拒否するかどうかを決定します。AWS は、リクエストコンテキストに適用されるすべてのポリシーを評価します。単一アカウントでのポリシーの AWS 評価ロジックの概要を次に示します。

以下のフローチャートは、決定が下されるまでの詳細な流れを示しています。このフローチャートでは、リソースベースのポリシーと他のタイプのポリシーでの暗黙的な拒否による影響はカバーしていません。

アイデンティティベースのポリシーおよびリソースベースのポリシーの評価の例

最も一般的なポリシータイプは、アイデンティティベースのポリシーとリソースベースのポリシーです。リソースへのアクセスがリクエストされると、同じアカウント内の少なくとも 1 つの許可について、AWS はポリシーによって付与されたすべてのアクセス許可を評価します。これらのポリシーのいずれかが明示的に拒否された場合、許可は無効になります。

Carlos のユーザー名が carlossalazar で、ファイルを Amazon S3 バケット amzn-s3-demo-bucket-carlossalazar-logs に保存するとします。

また、次のポリシーを IAM ユーザー carlossalazar にアタッチするとします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

このポリシーの AllowS3ListRead ステートメントでは、アカウント内のすべてのバケットを一覧表示することを Carlos に許可します。AllowS3Self ステートメントでは、Carlos のユーザー名と同じ名前のバケットに対するフルアクセスを Carlos に許可します。DenyS3Logs ステートメントでは、名前に log が含まれている S3 バケットへのアクセスを Carlos に拒否します。

さらに、次のリソースベースのポリシー (バケットポリシー) を amzn-s3-demo-bucket-carlossalazar バケットにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
            ]
        }
    ]
}

このポリシーでは、carlossalazar ユーザーのみが amzn-s3-demo-bucket-carlossalazar バケットにアクセスできることを指定します。

Carlos がファイルを amzn-s3-demo-bucket-carlossalazar-logs バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この例では、アイデンティティベースのポリシーとリソースベースのポリシーのみが適用されます。これらは両方ともアクセス許可ポリシーです。アクセス許可の境界は適用されないため、評価ロジックは次のロジックに限定されます。

AWS は、最初にリクエストのコンテキストに適用される Deny ステートメントの有無を確認します。アイデンティティベースのポリシーでは、Carlos に対してログ記録用の S3 バケットへのアクセスが明示的に拒否されるため、該当するステートメントが見つかります。Carlos はアクセスが拒否されます。

彼は間違いに気が付いて、ファイルを amzn-s3-demo-bucket-carlossalazar バケットに保存しようとします。AWS は Deny ステートメントを探しますが、1 つも見つかりません。次に、アクセス許可ポリシーを確認します。ID ベースのポリシーとリソースベースのポリシーの両方で、リクエストが許可されます。従って、AWS でリクエストが許可されます。どちらでもステートメントが明示的に拒否された場合、リクエストは拒否されます。いずれかのポリシータイプでリクエストが許可され、もう一方では許可されない場合でも、リクエストは許可されます。

明示的な拒否と暗黙的な拒否の違い

該当するポリシーに Deny ステートメントが含まれている場合、リクエストは明示的に拒否されます。リクエストに適用されるポリシーに Allow ステートメントと Deny ステートメントが含まれている場合は、Deny ステートメントが Allow ステートメントより優先されます。リクエストは明示的に拒否されます。

該当する Deny ステートメントがなく、該当する Allow ステートメントもない場合は、暗黙的な拒否が発生します。IAM プリンシパルは、デフォルトでアクセスが拒否されされるため、アクションを実行するには明示的に許可を受ける必要があります。そうでない場合は、アクセスは暗黙的に拒否されます。

承認戦略を設計する場合、プリンシパルのリクエストを成功させるには、作成するポリシーに Allow ステートメントを含める必要があります。ただし、明示的な拒否と暗黙的な拒否の任意の組み合わせを選択できます。

例えば、許可されたアクション、暗黙的に拒否されたアクション、および明示的に拒否されたアクションを含む、次のポリシーを作成できます。AllowGetList ステートメントは、Get または List プレフィックスで始まる IAM アクションに対して、読み取り専用のアクセスを許可します。iam:CreatePolicy など、IAM の他のすべてのアクションは、暗黙的に拒否されます。DenyReports ステートメントは、iam:GetOrganizationsAccessReport などのReport サフィックスを含むアクションへのアクセスを拒否することで、IAM レポートへのアクセスを明示的に拒否します。誰かがこのプリンシパルに別のポリシーを追加して、iam:GenerateCredentialReport などのIAM レポートへのアクセス許可を付与した場合は、この明示的拒否のために、レポート関連のリクエストは引き続き拒否されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}