# IAM ロール
IAM *ロール*は、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。IAM ロールは、アイデンティティが AWS で実行できることとできないことを決定するアクセス許可ポリシーを持つ AWS アイデンティティであるという点で IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。
ロールを使用して、通常は AWS リソースへのアクセス権のないユーザー、アプリケーション、サービスにそのアクセス権を委任できます。例えば、AWS アカウントのユーザーに、通常はないリソースに対するアクセス許可を付与したり、ある AWS アカウント のユーザーに、別のアカウントのリソースに対するアクセス許可を付与したりできます。または、モバイルアプリに AWS リソースの使用を許可しても、(キーの更新が困難であり、ユーザーがキーの抽出を行える可能性がある) アプリへの AWS キーの埋め込みは禁止すべきである場合があります。AWS の外部 (社内ディレクトリなど) に ID をすでに持っているユーザーに AWS へのアクセスを許可することが必要になる場合があります。または、リソースを監査できるように、アカウントへのアクセス権を第三者に付与することが必要になる場合もあります。
これらのシナリオでは、*IAM ロール*を使用して AWS リソースにアクセスを委任できます。このセクションでは、ロールの概要とさまざまな使用方法、適切なアプローチを選択するタイミングと方法、ロールの作成、管理、切り替え（または引き受け）、削除を行う方法について説明します。
**注記**
AWS アカウント を初めて作成するとき、デフォルトではロールは作成されません。アカウントにサービスを追加すると、そのユースケースをサポートするためにサービスにリンクされたロールが追加される場合があります。
サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールを削除する前に、最初に関連するリソースを削除する必要があります。これにより、リソースにアクセスするための許可を意図せず削除することが防止され、 リソースが保護されます。
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
**Topics**
+ [IAM ユーザーの作成が適している場合 (ロールではなく)](#id_which-to-choose)
+ [ロールに関する用語と概念](#id_roles_terms-and-concepts)
+ [その他のリソース](#id_roles_additional-resources)
+ [混乱する代理問題](confused-deputy.md)
+ [IAM ロールによく見られるシナリオ](id_roles_common-scenarios.md)
+ [IAM ロールの作成](id_roles_create.md)
+ [IAM ロールの管理](id_roles_manage.md)
+ [ロールを引き受けるための各種方法](id_roles_manage-assume.md)
## IAM ユーザーの作成が適している場合 (ロールではなく)
IAM ユーザーは、ID フェデレーションによってサポートされていないユースケースにのみ使用することをお勧めします。ユースケースには次のようなものがあります。
+ **IAM ロールを使用できないワークロード** – AWS へのアクセスが必要な場所から、ワークロードを実行する場合があります。状況によっては、IAM ロールを使用して WordPress プラグインなどに対して一時的な認証情報を提供することができない場合もあります。このような状況では、そのワークロードに対して IAM ユーザーの長期的なアクセスキーを使用して、AWS への認証を行います。
+ **サードパーティー AWS クライアント** – IAM Identity Center を使用したアクセスがサポートされていないツール (AWS でホストされていないサードパーティー AWS クライアントまたはベンダーなど) を使用している場合 は、IAM ユーザーの長期的なアクセスキーを使用します。
+ **AWS CodeCommit アクセス** — CodeCommit を使用してコードを保存している場合、CodeCommit の SSH キーまたはサービス固有の認証情報を持つ IAM ユーザーを使用して、リポジトリへの認証を行うことができます。通常の認証に IAM Identity Center のユーザーを使用することに加えて、これを行うことをお勧めします。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。IAM ユーザーを設定せずに CodeCommit リポジトリへのアクセス許可をユーザーに付与するには、**git-remote-codecommit** ユーティリティを設定します。IAM および CodeCommit の詳細については、「[CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー](id_credentials_ssh-keys.md)」を参照してください。**git-remote-codecommit** ユーティリティの設定についての詳細は、*AWS CodeCommit ユーザーガイド*の「[認証情報のローテーションを使用した AWS CodeCommit リポジトリへの接続](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)」を参照してください。
+ **Amazon Keyspaces (Apache Cassandra 向け) へのアクセス** – IAM Identity Center 内のユーザーを使用できない状況 (Cassandra との互換性をテストする場合など) では、サービス専用の認証情報を持つ IAM ユーザーを使用して Amazon Keyspaces で認証できます。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。一時的な認証情報を使用して Amazon Keyspaces に接続することもできます。詳細については、「*Amazon Keyspaces (Apache Cassandra 向け) デベロッパーガイド*」の「[一時的な認証情報を使用して IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続する](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)」を参照してください。
+ **緊急アクセス** — ID プロバイダーにアクセスできない状況で、AWS アカウント のアクションを実行する必要がある場合。緊急アクセスの IAM ユーザーを設定することは、レジリエンス計画の一部となります。緊急時のユーザー認証情報は、多要素認証 (MFA) を使用して厳重に管理し、安全性を確保することをお勧めします。
## ロールに関する用語と概念
ロールの操作に役立つ基本的な用語を紹介します。
****ロール** **
特定のアクセス権限を持ち、アカウントで作成できる IAM アイデンティティです。IAM ロールは、IAM ユーザーといくつかの類似点を持っています。ロールとユーザーは、両方とも、ID が AWS でできることとできないことを決定するアクセス許可ポリシーを持つ AWS ID です。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。
ロールを割り当てできるのは、以下のものです。
+ 同じ AWS アカウント または別の AWS アカウント 内の IAM ユーザー
+ 同じアカウント内の IAM ロール
+ サービスプリンシパル。AWS のサービスおよび機能で使用します。
+ Amazon EC2 や AWS Lambda などのコンピューティングサービスでコードを実行できるようにするサービス
+ Amazon S3 オブジェクトのレプリケーションなど、ユーザーに代わってリソースに対してアクションを実行する機能
+ IAM Roles Anywhere や Amazon ECS Anywhere など、AWS の外部で実行されるアプリケーションに一時的なセキュリティ認証情報を提供するサービス
+ SAML 2.0 または OpenID Connect と互換性のある外部 ID プロバイダー (IdP) サービスによって認証される外部ユーザー
****AWS サービス ** ロール**
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [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 のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールのサポートを開始する時点ですでにサービスを使用している場合は、アカウントの新しいロールに関する E メールが送信されることがあります。この場合、サービスにリンクされたロールは、サービスによって自動的にアカウントに作成されています。このロールをサポートするために必要な操作はありません。また、手動でロールを削除しないでください。詳細については、「[AWS アカウントに新しいロールが表示される](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared)」を参照してください。
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-Linked Role]** (サービスにリンクされたロール) 列が **[Yes]** (はい) になっているサービスを検索してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。詳細については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。
****ロールの連鎖****
ロールの連鎖は、 ロールを使用して 2 つ目のロールを引き受ける場合に発生します。ロール、AWS CLI、または API を切り替えることで、AWS マネジメントコンソール を介してロールの連鎖を実行できます。たとえば、`RoleA` には `RoleB` を引き受けるアクセス権があります。User1 は AssumeRole API オペレーションの長期的なユーザー認証情報を使用して `RoleA` を引き受けることができます。このオペレーションを用いて `RoleA` の短期的な認証情報を返します。ロールが連鎖していれば、User1 によって `RoleB` が引き受けられるよう `RoleA` の短期的な認証情報を使用できます。
ロールを引き受けるときは、セッションタグを渡して、タグを推移的に設定できます。推移的なセッションタグは、ロールの連鎖内の後続のすべてのセッションに渡されます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
ロールの連鎖では、AWS マネジメントコンソール、AWS CLI、 または AWS API ロールセッションが最長 1 時間に制限されます。これは、個々のロールに対して設定されている最大セッション期間に関係なく適用されます。[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを使用してロールを引き受ける場合は、`DurationSeconds` パラメータを使用してロールセッションの期間を指定できます。パラメータの値は、[ロールの最大セッション期間設定](id_roles_update-role-settings.md#id_roles_update-session-duration)によって、最大 43200 秒 (12 時間) まで指定できます。ただし、ロールの連鎖を使用してロールを引き受ける場合、`DurationSeconds` パラメータ値で 1 時間を超える値を指定すると、オペレーションは失敗します。
AWS マネジメントコンソール でのロールの切り替えの詳細については、「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してください。
****委任****
委任により、制御するリソースへのアクセスを許可するユーザーにアクセス許可を付与できます。委任には、2 つのアカウント間の信頼を設定することが含まれます。1 つ目は、リソースを所有するアカウント（信頼するアカウント）です。2 つ目は、リソース（信頼されたアカウント）にアクセスする必要があるユーザーを含むアカウントです。信頼するアカウントと信頼されたアカウントには、以下のいずれかを指定できます。
+ 同じアカウント。
+ 組織の制御下にある別々のアカウント。
+ 異なる組織によって所有される 2 つのアカウント。
リソースにアクセスする権限を委任するには、2 つのポリシーがアタッチされた信頼されるアカウントの [IAM ロールを作成します](id_roles_create_for-user.md)。*アクセス許可ポリシー*は、リソースに対して目的のタスクを実行するために必要なアクセス許可をロールのユーザーに付与します。*信頼ポリシー*は、信頼されたアカウントのどのメンバーにロールを割り当てることができるかを指定します。
信頼ポリシーを作成する際、プリンシパル要素およびプリンシパル要素内の ARN の一部としてワイルドカード (\*) を指定することはできません。信頼ポリシーは、信頼するアカウントのロールにアタッチされ、アクセス許可の半分です。残りの半分は、[ユーザーがロールを切り替えることができる、またはロールを引き受けることができる](id_roles_use_permissions-to-switch.md)信頼されたアカウントのユーザーにアタッチされたアクセス許可ポリシーです。ロールを引き受けるユーザーの各自のアクセス権限は一時的に無効になりますが、その代わりにロールのアクセス権限を取得します。ユーザーがロールの使用を終了または停止すると、元のユーザーアクセス権限に戻ります。[外部 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) という追加パラメータは、同じ組織がコントロールしていないアカウント間でロールを安全に利用するのに役立ちます。
****信頼ポリシー****
[JSON ポリシードキュメント](reference_policies_grammar.md)では、ロールを引き受けるために*信頼する*プリンシパルを定義します。ロール信頼ポリシーは、IAMのロールに関連付けられている必須の[リソースベースのポリシー](access_policies.md#policies_resource-based)です。信頼ポリシーで指定できる[プリンシパル](reference_policies_elements_principal.md)には、ユーザー、ロール、アカウント、およびサービスが含まれます。詳細については、「*AWS セキュリティブログ*」の「[IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
****クロスアカウントアクセスのロール****
あるアカウントのリソースに対するアクセス権限を、別のアカウントの信頼されるプリンシパルに付与するロール。クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の AWS サービスでは、リソースにポリシーを直接アタッチすることができます (ロールをプロキシとして使用する代わりに)。これらはリソースベースのポリシーと呼ばれ、別の AWS アカウント のプリンシパルにリソースへのアクセスを許可するために使用できます。これらのリソースには、Amazon Simple Storage Service (S3) バケット、Amazon Glacier ボールト、Amazon Simple Notification Service (SNS) トピック、Amazon Simple Queue Service (SQS) キューなどがあります。リソースベースのポリシーをサポートするサービスを確認するには､「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください｡ リソースベースのポリシーの詳細については、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。
## その他のリソース
以下のリソースは、IAM ロールに関連する IAM 用語の詳細を理解するのに役立ちます。
+ **プリンシパル**は、アクションを実行してリソースにアクセスできる AWS のエンティティです。プリンシパルは、AWS アカウントのルートユーザー、IAM ユーザー、またはロールをにすることができます。AWS サービスのアイデンティティを表すプリンシパルは、[サービスプリンシパル](reference_policies_elements_principal.md#principal-services)です。ロール信頼ポリシーのプリンシパル要素を使用して、ロールを引き受けると信頼するプリンシパルを定義します。
ロールの引き受けを許可できるプリンシパルの詳細と例については、「[AWS JSON ポリシーの要素: Principal](reference_policies_elements_principal.md)」を参照してください。
+ **ID フェデレーション**は、外部 ID プロバイダーと AWS の間に信頼関係を作成します。既存の OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) 2.0 プロバイダーを使用して、 AWS リソースにアクセスできるユーザーを管理できます。OIDC および SAML 2.0 を使用して、これらの外部 ID プロバイダーと AWS との信頼関係を設定する場合、ユーザーは IAM ロールに割り当てられます。ユーザーは一時的な認証情報を受け取り、これを使用して AWS リソースにアクセスすることもできます。
フェデレーティッドプリンシパルの詳細については、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
+ **フェデレーティッドプリンシパル**は、企業のユーザーディレクトリ、Directory Service からのOIDC プロバイダーの既存 ID です。[ID プロバイダー](id_roles_providers.md)を通じてアクセスがリクエストされると、AWS はフェデレーティッドプリンシパルにロールを割り当てます。
SAML および OIDC のフェデレーティッドプリンシパルの詳細については、「[フェデレーションユーザーのセッションとロール](introduction_access-management.md#intro-access-roles)」を参照してください。
+ **アクセス許可ポリシー**は、ロールが使用できるアクションとリソースを定義するアイデンティティベースのポリシーです。ドキュメントは IAM ポリシー言語のルールに従って記述されます。
詳細については、「[IAM JSON ポリシーリファレンス](reference_policies.md)」を参照してください。
+ **アクセス許可の境界**は、ポリシーを使用して、アイデンティティベースのポリシーがロールに付与できるアクセス許可の上限を設定する高度な機能です。アクセス許可の境界をサービスにリンクされたロールに適用することはできません。
詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」を参照してください。