単一のアカウント内のリクエストのポリシー評価 - AWS Identity and Access Management
リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価アクセス許可の境界を使用したアイデンティティベースのポリシーの評価SCP または RCP を使用した ID ベースのポリシーの評価ポリシー評価の例

単一のアカウント内のリクエストのポリシー評価

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

  • ID ベースのポリシー — アイデンティティベースのポリシーは IAM ID (ユーザー、ユーザーのグループ、またはロール) にアタッチされており、アクセス許可を IAM エンティティ (ユーザーおよびロール) にアタッチします。リクエストにアイデンティティベースのポリシーのみ、リクエストに適用された場合、AWS では、それらのすべてのポリシーに少なくとも 1 つ Allow がないか確認します。

  • リソースベースのポリシー – リソースベースのポリシーは、ポリシーで指定されたプリンシパルの許可を付与します。このアクセス許可では、ポリシーがアタッチされているリソースに対してプリンシパルが実行できる操作を定義します。

  • IAM アクセス許可の境界 – アクセス許可の境界は、ID ベースのポリシーが IAM エンティティ (ユーザーまたはロール) に付与できる許可の上限を設定する機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、ID ベースのポリシーとそのアクセス許可の境界の両方で許可されている許可のみ実行できます。アクセス許可の境界で暗黙的に拒否しても、リソースベースのポリシーによって付与されるアクセス許可は制限される場合もあります。詳細については、「AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法」を参照してください。

  • AWS Organizations サービスコントロールポリシー (SCP) - Organizations SCP は、組織または組織単位 (OU) のアカウント内のプリンシパルのために使用可能な最大の許可を指定します。SCP は、各 AWS アカウントのルートユーザー を含むメンバーアカウントのプリンシパルに適用されます。SCP が存在する場合、ID ベースのポリシーおよびリソースベースのポリシーによってメンバーアカウントのプリンシパルに付与された許可は、SCP がアクションを許可する場合にのみ有効です。唯一の例外は、組織管理アカウントとサービスにリンクされたロールのプリンシパルです。

  • AWS Organizations リソースコントロールポリシー (RCP) – Organizations RCP は、組織または組織単位 (OU) のアカウント内のリソースについて使用できる最大の許可を指定します。RCP はメンバーアカウントのリソースに適用され、プリンシパルが組織に属しているかどうかにかかわらず、AWS アカウントのルートユーザー を含むプリンシパルの有効な許可に影響を及ぼします。RCP は、組織管理アカウントのリソースや、サービスにリンクされたロールによって実行された呼び出しには適用されません。

  • セッションポリシー – セッションポリシーは、ロールまたはフェデレーションユーザーの一時セッションをプログラムで作成する際にパラメータとして渡すポリシーです。ロールセッションをプログラムで作成するには、AssumeRole* API オペレーションのいずれかを使用します。これを行い、セッションポリシーに合格すると、結果として得られるセッションのアクセス許可は、IAM エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。フェデレーションユーザーのセッションを作成するには、IAM ユーザーのアクセスキーを使用して、API の GetFederationToken オペレーションをプログラムで呼び出します。詳細については、「セッションポリシー」を参照してください。

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

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

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

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

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

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

アイデンティティベースのポリシーとアクセス許可の境界の評価

SCP または RCP を使用した ID ベースのポリシーの評価

ユーザーが組織のメンバーであるアカウントに属しており、リソースベースのポリシーが設定されていないリソースにアクセスする場合、結果として得られる許可は、ユーザーのポリシー、サービスコントロールポリシー (SCP)、およびリソースコントロールポリシー (SCP) すべての適用を受けます。これは、3 つすべてのポリシータイプによってアクションが許可されなければならないことを意味します。ID ベースのポリシー、SCP、または RCP での明示的な拒否は、許可をオーバーライドします。

ID ベースのポリシーと SCP または RCP の評価

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

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

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

重要

同じアカウント内の ID ベースのポリシーまたはリソースベースのポリシーの一方がリクエストを許可し、他方が許可しない場合でも、リクエストは許可されます。

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 でリクエストが許可されます。どちらでもステートメントが明示的に拒否された場合、リクエストは拒否されます。いずれかのポリシータイプでリクエストが許可され、もう一方では許可されない場合でも、リクエストは許可されます。