IAM エンティティのアクセス許可の境界 - AWS Identity and Access Management

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

IAM エンティティのアクセス許可の境界

AWS では、IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界をサポートしています。アクセス許可の境界は、管理ポリシーを使用してアイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。

ポリシーの詳細については、「ポリシータイプ」を参照してください。

IAM エンティティ (ユーザーまたはロール) の境界を設定するには、AWS 管理ポリシーまたはカスタマー管理ポリシーを使用します。このポリシーでは、ユーザーやロールのアクセス許可の上限を設定します。

たとえば、ShirleyRodriguez という IAM ユーザーに Amazon S3、Amazon CloudWatch、Amazon EC2 の管理のみを許可するとします。このルールを適用するには、次のポリシーを使用して ShirleyRodriguez ユーザーのアクセス許可の境界を設定できます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*" ], "Resource": "*" } ] }

ポリシーを使用してユーザーのアクセス許可の境界を設定する場合、このポリシーではユーザーのアクセス許可は制限しますが、それ自体のアクセス許可は提供しません。この例のポリシーでは、ShirleyRodriguez のアクセス許可の上限を Amazon S3、CloudWatch、および Amazon EC2 のすべてのオペレーションに設定します。Shirley は、IAM など、他のどのサービスでもオペレーションを実行することはできません。実行を許可するアクセス許可ポリシーが適用されている場合でも同様です。たとえば、ShirleyRodriguez ユーザーに次のポリシーを追加できます。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } }

このポリシーでは、IAM のユーザーの作成を許可します。このアクセス許可ポリシーを ShirleyRodriguez ユーザーにアタッチすると、Shirley はユーザーを作成しようとしても、オペレーションは失敗します。アクセス許可の境界で iam:CreateUser オペレーションが許可されていないため、失敗します。これら 2 つのポリシーを考慮すると、Shirley には AWS でのオペレーションを実行するアクセス許可がありません。Amazon S3 などの他のサービスでのアクションを許可するには、別のアクセス許可ポリシーを追加する必要があります。または、IAM のユーザーの作成を許可するように、アクセス許可の境界を更新します。

境界を設定した場合の有効なアクセス許可の評価

IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界では、エンティティに許可されるアクセス許可の上限が設定されます。これにより、ユーザーやロールの有効なアクセス許可が変わる場合があります。エンティティの有効なアクセス許可は、ユーザーやロールに影響するすべてのポリシーによって付与されるアクセス許可です。エンティティのアクセス許可は、アカウント内で、アイデンティティベースのポリシー、リソースベースのポリシー、アクセス許可の境界、Organizations SCP、またはセッションポリシーの影響を受ける場合があります。各種ポリシーの詳細については、「IAM でのポリシーとアクセス許可」を参照してください。

これらのいずれかのポリシータイプによって、オペレーションへのアクセスが明示的に拒否された場合、そのリクエストは拒否されます。複数のアクセス許可タイプによってエンティティに付与されたアクセス許可はさらに複雑です。AWS でのポリシーの評価の詳細については、「ポリシーの評価論理」を参照してください。

アイデンティティベースのポリシー (境界あり) – アイデンティティベースのポリシーは、ユーザー、ユーザーのグループ、またはロールにアタッチされているインラインポリシーまたは管理ポリシーです。アイデンティティベースのポリシーはエンティティにアクセス許可を付与し、アクセス許可の境界は、それらのアクセス許可を制限します。有効なアクセス許可は、両方のポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。


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

リソースベースのポリシー – リソースベースのポリシーでは、指定されたプリンシパルが、ポリシーがアタッチされているリソースにアクセスする方法を制御します。

IAM ユーザー用のリソースベースのポリシー

アカウント内でアクセス許可の境界で暗黙的に拒否しても、リソースベースのポリシーによって IAM ユーザーに付与されるアクセス許可は制限されません。アクセス許可の境界は、ID ベースのポリシーによってユーザーに付与されるアクセス許可を減らします。リソースベースのポリシーは、ユーザーに追加のアクセス許可を与えることができます。


                            リソースベースのポリシー、アクセス許可の境界、およびアイデンティティベースのポリシーの評価
IAM ロールおよびフェデレーティッドユーザーのリソースベースのポリシー

アカウント内では、アクセス許可の境界内における暗黙の拒否は、リソースベースのポリシーによって基になる IAM ロールまたは IAM ユーザーの ARN に付与されるアクセス許可を制限します。ただし、リソースベースのポリシーがセッションプリンシパル (引き受けられたロール ARN またはフェデレーティッドユーザー ARN) にアクセス許可を直接付与する場合、アクセス許可の境界内における暗黙の拒否によってこれらのアクセス許可は制限されません。引き受けられたロールセッションまたはフェデレーティッドユーザーセッションについての効果的なアクセス許可の詳細については、「セッションポリシー」をご参照ください。

