ポリシーを使用して 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 に保存され、プリンシパルエンティティのアクセス許可を指定します。ポリシーのタイプと用途の詳細については、「AWS Identity and Access Management でのポリシーとアクセス許可」を参照してください。

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

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

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

  • IAM ID – どの IAM ID (IAM グループ、ユーザー、ロール) にどのようにアクセスできるかを制御します。

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

  • AWS リソース – アイデンティティベースのポリシーまたはリソースベースのポリシーを使用して、リソースにアクセスできるユーザーを制御します。

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

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

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

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

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

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

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

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PermissionsBoundarySomeServices", "Effect": "Allow", "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:*", "s3:*" ], "Resource": "*" }, { "Sid": "PermissionsBoundaryNoConfidentialBucket", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ] } ] }

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

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

アイデンティティへのアクセスコントロール

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

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

ビジュアルエディタを使用してこのポリシーを作成するには
  1. AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

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

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

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

  4. [ポリシーエディタ] セクションで、[ビジュアル] オプションを選択します。

  5. [サービスを選択] で [IAM] を選択します。

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

  7. [リソース] を選択して、ポリシーのリソースを指定します。選択したアクションに基づいて、[グループ] および [ユーザー] のリソースタイプが表示されます。

    • グループ – [ARN を追加] を選択します。[リソース] で、[任意のアカウント] オプションを選択します。[パス付きの任意のグループ名] チェックボックスを選択し、ユーザーグループ名 AllUsers を入力します。[ユーザーを追加] を選択します。

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

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

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

  9. [サービスを選択] を選択してから、[IAM] を選択します。

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

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

    • CreateGroup

    • DeleteGroup

    • RemoveUserFromGroup

    • AttachGroupPolicy

    • DeleteGroupPolicy

    • DetachGroupPolicy

    • PutGroupPolicy

    • UpdateGroup

  12. [リソース] を選択して、ポリシーのリソースを指定します。選択したアクションに基づいて、[グループ] リソースタイプが表示されます。[ARN を追加] を選択します。[リソース] で、[任意のアカウント] オプションを選択します。[パス付きグループ名] にユーザーグループ名「AllUsers」を入力します。次に、[ARN を追加] を選択します。

  13. [リクエスト条件 - オプション] を選択してから、[別の条件を追加] を選択します。次の値をフォームに入力します。

    • 条件キーaws:username を選択

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

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

    • –「srodriguez」と入力し、[追加] を選択します。「mjackson」と入力し、[追加] を選択して、別の値を入力します。「adesai」と入力し、[条件を追加] を選択します。

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

  14. 完了したら、[Next] を選択します。

    注記

    いつでも [Visual] と [JSON] エディタオプションを切り替えることができます。ただし、[Visual] エディタで変更を行うか [次へ] を択した場合、IAM はポリシーを再構成して visual エディタに合わせて最適化することがあります。詳細については、「ポリシーの再構成」を参照してください。

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

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

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

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

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

たとえば、IAMUserChangePasswordPowerUserAccess の AWS 管理ポリシーのみを新しい IAM ユーザー、ユーザーグループ、またはロールにアタッチするポリシーを作成できます。

カスタマー管理ポリシーの場合、それらのポリシーを作成、更新、削除できるユーザーを制御できます。プリンシパルエンティティ (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:policy/TEAM-A/*" } }

管理ポリシーをアタッチおよびデタッチする権限の制御

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

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

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

以下のポリシー例では、ユーザーに、パス /TEAM-A/ を含む IAM グループとロールのみに対して管理ポリシーのアタッチを許可します。ユーザーグループとロールの ARN はポリシーの Resource 要素で指定します (この例では、ARN にはパスとワイルドカード文字が含まれているため、パス /TEAM-A/ を含むすべての IAM グループとロールに一致します)。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「JSON エディターを使用したポリシーの作成」を参照してください。

例 特定のユーザーグループまたはロールのみに対する管理ポリシーのアタッチを許可するポリシー
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::account-id:group/TEAM-A/*", "arn:aws:iam::account-id:role/TEAM-A/*" ] } }

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

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

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

このポリシーでは、ArnLike 条件演算子を使用することもできますが、これら2つの条件演算子が同じように動作するため、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 ロールを作成できます。ロールは、アクセス許可を含むが、特定のユーザーに関連付けられていないエンティティです。これにより他のアカウントのユーザーはロールを引き受けて、ロールに割り当てられた権限に応じてリソースにアクセスできます。詳細については、「所有している別の AWS アカウント内の IAM ユーザーに対するアクセス」を参照してください。

注記

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