ポリシーを使用して AWS リソースへのアクセスを制御する - AWS Identity and Access Management

ポリシーを使用して AWS リソースへのアクセスを制御する

ポリシーを使用して、IAM や AWS のすべてのサービスのリソースへのアクセスをコントロールできます。

AWS で ポリシーを使用してアクセスをコントロールするには、AWS がアクセスを許可する方法を理解する必要があります。AWS はリソースの集合で構成されています。IAM ユーザーはリソースです。Amazon S3 バケットはリソースです。AWS API、AWS CLI、または AWS Management Console を使用してオペレーション (ユーザーの作成など) を実行する場合、このオペレーションに対するリクエストを送信します。リクエストでは、アクション、リソース、プリンシパルエンティティ (ユーザーまたはロール)、プリンシパルアカウント、および必要なリクエスト情報を指定します。これらのすべての情報により、コンテキストが提供されます。

次に、AWSはユーザー (プリンシパル) が認証され (サインイン済み)、指定されたリソースで指定されたアクションの実行が許可されている (権限を持っている) ことを確認します。認可時、AWS は、リクエストのコンテキストに該当するすべてのポリシーをチェックします。通常、ポリシーは JSON ドキュメントとして AWS に保存され、プリンシパルエンティティのアクセス許可を指定します。ポリシーのタイプと用途の詳細については、「IAM でのポリシーとアクセス許可」を参照してください。

AWS は、リクエストの各部分がポリシーで許可されている場合のみ、リクエストを許可します。このプロセスの図を表示するには、「IAM の仕組みについて」を参照してください。AWS でリクエストを承認するかどうかの決定方法の詳細については、「ポリシーの評価論理」を参照してください。

IAM ポリシーを作成するときは、以下へのアクセスを制御できます。

  • プリンシパル – リクエストを行っているユーザー(プリンシパル)に許可される操作を制御します。

  • IAM アイデンティティ – どの IAM アイデンティティ (ユーザーグループ、ユーザー、ロール) に、どのようにアクセスできるかをコントロールします。

  • IAM ポリシー – だれがカスタマー管理ポリシーを作成、編集、削除でき、だれがすべての管理ポリシーをアタッチおよびデタッチできるかをコントロールします。

  • AWS リソース – アイデンティティベースのポリシーまたはリソースベースのポリシーを使用してだれがリソースにアクセスできるかをコントロールします。

  • AWS アカウント – リクエストを特定のアカウントのメンバーのみに許可するかどうかコントロールします。

ポリシーは、誰が AWS リソースにアクセスできるか、またそれらのリソース上でどのようなアクションを実行できるかを指定することを可能にします。すべての IAM ユーザーには、初期状態ではアクセス許可はありません。言い換えると、デフォルト設定では、ユーザーは何もできず、そのユーザーのアクセスキーを参照することすらできません。ユーザーに何かの操作を実行するアクセス許可を付与する場合は、そのユーザーにアクセス許可を追加できます (つまり、ポリシーをユーザーにアタッチします)。または、目的のアクセス許可を持つユーザーグループにユーザーを追加します。

例えば、自らのアクセスキーをリスト化するためのユーザー権限を付与することができます。また、権限を拡大し、各ユーザーが自らのキーを作成、更新、および削除できるようにすることもできます。

ユーザーグループにアクセス許可を付与することで、そのユーザーグループ内のすべてのユーザーに権限が付与されます。例えば、Administrators ユーザーグループに対しては、AWS アカウントのリソースに対してすべての IAM アクションを実行できるアクセス許可を付与します。その他の例としては、Managers ユーザーグループに対して、AWS アカウントの Amazon EC2 インスタンスを記述するアクセス許可を付与することが挙げられます。

ユーザー、ユーザーグループ、およびロールに基本的なアクセス許可を委任する方法については、「IAM リソースにアクセスするのに必要なアクセス許可」を参照してください。基本的な権限を示すポリシーのさらに多くの例については、「IAM リソースの管理に関するポリシーの例」を参照してください。

プリンシパルへのアクセスの制御

リクエスト元 (プリンシパル) に許可される操作を制御するには、ポリシーを使用します。そのためには、リクエスト元のアイデンティティ (ユーザー、ユーザーグループ、またはロール) にアイデンティティベースのポリシーをアタッチする必要があります。また、アクセス許可の境界を使用して、エンティティ (ユーザーまたはロール) に付与することのできるアクセス許可の上限を設定することもできます。

