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

アクセス権を委任するポリシーの例

以下の例では、AWS アカウントに別の AWS アカウントのリソースへのアクセス権を付与する方法を示しています。

ロールを使用して他の AWS アカウントのリソースへのアクセス権を委任する

IAM ロールを使用し、あるアカウントに属しているユーザーに対して、他のアカウントに属している AWS リソースへのアクセス権を付与する方法の詳細なウォークスルーについては、「チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。

重要

ロールの信頼ポリシーの Principal 要素に、特定の IAM ロールまたはユーザーを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときに一意のプリンシパル ID に変換されます。これにより、ロールまたはユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、関係が壊れます。ポリシーは、ユーザーまたはロールを再作成しても適用されません。これは、信頼ポリシーに保存されているプリンシパル ID に一致しないためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。ポリシーを保存するときに、ARN は新しいプリンシパル ID に変換されます。

ポリシーを使用してサービスへのアクセスを委任する

次の例では、ロールにアタッチできるポリシーを示します。ポリシーは、Amazon EMR および AWS Data Pipeline の 2 つのサービスを有効にして、ロールを想定します。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスのプリンシパルを指定するには、2 つの Service エレメントは指定できません。1 つのみ指定できます。代わりに、1 つの Service エレメントの値として複数のサービスのプリンシパルのアレイを使用します。

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "elasticmapreduce.amazonaws.com", "datapipeline.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する

この例では、アカウント A はリソースベースのポリシーを利用して(Amazon S3 バケットポリシー)、アカウント A の S3 バケットへのフルアクセス権限をアカウント B に付与します。次に、アカウント B が IAM ユーザーポリシーを作成して、アカウント A のバケットへのアクセス権をアカウント B のいずれかのユーザーに委任します。

アカウント A の S3 バケットポリシーは以下のポリシーのようになります。この例では、アカウント A の S3 バケットの名前を mybucket とし、アカウント B のアカウント番号は 111122223333 とします。この番号は、アカウント B の個々のユーザーまたはグループではなく、アカウント自体のみを指定します。

Copy
{ "Version": "2012-10-17", "Statement": { "Sid": "AccountBAccess1", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] } }

また、アカウント A は Amazon S3 アクセスコントロールリスト(ACL)を使用して、アカウント B に S3 バケットまたはバケット内の単一のオブジェクトへのアクセス権を付与することもできます。この場合、唯一変更する点は、アカウント A がアカウント B にアクセス権を付与する方法です。ただし、この例の 2 番目の部分で説明したように、アカウント B はポリシーを使用して、アカウント B の IAM グループにアクセス権を委任することになります。S3 バケットとオブジェクトへのアクセスを制御する方法の詳細については、『Amazon Simple Storage Service 開発者ガイド』の「アクセスコントロール」を参照してください。

以下の例は、アカウント B のグループまたはユーザーに読み取りアクセス権を委任するためにアカウント B の管理者が作成できる、IAM ユーザー (またはグループ) ポリシーを示しています。このポリシーはアカウント B へのアクセス権を付与しますが、グループまたはユーザーポリシーが明示的にリソースへのアクセス権限を付与するまで、アカウント B の個々のグループとユーザーはリソースにアクセスすることはできません。このポリシーのアクセス権限は、先ほどのクロスアカウントポリシーのアクセス権限のサブセットとしてのみ付与できます。アカウント B はそのグループとユーザーに、最初のポリシーでアカウント A から付与されたものよりも多くのアクセス権限を付与することはできません。このポリシーでは、List アクションのみを許可するように Action 要素が明示的に定義されます。このポリシーの Resource 要素は、アカウント A が実装するバケットポリシーの Resource に一致します。

このポリシーを実装するには、アカウント B は IAM を使用して、アカウント B の該当するユーザー(またはグループ)にそのポリシーをアタッチします。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:List*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] } }

リソースベースのポリシーを使用して他のアカウントの Amazon SQS キューへのアクセス権を委任する