Organizations SCP – SCP は、全体の AWS アカウントに適用されます。この場合、アカウント内のプリンシパルによって行われるすべてのリクエストのアクセス許可が制限されます。IAM エンティティ (ユーザーまたはロール) は、SCP、アクセス許可の境界、およびアイデンティティベースのポリシーの影響を受けるリクエストを行うことができます。この場合、そのリクエストは、その 3 つすべてのポリシータイプで許可されている場合にのみ許可されます。有効なアクセス許可は、その 3 つすべてのポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。


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

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

セッションポリシー – セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) と、セッションポリシーから派生します。エンティティのアイデンティティベースのポリシーのアクセス許可は、セッションポリシーとアクセス許可の境界で制限されています。この一連のポリシータイプの有効なアクセス許可は、その 3 つすべてのポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。セッションポリシーの詳細については、「セッションポリシー」を参照してください。


                セッションポリシー、アクセス許可の境界、およびアイデンティティベースのポリシーの評価

アクセス許可の境界を使用した他のユーザーへの責任の委任

アクセス許可の境界を使用して、アクセス許可の管理タスク (ユーザーの作成など) をアカウントの IAM ユーザーに委任できます。これにより、アクセス許可の特定の境界内で、ユーザーの代わりに他のユーザーがタスクを実行できます。

たとえば、María は X-Company の AWS アカウントの管理者であるとします。彼女は、ユーザーの作成業務を Zhang を委任したいと考えます。しかし、Zhang が以下の社内ルールに従ってユーザーを作成することを確認する必要があります。

  • ユーザーは、IAM を使用してユーザー、グループ、ロール、またはポリシーを作成できない。

  • ユーザーは、Amazon S3 バケット logs へのアクセスを拒否される。また、Amazon EC2 インスタンス i-1234567890abcdef0 にはアクセスできない。

  • ユーザーは各自の境界ポリシーを削除できない。

これらのルールを適用するために、María は以下のタスクを実行します (各タスクの詳細は後述します)。

  1. María は、XCompanyBoundaries 管理ポリシーを作成し、これをアカウントのすべての新しいユーザーに対するアクセス許可の境界として使用します。

  2. María は、DelegatedUserBoundary 管理ポリシーを作成し、これを Zhang のアクセス許可の境界として割り当てます。Maria は、管理者 IAM ユーザーの ARN を書き留め、それをポリシーで使用して、Zhang がアクセスできないようにします。

  3. María は、DelegatedUserPermissions 管理ポリシーを作成し、これを Zhang のアクセス許可ポリシーとしてアタッチします。

  4. María は、Zhang に新しい責任と制限を伝えます。

