メニュー
AWS Identity and Access Management
ユーザーガイド

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

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

注記

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

IAM ID を管理するためのアクセス権限

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

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

ポリシーの Resource エレメントの値は、アクション、およびそのアクションの影響を受ける可能性のあるリソースによって決まります。前述の例のポリシーでは、ユーザーが任意のユーザーを作成することができます(* はすべての文字列に一致するワイルドカードです)。対照的に、ユーザーが自分のアクセスキー (API アクション CreateAccessKey および UpdateAccessKey) のみの変更を許可するポリシーには、通常 Resource 要素があります。その場合、ARN には次の例のように現在のユーザーの名前に解決される変数が含まれます (ACCOUNT-ID-WITHOUT-HYPHENS を AWS アカウント ID に置き換えてください)。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:CreateAccessKey", "iam:UpdateAccessKey" ], "Resource": "arn:aws:iam::accountid:user/${aws:username}" } }

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

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

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

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

AWS マネジメントコンソール で作業するための権限

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

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

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

たとえば、ボブというユーザーがコンソールを使用して自分のアクセスキーを変更する場合、ボブはまず IAM コンソールに移動し、[Users] を選択します。このアクションにより、コンソールは ListUsers リクエストを発行します。ボブに iam:ListUsers アクションの権限がない場合は、コンソールがユーザーのリストの取得を試みたときに、コンソールはアクセスを拒否されます。結果として、ボブは自分の名前やアクセスキーにアクセスできません。ボブに CreateAccessKey アクションと UpdateAccessKey アクションの権限があっても関係ありません。

グループ、ユーザー、ロール、ポリシー、認証情報を管理するために AWS マネジメントコンソール で作業する権限をユーザーに与える場合は、ユーザーがコンソールで実行するアクションに対する権限を含める必要があります。これらのアクセス権限をユーザーに付与するために使用できるポリシーの例については、「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 インスタンスを管理します。Amazon S3 バケット、Amazon SNS トピック、Amazon SQS キューなどを活用する AWS サービスもあります。

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

  • Amazon EC2 Auto Scaling の場合、ユーザーは Auto Scaling へのアクセス権限を持っている必要がありますが、Amazon EC2 インスタンスを管理する権限を明示的に付与されている必要はありません。

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

アクセス権限を適切に設定して 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: ディレクトリを作成することをユーザーに許可する」を参照してください。