# IAM ロールの作成
ロールを作成するには、AWS マネジメントコンソール、AWS CLI、Tools for Windows PowerShell、または IAM API を使用できます。
AWS マネジメントコンソールを使用する場合は、ウィザードを使用し、一連のステップに従ってロールを作成できます。AWS サービス、AWS アカウント、SAML または OIDC のフェデレーティッドプリンシパルのいずれか向けにロールを作成するかにより、ウィザードの手順が多少異なります。
**IAM ユーザーに対するロール**
自分の AWS アカウント内か、自分が所有する他の AWS アカウントに定義されているロールにアクセス許可を委任する場合に、このロールを作成します。あるアカウントのユーザーは、同じアカウントまたは別のアカウントのロールに切り替えることができます。そのロールを使用している間、ユーザーはアクションだけを実行して、ロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。
詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。
クロスアカウントアクセス用のロールの作成の詳細については、「[カスタム信頼ポリシーを使用してロールを作成する](id_roles_create_for-custom.md)」を参照してください。
**AWS サービスに対するロール**
自分に代わってアクションを実行できるサービスにアクセス許可を委任する場合に、このロールを作成します。[サービスロール](id_roles.md#iam-term-service-role)をサービスに渡す場合は、そのロールの IAM ポリシーにアクセス許可を設定して、サービスが自身に関連付けられているアクションを実行できるようにします。AWS サービスごとに異なるアクセス許可が必要です。
サービスロールの作成の詳細については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。
サービスにリンクされたロールの作成の詳細については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。
**ID フェデレーションに対するロール**
AWS の外部に既に ID を持っているユーザーにアクセス許可を委任する場合に、このロールを作成します。ID プロバイダーを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要がありません。外部ユーザーは IdP を使用してサインインします。これらの外部 ID に、アカウントの AWS リソースを使用するアクセス許可を与えることができます。ID プロバイダーは、アプリケーションと共にアクセスキーのような長期的セキュリティ認証情報を配布したり埋め込んだりする必要がないので、AWS アカウントの安全性の維持に役立ちます。
詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。
# IAM ユーザーにアクセス許可を付与するロールを作成する
IAM ロールを使用することで、お客様の AWS リソースに対するアクセス許可を提供できます。IAM ロールにより、お客様の*信頼する*アカウントと他の AWS *信頼される* アカウントとの信頼関係を確立できます。信頼するアカウントは、アクセスされるリソースを所有し、信頼されるアカウントは、リソースへのアクセスを必要とするユーザーを含みます。ただし、別のアカウントがお客様のアカウントのリソースを所有する場合があります。たとえば、信頼するアカウントが、新しいリソースの作成 (Amazon S3 バケットでの新しいオブジェクトの作成など) を、信頼されたアカウントに許可する場合があります。この場合、リソースを作成したアカウントがリソースを所有します。さらに、リソースへのアクセスを誰に許可するかも管理します。
信頼関係の作成後、IAM ユーザーまたは信頼されたアカウントのアプリケーションでは AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) の API オペレーションを使用できます。このオペレーションから提供される一時的なセキュリティ認証情報を使用して、お客様のアカウントの AWS リソースにアクセスできます。
いずれものアカウントもお客様が管理できます。または、ユーザーが属するアカウントは第三者が管理できます。ユーザーが属する他のアカウントが管理対象外の AWS アカウント である場合は、`externalId` 属性を使用することもできます。外部 ID は、お客様とサードパーティーのアカウントの管理者との間で同意した任意の単語または数値です。このオプションにより、リクエストに正しい `sts:ExternalID` が含まれている場合にのみユーザーがロールを引き受けることができるという条件が、信頼ポリシーに自動的に追加されます。詳細については、「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。
ロールを使用してアクセス権限を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。サービスロールを使用して、サービスからアカウントのリソースへのアクセスを許可する方法については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。
## IAM ロールの作成（コンソール）
IAM ユーザーが引き受けるロールは、AWS マネジメントコンソール を使用して作成できます。例えば、組織で複数の AWS アカウント を使用して本稼働環境から開発環境を分離しているとします。この場合、開発用アカウントのユーザーに対して、本番稼働用アカウントのリソースへのアクセスを許可するロールを作成する方法の概要情報については、「[個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)」を参照してください。
**最小アクセス許可**
次の手順を実行するには、少なくとも以下のIAM アクセス許可が必要です。
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`
------
#### [ Console ]
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。
1. **[AWS アカウント]** のロールタイプを選択します。
1. アカウントのロールを作成するには、**[このアカウント]** を選択します。別のアカウントのロールを作成するには、[**別の AWS アカウント**] を選択し、リソースへのアクセス許可を付与する **[アカウント ID]** を入力します。
指定したアカウントの管理者は、そのアカウントのすべての IAM ユーザーに、このロールを引き受ける許可を付与できます。そのためには、管理者から `sts:AssumeRole` アクションの許可を付与するユーザーまたはグループにポリシーを添付します。そのポリシーで、`Resource` としてロールの ARN を指定する必要があります。
1. 管理対象外のアカウントのユーザーにアクセス許可を付与し、このロールをユーザーがプログラムで引き受ける場合は、**[外部 ID が必要]** を選択します。外部 ID は、お客様とサードパーティーのアカウントの管理者との間で同意した任意の単語または数値です。このオプションにより、リクエストに正しい `sts:ExternalID` が含まれている場合にのみユーザーがロールを引き受けることができるという条件が、信頼ポリシーに自動的に追加されます。詳細については、「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。
**重要**
このオプションを選択すると、AWS CLI、Tools for Windows PowerShell、または AWS API からのみの、ロールへのアクセスが制限されます。これは、AWS コンソールを使用して、その信頼ポリシーに `externalId` 条件が指定されているロールに切り替えることができないためです。ただし、関連するSDKを使用してスクリプトまたはアプリケーションを作成することで、この種のアクセスをプログラムで作成できます。詳細とサンプルスクリプトについては、AWS マネジメントコンソール セキュリティブログの「[AWS へのクロスアカウントアクセスを有効にする方法](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。
1. 多要素認証 (MFA) を使用してサインインするユーザーのロールを制限するには、**[MFA が必要]** を選択します。これにより、MFA によるサインインの有無を確認する条件がロールの信頼ポリシーに追加されます。ロールを引き受けるユーザーは、設定した MFA デバイスから一時的なワンタイムパスワードを使用してサインインする必要があります。MFA 認証のないユーザーはロールを引き受けることができません。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。
1. **[次へ]** を選択します。
1. IAM には、アカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。ロールを引き受けるユーザーに許可するアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。
1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。
**[アクセス許可の境界の設定]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。
1. [**次へ**] を選択します。
1. **ロール名** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。ロール名がポリシーまたは ARN の一部として使用される場合、ロール名は大文字と小文字が区別されます。サインイン処理中など、コンソールでロール名がユーザーに表示される場合、ロール名は大文字と小文字を区別しません。さまざまなエンティティがロールを参照する可能性があるため、作成後にロール名を編集することはできません。
1. (オプション) **[説明]** には、新しいロールの説明を入力します。
1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。前のページに戻って編集を行います。
1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. ロール情報を確認し、**ロールの作成** を選択します。
**重要**
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントの各ユーザーに対して、コンソールでロールを切り替えるか、プログラムでロールを引き受けるためのアクセス許可も付与する必要があります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
------
## IAM ロール (AWS CLI) の作成
AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。
**クロスアカウントアクセス用のロールを作成するには (AWS CLI)**
1. ロール [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) を作成します。
1. マネージドアクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。
または
ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。
1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。
詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
次の例では、シンプルな環境でクロスアカウントロールを作成するための最初の 2 つのステップ (最も一般的なステップ) を示します。この例では、`123456789012` アカウントの任意のユーザーに、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを許可します。また、この例では、Windows を実行しているクライアントコンピュータを使用中であり、アカウントの認証情報とリージョンを使ってコマンドラインインターフェイスを設定済みであることを前提とします。詳細については、「[AWS コマンドラインインターフェイスの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。
この例では、ロールの作成時に、次の信頼ポリシーを最初のコマンドに含めます。この信頼ポリシーでは、`123456789012` アカウントのユーザーに対して、`AssumeRole` オペレーションを使用してロールを引き受けることを許可します。ただし、ユーザーが `SerialNumber` パラメータと `TokenCode` パラメータを使用して MFA 認証を提供することを条件とします。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
]
}
```
------
**重要**
`Principal` 要素に特定の IAM ロールまたはユーザーの ARN が含まれている場合、この ARN はポリシーの保存時に一意のプリンシパル ID に変換されます。これにより、第三者がロールやユーザーを削除して再作成することで、そのユーザーのアクセス許可をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。したがって、信頼ポリシーの `Principal` 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。
2 番目のコマンドを使用する場合、既存の管理ポリシーをロールにアタッチする必要があります。以下のアクセス許可ポリシーでは、`example_bucket` Amazon S3 バケット に対して `ListBucket` アクションのみを実行することを、ロールを引き受ける任意のユーザーに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
]
}
```
------
この `Test-UserAccess-Role` ロールを作成するには、まず以前の信頼ポリシーを `trustpolicyforacct123456789012.json` という名前でローカル `policies` ドライブの `C:` フォルダに保存する必要があります。次に、以前のアクセス許可ポリシーを `PolicyForRole` という名前のカスタマー管理ポリシーとして AWS アカウント に保存します。次に、以下のコマンドを使用してロールを作成し、管理ポリシーをアタッチできます。
```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json
# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```
**重要**
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントに属している個々のユーザーに、ロールを切り替えるアクセス権限を付与する必要もあります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
ロールを作成し、このロールに AWS タスクの実行や AWS リソースへのアクセスに必要なアクセス許可を付与すると、`123456789012` アカウントのユーザーはこのロールを引き受けることができます。詳細については、「[IAM ロールに切り替える (AWS CLI)](id_roles_use_switch-role-cli.md)」を参照してください。
## IAM ロール（AWS API) の作成
AWS API からロールを作成するには、複数のステップが必要です。コンソールでロールを作成する場合は多くのステップが自動的に実行されますが、API では各ステップを手動で明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。
**コードでロールを作成するには (AWS API)**
1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。
ロールの信頼ポリシーに対して、ファイルの場所を指定できます。
1. マネージドアクセス許可ポリシー [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) をロールにアタッチします。
または
ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。
**重要**
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントに属している個々のユーザーに、ロールを切り替えるアクセス権限を付与する必要もあります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。
詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
ロールを作成し、このロールに AWS タスクの実行や AWS リソースへのアクセスに必要なアクセス許可を付与したら、アカウントのユーザーにアクセス許可を付与して、このロールを引き受けることを許可する必要があります。ロールの引き受けに関する詳細については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。
## IAM ロール (AWS CloudFormation) の作成
AWS CloudFormation での IAM ロールの作成については、[AWS CloudFormationユーザガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)の「[リソースとプロパティのリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) 」および「*例*」を参照してください 。
AWS CloudFormation の IAM テンプレートの詳細については、「AWS CloudFormation ユーザガイド」の「[AWS Identity and Access Management テンプレートスニペット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)」を参照してください。
# AWS サービスにアクセス許可を委任するロールを作成する
AWS の多くのサービスでは、ロールを使用して、ユーザーに代わって該当サービスが他のサービスのリソースにアクセスすることを許可する必要があります。サービスがお客様に代わってアクションを実行するために引き受けるロールは、[サービスロール](id_roles.md#iam-term-service-role)と呼ばれます。ロールがサービスの特殊な目的を果たす場合、そのロールは[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)として分類されます。どのサービスがサービスにリンクされたロールの使用をサポートしているのか、またはサービスがあらゆる形式の一時的な認証情報をサポートしているのか確認するには「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」をご覧ください。サービスがそれぞれロールをどのように使用するのか把握するには、テーブル内のサービス名を選択し、そのサービスに関するドキュメントをご覧ください。
`PassRole` アクセス許可を設定する場合、ユーザーがロールに必要以上のアクセス許可があるロールを渡さないようにする必要があります。例えば、Alice が Amazon S3 アクションを実行する許可を持っていない場合があります。Alice が Amazon S3 アクションを許可するサービスにロールを渡すことができる場合、サービスはジョブの実行時に、Alice に代わって Amazon S3 アクションを実行できます。
ロールを使用してアクセス許可を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。
## サービスロールのアクセス許可
IAM エンティティ (ユーザーまたはロール) がサービスロールを作成または編集できるようにするには、アクセス許可を設定する必要があります。
**注記**
サービスにリンクされたロールの ARN にはサービスプリンシパルが含まれています。以下のポリシーでは `SERVICE-NAME.amazonaws.com` として示されています。サービスプリンシパルは推量しないでください。サービスプリンシパルは、大文字と小文字が区別され、AWS のサービス間で異なる場合があります。サービスのサービスプリンシパルを表示するには、そのサービスにリンクされたロールのドキュメントを参照してください。
**IAM エンティティが特定のサービスロールを作成することを許可するには**
サービスロールを作成する必要のある IAM エンティティに、以下のポリシーを追加します。このポリシーでは、指定したサービスおよび特定の名前のサービスロールの作成を許可します。管理ポリシーまたはインラインポリシーをそのロールにアタッチできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
]
}
```
------
**IAM エンティティが任意のサービスロールを作成することを許可するには**
AWS では、管理者ユーザーのみにサービスロールの作成を許可することをお勧めします。ロールの作成とポリシーのアタッチを許可されたユーザーは、自分のアクセス許可をエスカレートできます。代わりに、彼らが必要とするロールの作成のみを許可したポリシーを作成するか、彼らの代わりに、管理者にサービスロールを作成させます。
管理者が AWS アカウント 全体にアクセスできるポリシーをアタッチするには、[AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess)AWS 管理ポリシーを使用します。
**IAM エンティティにサービスロールの編集を許可するには**
サービスロールを編集する必要のある IAM エンティティに、以下のポリシーを追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EditSpecificServiceRole",
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:PutRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
},
{
"Sid": "ViewRolesAndPolicies",
"Effect": "Allow",
"Action": [
"iam:GetPolicy",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
------
**IAM エンティティが特定のサービスロールを削除することを許可するには**
指定したサービスロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": "iam:DeleteRole",
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```
**IAM エンティティがサービスロールを削除することを許可するには**
AWS では、管理者ユーザーのみにサービスロールの削除を許可することをお勧めします。代わりに、彼らが必要とするロールの削除のみを許可したポリシーを作成するか、彼らの代わりに、管理者にサービスロールを削除させます。
管理者が AWS アカウント 全体にアクセスできるポリシーをアタッチするには、[AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess)AWS 管理ポリシーを使用します。
## AWS のサービス用ロールの作成 (コンソール)
サービス用のロールを作成するには、AWS マネジメントコンソール を使用します。一部のサービスでは、複数のサービスロールがサポートされているため、該当サービスの「[AWS ドキュメント](https://docs.aws.amazon.com/)」を参照の上、選択するユースケースを確認してください。必要な信頼ポリシーとアクセス権限ポリシーを割り当て、サービスがお客様に代わってロールを引き受ける方法について説明します。ロールのアクセス許可を管理するために使用できるステップは、サービスでユースケースを定義する方法や、サービスにリンクされたロールを作成するかどうかに応じて異なります。
------
#### [ Console ]
**AWS のサービス (IAM コンソール) のロールを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[サービスまたはユースケース]** でサービスを選択し、次にユースケースを選択します。ユースケースは、サービスに必要な信頼ポリシーを含める定義になります。
1. [**次へ**] を選択します。
1. **[アクセス許可ポリシー]** では、オプションは選択したユースケースによって異なります。
+ サービスがロールのアクセス許可を定義している場合、アクセス許可ポリシーを選択することはできません。
+ 制限されたアクセス許可ポリシーのセットから選択します。
+ すべてのアクセス許可ポリシーから選択します。
+ アクセス許可ポリシーを選択するのではなく、ロールの作成後にポリシーを作成し、そのポリシーをロールにアタッチします。
1. (オプション) [アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)を設定します。このアドバンスド機能は、サービスロールで使用できますが、サービスにリンクされたロールではありません。
1. **[アクセス許可の境界の設定]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。
IAM には、アカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。
1. アクセス許可の境界として使用するポリシーを選択します。
1. [**次へ**] を選択します。
1. **[ロール名]** では、オプションはサービスによって異なります。
+ サービスでロール名が定義されている場合、ロール名を編集することはできません。
+ サービスでロール名のプレフィックスが定義されている場合、オプションのサフィックスを入力できます。
+ サービスでロール名が定義されていない場合、ロールに名前を付けることができます。
**重要**
ロールに名前を付けるときは、次のことに注意してください。
ロール名は AWS アカウント内で一意である必要があります。ただし、大文字と小文字は区別されません。
例えば、**PRODROLE** と **prodrole** の両方の名前でロールを作成することはできません。ロール名がポリシーまたは ARN の一部として使用される場合、ロール名は大文字と小文字が区別されます。ただし、サインインプロセスなど、コンソールにロール名がユーザーに表示される場合、ロール名は大文字と小文字が区別されません。
他のエンティティがロールを参照する可能性があるため、ロールを作成した後にロール名を編集することはできません。
1. (オプション) **[説明]** にロールの説明を入力します。
1. (オプション) ロールのユースケースとアクセス許可を編集するには、**[ステップ 1: 信頼されたエンティティを選択]** または **[ステップ 2: アクセス権限を追加]** のセクションで **[編集]** を選択します。
1. (オプション) ロールの識別、整理、検索を簡単にするには、キーと値のペアとしてタグを追加します。IAM でのタグの使用の詳細については、「*IAM ユーザーガイド*」の「[AWS Identity and Access Management リソースのタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. ロールを確認したら、**[ロールを作成]** を選択します。
------
## サービス用のロールを作成する (AWS CLI)
AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。使用しているサービスが Amazon EC2 の場合は、インスタンスプロファイルも作成してロールを追加する必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。
**AWS のサービスのロールを AWS CLI で作成するには**
1. 次の `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` コマンドは、*Test-Role* という名前のロールを作成し、それに信頼ポリシーをアタッチします。
`aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`
1. マネージドアクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。
たとえば、次の `attach-role-policy` コマンドは、AWS と呼ばれる `ReadOnlyAccess` 管理ポリシーIAM ロールを `ReadOnlyRole` と呼ばれる IAM ロールロールにアタッチします。
`aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`
または
ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。
インラインアクセス許可ポリシーの追加については、以下の例を参照してください。
`aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`
1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。
詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
ロールを Amazon EC2 で使用する場合や、Amazon EC2 を使用する AWS の別のサービスで使用する場合は、ロールをインスタンスプロファイルに保存する必要があります。インスタンスプロファイルは、Amazon EC2 インスタンスの起動時にインスタンスにアタッチできるロールのコンテナです。インスタンスプロファイルに含めることができる ロールは 1 つのみであり、緩和できません。AWS マネジメントコンソールを使用してロールを作成すると、ロールと同じ名前のインスタンスプロファイルが自動的に作成されます。インスタンスプロファイルの詳細については、「[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)」を参照してください。ロールを使用して EC2 インスタンスを起動する方法については、「Amazon EC2 ユーザーガイド」の [Amazon EC2 リソースへのアクセスの制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)に関するページを参照してください。
**インスタンスプロファイルを作成し、これにロールを保存するには (AWS CLI)**
1. インスタンスプロファイル [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) を作成します。
1. ロールをインスタンスプロファイル [aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) に追加します。
次に示す AWS CLI のコマンド例では、ロールを作成してアクセス許可をアタッチする手順の最初の 2 つのステップを示します。また、インスタンスプロファイルを作成し、これにロールを追加する手順の最初の 2 つのステップも示します。この信頼ポリシー例では、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを Amazon EC2 サービスに許可します。また、この例では、Windows を実行するクライアントコンピュータを使用中であり、アカウントの認証情報とリージョンを使ってコマンドラインインターフェイスを設定済みであることを前提とします。詳細については、「[AWS コマンドラインインターフェイスの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。
この例では、ロールの作成時に、次の信頼ポリシーを最初のコマンドに含めます。この信頼ポリシーにより、Amazon EC2 サービスはロールを引き受けることを許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
```
------
2 番目のコマンドを使用する場合、アクセス許可ポリシーをロールにアタッチする必要があります。次のアクセス許可ポリシーの例では、Amazon S3 バケット `ListBucket` に対して `example_bucket` アクションのみを実行することをロールに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
この `Test-Role-for-EC2` ロールを作成するには、まず前の信頼ポリシーを `trustpolicyforec2.json` という名前で、前のアクセス許可ポリシーを `permissionspolicyforec2.json` という名前で、ローカル `C:` ドライブの `policies` ディレクトリに保存する必要があります。次に、以下のコマンドを使用して、ロールの作成、ポリシーのアタッチ、インスタンスプロファイルの作成、およびインスタンスプロファイルへのロールの追加を行います。
```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json
# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json
# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3
# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```
EC2 インスタンスを起動するとき、AWS コンソールを使用する場合は、[**インスタンスの詳細の設定**] ページでインスタンスプロファイル名を指定します。`aws ec2 run-instances` CLI コマンドを使用する場合は、`--iam-instance-profile` パラメータを指定します。
## サービス用のロールを作成する (AWS API)
AWS API からロールを作成するには、複数のステップが必要です。コンソールでロールを作成する場合は多くのステップが自動的に実行されますが、API では各ステップを手動で明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。使用しているサービスが Amazon EC2 の場合は、インスタンスプロファイルも作成してロールを追加する必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。
**AWS のサービスのロールを作成するには (AWS API)**
1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。
ロールの信頼ポリシーに対して、ファイルの場所を指定できます。
1. ロールに管理アクセス許可ポリシーをアタッチします: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
または
ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。
1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。
詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
ロールを Amazon EC2 で使用する場合や、Amazon EC2 を使用する AWS の別のサービスで使用する場合は、ロールをインスタンスプロファイルに保存する必要があります。インスタンスプロファイルは、ロールのコンテナとして機能します。各インスタンスプロファイルに含めることができるロールは 1 つのみであり、増やすことはできません。AWS マネジメントコンソールでロールを作成すると、ロールと同じ名前のインスタンスプロファイルが自動的に作成されます。インスタンスプロファイルの詳細については、「[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)」を参照してください。ロールを使用して Amazon EC2 インスタンスを起動する方法については、「Amazon EC2 ユーザーガイド」の [Amazon EC2 リソースへのアクセスの制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)に関するページを参照してください。
**インスタンスプロファイルを作成し、これにロールを保存するには (AWS API)**
1. インスタンスプロファイル [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) を作成します。
1. ロールをインスタンスプロファイル [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) に追加します。
# サービスにリンクされたロールの作成
サービスにリンクされたロールは、AWS のサービスに直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、サービスによって事前定義されており、お客様の代わりにサービスから他の AWS サービスを呼び出す必要のあるアクセス権限がすべて含まれています。このリンクされたサービスでも、サービスにリンクされたロールを作成、変更、削除する方法を定義しています。サービスによって、ロールが自動的に作成または削除される場合があります。そのため、ウィザードの一部、またはサービスのプロセスとして、ロールを作成、変更、削除できる場合があります。または、ロールを作成または削除するには、IAM を使用する必要がある場合があります。どの方法を使用するにしても、サービスにリンクされたロールを使用すると、サービスが自動でアクションを完了させるのに、 アクセス許可を手動で追加する必要がないため、サービスの設定プロセスが簡単になります。
**注記**
サービスロールは、サービスにリンクされたロールとは異なることに注意してください。サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
リンクされたサービスで、そのサービスにリンクされたロールのアクセス許可を定義します。特に定義されている場合を除き、ロールは、そのサービスでのみ引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
ロールを削除する前に、最初に関連するリソースを削除する必要があります。これにより、リソースへのアクセス許可を誤って削除してしまうことを防ぐことができます。
**ヒント**
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
## サービスにリンクされたロールのアクセス許可
ユーザーまたはロールがサービスにリンクされたロールを作成または編集できるようにするには、IAM エンティティ (ユーザーまたはロール) のアクセス許可を設定する必要があります。
**注記**
サービスにリンクされたロールの ARN にはサービスプリンシパルが含まれています。以下のポリシーでは `SERVICE-NAME.amazonaws.com` として示されています。サービスプリンシパルは推量しないでください。サービスプリンシパルは、大文字と小文字が区別され、AWS のサービス間で異なる場合があります。サービスのサービスプリンシパルを表示するには、そのサービスにリンクされたロールのドキュメントを参照してください。
**特定のサービスにリンクされたロールの作成を IAM エンティティに許可するには**
サービスにリンクされたロールを作成する必要のある IAM エンティティに、次のポリシーを追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
"Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
]
}
```
------
**IAM エンティティがサービスにリンクされた任意のロールを作成することを許可するには**
サービスにリンクされたロール、または必要なポリシーを含む任意のサービスロールを作成する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。このポリシーステートメントでは、IAM エンティティがポリシーをロールにアタッチすることは許可されません。
```
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**IAM エンティティが任意のサービスロールの説明を編集することを許可するには**
サービスにリンクされたロール、または任意のサービスロールの説明を編集する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": "iam:UpdateRoleDescription",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**IAM エンティティがサービスにリンクされた特定のロールを削除することを許可するには**
サービスにリンクされたロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```
**IAM エンティティがサービスにリンクされた任意のロールを削除することを許可するには**
サービスロールではなく、サービスにリンクされたロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**既存のロールをサービスに渡すことを IAM エンティティに許可するには**
一部の AWS サービスでは、新しいサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスに*ロールを渡す*アクセス許可がユーザーに必要です。ロールを渡す必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。このポリシーステートメントでは、エンティティは、渡すことができるロールのリストを表示できます。詳細については、「[AWS サービスにロールを渡すアクセス許可をユーザーに付与する](id_roles_use_passrole.md)」を参照してください。
```
{
"Sid": "PolicyStatementToAllowUserToListRoles",
"Effect": "Allow",
"Action": ["iam:ListRoles"],
"Resource": "*"
},
{
"Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```
## サービスにリンクされたロールによる間接的なアクセス許可
サービスにリンクされたロールによって付与されたアクセス許可は、他のユーザーおよびロールに間接的に転送できます。サービスにリンクされたロールが AWS サービスによって使用されると、そのサービスにリンクされたロールは独自のアクセス許可を使用して他の AWS サービスを呼び出すことができます。つまり、サービスにリンクされたロールを使用するサービスを呼び出すアクセス許可を持つユーザーとロールは、そのサービスにリンクされたロールがアクセスできるサービスに間接的にアクセスできる可能性があります。
たとえば、Amazon RDS DB インスタンスを作成すると、[RDS のサービスにリンクされたロール](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html)は、まだ存在しない場合は自動的に作成されます。このサービスにリンクされたロールを使用すると、RDS は、ユーザーに代わって Amazon EC2、Amazon SNS、Amazon SNS、Amazon CloudWatch Logs、Amazon Kinesis を呼び出すことを許可します。アカウントのユーザーとロールに RDS データベースの変更や作成を許可すると、RDS を呼び出すことで Amazon EC2、Amazon SNS、Amazon CloudWatch Logs ログ、Amazon Kinesis のリソースと間接的にやり取りできるようになる可能性があります。RDS はサービスにリンクされたロールを使用してこれらのリソースにアクセスするためです。
### サービスにリンクされたロールを作成する方法
サービスにリンクされたロールを作成するメソッドは、サービスによって異なります。場合によっては、サービスにリンクされたロールを手動で作成する必要はありません。たとえば、サービス特定のアクション (リソースの作成) を完了すると、サービスによって、サービスにリンクされたロールが作成される場合があります。または、サービスにリンクされたロールのサポートを開始する前からサービスを使用していた場合は、アカウントにロールが自動的に作成される場合があります。詳細については[AWS アカウントに新しいロールが表示される](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared)を参照してください。
また、サービスにリンクされたロールは、サービスコンソール、API、CLI を使用して、手動で作成できる場合があります。サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスにリンクされたロールをサービスで作成できるかどうかを確認するには、「**はい**」リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを参照してください。
ロールの作成がサービスでサポートされていない場合は、IAM を使用して、サービスにリンクされたロールを作成できます。
**重要**
サービスにリンクされたロールでは、[AWS アカウント の IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities)の制限に向かってカウントされますが、このロールは制限を超えてもアカウントに作成することができます。この制限を超える可能性があるのは、サービスにリンクされたロールのみです。
### サービスにリンクされたロールの作成 (コンソール)
IAM のサービスにリンクされたロールを作成する前に、サービスにリンクされたロールがサービスで自動的に作成されるかどうかを確認します。さらに、サービスのコンソール、API、または CLI からロールを作成できるかどうかも確認します。
**サービスにリンクされたロールを作成するには (コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。続いて、**[ロールの作成]** を選択します。
1. **[AWS のサービス]** ロールタイプを選択します。
1. 提供するサービスのユースケースを選択します。ユースケースは、サービスに必要な信頼ポリシーを含めるように定義されています。その後、**[Next]** を選択します。
1. ロールにアタッチするアクセス権限ポリシーを 1 つ以上選択します。選択したユースケースに基づき、サービスで以下のいずれかを行う場合があります。
+ ロールで使用するアクセス権限を定義します。
+ 制限されたアクセス権限からの選択を許可します。
+ すべてのアクセス権限からの選択を許可します。
+ この時点でポリシーを選択できないようにし、ポリシーを作成してからロールにアタッチします。
ロールに許可する許可を割り当てるポリシーの横にあるチェックボックスを選択し、**[次へ]** を選択します。
**注記**
設定したアクセス権限は、ロールを使用するすべてのエンティティで有効となります。デフォルトでは、ロールにはいずれのアクセス権限もありません。
1. **[ロール名]** の場合、ロール名のカスタマイズの度合いはサービスによって定義されます。サービスのロール名が定義されている場合、このオプションを変更することはできません。その他の場合、サービスはロールのプレフィックスを定義し、オプションのサフィックスを入力できるようにするかもしれません。
可能であれば、ロールのデフォルト名に追加するサフィックスを入力します。このサフィックスは、このロールの目的を識別するのに役立ちます。ロール名は AWS アカウント内で一意でなければなりません。大文字と小文字は区別されません。例えば、**\$1SAMPLE** と **\$1sample** というロール名を両方作成することはできません。多くのエンティティによりロールが参照されるため、作成後にロール名を変更することはできません。
1. (オプション) **[説明]** で、サービスにリンクされた新しいロールの説明を編集します。
1. 作成中にサービスにリンクされたロールにタグ付けすることはできません。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. ロール情報を確認し、**ロールの作成** を選択します。
### サービスにリンクされたロールの作成 (AWS CLI)
IAM でサービスにリンクされたロールを作成するには、リンクされたサービスで、サービスにリンクされたロールが自動的に作成されるかどうかと、サービスの CLI からロールを作成できるかどうかについて確認します。サービス CLI がサポートされていない場合は、IAM コマンドを使用して、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めて、サービスにリンクされたロールを作成することができます。
**サービスにリンクされたロールを作成するには (AWS CLI)**
次のコマンドを実行します。
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```
### サービスにリンクされたロールの作成 (AWS API)
IAM でサービスにリンクされたロールを作成するには、リンクされたサービスで、サービスにリンクされたロールが自動的に作成されるかどうかと、サービスの API からロールを作成できるかどうかについて確認します。サービス API がサポートされていない場合は、AWS API を使用して、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めて、サービスにリンクされたロールを作成することができます。
**サービスにリンクされたロールを作成するには (AWS API)**
[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API コールを使用します。リクエストで、サービス名`SERVICE_NAME_URL.amazonaws.com`を指定します。
たとえば、サービスにリンクされたロール (**[Lex Bots]**) を作成するには、`lex.amazonaws.com` を使用します。
# サードパーティー ID プロバイダーにロールを作成する
AWS アカウント で IAM ユーザーを作成する代わりに、ID プロバイダーを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび認証プロバイダーについて詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
## OIDC と SAML のフェデレーティッドプリンシパルのロールの作成 (コンソール)
ロールを作成する手順は、選択するサードパーティープロバイダーによって異なります。
+ OpenID Connect (OIDC) については、「[OpenID Connect フェデレーション用のロールを作成する (コンソール）](id_roles_create_for-idp_oidc.md)」を参照してください。
+ SAML 2.0 については、「[SAML 2.0 フェデレーション用のロールを作成する (コンソール)](id_roles_create_for-idp_saml.md)」を参照してください。
## フェデレーションアクセス用のロールの作成 (AWS CLI)
サポートされている ID プロバイダー (OIDC または SAML) 用のロールを AWS CLI から作成するステップは同じです。違いは、前提条件のステップで作成する信頼ポリシーの内容です。使用するプロバイダーのタイプに合わせた**前提条件**セクションのステップに従って開始します。
+ OIDC プロバイダーについては、「[OIDC 用のロールを作成するための前提条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)」を参照してください。
+ SAML プロバイダーについては、「[SAML 用のロールを作成するための前提条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)」を参照してください。
AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。
**ロールを作成するには (AWS CLI)**
1. ロール [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) を作成します。
1. アクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。
または
ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。
1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。
詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
次の例では、シンプルな環境で ID プロバイダーのロールを作成するための最初の 2 つのステップ (最も一般的なステップ) を示します。この例では、`123456789012` アカウントの任意のユーザーに、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを許可します。また、この例では、Windows が動作しているコンピュータで AWS CLI を実行していること、さらに認証情報を使って AWS CLI を設定済みであることを前提とします。詳細については、「[Configuring the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。
次の例では、ユーザーが Amazon Cognito を使用してサインインする場合のモバイルアプリ用の信頼ポリシーを示します。この例では、*us-east:12345678-ffff-ffff-ffff-123456* は Amazon Cognito によって割り当てられた ID プール ID を表します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}
}
```
------
以下のアクセス許可ポリシーでは、Amazon S3 バケット `example_bucket` に対して `ListBucket` アクションのみを実行することを、ロールを引き受ける任意のユーザーに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
この `Test-Cognito-Role` ロールを作成するには、まず前の信頼ポリシーを `trustpolicyforcognitofederation.json` という名前で、前のアクセス許可ポリシーを `permspolicyforcognitofederation.json` という名前で、ローカル `policies` ドライブの `C:` フォルダに保存する必要があります。次に、以下のコマンドを使用してロールを作成し、インラインポリシーをアタッチできます。
```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json
# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```
## フェデレーションアクセス用のロールの作成 (AWS API)
サポートされている ID プロバイダー (OIDC または SAML) 用のロールを AWS CLI から作成するステップは同じです。違いは、前提条件のステップで作成する信頼ポリシーの内容です。使用するプロバイダーのタイプに合わせた**前提条件**セクションのステップに従って開始します。
+ OIDC プロバイダーについては、「[OIDC 用のロールを作成するための前提条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)」を参照してください。
+ SAML プロバイダーについては、「[SAML 用のロールを作成するための前提条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)」を参照してください。
**ロールを作成する方法 (AWS API)**
1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。
1. アクセス許可ポリシーとして [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) をロールにアタッチします。
または
ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。
1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。
詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。
1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。
アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。
# OpenID Connect フェデレーション用のロールを作成する (コンソール）
AWS アカウントで AWS Identity and Access Management ユーザーを作成する代わりに、OpenID Connect (OIDC) フェデレーション ID プロバイダーを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび IdPs (ID プロバイダー) について詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
## OIDC 用のロールを作成するための前提条件
OIDC フェデレーション用のロールを作成する前に、まず次の基本的なステップを実行する必要があります。
**OIDC フェデレーション用のロールを作成する準備をするには**
1. フェデレーション OIDC ID を提供する 1 つ以上のサービスにサインアップします。AWS リソースにアクセスする必要があるアプリを作成する場合は、プロバイダー情報も合わせてアプリを設定します。サインアップすると、プロバイダーからアプリに固有のアプリケーション ID または対象者 ID が提供されます。（プロバイダーが異なれば、このプロセスには異なる用語が使用されます。このガイドでは、プロバイダーでアプリを識別するプロセスに*設定*という用語を使用します。） プロバイダーごとに複数のアプリを設定できます。または 1 つのアプリに複数のプロバイダーを設定できます。ID プロバイダーの使用に関する情報は以下で確認してください。
+ [Login with Amazon 開発者センター](https://login.amazon.com/)
+ Facebook 開発者サイトの「[アプリまたはウェブサイトに Facebook ログインを追加する](https://developers.facebook.com/docs/facebook-login/v2.1)」
+ Google 開発者サイトの「[ログインでの OAuth 2.0 の使用 (OpenID Connect) ](https://developers.google.com/accounts/docs/OAuth2Login)」
1. IdP から必要な情報を受け取ったら、IAM で IdP を作成します。詳細については、「[IAM で OpenID Connect (OIDC) ID プロバイダーを作成する](id_roles_providers_create_oidc.md)」を参照してください。
**重要**
Google、Facebook、または Amazon Cognito の OIDC IdP を使用している場合は、AWS マネジメントコンソール に個別の IAM IdP を作成しないでください。これらの OIDC ID プロバイダーは、すでに AWS に組み込まれており、ユーザーが使用できます。この手順をスキップして、次の手順で IdP を使用して新しいロールを作成します。
1. IdP 認証ユーザーが引き受けるロールのポリシーを準備します。すべてのロールに該当することですが、モバイルアプリ用のロールにも 2 つのポリシーがあります。1 つは、ロールの引き受け先を指定する信頼ポリシーです。もう 1 つはアクセス許可ポリシーです。このポリシーでは、モバイルアプリにアクセスを許可または拒否する AWS アクションやリソースを指定します。
ウェブ IdP については、[Amazon Cognito](https://aws.amazon.com/cognito/) を使用して ID を管理することをお勧めします。この場合、次の例に示すような信頼ポリシーを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
"ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
}
}
}
```
------
`us-east-2:12345678-abcd-abcd-abcd-123456` は、Amazon Cognito が割り当てる ID プール ID に置き換えます。
OIDC IdP を手動で設定する場合は、信頼ポリシーの作成時に以下の 3 つの値を使用して当該アプリにのみロールを引き受けることを許可します。
+ `Action` 要素で、`sts:AssumeRoleWithWebIdentity` アクションを使用します。
+ `Principal` 要素で、`{"Federated":providerUrl/providerArn}` 文字列を使用します。
+ 一部の一般的な OIDC IdP の場合、`providerUrl` は URL です。以下の例では、いくつかの一般的な IdP のプリンシパルを指定する方法を示します。
`"Principal":{"Federated":"cognito-identity.amazonaws.com"}`
`"Principal":{"Federated":"www.amazon.com"}`
`"Principal":{"Federated":"graph.facebook.com"}`
`"Principal":{"Federated":"accounts.google.com"}`
+ 他の OIDC プロバイダーの場合は、次の例のように、[Step 2](#idpoidcstep2) で作成した OIDC IdP の Amazon リソースネーム (ARN) を使用します。
`"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
+ `Condition` 要素で、`StringEquals` 条件を使用してアクセス許可を制限します。ID プール ID (Amazon Cognito の場合) またはアプリ ID (他のプロバイダーの場合) をテストします。この ID プール ID は、IdP でアプリを設定したときに取得したアプリ ID と一致する必要があります。この ID 間の一致により、リクエストが自分のアプリからであることを確認できます。
**注記**
Amazon Cognito アイデンティティプールの IAM ロールは、サービスプリンシパル `cognito-identity.amazonaws.com` を信頼してロールを引き受けます。このタイプのロールには、ロールを引き受けるプリンシパルを制限する条件キーが少なくとも 1 つ含まれている必要があります。
[クロスアカウントの IAM ロール](access_policies-cross-account-resource-access.md)を引き受ける Amazon Cognito アイデンティティプールには、その他の考慮事項が適用されます。これらのロールの信頼ポリシーは、`cognito-identity.amazonaws.com` サービスプリンシパルを受け入れる必要があり、ロールの引き受けを目的のアイデンティティプールのユーザーに制限するために `aud` 条件キーを含める必要があります。この条件なしで Amazon Cognito アイデンティティプールを信頼するポリシーでは、意図しないアイデンティティプールのユーザーがロールを引き受けるリスクが生じます。詳細については、「Amazon Cognito デベロッパーガイド」の「[基本 (クラシック) 認証の IAM ロールの信頼ポリシー](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies)」を参照してください。
使用している IdP に応じて、以下の例に示すような、条件要素を作成します。
`"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`
`"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`
`"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`
`"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`
OIDC プロバイダーの場合は、次の例に示すように、OIDC IdP の完全修飾 URL と `aud` コンテキストキーを使用します。
`"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**注記**
ロールの信頼ポリシーでプリンシパルとして指定する値は、IdP ごとに異なります。OIDC 用のロールで指定できるプリンシパルは 1 つだけです。したがって、モバイルアプリで複数の IdP からのサインインをユーザーに許可する場合は、サポートする IdP ごとに別個のロールを作成します。IdP ごとに別個の信頼ポリシーを作成します。
ユーザーがモバイルアプリを使用して Login with Amazon からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*amzn1.application-oa2-123456* は Login with Amazon を使用するアプリを設定したときに Amazon が割り当てるアプリ ID を表します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForLoginWithAmazon",
"Effect": "Allow",
"Principal": {"Federated": "www.amazon.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
}]
}
```
------
ユーザーがモバイルアプリを使用して Facebook からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*111222333444555* は Facebook が割り当てるアプリ ID を表します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForFacebook",
"Effect": "Allow",
"Principal": {"Federated": "graph.facebook.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
}]
}
```
------
ユーザーがモバイルアプリを使用して Google からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*666777888999000* は Google が割り当てるアプリ ID を表します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForGoogle",
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
}]
}
```
------
ユーザーがモバイルアプリを使用して Amazon Cognito からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*us-east:12345678-ffff-ffff-ffff-123456* は Amazon Cognito が割り当てる ID プール ID を表します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}]
}
```
------
## OIDC 用のロールの作成
前提条件を満たしたら、IAM でロールを作成できます。認識された共有 OpenID Connect (OIDC) の ID プロバイダー (IdP) の場合、IAM は *ID プロバイダーコントロール*と呼ばれる JSON ウェブトークン (JWT) に特定の請求を明示的に評価する必要があります。*ID プロバイダーコントロール*を持つ OIDC IdP の詳細については、「[共有 OIDC プロバイダーの ID プロバイダーコントロール](id_roles_providers_oidc_secure-by-default.md)」を参照してください。
次の手順は、AWS マネジメントコンソール で OIDC フェデレーション用のロールを作成する方法を示します。AWS CLI または AWS API からロールを作成するには、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」の手順を参照してください。
**重要**
Amazon Cognito を使用する場合は、Amazon Cognito コンソールを使用してロールをセットアップします。それ以外の場合は、IAM コンソールを使用して OIDC 用のロールを作成します。
**OIDC フェデレーション用の IAM ロールを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. ナビゲーションペインで **[ロール]** を選択した後、**[ロールの作成]** を選択します。
1. 信頼されたエンティティタイプとして **[ウェブアイデンティティ]** を選択し、**[次へ]** を選択します。
1. **[ID プロバイダー]** で、ロールの IdP を選択します。
+ 個々のウェブ IdP 用のロールを作成する場合は、**Login with Amazon**、**Facebook**、**Google** のいずれかを選択します。
**注記**
サポートする各 IdP に対して別々のロールを作成する必要があります。
+ Amazon Cognito 用の高度なシナリオのロールを作成する場合は、**Amazon Cognito** を選択します。
**注記**
高度なシナリオで作業する場合に限り、Amazon Cognito で使用するロールを手動で作成する必要があります。それ以外の場合は、Amazon Cognito で自動的にロールを作成できます。Amazon Cognito の詳細については、*[Amazon Cognito Developer Guide]* の [[Identity pools (federated) external identity providers]](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) を参照してください。
+ GitHub Actions 用のロールを作成する場合は、まず GitHub OIDC プロバイダーを IAM に追加する必要があります。GitHub OIDC プロバイダーを IAM に追加したら、**token.actions.githubusercontent.com** を選択します。
**注記**
AWS を GitHub の OIDC プロバイダーのフェデレーティッド ID として信頼するよう設定する方法については、「[GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。IAM IdP for GitHub に関連するロールへのアクセスを制限するベストプラクティスについては、このページの [GitHub OIDC ID プロバイダーのロールの設定](#idp_oidc_Create_GitHub) を参照してください。
+ HashiCorp Cloud Platform (HCP) Terraform のロールを作成するには、まず Terraform OIDC プロバイダーを IAM に追加することから始める必要があります。Terraform OIDC プロバイダーを IAM に追加したら、**[app.terraform.io]** を選択します。
**重要**
HashiCorp Cloud Platform (HCP) Terraform OIDC プロバイダーの IAM ロールは、ロールの信頼ポリシーの IAM 条件キー `app.terraform.io:sub` を評価する必要があります。この条件キーは、ロールを引き受けることができる HCP Terraform の組織、プロジェクト、ワークスペース、または実行フェーズを制限します。この条件キーがない場合、信頼ポリシーは組織外の ID によってロールと AWS リソースに対するアクセスを付与しますが、これは最小特権の原則に整合しません。
AWS アカウント内の HCP Terraform OIDC プロバイダーに関連付けられたロールのロール信頼ポリシーを設定または変更しても、IAM 条件キー `app.terraform.io:sub` を評価しない場合、エラーが発生します。さらに、ロール信頼ポリシーがこの条件キーを評価しない場合、AWS STS は認可リクエストを拒否します。
1. リクエストされた情報は、選択した OIDC プロバイダーによって異なります。
+ アプリケーション用の ID を入力します。ID のラベルは、選択するプロバイダーによって異なります。
+ Login with Amazon 用のロールを作成する場合は、アプリ ID を **[アプリケーション ID]** ボックスに入力します。
+ Facebook 用のロールを作成する場合は、アプリ ID を **[アプリケーション ID]** ボックスに入力します。
+ Google 用のロールを作成する場合は、対象者名を **[対象者]** ボックスに入力します。
+ Amazon Cognito 用のロールを作成する場合は、Amazon Cognito アプリケーション用に作成した アイデンティティプールの ID を、**[アイデンティティプール ID]** ボックスに入力します。
+ GitHub Actions のロールを作成する場合は、以下の情報を入力します。
+ **[対象者]** で [`sts.amazonaws.com`] を選択します。
+ **GitHub 組織**の場合、GitHub の組織名を入力します。GitHub 組織名は必須で、英数字 (ダッシュ (-) を含む) でなければなりません。GitHub 組織名に、ワイルドカード文字 (\$1 と ?) は使用できません。
+ (オプション) **[GitHub リポジトリ]** に、GitHub リポジトリの名前を入力します。値を指定しない場合は、デフォルトでワイルドカード (`*`) になります。
+ (オプション) **[GitHub ブランチ]** に、GitHub ブランチ名を入力します。値を指定しない場合は、デフォルトでワイルドカード (`*`) になります。
+ HashiCorp Cloud Platform (HCP) Terraform のロールを作成する場合は、次の詳細を入力します:
+ **[対象者]** で [`aws.workload.identity`] を選択します。
+ **[組織]** で、組織名を入力します。すべての組織にワイルドカード文字 (`*`) を指定できます。
+ **[プロジェクト]** で、プロジェクト名を入力します。すべてのプロジェクトにワイルドカード文字 (`*`) を指定できます。
+ **[ワークスペース]** で、ワークスペース名を入力します。すべてのワークスペースにワイルドカード文字 (`*`) を指定できます。
+ **[実行フェーズ]** で、実行フェーズ名を入力します。すべての実行フェーズにワイルドカード文字 (`*`) を指定できます。
1. (オプション) **[条件 (オプション)]**で、**[条件の追加]** を選択して、ロールによって付与されたアクセス許可を使用する前にアプリケーションのユーザーが満たしておく必要がある追加条件を作成します。例えば、特定の IAM ユーザー ID にのみ AWS リソースに対するアクセス許可を付与する条件を追加できます。ロールを作成した後に、信頼ポリシーに条件を追加することもできます。詳細については、「[ロール信頼ポリシーを更新する](id_roles_update-role-trust-policy.md)」を参照してください。
1. OIDC 情報を確認し、**[次へ]** を選択します。
1. IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。OIDC ユーザーに割り当てるアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。
1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。
**[アクセス許可の境界]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。
1. **[次へ]** を選択します。
1. **[ロール名]** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を編集できません。
1. (オプション) **[説明]** には、新しいロールの説明を入力します。
1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。
1. (オプション) ロールにメタデータを追加するには、キーバリューのペアとしてタグをアタッチします。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. ロール情報を確認し、**ロールの作成** を選択します。
## GitHub OIDC ID プロバイダーのロールの設定
GitHub を OpenID Connect (OIDC) ID プロバイダー (IdP) として使用する場合、ベストプラクティスは、IAM IdP に関連付けられたロールを引き受けることができるエンティティを制限することです。信頼ポリシーに条件ステートメントを含めると、ロールを特定の GitHub Organization、リポジトリ、またはブランチに制限できます。条件キー `token.actions.githubusercontent.com:sub` を文字列条件演算子と共に使用してアクセスを制限できます。条件を GitHub 組織内の特定のリポジトリまたはブランチのセットに制限することをお勧めします。AWS を GitHub の OIDC のフェデレーティッド ID として信頼するよう設定する方法については、「[GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」(GitHub Docs - アマゾン ウェブ サービスの OpenID Connect 設定) を参照してください。
アクションワークフローまたは OIDC ポリシーで GitHub 環境を使用する場合は、セキュリティを強化するために保護ルールを環境に追加することを強くお勧めします。デプロイブランチとタグを使用して、環境にデプロイできるブランチとタグを制限します。保護ルールを使用して環境を設定する方法については、GitHub の記事「*Using environments for deployment*」(デプロイ用の環境の使用) に記載されている「[Deployment branches and tags](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags)」(デプロイブランチとタグ) を参照してください。
GitHub の OIDC IdP がロールの信頼できるプリンシパルである場合、IAM はロールの信頼ポリシー条件をチェックして条件キー `token.actions.githubusercontent.com:sub` が存在していて、その値がワイルドカード文字 (\$1 と ?) または null だけではないことを確認します。IAM は、信頼ポリシーが作成または更新されたときにこのチェックを実行します。条件キー `token.actions.githubusercontent.com:sub` が存在しない場合、またはキー値が上記の値基準を満たさない場合、リクエストは失敗し、エラーが返されます。
**重要**
条件キー `token.actions.githubusercontent.com:sub` を特定の組織またはリポジトリに制限しない場合、管理外の組織またはリポジトリの GitHub Actions は、AWS アカウントで GitHub IAM IdP に関連付けられたロールを引き受けることができます。
以下の信頼ポリシー例は、定義済みの GitHub Organization、リポジトリ、ブランチへのアクセスを制限します。次の例では条件キー `token.actions.githubusercontent.com:sub` の値は、GitHub が文書化しているデフォルトのサブジェクト値の形式です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
}
}
}
]
}
```
------
次の例の条件は、定義された GitHub Organization とリポジトリへのアクセスを制限しますが、リポジトリ内の任意のブランチへのアクセスを許可します。
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
}
}
```
以下の条件例は、定義された GitHub Organization 内の任意のリポジトリまたはブランチへのアクセスを制限します。条件キー `token.actions.githubusercontent.com:sub` は、アクセスを GitHub 組織内からの GitHub Actions へのアクセスに制限する特定の値に制限することをお勧めします。
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
}
}
```
ポリシーの条件チェックで利用可能な OIDC フェデレーションのキーの詳細については、「[OIDC AWS フェデレーションで使用できるキー](reference_policies_iam-condition-keys.md#condition-keys-wif)」を参照してください。
# SAML 2.0 フェデレーション用のロールを作成する (コンソール)
AWS アカウント で IAM ユーザーを作成する代わりに、SAML 2.0 フェデレーションを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび認証プロバイダーについて詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
**注記**
フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「[フェイルオーバーにリージョン SAML エンドポイントを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)」を参照してください。
## SAML 用のロールを作成するための前提条件
SAML 2.0 フェデレーション用のロールを作成する前に、まず次の基本的なステップを実行する必要があります。
**SAML 2.0 フェデレーション用のロールを作成する準備をするには**
1. SAML ベースのフェデレーション用のロールを作成する前に、IAM で SAML プロバイダーを作成する必要があります。詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。
1. SAML 2.0 認証ユーザーが引き受けるロールのポリシーを準備します。すべてのロールに該当することですが、SAML フェデレーション用のロールにも 2 つのポリシーが含まれています。1 つは、ロールの引き受け先を指定するロール信頼ポリシーです。もう 1 つは IAM アクセス許可ポリシーです。このポリシーでは、SAML フェデレーティッドプリンシパルにアクセスを許可または拒否する AWS アクションやリソースが指定されます。
ロールの信頼ポリシーを作成する場合は、以下の 3 つの値を使用して当該アプリケーションにのみロールの引き受けを許可する必要があります。
+ `Action` 要素で、`sts:AssumeRoleWithSAML` アクションを使用します。
+ `Principal` 要素で、`{"Federated":ARNofIdentityProvider}` 文字列を使用します。`ARNofIdentityProvider` を、[Step 1](#idpsamlstep1) で作成した [SAML ID プロバイダー](id_roles_providers_saml.md)の ARN と置き換えます。
+ `Condition` 要素では、 `StringEquals` 条件を使用して、SAML レスポンスの `saml:aud` 属性が、コンソールにサインインするときにブラウザに表示される URL と一致することをテストします。このサインインエンドポイント URL は、ID プロバイダーの SAML 受取人属性です。特定のリージョン内にサインイン URL を含めることができます。AWS では、フェデレーションの耐障害性を向上させるために、グローバルエンドポイントの代わりにリージョンエンドポイントを使用することをお勧めします。実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。
サインイン URL には、SAML プロバイダーに割り当てられる一意の識別子 AWS が含まれている必要があります。IAM コンソールで ID プロバイダーを選択して詳細ページを表示することで、一意の識別子を確認できます。
`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`
次の例では、SAML フェデレーティッドユーザー用に設計された信頼ポリシーを示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRoleWithSAML",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
},
"Condition": {
"StringEquals": {
"SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
}
}
}
}
```
------
プリンシパル ARN は、IAM で作成した SAML プロバイダー用の実際の ARN に置き換えます。これは、独自のアカウント ID およびプロバイダー名になります。
## SAML 用のロールの作成
前提条件のステップを完了すると、SAML ベースのフェデレーション用のロールを作成できます。
**SAML ベースのフェデレーション用のロールを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。
1. **[SAML 2.0 フェデレーション]** ロールタイプを選択します。
1. **[SAML プロバイダーの選択]** で、ロールのプロバイダーを選択します。
1. SAML 2.0 のアクセスレベルメソッドを選択します。
+ **[プログラムによるアクセスのみを許可する]** を選択して、AWS API または AWS CLI からプログラムで引き受けることができるロールを作成します。
+ [**プログラムによるアクセスと AWS マネジメントコンソール によるアクセスを許可する**] を選択して、AWS マネジメントコンソール からプログラムで引き受けることのできるロールを作成します。
作成されたロールはいずれも似ていますが、コンソールから引き受けられるロールにも、特定の条件を含む信頼ポリシーがあります。この条件により、SAML オーディエンス (`SAML:aud` 属性) が SAML プロバイダーの AWS サインインエンドポイントに設定されていることが明示的に保証されます。
1. 属性を定義する手順は、アクセスタイプによって異なります。
+ プログラムによるアクセス用のロールを作成する場合は、**[属性]** リストから属性を選択します。次に、**[値]** ボックスで、ロールに追加する値を入力します。これにより、ロールアクセスは、指定した属性を SAML 認証応答 (アサーション) に含んでいる ID プロバイダーのユーザーのみに制限されます。ロールが組織のユーザーのサブセットに限定されるように、少なくとも 1 つの属性を指定する必要があります。
+ プログラムによるアクセスと AWS マネジメントコンソール アクセスのロールを作成する場合、**[サインインエンドポイント]** セクションでは、コンソールにサインインするときにブラウザに表示される URL を定義します。このエンドポイントは、ID プロバイダーの SAML 受取人属性であり、[`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml) コンテキストキーにマッピングされます。詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。
1. **[リージョンエンドポイント]** または **[非リージョンエンドポイント]** を選択します。フェデレーションの耐障害性を向上させるには、複数のリージョンにまたがる SAML サインインエンドポイントを使用することをお勧めします。
1. **リージョン**では、SAML プロバイダーが AWS サインインでサポートするリージョンを選択します。
1. **[一意の識別子を含めるサインイン URL]** には、サインインエンドポイントに SAML ID プロバイダーに割り当てられた一意の識別子 AWS を含めるかどうかを選択します。このオプションは、暗号化された SAML アサーションに必要です。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
1. 信頼ポリシーに属性関連の条件をさらに追加するには、**[条件 (オプション)]** を選択し、続いて追加の条件を選択して、値を指定します。
**注記**
最も一般的に使用される SAML 属性がリストに表示されます。IAM では、条件の作成に使用できる追加の属性をサポートしています。サポートされる属性のリストについては、「[SAML ベースのフェデレーションに利用可能なキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml)」を参照してください。リストに含まれないサポート対象の SAML 属性の条件が必要な場合、その条件は次のステップで手動で追加できます。これを行うには、ロールを作成後に信頼ポリシーを編集します。
1. SAML 2.0 の信頼情報を確認し、**[次へ]** を選択します。
1. IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。SAML フェデレーションユーザーに付与するアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。
1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。
**[アクセス許可の境界]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。
1. **[次へ]** を選択します。
1. **[次へ: レビュー]** を選択します。
1. **[ロール名]** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を変更できません。
1. (オプション) **[説明]** には、新しいロールの説明を入力します。
1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。
1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. ロール情報を確認し、**ロールの作成** を選択します。
ロールの作成後に、AWS に関する情報を使用して ID プロバイダーソフトウェアを設定し、SAML 信頼を確立します。この情報には、SAML フェデレーションユーザーが使用するロールが含まれます。これは、IdP と AWS との証明書利用者信頼の設定と呼ばれます。詳細については、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)」を参照してください。
# カスタム信頼ポリシーを使用してロールを作成する
カスタムの信頼ポリシーを作成して、アクセスを委任し、他のユーザーに自分の AWS アカウント でアクションの実行を許可することができます。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。
ロールを使用してアクセス権限を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。
## カスタム信頼ポリシーを使用した IAM ロールの作成 (コンソール)
IAM ユーザーが引き受けるロールは、AWS マネジメントコンソール を使用して作成できます。例えば、組織で複数の AWS アカウント を使用して本稼働環境から開発環境を分離しているとします。開発用アカウントのユーザーに対して本番用アカウントのリソースへのアクセスを許可するロールを作成するための高レベルの情報については、「[個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)」を参照してください。
**カスタム信頼ポリシーを使用してロールを作成するには (コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。
1. **[Custom trust policy]** (カスタム信頼ポリシー) ロールタイプを選択してください。
1. **[Custom trust policy]** (カスタム信頼ポリシー) セクションで、ロールのカスタム信頼ポリシーを入力または貼り付けます。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。
1. [ポリシーの検証](access_policies_policy-validator.md)中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、[**Next**] (次へ) を選択します。
1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。このアドバンスド機能は、サービスロールで使用できますが、サービスにリンクされたロールではありません。
**[Permissions boundary]** (アクセス許可の境界) セクションを開き、**[Use a permissions boundary to control the maximum role permissions]** (アクセス許可の境界を使用してロールのアクセス許可の上限を設定する) を選択します。IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可の境界として使用するポリシーを選択します。
1. [**次へ**] を選択します。
1. [**ロール名**] の場合、ロール名のカスタマイズの度合いはサービスによって定義されます。サービスのロール名が定義されている場合、このオプションを変更することはできません。それ以外の場合、サービスでロールのプレフィックスが定義され、オプションのサフィックスを入力できる場合があります。一部のサービスでは、ロールの名前全体を指定することができます。
可能な場合は、ロール名またはロール名のサフィックスを入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を変更できません。
1. (オプション) **[説明]** には、新しいロールの説明を入力します。
1. (オプション) **[ステップ 1: 信頼されたエンティティを選択する]** または **[ステップ 2: 許可を追加する]** セクションで **[編集]** を選択し、ロールのカスタムポリシーと許可を編集します。
1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. ロール情報を確認し、**ロールの作成** を選択します。
# アクセス権を委任するポリシーの例
以下の例では、AWS アカウント に別の AWS アカウント のリソースへのアクセスを許可する方法を示しています。これらの例の JSON ポリシードキュメントを使用して IAM ポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。
**Topics**
+ [ロールを使用して他の AWS アカウント のリソースへのアクセス権を委任する](#example-delegate-xaccount-rolesapi)
+ [ポリシーを使用してサービスへのアクセスを委任する](#id_roles_create_policy-examples-access-to-services)
+ [リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する](#example-delegate-xaccount-S3)
+ [リソースベースのポリシーを使用して他のアカウントの Amazon SQS キューへのアクセス権を委任する](#example-delegate-xaccount-SQS)
+ [アカウントがアクセスを拒否されているとアクセス権を委任できない](#example-delegate-xaccount-SQS-denied)
## ロールを使用して他の AWS アカウント のリソースへのアクセス権を委任する
IAM ロールを使用し、あるアカウントに属しているユーザーに、他のアカウントに属している AWS リソースへのアクセスを許可する方法のチュートリアルについては、「[IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)」を参照してください。
**重要**
特定のロールまたはユーザーの ARN を、ロールの信頼ポリシーの `Principal` 要素に含めることができます。ポリシーを保存すると、AWS は ARN を一意のプリンシパル ID に変換します。これにより、ロールまたはユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、関係が壊れます。ポリシーは、ユーザーまたはロールを再作成しても適用されません。これは、信頼ポリシーに保存されているプリンシパル ID に一致しないためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。ポリシーを保存するときに、ARN は新しいプリンシパル ID に変換されます。
## ポリシーを使用してサービスへのアクセスを委任する
次の例では、ロールにアタッチできるポリシーを示します。ポリシーは、Amazon EMR および AWS Data Pipeline の 2 つのサービスを有効にして、ロールを想定します。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスプリンシパルを指定する場合に、2 つの `Service` 要素は指定できません。1 つのみ指定できます。代わりに、1 つの `Service` 要素の値として複数のサービスのプリンシパルのアレイを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"elasticmapreduce.amazonaws.com",
"datapipeline.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する
この例では、アカウント A はリソースベースのポリシー (Amazon S3 [バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html)) を利用して、アカウント A の S3 バケットへのフルアクセスをアカウント B に許可します。次に、アカウント B が IAM ユーザーポリシーを作成して、アカウント A のバケットへのアクセス権をアカウント B のいずれかのユーザーに委任します。
アカウント A の S3 バケットポリシーは以下のポリシーのようになります。この例では、アカウント A の S3 バケットの名前を amzn-s3-demo-bucket とし、アカウント B のアカウント番号を 111122223333 とします。この番号は、アカウント B の個々のユーザーまたはグループではなく、アカウント自体のみを指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBAccess1",
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
また、アカウント A は Amazon S3 [アクセスコントロールリスト (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) を使用して、アカウント B に S3 バケットまたはバケット内の 1 つのオブジェクトへのアクセスを許可することもできます。この場合、唯一変更する点は、アカウント A がアカウント B にアクセス権を付与する方法です。ただし、この例の 2 番目の部分で説明したように、アカウント B はポリシーを使用して、アカウント B の IAM グループにアクセス権を委任することになります。S3 バケットとオブジェクトのアクセス制御の詳細については、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)の*アクセス制御*を参照してください。
アカウント B の管理者が、次のサンプルポリシーを作成するとします。このポリシーでは、アカウント B のグループまたはユーザーに読み取りアクセスが許可されます。前のポリシーでは、アカウント B へのアクセスが許可されます。ただし、アカウント B の個々のグループとユーザーは、グループまたはユーザーポリシーでリソースへの明示的なアクセス許可が付与されるまで、リソースにアクセスできません。このポリシーのアクセス許可は、前のクロスアカウントポリシーのアクセス許可のサブセットとしてのみ付与できます。アカウント B はそのグループとユーザーに、最初のポリシーでアカウント A から付与されたものよりも多くのアクセス権限を付与することはできません。このポリシーでは、`Action` アクションのみを許可するように `List` 要素が明示的に定義されます。このポリシーの `Resource` 要素は、アカウント A が実装するバケットポリシーの `Resource` に一致します。
このポリシーを実装するには、アカウント B は IAM を使用して、アカウント B の該当するユーザー (またはグループ) にそのポリシーをアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:List*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
## リソースベースのポリシーを使用して他のアカウントの 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 を使用して、このポリシーを実装します。
------
#### [ JSON ]
****
```
{
"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 を使用して、このポリシーをグループ（またはユーザー）にアタッチします。
------
#### [ JSON ]
****
```
{
"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 アカウント は、自リソースへのアクセスをユーザーの親アカウントに対して明示的に拒否している場合、自リソースへのアクセス権をそれらのユーザーに委任することはできません。この拒否は、アクセス権を付与する既存のポリシーをユーザーが持っているかどうかにかかわらず、そのアカウントのユーザーにも反映されます。
たとえば、アカウント A は自身の S3 バケットについて、アカウント B からのアクセスを明示的に拒否するバケットポリシーを作成するとします。ただし、アカウント B は、アカウント B のユーザーにアカウント A のバケットへのアクセス権を付与する IAM ユーザーポリシーを作成しています。アカウント A の S3 バケットに適用される明示的な拒否は、アカウント B のユーザーにも反映され、アカウント B のユーザーにアクセス権を付与する IAM ユーザーポリシーよりも優先されます (アクセス許可の評価方法については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください)。
アカウント A のバケットポリシーは、以下のポリシーになります。この例では、アカウント A の S3 バケットの名前を amzn-s3-demo-bucket とし、アカウント B のアカウント番号を 1111-2222-3333 とします。アカウント A は、Amazon S3 を使用して、このポリシーを実装します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBDeny",
"Effect": "Deny",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
この明示的な拒否は、アカウント A の S3 バケットにアクセスする権限を提供するアカウント B のポリシーをオーバーライドします。