タスク 1: María は、最初に管理ポリシーを作成して、新しいユーザーの境界を定義する必要があります。María は、必要なアクセス許可ポリシーをユーザーに付与することを Zhang に許可しますが、これらのユーザーを制限したいと思います。これを行うには、次のカスタマー管理ポリシーを XCompanyBoundaries という名前で作成します。このポリシーは以下の処理を実行します。

  • 複数のサービスへのフルアクセスをユーザーに許可する

  • IAM コンソールでの制限された自己管理アクセスを許可するつまり、ユーザーはコンソールにサインインした後にパスワードを変更できます。初期パスワードを設定することはできません。これを許可するには、"*LoginProfile" アクションを AllowManageOwnPasswordAndAccessKeys ステートメントに追加します。

  • Amazon S3 ログバケットまたは i-1234567890abcdef0 Amazon EC2 インスタンスへのユーザーアクセスを拒否する

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ServiceBoundaries", "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*", "dynamodb:*" ], "Resource": "*" }, { "Sid": "AllowIAMConsoleForCredentials", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswordAndAccessKeys", "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*ServiceSpecificCredential*", "iam:*SigningCertificate*" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::logs", "arn:aws:s3:::logs/*" ] }, { "Sid": "DenyEC2Production", "Effect": "Deny", "Action": "ec2:*", "Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0" } ] }

ステートメントごとに用途は異なります。

  1. このポリシーの ServiceBoundaries ステートメントでは、指定された AWS のサービスへのフルアクセスを許可します。つまり、これらのサービスにおける新しいユーザーのアクションは、ユーザーにアタッチされているアクセス許可ポリシーによってのみ制限されます。

  2. AllowIAMConsoleForCredentials ステートメントは、すべての IAM ユーザーを一覧表示するためのアクセス権を付与します。このアクセス権は、AWS マネジメントコンソール で [ユーザー] ページに移動するために必要です。また、このアクセス権では、アカウントのパスワード要件を表示することができます。これは、自分のパスワードを変更する場合に必要です。

  3. AllowManageOwnPasswordAndAccessKeys ステートメントは、自分のパスワードおよびプログラムを使用したアクセスキーの管理のみ許可します。これは、Zhang や別の管理者が IAM へのフルアクセスを許可するアクセス許可ポリシーを新しいユーザーに与える場合に重要です。この場合、そのユーザーが自分や他のユーザーのアクセス許可を変更することができます。このステートメントで、これを防止します。

  4. DenyS3Logs ステートメントでは、logs バケットへのアクセスを明示的に拒否します。

  5. DenyEC2Production ステートメントでは、i-1234567890abcdef0 インスタンスへのアクセスを明示的に拒否します。

タスク 2: María は、すべての X-Company ユーザーを作成することを Zhang に許可しますが、条件として XCompanyBoundaries をアクセス許可の境界とします。そのために、次のカスタマー管理ポリシーを DelegatedUserBoundary という名前で作成します。このポリシーでは、Zhang に許可されるアクセス許可の上限を定義します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "CreateOrChangeOnlyWithBoundary", "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:DeleteUserPolicy", "iam:AttachUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary", "iam:PutUserPolicy" ], "Resource": "*", "Condition": {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"}} }, { "Sid": "CloudWatchAndOtherIAMTasks", "Effect": "Allow", "Action": [ "cloudwatch:*", "iam:GetUser", "iam:ListUsers", "iam:DeleteUser", "iam:UpdateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile", "iam:GetAccountPasswordPolicy", "iam:GetLoginProfile", "iam:ListGroups", "iam:ListGroupsForUser", "iam:CreateGroup", "iam:GetGroup", "iam:DeleteGroup", "iam:UpdateGroup", "iam:CreatePolicy", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetUserPolicy", "iam:GetRolePolicy", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:ListEntitiesForPolicy", "iam:ListUserPolicies", "iam:ListAttachedUserPolicies", "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:SetDefaultPolicyVersion", "iam:SimulatePrincipalPolicy", "iam:SimulateCustomPolicy" ], "NotResource": "arn:aws:iam::123456789012:user/Maria" }, { "Sid": "NoBoundaryPolicyEdit", "Effect": "Deny", "Action": [ "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": [ "arn:aws:iam::123456789012:policy/XCompanyBoundaries", "arn:aws:iam::123456789012:policy/DelegatedUserBoundary" ] }, { "Sid": "NoBoundaryUserDelete", "Effect": "Deny", "Action": "iam:DeleteUserPermissionsBoundary", "Resource": "*" } ] }

ステートメントごとに用途は異なります。

  1. CreateOrChangeOnlyWithBoundary ステートメントでは、IAM ユーザーを作成することを Zhang に許可します。ただし、XCompanyBoundaries ポリシーを使用してアクセス許可の境界を設定することを条件とします。また、このステートメントでは、既存のユーザーにアクセス許可の境界を設定することを Zhang に許可します。ただし、同じポリシーを使用することを条件とします。最後に、このステートメントでは、このアクセス許可の境界が設定されたユーザーのアクセス許可ポリシーを管理することを Zhang に許可します。

  2. CloudWatchAndOtherIAMTasks ステートメントでは、他のユーザー、グループ、およびポリシーの管理タスクを実行することを Zhang に許可します。条件キーに一覧表示されていない IAM ユーザーのパスワードをリセットし、アクセスキーを作成するアクセス許可があります。これにより、ユーザーのサインインの問題を支援できます。

  3. NoBoundaryPolicyEdit ステートメントでは、XCompanyBoundaries ポリシーを更新するためのアクセスを Zhang に拒否します。自分自身や他のユーザーのアクセス許可の境界を設定するために使用されているポリシーを変更することは許可されません。

  4. NoBoundaryUserDelete ステートメントは、Zhang が自分自身あるいは他のユーザーのアクセス許可境界を削除するためにアクセスすることを拒否します。

次に María は、Zhang ユーザーのアクセス許可の境界として DelegatedUserBoundary ポリシーを割り当てます。

タスク 3: アクセス許可の境界ではアクセス許可の上限を設定するだけで、それ自体はアクセスを付与しないため、Maria は Zhang のアクセス許可ポリシーを作成する必要があります。次のポリシーを DelegatedUserPermissions という名前で作成します。このポリシーでは、設定された境界内で、Zhang が実行できるオペレーションを定義します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAM", "Effect": "Allow", "Action": "iam:*", "Resource": "*" }, { "Sid": "CloudWatchLimited", "Effect": "Allow", "Action": [ "cloudwatch:GetDashboard", "cloudwatch:GetMetricData", "cloudwatch:ListDashboards", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Sid": "S3BucketContents", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::ZhangBucket" } ] }

ステートメントごとに用途は異なります。

  1. このポリシーの IAM ステートメントでは、IAM へのフルアクセスを Zhang に許可します。ただし、アクセス許可の境界で一部の IAM オペレーションのみが許可されるため、有効な IAM アクセス許可はアクセス許可の境界でのみ限定されます。

  2. CloudWatchLimited ステートメントでは、CloudWatch で 5 つのアクションを実行することを Zhang に許可します。アクセス許可の境界ですべての CloudWatch アクションが許可されるため、有効な CloudWatch アクセス許可はアクセス許可ポリシーでのみ限定されます。

  3. S3BucketContents ステートメントでは、Amazon S3 バケット ZhangBucket を表示することを Zhang に許可します。ただし、アクセス許可の境界で一切の Amazon S3 アクションが許可されないため、アクセス許可ポリシーにかかわらず、S3 オペレーションを実行することはできません。

    注記

    Zhang のポリシーにより、彼は自分がアクセスできない Amazon S3 リソースにアクセスできるユーザーを作成できます。これらの管理アクションを委任することによって、Maria は Zhang に Amazon S3 へのアクセス権を効果的に信頼します。

次に María は、DelegatedUserPermissions ユーザーのアクセス許可ポリシーとして Zhang ポリシーをアタッチします。

タスク 4: María は、新しいユーザーを作成する手順を Zhang に伝えます。新しいユーザーを作成して必要なアクセス権を付与できますが、アクセス許可の境界として XCompanyBoundaries ポリシーを割り当てる必要があることを説明します。

Zhang は以下のタスクを実行します。

  1. Zhang は AWS マネジメントコンソール を使用してユーザーを作成します。ユーザー名として「Nikhil」と入力し、このユーザーに対してコンソールへのアクセスを有効にします。上記のポリシーではユーザーが IAM コンソールにサインインした後にのみパスワードを変更できるため、[Requires password reset (パスワードのリセットが必要)] の横にあるチェックボックスをオフにします。

  2. [アクセス許可の設定] ページで、Zhang は Nikhil にタスクの実行を許可するアクセス許可ポリシーとして [IAMFullAccess] と [AmazonS3ReadOnlyAccess] を選択します。

  3. Zhang は、María に教えられた手順を忘れて、[Set permissions boundary (アクセス許可の境界の設定)] セクションをスキップします。

  4. Zhang はユーザーの詳細を確認し、[ユーザーの作成] を選択します。

    オペレーションは失敗し、アクセスが拒否されます。Zhang の DelegatedUserBoundary アクセス許可の境界では、作成するユーザーにアクセス許可の境界として XCompanyBoundaries ポリシーが必要です。

  5. Zhang は前のページに戻ります。[Set permissions boundary (アクセス許可の境界の設定)] セクションで、XCompanyBoundaries ポリシーを選択します。

  6. Zhang はユーザーの詳細を確認し、[ユーザーの作成] を選択します。

    ユーザーが作成されます。

Nikhil は、サインインすると、アクセス許可の境界で拒否されているオペレーションを除いて、IAM と Amazon S3 にアクセスできます。たとえば、IAM で自分のパスワードは変更できますが、別のユーザーを作成したり、自分のポリシーを編集したりすることはできません。Nikhil は Amazon S3 への読み取り専用アクセス権を持っています。

リソースベースのポリシーを logs バケットに追加して Nikhil がそのバケットにオブジェクトを配置できるようにしても、Nikhil はこのバケットにアクセスできません。理由は、logs バケットのアクションはすべて、彼のアクセス許可の境界によって明示的に拒否されているためです。いずれかのポリシータイプで明示的に拒否されていると、リクエストは拒否されます。ただし、Secrets Manager シークレットにアタッチされているリソースベースのポリシーで、secretsmanager:GetSecretValue アクションの実行を Nikhil に許可している場合、Nikhil は、そのシークレットを取得して復号できます。これは、Secrets Manager オペレーションは、彼のアクセス許可境界によって明示的に拒否されており、アクセス許可の境界の暗黙的な拒否により、リソースベースのポリシーが制限されないためです。