以下の例では、アカウント A には Amazon SQS キューがあり、キューにアタッチされているリソースベースのポリシーを使用して、キューへのアクセス権をアカウント B に付与します。その後で、アカウント B が IAM グループポリシーを使用して、アカウント B のグループにアクセス権を委任します。

下記の例のキューポリシーでは、アカウント B にアカウント A の queue1 というキューで SendMessage および ReceiveMessage のアクションを実行するアクセス権限が付与されます。ただし、この許可が有効なのは、2014 年 11 月 30 日の正午から午後 3 時の間だけです。アカウント B のアカウント番号は 1111-2222-3333 アカウントです。アカウント A は、Amazon SQS を使用して、このポリシーを実装します。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": ["arn:aws:sqs:*:123456789012:queue1"], "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"}, "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"} } } }

アカウント B のグループにアクセス権を委任するアカウント B のポリシーは、以下の例のようになります。アカウント B は、IAM を使用して、このポリシーをグループ(またはユーザー)にアタッチします。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:queue1" } }

上記の IAM ユーザーポリシーの例では、アカウント B はワイルドカードを使用して、アカウント A のキューのすべての Amazon SQS アクションにアクセスする権限をユーザーに付与しています。ただし、アカウント B がアクセス権を委任できるのは、アカウント B がアクセス権を付与されている範囲に限られます。そのため、2 番目のポリシーが適用されたアカウント B のグループがキューにアクセスできるのは、2014 年 11 月 30 日の正午から午後 3 時までの間だけです。また、アカウント A の Amazon SQS キューポリシーで定義されているように、ユーザーが実行できるのは SendMessage および ReceiveMessage のアクションに限定されます。

アカウントがアクセスを拒否されているとアクセス権を委任できない

デフォルトでは、お客様の AWS アカウントのリソースに他の AWS アカウントとそのユーザーがアクセスすることはできません。ただし、ポリシーを利用して AWS アカウントに対してリソースへのアクセスを明示的に拒否している場合、その拒否はそのアカウントのユーザーにも反映されます。これは、それらのユーザーにアクセス権を付与する既存のポリシーがあっても同様です。つまり、AWS アカウントは、自リソースへのアクセスをユーザーの親アカウントに対して明示的に拒否している場合、自リソースへのアクセス権をそれらのユーザーに委任することはできません。

たとえば、アカウント A は自身の S3 バケットについて、アカウント B からのアクセスを明示的に拒否するバケットポリシーを作成するとします。ただし、アカウント B は、アカウント B のユーザーにアカウント A のバケットへのアクセス権を付与する IAM ユーザーポリシーを作成しています。アカウント A の S3 バケットに適用される明示的な拒否は、アカウント B のユーザーにも反映され、アカウント B のユーザーにアクセス権を付与する IAM ユーザーポリシーよりも優先されます(アクセス権限の評価方法については、「IAM ポリシーの評価論理」を参照してください)。

アカウント A のバケットポリシーは、以下のポリシーになります。この例では、アカウント A の S3 バケットの名前を mybucket とし、アカウント B のアカウント番号は 1111-2222-3333 とします。アカウント A は Amazon S3 を利用して、このポリシーを実装します。

Copy
{ "Version": "2012-10-17", "Statement": { "Sid": "AccountBDeny", "Effect": "Deny", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": "arn:aws:s3:::mybucket/*" } }

以下の IAM ユーザーポリシーを実装するには、アカウント B は IAM を使用してそのポリシーをアカウント B のユーザーにアタッチします。

Copy
{ "Version": "2012-10-17", "Statement":{ "Effect":"Allow", "Action":"s3:*", "Resource":"arn:aws:s3:::mybucket/*" } }

アカウント A のバケットポリシーでは、アカウント B による mybucket へのアクセスを明示的に拒否しています。委任できるのは、付与されているアクセス権限のサブセットだけであるため、アカウント B の IAM ユーザーポリシーがアカウント A のバケットへのアクセス権をアカウント B のユーザーに付与していても、その効果はありません。アカウント B のユーザーは、アカウント A のバケットにアクセスすることはできません。