たとえば、CloudWatch、Amazon DynamoDB、Amazon EC2、および Amazon S3 に対するフルアクセスをユーザー Zhang Wei に許可するとします。この場合、2 つの異なるポリシーを作成し、後で別のユーザーにアクセス許可セットの 1 つが必要になった場合に、ポリシーを分割できます。または、両方のアクセス許可を 1 つのポリシーにまとめて、このポリシーを Zhang Wei という IAM ユーザーにアタッチできます。また、Zhang が属しているユーザーグループや、Zhang が引き受けることができるロールにポリシーをアタッチすることもできます。その結果、Zhang が S3 バケットのコンテンツを表示する場合、リクエストは許可されます。新しい IAM ユーザーを作成しようとすると、必要なアクセス許可がないため、このリクエストは拒否されます。

S3 バケット CompanyConfidential へのアクセスを完全に遮断するには、Zhang に対してアクセス許可の境界を設定できます。そのためには、Zhang に付与するアクセス許可の上限を決定します。この場合、ユーザーの操作を制御するために、アクセス許可ポリシーを使用します。ここで必要なことは、ユーザーが機密バケットにアクセスしないことだけです。したがって、以下のポリシーを使用して Zhang の境界を定義し、Amazon S3 と他のいくつかのサービスに対するすべての AWS アクションを許可する一方で、S3 バケット CompanyConfidential へのアクセスを拒否します。このアクセス許可の境界では、一切の IAM アクションが許可されないため、Zhang は自分 (または他のいかなるユーザー) の境界も削除できません。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SomeServices", "Effect": "Allow", "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:*", "s3:*" ], "Resource": "*" }, { "Sid": "NoConfidentialBucket", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::CompanyConfidential/*", "arn:aws:s3:::CompanyConfidential" ] } ] }

このようなポリシーをユーザーのアクセス許可の境界として割り当てる場合、境界自体はアクセス許可を付与しないことに注意してください。アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の上限を設定します。アクセス許可の境界の詳細については、「IAM エンティティのアクセス許可の境界」を参照してください。

前述の手順の詳細については、以下のリソースを参照してください。

アイデンティティへのアクセスの制御

IAM ポリシーを作成し、そのポリシーをユーザーグループ経由ですべてのユーザーにアタッチすることで、アイデンティティに対してユーザーが実行できる操作を制御できます。これを行うには、アイデンティティに対して実行できる操作や、アイデンティティにアクセスできるユーザーを制限するポリシーを作成します。

たとえば、AllUsers という名前のユーザーグループを作成し、そのユーザーグループをすべてのユーザーにアタッチできます。前出のセクションの説明からわかるように、ユーザーグループを作成することで、認証情報をローテーションするためのアクセス許可をすべてのユーザーに付与することができます。その上で、ポリシーの条件に名前が含まれていないユーザーがユーザーグループに変更を加えしようとした場合は、そのアクセスが拒否されるようにポリシーを作成できます。ただし、ポリシーのその部分では、リストされたユーザーを除くすべてのユーザーへのアクセスが拒否されます。また、ユーザーグループのすべてのユーザーが、ユーザーグループを管理するすべてのアクションにアクセスできるような権限も、含めておく必要があります。最後に、このポリシーをユーザーグループにアタッチし、すべてのユーザーに適用します。この結果、ポリシーで指定されていないユーザーがユーザーグループに変更を加えようとすると、そのリクエストは拒否されるようになります。

