他の IAM リソースにアクセスするのに必要なアクセス許可 - AWS Identity and Access Management

他の IAM リソースにアクセスするのに必要なアクセス許可

リソース はサービス内のオブジェクトです。IAM リソースには、グループ、ユーザー、ロール、およびポリシーが含まれます。 AWS アカウントのルートユーザー 認証情報を使用してサインインしている場合は、IAM 認証情報または IAM リソースの管理に制限はありません。ただし、IAM ユーザーには、認証情報または IAM リソースを管理する権限が明示的に与えられている必要があります。これは、ユーザーに ID ベースのポリシーをアタッチすることで実行できます。

注記

AWS ドキュメント全体で、特定のカテゴリに言及せずに IAM ポリシーを参照する場合は、それはアイデンティティベースのカスタマー管理ポリシーを意味します。ポリシーカテゴリの詳細については、「IAM でのポリシーとアクセス許可」を参照してください。

IAM ID を管理するためのアクセス許可

通常、IAM グループ、ユーザー、ロール、および認証情報を管理するために必要な権限は、タスクの API アクションに対応します。たとえば、IAM ユーザーを作成するには、対応する API コマンド: iam:CreateUserを持つ CreateUser アクセス許可を持っている必要があります。IAM ユーザーに他の IAM ユーザーを作成する権限を与えるには、そのユーザーに次のような IAM ポリシーをアタッチします。

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

ポリシーの Resource 要素の値は、アクション、およびそのアクションの影響を受ける可能性のあるリソースによって決まります。前述の例のポリシーでは、ユーザーが任意のユーザーを作成することができます (* はすべての文字列に一致するワイルドカードです)。対照的に、ユーザーに自分のアクセスキー (API アクション CreateAccessKey および UpdateAccessKey) のみの変更を許可するポリシーには、通常 Resource 要素が含まれます。この場合、ARN には次の例のように現在のユーザーの名前を解決する変数が含まれます (${aws:username})。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ListUsersForConsole", "Effect": "Allow", "Action": "iam:ListUsers", "Resource": "arn:aws:iam::*:*" }, { "Sid": "ViewAndUpdateAccessKeys", "Effect": "Allow", "Action": [ "iam:UpdateAccessKey", "iam:CreateAccessKey", "iam:ListAccessKeys" ], "Resource": "arn:aws:iam::*:user/${aws:username}" } ] }

前の例では、${aws:username} は現在のユーザーのユーザー名に解決される変数です。ポリシー変数の詳細については、「IAM ポリシーの要素: 変数とタグ」を参照してください。

多くの場合、アクション名にワイルドカード文字 (*) を使用すると、特定のタスクに関連するすべてのアクションの権限を容易に付与できます。たとえば、ユーザーが任意の IAM アクションを実行することを許可するには、アクションに対して iam:* を使用できます。ユーザーがアクセスキーのみに関連する任意のアクションを実行することを許可するには、ポリシーステートメントの iam:*AccessKey* 要素で Action を使用できます。これにより、CreateAccessKeyDeleteAccessKeyGetAccessKeyLastUsedListAccessKeysUpdateAccessKey の各アクションを実行するアクセス許可がユーザーに付与されます。 (将来、名前に「AccessKey」を含むアクションが IAM に追加された場合、iam:*AccessKey* 要素の Action を使用していれば、その新しいアクションに対する権限もユーザーに与えられます)。以下の例では、自分のアクセスキーに関連するすべてのアクションの実行をユーザーに許可するポリシーを示しています (account-id は AWS アカウント ID に置き換えてください)。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:*AccessKey*", "Resource": "arn:aws:iam::account-id:user/${aws:username}" } }

一部のタスクには複数のアクションが必要です。たとえば、グループの削除では、まずグループからユーザーを削除し、グループのポリシーをデタッチまたは削除してから、グループを実際に削除する必要があります。ユーザーがグループを削除できるようにする場合は、関連するすべてのアクションの実行権限をそのユーザーに与える必要があります。

AWS Management Consoleで作業するための許可

前の例では、AWS CLI または AWS SDK の使用によるアクションの実行をユーザーに許可するポリシーの例を示しています。

ユーザーがコンソールを操作すると、コンソールは、グループ、ユーザー、ロール、ポリシーのリストの取得、およびグループ、ユーザー、またはロールに関連付けられたポリシーの取得を行うためのリクエストを IAM に対して発行します。また、コンソールは AWS アカウント 情報とプリンシパルに関する情報を取得するリクエストを発行します。プリンシパルは、コンソールでリクエストを行うユーザーです。

