# IAM ロールによく見られるシナリオ
多くの AWS 機能と同様に、通常ロールを使用する方法には、IAM コンソールでインタラクティブに使用する方法と、AWS CLI、Tools for Windows PowerShell、API のいずれかを使用してプログラムで使用する方法の 2 つがあります。
+ IAM コンソールを使用するアカウントの IAM ユーザーは、別のロールに*切り替えて*、コンソールでそのロールのアクセス許可を一時的に使用できます。ユーザーは、元のアクセス権限を返却し、そのロールに割り当てられたアクセス権限を取得します。ユーザーがそのロールを終了すると、元のアクセス権限に戻ります。
+ アプリケーションまたは AWS によって提供されるサービス (Amazon EC2 など) は、AWS にプログラムによるリクエストを行うためのロールの一時的セキュリティ認証情報をリクエストすることで、ロールを*引き受ける*ことができます。ロールをこのように使用することで、リソースへのアクセスが必要なエンティティごとに長期的なセキュリティ認証情報を共有または保持する (IAM ユーザーを作成するなどして) 必要がなくなります。
**注記**
このガイドでは、*ロールの切り替え*および*ロールの引き受け*という言葉を、ほとんど同じ意味で使用しています。
ロールを使用する最もシンプルな方法は、自分のアカウントまたは別の AWS アカウント 内に作成したロールに切り替えるアクセス許可を IAM ユーザーに付与する方法です。IAM ユーザーは、 コンソールを使用して簡単にロールを切り替え、通常は必要ないアクセス許可を使用することができます。その後、ロールを終了して、それらのアクセス許可を返却できます。これは、機密性の高いリソースに*誤って*アクセスしたり変更したりすることを回避するのに役立ちます。
アプリケーションとサービスへのアクセスを許可する (つまり、外部フェデレーションユーザー) など、ロールを複雑な方法で使用するには、`AssumeRole` API を呼び出します。この API 呼び出しは、アプリケーションが後続の API 呼び出しで使用できる一時的な認証情報のセットを返します。一時的な認証情報を使用して試行されたアクションは、関連付けられたロールによって付与されたアクセス権限のみを使用します。アプリケーションは、ユーザーがコンソールで行った方法でロールを "終了" する必要はありません。アプリケーションは一時的な認証情報を使用して停止し、元の認証情報で呼び出しを再開するだけです。
フェデレーティッドユーザーは、ID プロバイダー (IdP) から提供される認証情報を使用してサインインします。その後、AWS は一時的な認証情報を信頼された IdP に提供し、後続の AWS リソースリクエストに含めることができるようにユーザーに渡します。これらの認証情報は、割り当てられたロールに付与されたアクセス権限を提供します。
このセクションは、次のシナリオの概要を提供します。
+ [ユーザーが所有する別のアカウントのリソースにアクセスできるように、ユーザーが所有する 1 つの AWS アカウント の IAM ユーザーにアクセスを許可する](id_roles_common-scenarios_aws-accounts.md)
+ [AWS ワークロード以外へのアクセスを提供する](id_roles_common-scenarios_non-aws.md)
+ [サードパーティーが所有する AWS アカウント の IAM ユーザーへのアクセスを許可する](id_roles_common-scenarios_third-party.md)
+ [AWS が提供するサービスに AWS リソースへのアクセスを許可する](id_roles_common-scenarios_services.md)
+ [外部で認証された (ID フェデレーション) ユーザーにアクセスを許可する](id_roles_common-scenarios_federated-users.md)
# 所有している別の AWS アカウント内の IAM ユーザーに対するアクセス
IAM ユーザーには、AWS アカウント 内のロール、または所有する他の AWS アカウント で定義されたロールに切り替えるアクセス許可を付与することができます。
**注記**
お客様が所有または制御していないアカウントへのアクセス権を付与する場合は、このトピックの「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。
組織の業務に不可欠な Amazon EC2 インスタンスがあるとします。このインスタンスを終了するためのアクセス許可をユーザーに直接付与する代わりに、これらの権限を持つロールを作成できます。次に、インスタンスを終了する必要があるときに、このロールに切り替えることを管理者に許可します。これにより、インスタンスに次の保護レイヤーが追加されます。
+ ユーザーにロールを引き受けるアクセス権限を明示的に付与する必要があります。
+ ユーザーは、アクティブに AWS マネジメントコンソール を使用してロールに切り替えるか、AWS CLI または AWS API を使用してロールを引き受ける必要があります。
+ MFA デバイスでサインインしているユーザーのみがロールを引き受けることができるように、ロールに多要素認証 (MFA) 保護を追加できます。ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるようにロールを設定する方法については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。
このアプローチを使用して*最小権限の原則*を強制することをお勧めします。つまり、昇格されたアクセス許可の使用は、特定のタスクに必要なときのみに制限されます。ロールを使用すると、機密性の高い環境が誤って変更されるのを防ぐことができます (特に、ロールが必要なときだけ使用されるように[監査](cloudtrail-integration.md)と組み合わせている場合)。
この目的でロールを作成する場合、ユーザーがロールの信頼ポリシーの `Principal` 要素にアクセスする必要のあるアカウントを ID で指定します。その後、その他のアカウントの特定のユーザーに、そのロールに切り替えるためのアクセス権限を付与できます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
あるアカウントのユーザーは、同じアカウントまたは別のアカウントのロールに切り替えることができます。そのロールを使用している間、ユーザーはアクションだけを実行して、ロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。
## 個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例
本稼働環境から開発環境を分離するための複数の AWS アカウント が組織に存在するとします。開発アカウントのユーザーは、本番稼働用アカウントでリソースにアクセスすることが必要になる場合があります。たとえば、開発環境から本番稼働環境に更新を昇格させる場合、クロスアカウントアクセスが必要になることがあります。両方のアカウントで作業するユーザーにそれぞれの ID（およびパスワード）を作成することも可能ですが、複数のアカウントに対する複数の認証情報を管理する必要があり、ID 管理が困難になります。以下の図では、すべてのユーザーは開発用アカウントで管理されていますが、数名の開発者は本稼働用アカウントに制限付きでアクセスする必要があります。開発用アカウントにはテスターと開発者の 2 つのグループがあり、それぞれ個別のポリシーがあります。
![\[ロールを使用して別のアカウントのユーザーにアクセス権限を委任する\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. 管理者は、本番稼働用アカウントで IAM を使用し、このアカウントで `UpdateApp` ロールを作成します。ロールでは、管理者は開発用アカウントを `Principal` として指定する信頼ポリシーを定義します。これは、開発用アカウントの認証されたユーザーが `UpdateApp` ロールを使用できることを意味します。また、管理者は、`productionapp` という Amazon S3 バケットに対する読み取りと書き込みを指定するロールについてのアクセス許可ポリシーを定義します。
次に、管理者は、このロールを引き受ける必要がある任意のユーザーと該当情報を共有します。この情報は、ロールのアカウント番号と名前 (AWS コンソールユーザーの場合)、または Amazon リソースネーム (ARN) (AWS CLI または AWS API アクセスの場合) です。ロールの ARN は `arn:aws:iam::123456789012:role/UpdateApp` のようになります。これは、ロールの名前が `UpdateApp` で、ロールがアカウント番号 123456789012 に作成されたことを意味します。
**注記**
管理者は、ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるように、オプションでロールを設定できます。詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。
1. 開発アカウントでは、管理者は開発者グループのメンバーに対して、このロールに切り替えるアクセス許可を付与します。これは、Developers グループに AWS Security Token Service（AWS STS）`UpdateApp` ロールの `AssumeRole` API を呼び出すアクセス権限を付与することで行われます。これにより、開発用アカウントの Developers グループに所属する IAM ユーザーは、本稼働用アカウントの `UpdateApp` ロールに切り替えることができます。Developers グループに所属しないの他のユーザーには、そのロールに切り替えるアクセス許可がないため、本番稼働用アカウントの S3 バケットにはアクセスできません。
1. ユーザーは、ロールへの切り替えをリクエストします。
+ AWS コンソール: ユーザーはナビゲーションバーのアカウント名を選択してから、[**ロールの切り替え**] を選択します。ユーザーは、アカウント ID（またはエイリアス）とロール名を指定します。または、管理者からメールで送信されたリンクをクリックすることもできます。リンクをクリックすると、詳細がすでに入力された [**ロールの切り替え**] ページに移動します。
+ AWS API/AWS CLI: 開発用アカウントの Developers グループに所属するユーザーが `AssumeRole` 関数を呼び出し、`UpdateApp` ロールの認証情報を取得します。呼び出しの一部として、ユーザーが `UpdateApp` ロールの ARN を指定します。Testers グループのユーザーが同じ要求をしても、テスターは `UpdateApp` ロールの ARN に対して `AssumeRole` を呼び出すことは許可されていないため、その要求は拒否されます。
1. AWS STS が一時的な認証情報を返します。
+ AWS コンソール: AWS STS はリクエストをロールの信頼ポリシーと照合し、そのリクエストが信頼されたエンティティ (開発用アカウント) からであることを確認します。照合の後、AWS STS は AWS コンソールに[一時的セキュリティ認証情報](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)を返します。
+ API/CLI: AWS STS は、リクエストをロールの信頼ポリシーと照合し、信頼されたエンティティ (Development アカウント) からであることを確認します。照合の後、AWS STS はアプリケーションに[一時的セキュリティ認証情報](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)を返します。
1. 一時的な認証情報により、AWS リソースにアクセスすることができます。
+ AWS コンソール: AWS コンソールは、後続のすべてのコンソールアクション (この場合は、`productionapp` バケットの読み書き) でユーザーの代わりに一時的な認証情報を使用します。コンソールは、本稼働用アカウントにある他のリソースにはアクセスできません。ユーザーがロールを終了すると、ユーザーのアクセス権限がロールに切り替える前に持っていた元のアクセス権限に戻ります。
+ API/CLI: アプリケーションは、その一時的な認証情報を使用して `productionapp` バケットを更新します。一時的な認証情報を使用し、アプリケーションは `productionapp` バケットでのみ読み書きを行うことができますが、本番稼働用アカウントにあるその他のリソースにはアクセスできません。アプリケーションは、ロールを終了する必要はありませんが、その代わりに一時的な認証情報の使用を停止し、後続の API 呼び出しで元の認証情報の使用する必要があります。
## その他のリソース
詳細については次を参照してください:
+ [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)
# AWS 以外のワークロードに対するアクセス
[IAM ロール](id_roles.md)は、[アクセス許可](access_policies.md)が割り当てられている AWS Identity and Access Management IAM 内のオブジェクトです。IAMの ID または AWS 外部からの ID を使用して[そのロールを引き受ける](id_roles_manage-assume.md)と、ロールセッションのための一時的なセキュリティ認証情報が提供されます。データセンターや AWS 以外のインフラストラクチャで実行されるワークロードが、AWS リソースにアクセスしなければならない場合があります。長期的なアクセスキーを作成、配布、管理する代わりに、AWS Identity and Access Management Roles Anywhere (IAM Roles Anywhere) を使用して AWS 以外のワークロードを認証することができます。IAM Roles Anywhere は、認証局 (CA) から発行された X.509 証明書を使用して ID を認証し、IAM ロールによって提供される一時的な認証情報を使用した AWS のサービス への安全なアクセスを提供します。
**IAM Roles Anywhere を使用するには**
1. [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) を使用して CA を設定するか、独自の PKI インフラストラクチャの CA を使用します。
1. CA を設定したら、IAM Roles Anywhere にトラストアンカーと呼ばれるオブジェクトを作成します。このアンカーは、IAM Roles Anywhere と CA との間に認証目的で信頼を確立します。
1. その後、既存の IAM ロールを設定するか、IAM Roles Anywhere サービスを信頼する新しいロールを作成できます。
1. トラストアンカーを使用して IAM Roles Anywhere で AWS 以外のワークロードを認証します。AWS は AWS リソースへのアクセスが許可された IAM ロールに対し、AWS 以外のワークロードの一時的な認証情報を付与します。
## 追加リソース
AWS 以外のワークロードへのアクセスを提供する方法について詳しく知りたい場合は、以下のリソースを参考にすると便利です。
+ IAM Roles Anywhere の設定の詳細については、「*IAM Roles Anywhere User Guide*」(IAM Roles Anywhere ユーザーガイド) の「[What is AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)」( Roles Anywhere とは) を参照してください。
+ IAM Roles Anywhere のパブリックキーインフラストラクチャ (PKI) を設定する方法については、「AWS セキュリティブログ」の「[IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)」を参照してください。
# 第三者が所有する AWS アカウント へのアクセス
組織内の AWS リソースへ組織外の第三者がアクセスする必要がある場合には、ロールを使用することでアクセス許可を委任することができます。たとえば、組織内の AWS リソースの管理を第三者へ委託しているような場合が相当します。IAM ロールを使用することで、AWS セキュリティ認証情報を共有することなく第三者に AWS リソースへのアクセスを許可することができます。第三者は代わりに、AWS アカウント に作成したロールを引き受けることで、AWS リソースにアクセスできます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
第三者は、以下の情報を提供する必要があります。これらの情報は、第三者が引き受けることのできるロールの作成に必要です。
+ **第三者の AWS アカウント ID**。ロールの信頼ポリシーを定義するときは、その AWS アカウント ID をプリンシパルとして指定します。
+ **ロールを一意に関連付けるための外部 ID**。外部 ID は、ユーザーと第三者によってのみ識別される識別子です。たとえば、ユーザーとサードパーティーの間の請求書 ID は使用できますが、サードパーティーの名前や電話番号などの推測できるものは使用しないでください。ロールの信頼ポリシーを定義するときは、この ID を指定する必要があります。サードパーティーは、ロールを引き受けるときに、この ID を指定する必要があります。
+ **第三者が AWS リソースでの作業を行うのに必要なアクセス許可**。ロールのアクセス許可ポリシーを定義する際に、権限を指定する必要があります。このポリシーには、第三者はどのアクションができるのか、およびどのリソースにアクセスできるのかが定義されています。
ロールの作成が完了したら、そのロールの Amazon リソースネーム（ARN）を対象の第三者に提供します。第三者がロールを担当するにあたり、このロールの ARN を必要とします。
**重要**
お客様の AWS リソースへのアクセスを第三者に許可すると、第三者はポリシーで指定したすべてのリソースにアクセスできます。サードパーティーによるリソースの使用は、ユーザーに請求されます。したがって、第三者によるリソースの使用については適切な制限を設けるようにしてください。
## 第三者によるアクセスのための外部 ID
外部 ID を使用すると、ロールを引き受けるユーザーは、業務を遂行する環境へのアクセスをリクエストできます。また、アカウント所有者が、特定の環境においてのみロールを引き受けることができるようにする方法の 1 つでもあります。外部 ID の最も重要な機能は、[混乱する代理問題](confused-deputy.md) の防止と対処です。
**重要**
AWS は、外部 ID を機密情報として扱いません。アクセスキーペアやパスワードなどの機密情報を AWS で作成した場合、それらを再び表示することはできません。ロールの外部 ID は、ロールを表示する権限を持つすべてのユーザーが表示できます。
## 外部 ID が適している状況
外部 ID は以下の状況で使用します。
+ お客様は AWS アカウント の所有者で、それ以外の AWS アカウント アカウントにアクセスするロールを第三者のために設定しました。第三者がお客様のロールを引き受けるときに含める外部 ID は、第三者に問い合わせる必要があります。その後、ロールの信頼ポリシーでその外部 ID を確認します。これにより、外部の第三者は、お客様に代わって操作を行う場合にのみ、お客様のロールを引き受けることができます。
+ お客様は、前のシナリオの Example Corp のように、さまざまな顧客に代わってロールを引き受ける立場にあります。各顧客に一意の外部 ID を割り当て、ロールの信頼ポリシーに外部 ID を追加するように指示します。ロールを引き受けるには、リクエストに正しい外部 ID が常に含まれていることを確認する必要があります。
既にそれぞれの顧客に一意の ID を割り当てている場合は、この一意の ID を外部 ID として使用できます。外部 ID は、この目的のためだけに明示的に作成したり個別に追跡したりする必要のある特別な値ではありません。
外部 ID は常に `AssumeRole` API 呼び出しで指定する必要があります。さらに、顧客からロールの ARN を受け取ったら、正しい外部 ID と正しくない外部 ID の両方を使用して、そのロールを引き受けることができるかどうかをテストします。正しい外部 ID がなくてもロールを引き受けることのできる場合は、システムに顧客のロール ARN を保存しないでください。顧客がロール信頼ポリシーを更新し、正しい外部 ID を要求するまで待ちます。こうすることにより、顧客による不正を防止し、"混乱した代理" 問題からお客様と顧客の両方を守ることができます。
## 外部 ID を使用したシナリオの例
例えば、Example Corp という第三者企業を雇って、コストを最適化するためにお客様の AWS アカウント をモニタリングする業務を依頼するとします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。また、Example Corp は他の顧客について他の多くの AWS アカウントをモニタリングしています。
Example Corp に AWS アカウントの IAM ユーザーとのその長期的認証情報へのアクセスを許可しないでください。代わりに、IAM ロールとその一時的なセキュリティ認証情報を使用します。IAM ロールは、第三者が長期的認証情報 (IAM ユーザーアクセスキーなど) を共有することなくお客様の AWS リソースにアクセスできるようにするメカニズムです。
IAM ロールを使用して AWS アカウント と Example Corp アカウントと間の信頼関係を確立できます。この関係が確立されると、Example Corp アカウントのメンバーは、AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を呼び出して、一時的セキュリティ認証情報を取得できます。次に、Example Corp のメンバーは、この認証情報を使用してアカウントの AWS リソースにアクセスできます。
**注記**
一時的セキュリティ認証情報を取得するために呼び出すことのできる AssumeRole とその他の AWS API オペレーションの詳細については、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
このシナリオの詳細は以下のとおりです。
1. お客様は Example Corp を雇うとします。Example Corp はお客様の一意の顧客 ID を作成します。Example Corp はその一意の顧客 ID と Example Corp の AWS アカウント 番号をお客様に提供します。この情報は次の手順でお客様が IAM ロールを作成するために必要になります。
**注記**
Example Corp は、顧客ごとに一意である限り、任意の文字列値を ExternalId に使用できます。顧客のアカウント番号を使用することもできますし、ランダムな文字列でもかまいません。ただし、2 つの顧客に同じ値を使用することはできません。「シークレット」することを意図したものではありません。Example Corp は、顧客ごとに ExternalId 値を指定する必要があります。重要なのは、各外部IDがユニークであることを確認するために、お客様**によってではなく**、Example Corp によって生成される必要があるということです。
1. お客様は AWS にサインインし、お客様のリソースへのアクセス権を Example Corp に付与する IAM ロールを作成します。他の IAM ロールと同様に、このロールにも 2 つのポリシー (アクセス許可ポリシーと信頼ポリシー) があります。ロールの信頼ポリシーでは、だれがこのロールを引き受けることができるかを指定します。このサンプルシナリオでは、ポリシーで `Principal` として Example Corp の AWS アカウント 番号を指定します。これにより、そのアカウントの ID はロールを引き受けることができるようになります。さらに、信頼ポリシーに `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 要素を追加します。この `Condition` は `ExternalId` コンテキストキーをテストして、その要素が Example Corp の一意の顧客 ID に一致するようにします。その例を示します。
```
"Principal": {"AWS": "Example Corp's AWS アカウント ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. ロールのアクセス許可ポリシーでは、ロールがだれに何を許可するかを指定します。たとえば、お客様の Amazon EC2 と Amazon RDS のリソースのみを管理でき、お客様の IAM ユーザーまたはグループは管理できないようにロールを指定できます。サンプルシナリオでは、アクセス許可ポリシーを使用して、お客様のアカウントのすべてのリソースに対する読み取り専用アクセス権を Example Corp に付与します。
1. ロールの作成が完了したら、そのロールの Amazon リソースネーム（ARN）を Example Corp に提供します。
1. Example Corp がお客様の AWS リソースに対するアクセス許可を必要とするとき、Example Corp の担当者が AWS `sts:AssumeRole` API を呼び出します。この呼び出しには、引き受けるロールの ARN とお客様の顧客 ID に対応する ExternalId パラメータが含まれています。
リクエスト元が Example Corp の AWS アカウント であり、ロール ARN と外部 ID が正しい場合、リクエストは成功します。次に、一時的なセキュリティ認証情報が提供されます。Example Corp はその情報を使用して、お客様のロールが許可している AWS リソースにアクセスできます。
つまり、ロールのポリシーに外部 ID が含まれている場合、そのロールを引き受けるユーザーは、ロールでプリンシパルであり、正しい外部 ID を指定する必要があります。
## 外部 ID の重要なポイント
+ 異なる AWS で複数の顧客をサポートするマルチテナント環境では、AWS アカウント アカウントごとに 1 つの外部 ID を使用することをお勧めします。この ID は、サードパーティーによって生成されたランダムな文字列である必要があります。
+ ロールを引き受けるときにサードパーティーが外部 ID を提供することを要求するには、ロールの信頼ポリシーを選択した外部 ID で更新します。
+ ロールを引き受けるときに外部 ID を提供するには、AWS CLI または AWS API を使用してそのロールを引き受けます。詳細については、「STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーション」または「STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI オペレーション」を参照してください。
+ `ExternalId` の値は、2～1,224 文字で構成されている必要があります。この値は、空白のない英数字にする必要があります。次の記号を含めることもできます。プラス記号 (\$1)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (@)、コロン (:)、スラッシュ (/)、およびハイフン (–)。
## その他のリソース
第三者が所有する AWS アカウントへのアクセスを提供する方法について詳しく知りたい場合は、以下のリソースを参考にすると便利です。
+ AWS アカウント内で他のユーザーがアクションを実行できるようにする方法については、「[カスタム信頼ポリシーを使用してロールを作成する](id_roles_create_for-custom.md)」を参照してください。
+ ロールを切り替えるアクセス許可を付与する方法については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
+ 信頼できるユーザーを作成して一時的なセキュリティ認証情報を提供する方法については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。
# AWS サービスへのアクセス
多くの AWS のサービスでは、ロールを使用して、そのサービスがアクセスできものを制御する必要があります。サービスがお客様に代わってアクションを実行するために引き受けるロールは、[サービスロール](id_roles.md#iam-term-service-role)と呼ばれます。ロールにサービスに対して特殊な目的がある場合、そのロールは[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)として分類できます。特定のサービスがロールを使用するかどうかと、使用するサービスのロールを割り当てる方法については、各サービスの [AWS ドキュメント](https://docs.aws.amazon.com/)を参照してください。
AWS が提供するサービスへのアクセスを委任するロールの作成については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。
# 外部で認証されたユーザーへのアクセス (ID フェデレーション)
社内のディレクトリなど、AWS 以外の ID をユーザーがすでに持っているとします。それらのユーザーが AWS リソースを使用する (または、それらのリソースにアクセスするアプリケーションを使用する) 必要がある場合、それらのユーザーには AWS セキュリティ認証情報も必要です。IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できます。
**注記**
セキュリティ上のベストプラクティスとして、IAM ユーザーを作成する代わりに、ID フェデレーションを使用して [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) でユーザーアクセスを管理することをお勧めします。IAM ユーザーが必要な特定の状況についての情報は、「[IAMユーザー (ロールの代わりに) を作成する場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。
## Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション
AWS リソースにアクセスするモバイルまたはウェブベースのアプリを作成する場合、アプリが AWS にプログラムによるリクエストを送るには認証情報が必要になります。ほとんどのモバイルアプリケーションのシナリオでは、[Amazon Cognito](https://aws.amazon.com/cognito/) の使用をお勧めします。このサービスを [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) および [AWS Mobile SDK for Android and Fire OS](https://aws.amazon.com/sdkforandroid/) で使用して、ユーザーの一意のIDを作成し、AWS リソースへの安全なアクセスのためにユーザーを認証できます。Amazon Cognito では、次のセクションに示されているのと同じ ID プロバイダーがサポートされます。さらに、[開発者が認証した ID](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) と認証されていない (ゲスト) アクセスもサポートされます。また、Amazon Cognito には、ユーザーがデバイスを変えてもデータが保持されるように、ユーザーデータを同期するための API オペレーションも用意されています。詳細については、「[モバイルアプリのための Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito)」を参照してください。
## パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション
可能な限り、モバイルおよびウェブベースのアプリケーションシナリオで Amazon Cognito を使用してください。Amazon Cognito は、パブリック ID プロバイダーサービスを使用する際の裏方作業をほとんど行います。同じサードパーティのサービスで機能し、また匿名サインインもサポートしています。ただし、より高度なシナリオでは、OpenID Connect (OIDC) と互換性がある Login with Amazon、Facebook、Google、その他 IdP でのログインなど、サードパーティのサービスを直接使用できます。これらのサービスを使用した OIDC フェデレーションの使用についての詳細は、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
## SAML 2.0 を使用したユーザーのフェデレーション
組織が既に SAML 2.0 (Security Assertion Markup Language 2.0) をサポートする ID プロバイダーソフトウェアパッケージを使用している場合、ID プロバイダー (IdP) としての組織と、サービスプロバイダーとしての AWS との間に信頼を作成できます。その後、SAML を使用して、AWS マネジメントコンソール へのフェデレーティッドシングルサインオン (SSO) または AWS API オペレーションを呼び出すためのフェデレーションアクセスをユーザーに許可できます。たとえば、社内で Microsoft Active Directory と Active Directory Federation Services を使用している場合は、SAML 2.0 を使用してフェデレーションが可能です。SAML 2.0 を使用したユーザーのフェデレーション方法の詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
## カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション
ID ストアに SAML 2.0 との互換性がない場合、カスタム ID ブローカーアプリケーションを作成して同じような機能を実行できます。ブローカーアプリケーションはユーザーを認証し、そのユーザー用に一時的な認証情報を AWS に要求して、それをユーザーに提供し AWS リソースにアクセスできるようにします。
たとえば、Example Corp. には、会社の AWS リソースにアクセスする社内アプリケーションを実行する必要のある従業員が多数います。従業員は、会社の ID および認証システムに既に ID があり、従業員ごとに別の IAM ユーザーを作成することは望ましくありません。
Bob は Example Corp の開発者です。Example Corp の社内アプリケーションで会社の AWS リソースにアクセスできるようにするために、カスタム ID ブローカーアプリケーションを開発しています。このアプリケーションは、従業員が Example Corp. の既存の ID および認証システムにサインインしていることを確認します。これには、LDAP や Active Directory などのシステムを使用している可能性があります。ID ブローカーアプリケーションは、従業員の一時的なセキュリティ認証情報を取得します。このシナリオは、前のシナリオ（カスタム認証システムを使用するモバイルアプリ）に似ています。ただし、AWS リソースにアクセスする必要のあるアプリケーションはすべて企業ネットワーク内で実行され、会社には既存の認証システムがあります。
一時的なセキュリティ認証情報を取得するために、ID ブローカーアプリケーションは、ユーザーのポリシーの管理方法と一時的な認証情報の有効期限に応じて、`AssumeRole` または `GetFederationToken` を呼び出して、一時的なセキュリティ認証情報を取得します (これらの API オペレーションの違いの詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」および「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください)。この呼び出しは、AWS アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成される一時的なセキュリティ認証情報を返します。ID ブローカーアプリケーションは、これらの一時的なセキュリティ認証情報を社内アプリケーションで使用できるようにします。アプリは、一時的な認証情報を使用して AWS を直接呼び出すことができます。アプリは、認証情報をキャッシュし、有効期限が切れると、新しい一時的な認証情報をリクエストします。このシナリオを以下に図で示します。
![\[カスタム ID ブローカーアプリケーションを使用したワークフローの例\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
このシナリオには次の属性があります。
+ ID ブローカーアプリケーションには、一時的なセキュリティ認証情報を作成するために IAM のトークンサービス (STS) API にアクセスする権限があります。
+ ID ブローカーアプリケーションが、従業員が既存の認証システム内で認証されていることを確認できます。
+ ユーザーは、AWS マネジメントコンソールへのアクセスを与える一時的な URL を入手できます（これはシングルサインオンと呼ばれています）。
一時的なセキュリティ認証情報の作成方法の詳細については、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。AWS マネジメントコンソールへのアクセスを取得する SAML フェデレーティッドプリンシパルの詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。