ビジュアルエディタを使用してこのポリシーを作成するには

  1. AWS Management Console にサインインし、IAM コンソール(https://console.aws.amazon.com/iam/)を開きます。

  2. 左側のナビゲーションペインで、[ポリシー] を選択します。

    初めて [ポリシー] を選択する場合には、[管理ポリシーにようこそ] ページが表示されます。[Get Started] を選択します。

  3. [Create policy] を選択します。

  4. [Visual editor (ビジュアルエディタ)] タブで、まず [Choose a service (サービスの選択)] を選択します。次に、[IAM] を選択します。

  5. [アクションの選択] を選択し、検索ボックスに「group」と入力します。ビジュアルエディタで、group という語を含むすべての IAM アクションが表示されます。すべてのチェックボックスをオンにします。

  6. [リソース] を選択して、ポリシーのリソースを指定します。選択したアクションに基づいて、[グループ]、[group-path (グループパス)]、[ユーザー] の各リソースタイプが表示されます。

    • グループ – [Add ARN (ARN の追加)] を選択します。[リソース] で、[すべて] の横にあるチェックボックスをオンにします。[パス付きグループ名] にユーザーグループ名「AllUsers」を入力します。次に、[Add (追加)] を選択します。

    • [group-path (グループパス)] – [すべて] の横にあるチェックボックスをオンにします。

    • [ユーザー] – [すべて] の横にあるチェックボックスをオンにします。

    選択したアクションの 1 つである ListGroups は、特定のリソースの使用をサポートされていません。そのアクションに対して [All resources (すべてのリソース)] を選択する必要はありません。[JSON] タブでポリシーを保存するか、ポリシーを表示すると、IAM によって自動的に新しいアクセス許可ブロックが作成され、すべてのリソースでこのアクションにアクセス許可が付与されることがわかります。

  7. 別のアクセス許可ブロックを追加するには、[Add additional permissions (さらにアクセス許可を追加する)] を選択します。

  8. [サービスロールの選択]、[IAM] の順に選択します。

  9. [アクションの選択]、[Switch to deny permissions (アクセス許可の拒否に切り替え)] の順に選択します。この操作を行うと、ブロック全体を使用してアクセス許可が拒否されます。

  10. 検索ボックスに「group」と入力します。ビジュアルエディタで、group という語を含むすべての IAM アクションが表示されます。次のアクションの横にあるチェックボックスをオンにします。

    • CreateGroup

    • DeleteGroup

    • RemoveUserFromGroup

    • AttachGroupPolicy

    • DeleteGroupPolicy

    • DetachGroupPolicy

    • PutGroupPolicy

    • UpdateGroup

  11. [リソース] を選択して、ポリシーのリソースを指定します。選択したアクションに基づいて、[グループ] リソースタイプが表示されます。[Add ARN (ARN の追加)] を選択します。[リソース] で、[すべて] の横にあるチェックボックスをオンにします。[パス付きグループ名] にユーザーグループ名「AllUsers」を入力します。次に、[Add (追加)] を選択します。

  12. [Specify request conditions (optional) (リクエスト条件の指定 (オプション))]、[Add condition (条件の追加)] の順に選択します。次の値をフォームに入力します。

    • [Key (キー)] – [aws:username] を選択します。

    • [限定条件] – [Default (デフォルト)] を選択します。

    • [演算子] – [StringNotEquals] を選択します。

    • [Value (値)] – 「srodriguez」と入力し、[Add another condition value (別の条件値の追加)] を選択します。「mjackson」と入力し、[Add another condition value (別の条件値の追加)] を選択します。「adesai」と入力し、[Add (追加)] を選択します。

    この条件により、リストに含まれていないユーザーが指定したユーザーグループ管理アクションの呼び出しを行うと、そのアクセスは拒否されます。これによりアクセス許可が明示的に拒否されるため、ユーザーにアクションの呼び出しを許可した以前のブロックは上書きされます。リストに含まれるユーザーは、アクセスを拒否されることはありません。また、アクセス許可は最初のアクセス許可ブロックで付与されるためユーザーグループを完全に管理できます。

  13. 完了したら、[ポリシーの確認] を選択します。

    注記

    いつでも [Visual editor (ビジュアルエディタ)] タブと [JSON] タブを切り替えることができます。ただし、[Visual editor (ビジュアルエディタ)] タブで [ポリシーの確認] を変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、「ポリシーの再構成」を参照してください。

  14. [Review policy (ポリシーの確認)] ページで、[Name (名前)] に「LimitAllUserGroupManagement」と入力します。[説明] に「Allows all users read-only access to a specific user group, and allows only specific users access to make changes to the user group」と入力します。ポリシー概要を確認し、意図したアクセス許可を付与したことを確認します。次に、[ポリシーの作成] を選択して新しいポリシーを保存します。

  15. ユーザーグループにポリシーをアタッチします。詳細については、「IAM ID のアクセス許可の追加および削除」を参照してください。

また、この JSON ポリシードキュメント例を使用して、同じポリシーを作成できます。この JSON ポリシーを表示するには、「IAM: 特定の IAM ユーザーによるグループの管理をプログラムによりコンソールで許可する」を参照してください。JSON ドキュメントを使用してポリシーを作成する詳細な手順については、「[JSON] タブでのポリシーの作成」を参照してください。

ポリシーへのアクセスの制御

ユーザーが AWS 管理ポリシーを適用する方法を制御できます。これを行うには、すべてのユーザーにこのポリシーをアタッチします。理想としては、このためにユーザーグループを使用します。

例えば、IAMUserChangePasswordPowerUserAccess の AWS 管理ポリシーのみを新しい IAM ユーザー、ユーザーグループ、またはロールにアタッチするポリシーを作成することなどが考えられます。

カスタマー管理ポリシーの場合、それらのポリシーを作成、更新、削除できるユーザーを制御できます。プリンシパルエンティティ (ユーザーグループ、ユーザー、ロール) に対し、ポリシーをアタッチおよびデタッチできるユーザーの制御が可能です。ユーザーにどのエンティティのどのポリシーのアタッチまたはデタッチを許可するかも制御できます。

たとえば、アカウント管理者にポリシーを作成、更新、削除する権限を付与できます。次に、チームリーダーまたはその他の制限付き管理者に、管理対象となるプリンシパルエンティティのポリシーをアタッチおよびデタッチする権限を付与します。

詳細については、以下のリソースを参照してください。

カスタマー管理ポリシーを作成、更新、削除するアクセス許可の制御

IAM ポリシーを使用して、だれが AWS アカウントのカスタマー管理ポリシーを作成、更新、削除できるかをコントロールできます。ポリシーまたはポリシーのバージョンの作成、更新、削除に直接関連する API オペレーションを以下に示します。

前述のリストの API オペレーションは、許可または拒否できるアクション、つまり IAM ポリシーを使用して付与できるアクセス許可に対応しています。

次のポリシー例を考えます。この例では、AWS アカウントのすべてのカスタマー管理ポリシーのデフォルトバージョンを作成、更新 (新しいポリシーバージョンの作成)、削除、および設定することをユーザーに許可します。このポリシーの例では、ユーザーにポリシーの一覧表示とポリシーの取得も許可しています。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON] タブでのポリシーの作成」を参照してください。