一般に、アクションを実行するには、ポリシーに一致するアクションのみを含める必要があります。ユーザーを作成するには、CreateUser アクションを呼び出すアクセス許可が必要です。多くの場合、コンソールを使用してアクションを実行するときは、コンソール内のリソースを表示、一覧表示、取得、またはその他の方法で表示するアクセス許可が必要です。これは、指定されたアクションを実行するためにコンソールをナビゲートできるようにするために必要です。たとえば、ジョージというユーザーがコンソールを使用して自分のアクセスキーを変更する場合、ジョージはまず IAM コンソールに移動し、[Users] を選択します。このアクションにより、コンソールで ListUsers リクエストが発行されます。ジョージに iam:ListUsers アクションの権限がない場合は、コンソールがユーザーのリストの取得を試みたときに、コンソールはアクセスを拒否されます。結果として、Jorge は自分の名前やアクセスキーにアクセスできません。Jorge に CreateAccessKey アクションと UpdateAccessKey アクションに対するアクセス許可があっても関係ありません。

グループ、ユーザー、ロール、ポリシー、認証情報を管理するために AWS Management Console で作業する権限をユーザーに与える場合は、ユーザーがコンソールで実行するアクションに対する権限を含める必要があります。これらのアクセス権限をユーザーに付与するために使用できるポリシーの例については、「IAM リソースの管理に関するポリシーの例」を参照してください。

AWS アカウント全体にわたるアクセス権限の付与

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

注記

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

あるサービスから他のサービスへのアクセス権限

多くの AWS サービスは、他の AWS サービスにアクセスします。たとえば、Amazon EMR、Elastic Load Balancing、Amazon EC2 Auto Scaling などのいくつかの AWS サービスは、Amazon EC2 インスタンスを管理します。その他の AWS サービスは、Amazon S3 バケット、Amazon SNS トピック、Amazon SQS キューなどを利用します。

こうした場合におけるアクセス権限の管理方法は、サービスによって異なります。ここでは、異なるサービスでアクセス権限がどのように扱われるかについての例をいくつか紹介します。

  • Amazon EC2 Auto Scaling では、ユーザーに Auto Scaling を使用する許可がある必要がありますが、Amazon EC2 インスタンスを管理する権限を明示的に付与されている必要はありません。

  • AWS Data Pipeline では、IAM ロールによってパイプラインで何ができるかが決定され、ユーザーはロールを引き受けるためのアクセス許可が必要です (詳細については、&guide-edp-dev; の「AWS Data PipelineIAM を使用してパイプラインにアクセス権限を付与する」を参照してください)。

アクセス権限を適切に設定して AWS サービスが意図するタスクを実行できるようにする方法の詳細については、呼び出すサービスのドキュメントを参照してください。サービスのロールを作成する方法については、「AWS のサービスにアクセス許可を委任するロールの作成」を参照してください。

ユーザーの代理操作を実行する IAM ロールでサービスを設定する

ユーザーの代理操作を行うように AWS サービスを設定する場合は、通常、サービスに許可する操作を定義する IAM ロールの ARN を指定します。AWS によって、サービスにロールを渡すアクセス許可があるかがチェックされます。詳細については、「AWS のサービスにロールを渡すアクセス権限をユーザーに付与する」を参照してください。

必須アクション

アクションは、リソースの表示、作成、編集、削除など、リソースに対して実行できる処理です。アクションは各 AWS サービスによって定義されます。

ユーザーがアクションを実行できるようにするには、呼び出し ID または影響を受けるリソースに適用されるポリシーに必要なアクションを含める必要があります。一般的に、アクションの実行に必要なアクセス許可を提供するには、そのアクションをポリシーに含める必要があります。たとえば、ユーザーを作成するには、CreateUser アクションをポリシーに追加する必要があります。

場合によっては、ポリシーに追加の関連アクションを含めなければならない場合があります。たとえば、AWS Directory Service にディレクトリを作成するアクセス許可をユーザーに付与するには、ds:CreateDirectory オペレーションを使用して、以下のアクションをポリシーに含める必要があります。

  • ds:CreateDirectory

  • ec2:DescribeSubnets

  • ec2:DescribeVpcs

  • ec2:CreateSecurityGroup

  • ec2:CreateNetworkInterface

  • ec2:DescribeNetworkInterfaces

  • ec2:AuthorizeSecurityGroupIngress

  • ec2:AuthorizeSecurityGroupEgress

ビジュアルエディタを使用してポリシーを作成または編集すると、ポリシーに必要なすべてのアクションを選択するのに役立つ警告とプロンプトが表示されます。

AWS Directory Service にディレクトリを作成するために必要なアクセス許可の詳細については、「例 2: ディレクトリを作成することをユーザーに許可する」を参照してください。