例 すべてのポリシーの作成、更新、削除、一覧表示、取得、デフォルトバージョンの設定を許可するポリシーの例

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:SetDefaultPolicyVersion" ], "Resource": "*" } }

指定した管理ポリシーのみに適用するポリシーを作成して、これらの API オペレーションの使用を制限することもできます。たとえば、特定のカスタマー管理ポリシーのみを対象にして、ユーザーにデフォルトバージョンの設定とポリシーバージョンの削除を許可することが考えられます。これは、権限を付与するポリシーの Resource エレメントにポリシー ARN を指定することで実行できます。

次のポリシー例では、ポリシーバージョンを削除してデフォルトバージョンを設定することをユーザーに許可します。ただし、これらのアクションが許可されるのは、パス /TEAM-A/ が含まれているカスタマー管理ポリシーに限られます。カスタマー管理ポリシー ARN は、ポリシーの Resource 要素で指定されています(この例では、ARN にパスとワイルドカードが含まれているため、パス /TEAM-A/ を含むすべてのカスタマー管理ポリシーに一致します)。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON] タブでのポリシーの作成」を参照してください。

カスタマー管理ポリシーの名前にパスを使用する場合の詳細については、「フレンドリ名とパス」を参照してください。

例 特定のポリシーのみを対象にして、ポリシーバージョンの削除とデフォルトバージョンの設定を許可するポリシーの例

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/TEAM-A/*" } }

管理ポリシーをアタッチおよびデタッチするアクセス許可の制御

また、IAM ポリシーを使用して、ユーザーが特定の管理ポリシーのみで作業することを許可できます。実際には、ユーザーがどのアクセス許可を他のプリンシパルエンティティに付与できるかをコントロールできます。

プリンシパルエンティティの管理ポリシーのアタッチとデタッチに直接関連する API オペレーションを以下に示します。

指定した管理ポリシーおよびプリンシパルエンティティのみに適用するポリシーを作成して、これらの API オペレーションの使用を制限することができます。たとえば、指定した管理ポリシーのみを対象にして、ユーザーに管理ポリシーのアタッチを許可することが考えられます。あるいは、指定したプリンシパルエンティティのみを対象にして、ユーザーに管理ポリシーのアタッチを許可することも考えられます。

以下のポリシー例では、パス /TEAM-A/ を含むユーザーグループとロールのみに対して管理ポリシーをアタッチできるように、ユーザーに権限を付与しています。ユーザーグループとロールの ARN はポリシーの Resource 要素で指定します(この例では、ARN にパスとワイルドカード文字が含まれているため、パス /TEAM-A/ を含むすべてのユーザーグループとロールが適合することになります)。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON] タブでのポリシーの作成」を参照してください。

例 特定のユーザーグループまたはロールにのみ、管理ポリシーのアタッチを許可するポリシーの例

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:group/TEAM-A/*", "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/TEAM-A/*" ] } }

前の例のアクションをさらに制限して、特定のポリシーにのみ影響を与えられるようにすることができます。つまり、ポリシーに条件を追加することで、ユーザーがどのアクセス許可を他のプリンシパルエンティティにアタッチできるかをコントロールできます。

次の例では、条件により、アタッチしたポリシーが指定したポリシーのいずれかに一致した場合のみに AttachGroupPolicyAttachRolePolicy の権限を許可します。条件では、iam:PolicyARN 条件キーを使用して、どのポリシーをアタッチできるかを決定しています。次のポリシー例は、前の例を拡張したものです。この例では、パス /TEAM-A/ が含まれている管理ポリシーを、パス /TEAM-A/ が含まれているユーザーグループとロールにのみアタッチすることをユーザーに許可しています。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON] タブでのポリシーの作成」を参照してください。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:group/TEAM-A/*", "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/TEAM-A/*" ], "Condition": {"ArnLike": {"iam:PolicyARN": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/TEAM-A/*"} } } }

このポリシーでは、ARN にワイルドカード文字が含まれているため、ArnLike 条件演算子を使用します。特定の ARN については、ArnEquals 条件演算子を使用します。ArnLike および ArnEquals の詳細については、「ポリシー要素リファレンス」の「条件の種類」セクションの「Amazon リソースネーム (ARN) 条件演算子」を参照してください。

たとえば、アクションの使用を制限して、指定した管理ポリシーのみを対象にすることもできます。これは、権限を付与するポリシーの Condition エレメントにポリシー ARN を指定することで実行できます。たとえば、カスタマー管理ポリシーの ARN を指定するには、次のようにします。

"Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::123456789012:policy/POLICY-NAME"} }

または、ポリシーの Condition 要素で AWS 管理ポリシーの ARN を指定することもできます。AWS 管理ポリシーの ARN では、以下の例に示すように、アカウント ID の代わりにポリシー ARN で aws という特別なエイリアスを使用します。

"Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"} }

リソースに対するアクセスの制御

アイデンティティベースのポリシーまたはリソースベースのポリシーを使用してリソースにアクセスできるユーザーを制御できます。アイデンティティベースのポリシーでは、ポリシーをアイデンティティにアタッチし、そのアイデンティティがアクセスできるリソースを指定します。リソースベースのポリシーでは、制御するリソースにポリシーをアタッチします。ポリシーでは、リソースにアクセスできるプリンシパルを指定します。ポリシーの両方のタイプの詳細については、「アイデンティティベースのポリシーおよびリソースベースのポリシー」を参照してください。

詳細については、以下のリソースを参照してください。

リソース作成者であっても自動的にアクセス権限を有するわけではない

AWS アカウント ルートユーザー 認証情報を使用してサインインする場合、そのアカウントに属するリソースであらゆるアクションを実行する権限があります。ただし、それは IAM ユーザーには当てはまりません。IAM ユーザーはリソースを作成するためのアクセス許可を付与されることはありますが、そのユーザーの権限は、たとえ自ら作成したリソースに対するものであっても、明示的に付与された権限に限定されます。つまり、IAM ロールなどのリソースを作成するだけでは、そのロールを編集または削除するアクセス許可は自動的には与えられません。さらに、アクセス許可は、アカウント所有者またはユーザー権限を管理するアクセス許可を付与されたその他のユーザーによって、いつでも無効にすることができます。

特定のアカウント内のプリンシパルへのアクセスの制御

お客様は自らのアカウント内の IAM ユーザーに対し、お客様のリソースへのアクセス権限を直接付与できます。別のアカウントのユーザーがお客様のリソースへのアクセスを必要としている場合は、IAM ロールを作成できます。ロールは、アクセス許可を含むが、特定のユーザーに関連付けられていないエンティティです。これにより他のアカウントのユーザーはロールを引き受けて、ロールに割り当てられた権限に応じてリソースにアクセスできます。詳細については、「所有している別の IAM アカウントへのアクセス権を AWS ユーザーに提供」を参照してください。

注記

一部のサービス (Amazon S3、Amazon SNS、Amazon SQS など) は、「アイデンティティベースのポリシーおよびリソースベースのポリシー」に説明されているリソースベースのポリシーをサポートしています。これらのサービスでは、ロールを使用する代わりに、共有するリソース (バケット、トピック、またはキュー) にポリシーをアタッチできます。リソースベースポリシーは、リソースへのアクセス許可を持つ AWS アカウントを指定できます。