# IAM の一時的な認証情報
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。
+ 一時的セキュリティ認証情報は、その名前が示すとおり、*使用期限が短く*なっています。有効期限は数分から数時間に設定できます。認証情報が失効すると、AWS はそれらを認識しなくなります。また、その認証情報によって作成された API リクエストによるあらゆるタイプのアクセスが許可されなくなります。
+ 一時的セキュリティ認証情報はユーザーとともに保存されることはなく、ユーザーのリクエストに応じて動的に生成され、提供されます。一時的セキュリティ認証情報が失効すると（または失効する前でも）、ユーザーは新しい認証情報をリクエストできます。ただし、リクエストするユーザーがまだその権限を持っている場合に限ります。
そのため、一時的な認証情報には、長期の認証情報よりも次の利点があります。
+ アプリケーションの長期の AWS セキュリティ認証情報を配布したり埋め込んだりする必要がありません。
+ ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できます。一時的認証情報は[ロール](id_roles.md)および [ID フェデレーション](id_roles_providers.md)の基本となります。
+ 一時的セキュリティ認証情報の有効期限は限られているので、認証情報が不要になった際に更新したり、明示的に取り消したりする必要がありません。一時的セキュリティ認証情報の有効期限が切れると、再利用することはできません。認証情報が有効な期間を、最大限度まで指定できます。
## AWS STS と AWS リージョン
一時的な認証情報は AWS STS によって生成されます。デフォルトでは、AWS STS は `https://sts.amazonaws.com` に 1 つのエンドポイントのあるグローバルサービスです。ただし、他のサポートされているリージョンにあるエンドポイントへの AWS STS API 呼び出しを実行することもできます。地理的に近い場所にあるリージョンのサーバーに対してリクエストを送信することによって、レイテンシー (サーバーのラグ) を低減できます。認証情報を取得したリージョンに関係なく、認証情報はグローバルに使用できます。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。
## 一時的な認証情報の一般的なシナリオ
一時的な認証情報は、ID フェデレーション、委任、クロスアカウントアクセス、および IAM ロールが使用されるシナリオで便利です。
### ID フェデレーション
AWS 以外の外部システムでユーザー ID を管理し、それらのシステムのアクセス許可からサインインするユーザーに、AWS タスクの実行や AWS リソースへのアクセスの権限を付与できます。IAM では、2 種類のアイデンティティフェデレーションがサポートされます。いずれの場合も、ID は AWS の外部に格納されます。異なる点は、外部システムが存在する場所 (データセンターまたはウェブの外部サードパーティ) です。ID フェデレーションの一時的なセキュリティ認証情報の特徴を比較するには、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
外部 ID プロバイダーについては、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
+ **OpenID Connect (OIDC) フェデレーション** – モバイルまたはウェブアプリケーションに対して、ユーザーに一般的なサードパーティー ID プロバイダー (Login with Amazon、Facebook、Google、OIDC 2.0 互換の任意のプロバイダーなど) を使用したサインインを求めることができます。カスタムサインインコードを作成したり、独自のユーザー ID を管理したりする必要はありません。OIDC フェデレーションを使用すると、IAM ユーザーアクセスキーなどの長期的セキュリティ認証情報をアプリケーションに配布する必要がないため、AWS アカウント を安全に保つことができます。詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
AWS STS OIDC フェデレーションでは、Login with Amazon、Facebook、Google、および任意の OpenID Connect (OIDC) 互換の ID プロバイダーがサポートされています。
**注記**
モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。このサービスをモバイル開発用の AWS SDK と共に使用して、ユーザーの一意の ID を作成し、AWS リソースへの安全なアクセスのためにユーザーを認証できます。Amazon Cognito では、AWS STS と同じ ID プロバイダーがサポートされます。さらに、認証されていない (ゲスト) アクセスもサポートされ、ユーザーがサインインしたときにユーザーデータを移行することができます。また、Amazon Cognito には、ユーザーがデバイスを変えてもデータが保持されるように、ユーザーデータを同期するための API オペレーションも用意されています。詳細については、Amplify ドキュメントの「[Amplify による認証](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)」を参照してください。
+ **SAML フェデレーション** - 組織のネットワークのユーザーを認証し、新しい AWS ID を作成したり、異なるサインイン認証情報でサインインすることを求めたりすることなく、それらのユーザーに AWS へのアクセスを提供できます。これは、一時アクセスに対するシングルサインオンのアプローチとして知られています。AWS STS は Security Assertion Markup Language (SAML) 2.0 のようなオープンスタンダードをサポートしており、Microsoft AD FS を通じて Microsoft Active Directory を活用することが可能です。また、SAML 2.0 を使用して、ユーザー ID フェデレーション用の独自のソリューションを管理することもできます。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
+ **カスタムフェデレーションブローカー** – AWS組織の認証システムを使用して リソースへのアクセスを許可することができます。シナリオの例については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
+ **SAML 2.0 を使用したフェデレーション** – AWS 組織の認証システムと SAML を使用して、 リソースへのアクセスを許可することができます。詳細とシナリオの例については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
### クロスアカウントアクセスのロール
多くの組織は、複数の AWS アカウント を保持しています。ロールとクロスアカウントアクセスを使用すると、1 つのアカウントでユーザー ID を定義し、その ID を使用して、組織に属している他のアカウントの AWS リソースにもアクセスできるようにすることができます。これは、一時アクセスに対する*委任*アプローチとして知られています。クロスアカウントロールの作成の詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
### Amazon EC2 の ロール
Amazon EC2 インスタンスでアプリケーションを実行し、これらのアプリケーションが AWS リソースにアクセスする必要がある場合は、アプリケーションの起動時に一時的セキュリティ認証情報をインスタンスに提供できます。これらの一時的なセキュリティ認証情報は、インスタンスで実行されるすべてのアプリケーションが使用できるので、インスタンスに長期的な認証情報を保存する必要がありません。詳細については、「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する](id_roles_use_switch-role-ec2.md)」を参照してください。
IAM Amazon EC2 のロールの認証情報の詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)」を参照してください。
### その他の AWS サービス
一時的セキュリティ認証情報を使用して、ほとんどの AWS サービスにアクセスできます。一時的セキュリティ認証情報を受け入れるサービスのリストは、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
## 一時認証情報を使用するサンプルアプリケーション
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](#id_credentials_temp)AWS STS を使用して一時的なセキュリティ認証情報を管理する方法を確認するために、完全なシナリオ例を実装する以下のサンプルアプリケーションをダウンロードできます。
+ [Windows Active Directory、ADFS、SAML 2.0 を使用して AWS へのフェデレーションを有効化する](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/) Windows アクティブディレクトリ (AD)、アクティブディレクトリフェデレーションサービス (ADFS) 2.0、SAML (セキュリティアサーションマークアップ言語) 2.0 で、エンタープライズフェデレーションを使用して AWS へのアクセスを委任する方法を示します。
+ [AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)。シングルサインオン (SSO) を有効にするカスタムフェデレーションプロキシを作成して、既存の Active Directory ユーザーが AWS マネジメントコンソール にサインインできるようにする方法を示します。
+ [Shibboleth を使用して AWS マネジメントコンソール へのシングルサインオンを行う方法](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/)。[Shibboleth](http://shibboleth.net/) と [SAML](id_roles_providers_saml.md) を使用して、AWS マネジメントコンソール へのシングルサインオン (SSO) アクセスを可能にする方法を示します。
### OIDC フェデレーションのサンプル
以下のサンプルアプリケーションは、Login with Amazon、Amazon Cognito、Facebook、Google などのプロバイダーで OIDC フェデレーションを使用する方法を示しています。これらのプロバイダーからの認証情報を一時的な AWS セキュリティ認証情報に交換して、AWS のサービスにアクセスできます。
+ [Amazon Cognitoチュートリアル](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) – モバイル開発用の AWS SDK で Amazon Cognitoを使用することをお勧めします。Amazon Cognito は、モバイルアプリの ID を管理するための最も簡単な方法であり、同期やクロスデバイス ID のような追加機能も利用できます。Amazon Cognito の詳細については、「Amplify ドキュメント」の「[Amplify による認証](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)」を参照してください。
## 一時的なセキュリティ認証情報のための追加リソース
以下のシナリオやアプリケーションは、一時的なセキュリティ認証情報の使用時に役立ちます。
+ [AWS STS SourceIdentity をアイデンティティプロバイダーと統合する方法](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/)。この記事では、Okta、Ping、OneLogin を IdP として使用し、AWS STS `SourceIdentity` 属性を設定する方法について説明します。
+ [OIDC フェデレーション](id_roles_providers_oidc.md)。このセクションでは、OIDC フェデレーションと `AssumeRoleWithWebIdentity` API を使用するときに IAM ロールを設定する方法について説明します。
+ [MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)。このトピックでは、アカウントで機密性の高い API アクションを保護するために、ロールを使用して多要素認証（MFA）を要求する方法について説明します。
AWS におけるポリシーとアクセス権限の詳細については、以下のトピックを参照してください。
+ [AWS リソースの アクセス管理](access.md)
+ [ポリシーの評価論理](reference_policies_evaluation-logic.md).
+ [Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)の「*Amazon S3 リソースへのアクセス許可の管理*」。
+ 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
# AWS STS 認証情報を比較する
次の表は、一時的なセキュリティ認証情報を返す、AWS STS の API オペレーションの機能を比較したものです。ロールを引き受けることで一時的なセキュリティ認証情報をリクエストするための別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。セッションタグを渡すことができるさまざまな AWS STS API オペレーションについては、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
**注記**
AWS STS API 呼び出しは、グローバルエンドポイントにも、リージョンのエンドポイントの 1 つに対しても送信できます。より近くのエンドポイントを選択した場合、レイテンシーを軽減し、API 呼び出しのパフォーマンスが向上します。また、元のエンドポイントとの通信ができなくなった場合は、代替リージョンのエンドポイントに呼び出しを送信することもできます。各種 AWS SDK の 1 つを使用している場合、API コールを行う前に SDK メソッドを使用してリージョンを選択します。手動で HTTP API リクエストを組み立てる場合、独自で正しいエンドポイントにリクエストを送信する必要があります。詳細については、[*リージョンとエンドポイント*の「AWS STS 」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)および「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」 を参照してください。
| **AWS STS API** | **呼び出し元** | **認証情報の有効期間 (最小 \$1 最大 \$1 デフォルト)** | **MFA サポート**¹ | **セッションポリシーのサポート**² | **得られた一時的な認証情報に対する制限** |
| --- | --- | --- | --- | --- | --- |
| [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | 既存の一時的なセキュリティ認証情報を持つ IAM ユーザーまたは IAM ロール | 15 分 \$1 最大セッション期間設定³ \$1 1 時間 | はい | はい | `GetFederationToken` または `GetSessionToken` を呼び出せません。 |
| [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | 任意のユーザー。呼び出し元は、既知の ID プロバイダーからの認証を示す SAML 認証レスポンスを渡す必要があります。 | 15 分 \$1 最大セッション期間設定³ \$1 1 時間 | いいえ | はい | `GetFederationToken` または `GetSessionToken` を呼び出せません。 |
| [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | 任意のユーザー。呼び出し元は、既知の ID プロバイダーからの認証を示す OIDC 準拠の JWT トークンを渡す必要があります。 | 15 分 \$1 最大セッション期間設定³ \$1 1 時間 | いいえ | はい | `GetFederationToken` または `GetSessionToken` を呼び出せません。 |
| [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | IAM ユーザーまたは AWS アカウントのルートユーザー | IAM ユーザー: 15 分 \$1 36 時間 \$1 12 時間 ルートユーザー: 15 分 \$1 1 時間 \$1 1 時間 | いいえ | はい | AWS CLI または AWS API を使用して IAM オペレーションを呼び出すことはできません。この制限はコンソールセッションには適用されません。 `GetCallerIdentity` 以外の AWS STS オペレーションは呼び出せません。⁴ コンソールへの SSO は許可されています。⁵ |
| [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | IAM ユーザーまたは AWS アカウントのルートユーザー | IAM ユーザー: 15 分 \$1 36 時間 \$1 12 時間 ルートユーザー: 15 分 \$1 1 時間 \$1 1 時間 | はい | いいえ | リクエストに MFA 情報が含まれていない場合は、IAM API オペレーションを呼び出せません。 `AssumeRole` または `GetCallerIdentity` を除く AWS STS API オペレーションを呼び出せません。 コンソールへの SSO は許可されていません。⁶ |
¹ **MFA サポート**。AssumeRole および GetSessionToken API オペレーションを呼び出すときに、多要素認証 (MFA) デバイスに関する情報を含めることができます。そうすることで、API 呼び出しによって得られた一時的なセキュリティ認証情報を、MFA デバイスで認証されたユーザーだけが使用できるようにできます。詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。
² **セッションポリシーのサポート**。セッションポリシーは、ロールまたは AWS STS フェデレーションユーザーのセッションに一時的なセッションをプログラムで作成する際、パラメータとして渡すポリシーです。このポリシーでは、セッションに割り当てられているロールまたはユーザーのアイデンティティベースのポリシーのアクセス許可を制限しています。結果として得られるセッションのアクセス許可は、エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。ロールセッションのアクセス許可の詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。
³ **[Maximum session duration setting]** (最大セッション期間設定)。`DurationSeconds` パラメータを使用して、ロールセッションの期間を 900 秒 (15 分) からそのロールの最大セッション期間設定まで指定できます。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。
⁴ **GetCallerIdentity**。このオペレーションを実行するためのアクセス許可は必要ありません。管理者が、`sts:GetCallerIdentity` アクションへのアクセスを明示的に拒否するポリシーを IAM ユーザーまたはロールに追加しても、このオペレーションは実行できます。IAM ユーザーまたはロールがアクセスを拒否されたときに同じ情報が返されるため、アクセス許可は必要ありません。レスポンスの例については、「[iam:DeleteVirtualMFADevice を実行することを認可されていません](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa)」を参照してください。
⁵ **コンソールへのシングルサインオン (SSO)**。SSO をサポートするために、AWS でフェデレーションエンドポイント (`https://signin.aws.amazon.com/federation`) を呼び出し、一時的セキュリティ認証情報を渡すことができます。エンドポイントから返されるトークンを使用すると、パスワードを要求せずにユーザーを直接コンソールにサインインさせる URL を作成できます。詳細とサンプルスクリプトについては、[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md) および AWS セキュリティブログの「[AWS へのクロスアカウントアクセスを有効にする方法](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。
⁵ 一時的な認証情報を取得した後、この認証情報をフェデレーションのシングルサインオンエンドポイントに渡して AWS マネジメントコンソール にアクセスすることはできません。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
# サービスベアラートークン
一部の AWS のサービスでは、プログラムでリソースにアクセスする前に、AWS STS サービスベアラートークンを取得するアクセス許可が必要です。これらのサービスは、従来の [API リクエストに対する AWS Signature Version 4](reference_sigv.md) を使用する代わりに、ベアラトークンの使用が必要なプロトコルをサポートします。ベアラートークンをリクエストする AWS CLI または AWS API オペレーションを実行すると、AWS のサービスはお客様に代わってベアラートークンをリクエストします。サービスによってトークンが提供され、このトークンを使用して、サービスで後続のオペレーションを実行できます。
AWS STS サービスベアラートークンには、アクセス許可に影響する可能性がある元のプリンシパル認証の情報が含まれます。この情報には、プリンシパルタグ、セッションタグ、セッションポリシーが含まれます。トークンのアクセスキー ID は、`ABIA` プレフィックスで始まります。これは、CloudTrail ログ内のサービスベアラートークンを使用して実行されたオペレーションを識別するのに役立ちます。
**重要**
ベアラートークンは、それを生成するサービスへの呼び出しと、それが生成されたリージョンでのみ使用できます。ベアラトークンを使用して、他のサービスやリージョンでオペレーションを実行することはできません。
ベアラートークンをサポートするサービスの例は、AWS CodeArtifact です。NPM、Maven、または PIP などのパッケージマネージャを使用して AWS CodeArtifact を操作する前に、`aws codeartifact get-authorization-token` オペレーションを呼び出す必要があります。このオペレーションは、AWS CodeArtifact オペレーションを実行するために使用できるベアラートークンを返します。または、同じオペレーションを完了し、クライアントを自動的に設定する `aws codeartifact login` コマンドを使用できます。
ベアラートークンを生成する AWS のサービスでアクションを実行する場合は、IAM ポリシーに次のアクセス許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowServiceBearerToken",
"Effect": "Allow",
"Action": "sts:GetServiceBearerToken",
"Resource": "*"
}
]
}
```
------
サービスのベアラートークンの例については、「*AWS CodeArtifact* ユーザーガイド」の「[Using identity-based policies for AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html)」( でのアイデンティティベースのポリシーの使用) を参照してください。
# 一時的なセキュリティ認証情報をリクエストする
一時的なセキュリティ認証情報をリクエストするには、AWS API で AWS Security Token Service (AWS STS) を使用できます。これには、AWS リソースへのアクセスを制御できる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供するオペレーションが含まれます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](id_credentials_temp.md)ロールを引き受けることで一時的なセキュリティ認証情報をリクエストするための別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。
API オペレーションを呼び出すには、いずれかの [AWS SDK](https://aws.amazon.com/tools/) を使用することができます。SDK は、Java、.NET、Python、Ruby、Android、iOS など、さまざまなプログラミング言語や環境で使用できます。SDK は、リクエストへの暗号を使用した署名、必要に応じてリクエストの再試行、エラーレスポンスの処理などのタスクを処理します。また、[AWS Security Token Service API リファレンス](https://docs.aws.amazon.com/STS/latest/APIReference/) で説明されている AWS STS Query API を使用することもできます。最後に、AWS STS コマンドは [AWS Command Line Interface](https://aws.amazon.com/documentation/cli) および [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell) という 2 つのコマンドラインツールでサポートされています。
AWS STS API オペレーションは、アクセスキーペアやセキュリティトークンを含む一時的セキュリティ認証情報で新しいセッションを作成します。アクセスキーペアは、アクセスキー ID とシークレットキーで構成されます。ユーザー（またはユーザーが実行しているアプリケーション）はこれらの認証情報を使用して、リソースにアクセスできます。AWS STS API オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーとセッションタグを渡すことができます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーの詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
**注記**
AWS STS API オペレーションから返されるセッショントークンのサイズは固定ではありません。最大サイズを仮定しないことを強くお勧めします。一般的なトークンのサイズは 4096 バイト未満ですが、変化する可能性があります。
## AWS リージョンでの AWS STS の使用
AWS STS API 呼び出しは、グローバルエンドポイントにも、リージョンのエンドポイントの 1 つに対しても送信できます。より近くのエンドポイントを選択した場合、レイテンシーを軽減し、API 呼び出しのパフォーマンスが向上します。また、元のエンドポイントとの通信ができなくなった場合は、代替リージョンのエンドポイントに呼び出しを送信することもできます。各種 AWS SDK の 1 つを使用している場合、API コールを行う前に SDK メソッドを使用してリージョンを選択します。手動で HTTP API リクエストを組み立てる場合、独自で正しいエンドポイントにリクエストを送信する必要があります。詳細については、[*リージョンとエンドポイント*の「AWS STS 」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)および「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」 を参照してください。
AWS 環境およびアプリケーションで使用する一時的な認証情報の取得に使用できる API オペレーションを、次に示します。
## カスタム ID ブローカーを介したクロスアカウントの委任とフェデレーションの認証情報のリクエスト
この [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) API オペレーションは、既存の IAM ユーザーに、まだアクセスできない AWS リソースへのアクセスを許可する際に役立ちます。例えば、ユーザーが別の AWS アカウント のリソースにアクセスする必要がある場合があります。また、特権アクセスを一時的に得るための方法 ( 多要素認証 (MFA) など) としても役立ちます。アクティブなユーザーの認証情報を使用してこの API を呼び出す必要があります。誰がこの操作を呼び出すことができるのかについては、[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md) を参照してください。詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」および「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。
**カスタム ID ブローカーを通じてクロスアカウント委任とフェデレーションの一時的なセキュリティ認証情報をリクエストするには**
1. AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。
1. [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) 操作を呼び出します。
以下の例は、`AssumeRole` を使用したリクエストと応答のサンプルを示します。このサンプルリクエストは、含まれている[セッションポリシー](access_policies.md#policies_session)、[セッションタグ](id_session-tags.md)、[外部 ID](id_roles_common-scenarios_third-party.md)、および[ソース ID](id_credentials_temp_control-access_monitor.md) を使用して、指定された期間の `demo` ロールを引き受けます。結果のセッションには `John-session` という名前が付けられます。
**Example リクエスト例**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=John-session
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&ExternalId=123ABC
&SourceIdentity=DevUser123
&AUTHPARAMS
```
上記の例に示すポリシーの値は、次のポリシーの URL エンコードされたバージョンです。
------
#### [ JSON ]
****
```
{"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
```
------
この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、[Amazon Web Services 全般のリファレンス] の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。
一時的セキュリティ認証情報に加えて、レスポンスにはフェデレーティッドユーザーの Amazon リソースネーム（ARN）、および認証情報の有効期限が含まれています。
**Example レスポンスの例**
```
DevUser123
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2019-07-15T23:28:33.359Z
AKIAIOSFODNN7EXAMPLE
arn:aws:sts::123456789012:assumed-role/demo/John
ARO123EXAMPLE123:John
8
c6104cbe-af31-11e0-8154-cbc7ccf896c7
```
**注記**
AWS 変換では、渡されたセッションポリシーとセッションタグが、個別の制限を持つひとまとめのバイナリ形式に圧縮されます。プレーンテキストが他の要件を満たしていても、この制限ではリクエストが失敗する可能性があります。`PackedPolicySize` レスポンス要素は、リクエストのポリシーとタグがサイズ制限にどの程度近づいているかをパーセントで示します。
## OIDC プロバイダーを通じた認証情報のリクエスト
[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーションは、JSON ウェブトークン (JWT) と引き換えに一時的な AWS セキュリティ認証情報のセットを返します。これには、Login with Amazon、Facebook、Google などのパブリック ID プロバイダー、および GitHub アクションや Azure Devops などの OpenID Connect (OIDC) 検出と互換性のある JWTs を発行するプロバイダーが含まれます。詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
**注記**
`AssumeRoleWithWebIdentity` リクエストは で署名されていないため、AWS 認証情報は必要ありません。
**OIDC プロバイダーを通じた認証情報のリクエスト**
1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 操作を呼び出します。
を呼び出すと`AssumeRoleWithWebIdentity`、 は IdP の JSON ウェブキーセット (JWKS) で利用可能になったパブリックキーを使用してデジタル署名を検証することで、提示されたトークンAWSを検証します。トークンが有効で、IAM ロールの信頼ポリシーに規定されたすべての条件が満たされている場合、AWS は次の情報を返します。
+ 一時的なセキュリティ認証情報一式。一時的なセキュリティ認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。
+ 引き受けたロールのロール ID と ARN。
+ 一意のユーザー ID を含む `SubjectFromWebIdentityToken` 値。
1. アプリケーションは、レスポンスで返された一時的なセキュリティ認証情報を使用して AWS APIコールを行うことができます。これは、長期的なセキュリティ認証情報を使用して AWS API 呼び出しを行うのと同じ処理です。異なる点は、AWS で一時的なセキュリティ認証情報が有効であることを確認できる、セッショントークンを含める必要があることです。
アプリケーションは、AWS STS が返した認証情報をキャッシュし、必要に応じて更新する必要があります。アプリケーションが AWS SDK を使用して構築されている場合、SDK には、有効期限が切れる前に `AssumeRoleWithWebIdentity` の呼び出しと AWS 認証情報の更新を処理できる認証情報プロバイダーがあります。詳細については、「*AWS SDKs および ツールリファレンスガイド*」の「[AWS SDKs および Tools 標準化された認証情報プロバイダー](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html)」を参照してください。
## SAML 2.0 ID プロバイダーを通じた認証情報のリクエスト
[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API オペレーションでは、組織の既存の ID システムによって認証された SAML フェデレーティッドプリンシパルに一連の一時的なセキュリティ認証情報が返されます。また、ユーザーは [SAML](https://www.oasis-open.org/standards#samlv2.0)2.0 (Security Assertion Markup Language) を使用して AWS に認証および認可情報を渡す必要があります。この API オペレーションは、SAML アサーションを生成できるソフトウェアに認証システム (Windows Active Directory、OpenLDAP など) を統合している組織で役立ちます。このような統合はユーザー ID とアクセス許可に関する情報を提供します (Active Directory Federation Services や Shibboleth など)。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) 操作を呼び出します。
これは署名なしの呼び出しです。つまり、リクエストを実行する前に AWS セキュリティ認証情報を認証する必要はありません。
**注記**
`AssumeRoleWithSAML` に対する呼び出しは署名 (暗号化) されていません。そのため、信頼されている経路を通じてリクエストが送信される場合のみ、オプションのセッションポリシーを含める必要があります。そうでない場合、他のユーザーが制限を削除するようにポリシーを変更できます。
1. `AssumeRoleWithSAML` を呼び出すときに、AWS は SAML アサーションの信頼性を確認します。ID プロバイダーがアサーションを確認した場合、AWS は次の情報を返します。
+ 一時的なセキュリティ認証情報一式。一時的なセキュリティ認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。
+ 引き受けたロールのロール ID と ARN。
+ SAML アサーションの `Audience` 要素の `Recipient` 属性値を含む `SubjectConfirmationData` 値。
+ SAML アサーションの `Issuer` 要素の値を含む `Issuer` 値。
+ `Issuer` 値、AWS アカウント ID、SAML プロバイダーのフレンドリ名から構築されたハッシュ値を含む `NameQualifier` 要素。`Subject` 要素と組み合わせると、SAML フェデレーティッドプリンシパルを一意に特定できます。
+ SAML アサーションの `Subject` 要素内の `NameID` 要素の値を含む `Subject` 要素。
+ `SubjectType` 要素の形式を示す `Subject` 要素。値は、`persistent`、`transient`、または SAML アサーションで使用されている `Format` および `Subject` 要素の完全な `NameID` URI とすることができます。`NameID` 要素の `Format` 属性の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。
1. レスポンスで返された一時的なセキュリティ認証情報を使用して AWS API コールを実行します。これは、長期的なセキュリティ認証情報を使用して AWS API 呼び出しを行うのと同じ処理です。異なる点は、AWS で一時的なセキュリティ認証情報が有効であることを確認できる、セッショントークンを含める必要があることです。
アプリで認証情報をキャッシュする必要があります。認証情報はデフォルトで 1 時間後に無効になります。[ SDK の ](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios)AmazonSTSCredentialsProviderAWS アクションを使用していない場合、再度 `AssumeRoleWithSAML` を呼び出すかどうかはお客様およびお客様のアプリによります。古い認証情報が失効する前に、このオペレーションを呼び出して新しい一時的なセキュリティ認証情報を取得します。
## カスタム ID ブローカーを通じた認証情報のリクエスト
[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API オペレーションでは、AWS STS フェデレーションユーザーのプリンシパルに一連の一時的なセキュリティ認証情報が返されます。この API は、デフォルトの有効期限が大幅に長い (1 時間ではなく 12 時間) という点で `AssumeRole` とは異なります。また、`DurationSeconds` パラメータを使用して、一時的なセキュリティ認証情報が有効である期間を選択することもできます。結果として得られる認証情報は、900 秒 (15 分) から 129,600 秒 (36 時間) までの指定された期間内で有効です。有効期限を長くすると、新しい認証情報を頻繁に取得する必要がなくなるため、AWS への呼び出し回数を減少させることができます。
1. 特定の IAM ユーザーの AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。
1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 操作を呼び出します。
`GetFederationToken` 呼び出しは、セッショントークン、アクセスキー、シークレットキー、失効情報で構成される一時的セキュリティ認証情報を返します。組織内でアクセス権限を管理する (たとえば、プロキシアプリケーションを使用してアクセス権限を割り当てる) 場合、`GetFederationToken` を使用できます。
以下の例に、`GetFederationToken` を使用したリクエストと応答のサンプルを示します。このリクエスト例では、指定された期間の呼び出し元ユーザーを[セッションポリシー](access_policies.md#policies_session) ARN および[セッションタグ](id_session-tags.md)とフェデレートします。結果のセッションには `Jane-session` という名前が付けられます。
**Example リクエスト例**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jane-session
&PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&AUTHPARAMS
```
前述の例に示すポリシー ARN には、次の URL エンコードされた ARN が含まれています。
`arn:aws:iam::123456789012:policy/Role1policy`
また、例の `&AUTHPARAMS` パラメータは、認証情報のプレースホルダーとして使用されることに注意してください。これは、*署名*であり、AWS HTTP API リクエストに含める必要があります。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、「Amazon Web Services 全般のリファレンス」の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。
一時的セキュリティ認証情報に加えて、レスポンスにはフェデレーティッドユーザーの Amazon リソースネーム（ARN）、および認証情報の有効期限が含まれています。
**Example レスポンスの例**
```
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2019-04-15T23:28:33.359Z
AKIAIOSFODNN7EXAMPLE;
arn:aws:sts::123456789012:federated-user/Jean
123456789012:Jean
4
c6104cbe-af31-11e0-8154-cbc7ccf896c7
```
**注記**
AWS 変換では、渡されたセッションポリシーとセッションタグが、個別の制限を持つひとまとめのバイナリ形式に圧縮されます。プレーンテキストが他の要件を満たしていても、この制限ではリクエストが失敗する可能性があります。`PackedPolicySize` レスポンス要素は、リクエストのポリシーとタグがサイズ制限にどの程度近づいているかをパーセントで示します。
AWS ではリソースレベルでアクセス許可を付与する（たとえば、Amazon S3 バケットにリソースベースのポリシーをアタッチする）ことを推奨しています。`Policy` パラメータは省略できます。ただし、AWS STS フェデレーションユーザーのプリンシパルにポリシーを含まない場合、一時的なセキュリティ認証情報によってアクセス権限が付与されません。この場合、リソースポリシーを使用してフェデレーティッドユーザーに AWS リソースへのアクセスを許可する*必要があります*。
例えば、AWS アカウント 番号が 111122223333 であり、Susan にアクセスを許可しようとしている Amazon S3 バケットがあるとします。Susan の一時的セキュリティ認証情報にはバケットのポリシーが含まれていません。この場合、Susan の ARN (`arn:aws:sts::111122223333:federated-user/Susan` など) と一致する ARN があるポリシーがバケットにあるようにする必要があります。
## 信頼されていない環境でのユーザーの認証情報のリクエスト
この [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) API オペレーションでは、既存の IAM ユーザーに一時的セキュリティ認証情報のセットが返ります。この API は、MFA が IAM ユーザーに対して有効なときに AWS リクエストを作成するなど、セキュリティを強化するために役立ちます。認証情報は一時的なものであるため、安全性の低い環境からリソースにアクセスする IAM ユーザーがいる場合、これによりセキュリティが強化されます。安全性の低い環境の例には、モバイルデバイスやウェブブラウザが含まれます。
1. 特定の IAM ユーザーの AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。
1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 操作を呼び出します。
1. `GetSessionToken` は、セッショントークン、アクセスキー ID、およびシークレットアクセスキーから構成される一時的なセキュリティ認証情報を返します。
デフォルトでは、IAM ユーザーの一時的なセキュリティ認証情報は、最大 12 時間有効です。ただし、`DurationSeconds` パラメータを使用して最短 15 分、最長 36 時間の有効期間をリクエストできます。セキュリティ上の理由から、AWS アカウントのルートユーザー のトークンは有効期間が 1 時間に制限されます。
以下の例は、`GetSessionToken` を使用したリクエストと応答のサンプルを示します。レスポンスには、一時的なセキュリティ認証情報の有効期限も含んでいます。
**Example リクエスト例**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=1800
&AUTHPARAMS
```
この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、「*Amazon Web Services 全般のリファレンス*」の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。
**Example レスポンスの例**
```
AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2011-07-11T19:55:29.611Z
AKIAIOSFODNN7EXAMPLE
58c5dbae-abef-11e0-8cfe-09039844ac7d
```
オプションで、`GetSessionToken` リクエストに、AWS の多要素認証 (MFA) で確認する `SerialNumber` および `TokenCode` 値を含めることができます。指定された値が有効であれば、AWS STS は、MFA 認証の状態を含む一時的なセキュリティ認証情報を提供します。この一時的セキュリティ認証情報を使用して、MFA で保護された API オペレーションまたは AWS ウェブサイトに、MFA 認証が有効である限りアクセスできます。
以下の例は、MFA 認証コードとデバイスのシリアルナンバーを含む `GetSessionToken` リクエストを示しています。
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=7200
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
```
**注記**
AWS STS の呼び出しは、グローバルエンドポイントまたは AWS アカウント をアクティブ化しているリージョンのエンドポイントに対して行えます。詳細については、[*リージョンとエンドポイント*の「AWS STS」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)を参照してください。
この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、[Amazon Web Services 全般のリファレンス] の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。
# AWS リソースで一時的な認証情報を使用する
一時的な認証情報を使用して、AWS または AWS CLI API（[AWS SDK](https://aws.amazon.com/tools/)を使用）を使用して AWS リソースのプログラム要求を行うことができます。一時的な認証情報は、IAM ユーザーの認証情報など、長期的なセキュリティ認証情報を使用するのと同じアクセス許可を提供します。ただし、いくつか違いがあります。
+ 一時的セキュリティ認証情報を使用して呼び出しを行うときは、一時的な認証情報と共に返されるセッショントークンを呼び出しに含める必要があります。AWS はセッショントークンを使用して、一時的セキュリティ認証情報を検証します。
+ 一時的な認証情報は、指定した期間が過ぎると失効します。一時認証情報が有効期限切れになると、その認証情報を使用する呼び出しはすべて失敗するため、新しい一時認証情報を生成する必要があります。一時的な認証情報は、最初に指定された間隔を超えて延長または更新することはできません。
+ 一時的な認証情報を使用してリクエストを行う場合、プリンシパルに一連のタグが含まれる場合があります。これらのタグは、引き受けるロールにアタッチされたセッションタグとタグから取得されます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
[AWS SDK ](https://aws.amazon.com/tools)、[AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) または [Tools for Windows PowerShell](https://aws.amazon.com/powershell) を使用している場合、一時的なセキュリティ認証情報を取得および使用する方法はコンテキストによって異なります。コード、AWS CLI、または Tools for Windows PowerShell コマンドを EC2 インスタンス内で実行している場合は、Amazon EC2 のロールを利用できます。それ以外の場合は、[AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/) を呼び出して一時的な認証情報を取得した後、その情報を明示的に使用して AWS のサービスを呼び出すことができます。
**注記**
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。AWS STS の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。AWS STS は、デフォルトのエンドポイントが `https://sts.amazonaws.com` にあるグローバルサービスです。このエンドポイントや他のエンドポイントから取得した認証情報はグローバルに有効ですが、このエンドポイントは米国東部 (バージニア北部) リージョンにあります。これらの認証情報は、どのリージョンのサービスとリソースでも機能します。サポートされているリージョンのいずれかにあるエンドポイントへの AWS STS API 呼び出しを実行することもできます。地理的に近い場所にあるリージョンのサーバーに対してリクエストを実行することによって、レイテンシーを低減できます。認証情報を取得したリージョンに関係なく、認証情報はグローバルに使用できます。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。
**Contents**
+ [Amazon EC2 インスタンスでの一時的な認証情報の使用](#using-temp-creds-sdk-ec2-instances)
+ [AWS SDK での一時的セキュリティ認証情報の使用](#using-temp-creds-sdk)
+ [AWS CLI で一時的なセキュリティ認証情報を使用する](#using-temp-creds-sdk-cli)
+ [API オペレーションで一時的なセキュリティ認証情報を使用する](#RequestWithSTS)
+ [詳細情報](#using-temp-creds-more-info)
## Amazon EC2 インスタンスでの一時的な認証情報の使用
AWS CLI コマンドまたはコードを EC2 インスタンス内で実行する場合、認証情報を取得するために推奨される方法は、[Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) のロールを使用する方法です。つまり、EC2 インスタンスで実行されているアプリケーションに付与するアクセス許可を指定する IAM ロールを作成します。インスタンスを起動するときに、このロールとインスタンスを関連付けます。
これにより、インスタンスで実行されるアプリケーション、AWS CLI、Tools for Windows PowerShell コマンドがインスタンスメタデータから自動的に一時的セキュリティ認証情報を取得できるようになります。一時的なセキュリティ認証情報を明示的に取得する必要はありません。AWS SDK、AWS CLI、および Tools for Windows PowerShell は EC2 インスタンスメタデータサービス (IMDS) から認証情報を自動的に取得して使用します。一時的なセキュリティ認証情報には、インスタンスに関連付けられたロールに定義されているアクセス権限が付与されます。
詳細情報および例については、次のセクションを参照してください。
+ [IAM ロールを使用した Amazon Elastic Compute Cloud の AWS リソースへのアクセスの許可](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK for Java
+ [IAM ロールを使用したアクセスの許可](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK for .NET
+ [ロールの作成](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) — AWS SDK for Ruby
## AWS SDK での一時的セキュリティ認証情報の使用
コード内で一時的なセキュリティ認証情報を使用するには、`AssumeRole` などの AWS STS API をプログラムから呼び出し、結果として得られる認証情報とセッショントークンを抽出します。その後、これらの値を AWS への後続の呼び出しの認証情報として使用します。以下の例は、AWS SDK を使用している場合に、一時的なセキュリティ認証情報を使用する方法を示す疑似コードです。
```
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
assumeRoleResult.AccessKeyId,
assumeRoleResult.SecretAccessKey,
assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
```
Python で記述された例（[AWS SDK for Python (Boto)](https://aws.amazon.com/sdk-for-python/) を使用）については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。この例では、`AssumeRole` を呼び出して一時的なセキュリティ認証情報を取得し、それらの認証情報を使用して Amazon S3 を呼び出します。
`AssumeRole`、`GetFederationToken`、およびその他の API オペレーションを呼び出す方法の詳細については、「[AWS Security Token Service API リファリファレンス](https://docs.aws.amazon.com/STS/latest/APIReference/)」を参照してください。結果から一時的なセキュリティ認証情報とセッショントークンを取得する方法の詳細については、お使いの SDK のドキュメントを参照してください。すべての AWS SDK に関するドキュメントは、主要な [AWS のドキュメントページ](https://aws.amazon.com/documentation)の「**SDK とツールキット**」セクションにあります。
古い認証情報が失効する前に、新しい認証情報を取得する必要があります。一部の SDK では、ユーザーの代わりに認証情報の更新処理を管理するプロバイダーを使用できます。お使いの SDK のドキュメントを確認してください。
## AWS CLI で一時的なセキュリティ認証情報を使用する
AWS CLI で一時的なセキュリティ認証情報を使用できます。これは、ポリシーをテストする場合に便利です。
[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/) を使用して、[AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/) (`AssumeRole` や `GetFederationToken` など) を呼び出し、結果の出力をキャプチャします。次の例は、出力をファイルに送信する `AssumeRole` の呼び出しを示しています。この例では、`profile` パラメータは AWS CLI 設定ファイル内のプロファイルであると想定されています。また、ロールを引き受けるアクセス許可を持つ IAM ユーザーの認証情報を参照することも想定されます。
```
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt
```
コマンドが完了したら、ルーティングした場所からアクセスキー ID、シークレットアクセスキー、セッショントークンを抽出できます。この操作は、手動またはスクリプトを使用して行うことができます。次に、これらの値を環境変数に割り当てます。
AWS CLI コマンドを実行すると、AWS CLI によって特定の順序で資格情報が検索されます。最初は環境変数で、次に構成ファイルで検索されます。したがって、一時的な認証情報を環境変数に設定すると、AWS CLI でこれらの認証情報がデフォルトで使用されます （コマンドで `profile` パラメーターを指定すると、AWS CLI は環境変数をスキップします。代わりに、AWS CLI は構成ファイルを調べます。これにより、必要に応じて環境変数の資格情報をオーバーライドできます。）
以下の例では、環境変数に一時的なセキュリティ認証情報を設定した後で AWS CLI コマンドを呼び出しています。AWS CLI コマンドには `profile` パラメータが指定されていないため、AWS CLI で最初に環境変数内で認証情報が検索されます。その結果、一時的な認証情報が使用されます。
**Linux**
```
$ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ export AWS_SESSION_TOKEN=AQoDYXdzEJr...
$ aws ec2 describe-instances --region us-west-1
```
**Windows**
```
C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr...
C:\> aws ec2 describe-instances --region us-west-1
```
## API オペレーションで一時的なセキュリティ認証情報を使用する
AWS に対する直接 HTTPS API リクエストを行う場合、AWS Security Token Service (AWS STS) から取得した一時的セキュリティ認証情報でそれらのリクエストを署名できます。これを行うには AWS STS から受け取るアクセスキー ID とシークレットアクセスキーを使用します。長期的な認証情報を使用してリクエストに署名するのと同じ方法で、アクセスキー ID とシークレットアクセスキーを使用します。また、AWS STS から渡されるセッショントークンを API リクエストに追加します。セッショントークンは、HTTP ヘッダーに追加するか、`X-Amz-Security-Token` という名前のクエリ文字列パラメータに追加します。セッショントークンを追加するのは、HTTPヘッダー*または*クエリ文字列パラメータのいずれかです。両方には追加しません。HTTPS API リクエストの署名の詳細については、「AWS 全般のリファレンス」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)」を参照してください。
## 詳細情報
他の AWS のサービスで AWS STS を使用する方法の詳細については、以下のブログ記事を参照してください。
+ **Amazon S3**。「Amazon Simple Storage Service ユーザーガイド」の「[IAM ユーザー一時クレデンシャルを使用したリクエストの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html)」または「[フェデレーションユーザー一時クレデンシャルを使用したリクエストの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html)」を参照してください。
+ **Amazon SNS** 「Amazon Simple Notification Service デベロッパーガイド」の「[Amazon SNS でのアイデンティティベースのポリシーの使用](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS)」を参照してください。
+ **Amazon SQS** 「Amazon Simple Queue Service デベロッパーガイド」の「[Amazon SQS での Identity and access management](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS)」を参照してください。
+ **Amazon SimpleDB** 『[Amazon SimpleDB 開発者ガイド](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html)』の「*一時的なセキュリティクレデンシャルの使用*」を参照してください。
# 一時的なセキュリティ認証情報のアクセス許可
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](id_credentials_temp.md)AWS STS によって一時的なセキュリティ証明書が発行された後、それらの証明書は期限切れになるまで有効であり、取り消すことはできません。ただし、一時的なセキュリティ認証情報に割り当てられたアクセス権限は、認証情報を使用するリクエストがなされるたびに評価されるため、発行後にアクセス権を変更することで、認証情報を取り消すのと同等の効果を得ることができます。
以下のトピックでは、AWS のアクセス許可とポリシーに関する実用的な知識があることを前提としています。これらのトピックの詳細については、「[AWS リソースの アクセス管理](access.md)」を参照してください。
**Topics**
+ [AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限](id_credentials_temp_control-access_assumerole.md)
+ [引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)
+ [GetFederationToken のアクセス権限](id_credentials_temp_control-access_getfederationtoken.md)
+ [GetSessionToken のアクセス権限](id_credentials_temp_control-access_getsessiontoken.md)
+ [一時的なセキュリティ認証情報のアクセス権限を無効にする](id_credentials_temp_control-access_disable-perms.md)
+ [一時的なセキュリティ認証情報を作成するためのアクセス権限の付与](id_credentials_temp_control-access_enable-create.md)
+ [ID 拡張コンソールセッションを使用するための許可の付与](id_credentials_temp_control-access_sts-setcontext.md)
# AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限
引き受けるロールのアクセス許可ポリシーによって、`AssumeRole`、`AssumeRoleWithSAML`、および `AssumeRoleWithWebIdentity` によって返る一時的なセキュリティ認証情報のアクセス許可が決まります。これらのアクセス権限は、ロールを作成または更新するときに定義します。
必要に応じて、インラインまたはマネージド [セッションポリシー](access_policies.md#policies_session) を`AssumeRole`、`AssumeRoleWithSAML`、または `AssumeRoleWithWebIdentity` API オペレーションのパラメータとして渡すことができます。セッションポリシーは、ロールの一時的な認証情報セッションのアクセス許可を制限します。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。ロールの一時的な認証情報を以降の AWS API コールで使用し、ロールを所有するアカウント内のリソースにアクセスできます。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。AWS でロールの有効なアクセス許可を決定する方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
`AssumeRole` を最初に呼び出した認証情報にアタッチされたポリシーは、「許可」または「拒否」の認可決定を行うときに AWS によって評価されません。ユーザーは引き受けたロールによって割り当てられたアクセス権限に従って、元のアクセス権限を一時的に放棄します。`AssumeRoleWithSAML` および `AssumeRoleWithWebIdentity` API オペレーションの場合、API の呼び出し元が AWS ID ではないため、評価するポリシーはありません。
## 例: AssumeRole を使用してアクセス権限を割り当てる
`AssumeRole` API オペレーションをさまざまなポリシーと共に使用できます。ここにいくつか例を挙げます。
### ロールのアクセス許可ポリシー
この例では、オプションの `Policy` パラメータでセッションポリシーを指定せずに、`AssumeRole` API オペレーションを呼び出します。一時的な認証情報に割り当てられるアクセス許可は、引き受けるロールのアクセス許可ポリシーによって決まります。次のアクセス許可ポリシーの例では、`productionapp` という名前の S3 バケットに含まれるすべてのオブジェクトを一覧表示するアクセス許可をロールに付与します。また、このバケット内のオブジェクトを取得、格納、削除することもロールに許可します。
**Example ロールアクセス権限ポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### パラメータとして渡されたセッションポリシー
前の例と同じロールを引き受けることをユーザーに許可すると仮定します。ただし、この場合、オブジェクトを取得して `productionapp` S3 バケットに配置するためのアクセス許可のみをロールセッションに付与する必要があります。オブジェクトの削除は許可しません。これを実現する 1 つの方法が、新しいロールを作成し、そのロールのアクセス許可ポリシーで目的のアクセス許可を指定することです。もう 1 つの方法では、`AssumeRole` API を呼び出し、API オペレーションの一部としてオプションの `Policy` パラメータにセッションポリシーを含めます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。ロールセッションのアクセス許可の詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。
新しいセッションの一時的な認証情報を取得した後、それらのアクセス許可を付与するユーザーに取得した認証情報を渡すことができます。
たとえば、API 呼び出しのパラメータとして以下のポリシーを渡すとします。このセッションを使用するユーザーには、次のアクションのみを実行するアクセス許可が付与されています。
+ `productionapp` バケットのすべてのオブジェクトをリストします。
+ `productionapp` バケットのオブジェクトを取得し格納します。
次のセッションポリシーでは、`s3:DeleteObject` アクセス許可は除外され、引き受けたセッションに `s3:DeleteObject` アクセス許可は付与されません。このポリシーでは、ロールの既存のアクセス許可ポリシーが上書きされるように、ロールセッションのアクセス許可の上限を設定します。
**Example `AssumeRole` API コールで渡すセッションポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### リソースベースのポリシー
一部の AWS リソースはリソースベースのポリシーをサポートし、このポリシーは一時的なセキュリティ認証情報に影響するアクセス許可を定義する別の仕組みとして利用できます。リソースベースのポリシーをサポートしているのは、Amazon S3 バケット、Amazon SNS トピック、Amazon SQS キューなど、一部のリソースのみです。以下の例では、前の例を拡張して、`productionapp` という名前の S3 バケットを使用します。以下に挙げるポリシーが、バケットにアタッチされます。
`productionapp` バケットに以下のリソースベースのポリシーをアタッチすると、*すべての*ユーザーに対して、バケットからオブジェクトを削除するアクセス許可は拒否されます。(ポリシーの `Principal` 要素を参照してください。) ロールのアクセス許可ポリシーで `DeleteObject` アクセス許可が付与されていますが、これには引き受けたすべてのロールユーザーも含まれます。明示的な `Deny` ステートメントは `Allow` ステートメントより常に優先されます。
**Example バケットポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
AWS による複数のポリシータイプの組み合わせと評価の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
# 引き受けたロールで実行されるアクションのモニタリングと制御
[IAM ロール](id_roles.md)は、[アクセス許可](access_policies.md)が割り当てられている IAM 内のオブジェクトです。IAM IDまたは AWS の外部からのIDを使用して[そのロールを引き受ける](id_roles_manage-assume.md)と、ロールに割り当てられたアクセス許可を持つセッションを受け取ります。
AWS でアクションを実行すると、セッションに関する情報を AWS CloudTrail にログ記録して、アカウント管理者がモニタリングできるようになります。管理者は、AWS でアクションを実行する個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを設定できます。この ID 情報は、*ソース ID* として AWS CloudTrail に保存されます。管理者は CloudTrail のアクティビティを確認すると、ソース ID 情報を表示して、引き受けたロールセッションでアクションを実行したユーザーやアクションを判断できます。
ソースIDが設定されると、ロールセッション中に実行されるすべての AWS アクションの要求に存在します。設定された値は、ロールが AWS CLI または AWS APIを介して別のロールを引き受けるために使用される場合、[ロール連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。設定される値は、ロールセッション中に変更できません。管理者は、ソース ID の存在または値に基づいて詳細なアクセス許可を構成して、共有ロールで実行される AWS アクションをさらに制御できます。ソース ID 属性を使用できるかどうか、必須かどうか、どの値を使用できるかを決定できます。
ソース ID の使用方法は、ロールセッション名およびセッションタグとは重要な点で異なります。ソース ID 値は、設定後は変更できません。また、ロールセッションで実行される追加のアクションでも保持されます。セッションタグとロールセッション名の使用方法は次のとおりです。
+ **セッションタグ** – ロールを引き受けるとき、またはユーザーをフェデレートするときに セッションタグ を渡すこともできます。セッションタグは、ロールを引き受けるときに存在します。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。次に、CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
+ **ロールセッション名** – ロール信頼ポリシーで `sts:RoleSessionName` 条件キーを使用して、ユーザーがロールを引き受けるときに特定のセッション名を提供するように要求できます。ロールセッション名は、ロールが異なるプリンシパルによって使用される場合に、ロールセッションを区別するために使用できます。ロールセッション名の詳細については、「[sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。。
ロールを引き受ける ID を制御する場合は、ソース ID を使用することをお勧めします。ソースアイデンティティは、CloudTrail ログをマイニングして、アクションを実行するためにロールを使用したユーザーを特定する場合にも役立ちます。
**Topics**
+ [ソース ID を使用するための設定](#id_credentials_temp_control-access_monitor-setup)
+ [ソースアイデンティティについて知っておくべきこと](#id_credentials_temp_control-access_monitor-know)
+ [ソース ID を設定するために必要なアクセス許可](#id_credentials_temp_control-access_monitor-perms)
+ [ロールを引き受けるときのソース ID の指定](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [AssumeRole でのソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role)
+ [AssumeRoleWithSAML を使用したソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [AssumeRoleWithWebIdentity によるソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [ソース ID 情報を使用してアクセスを制御する](#id_credentials_temp_control-access_monitor-control-access)
+ [CloudTrail でのソースアイデンティティの表示](#id_credentials_temp_control-access_monitor-ct)
## ソース ID を使用するための設定
ソース ID を使用するように設定する方法は、ロールを引き受けるときに使用される方法によって異なります。例えば、IAMユーザーは、`AssumeRole` オペレーションを直接使用してロールを引き受ける場合があります。エンタープライズ ID (ワークフォースIDとも呼ばれる) がある場合、AWS を使用して `AssumeRoleWithSAML` リソースにアクセスする可能性があります。エンドユーザーがモバイルまたはWebアプリケーションにアクセスする場合、`AssumeRoleWithWebIdentity` を使用してアクセスする可能性があります。次に、既存の環境でソース ID 情報を利用するためのを設定する方法を理解するのに役立つ概要のワークフローの概要を示します。
1. **テストユーザーおよびロールの構成** — 運用前環境を使用して、テストユーザーおよびロールを構成し、ソースアイデンティティを設定できるようにポリシーを構成します。
フェデレーション ID に ID プロバイダー (IdP) を使用する場合は、アサーションまたはトークンでソース ID に選択したユーザー属性を渡すように IdP を設定します。
1. **ロールを引き受けるには** – ロールを想定し、テスト用に設定したユーザーとロールにソース ID を渡します。
1. **CloudTrail の確認** — CloudTrail ログでテストロールのソース ID 情報を確認します。
1. **ユーザーのトレーニング** — 運用前の環境でテストした後、必要に応じて、ソース ID 情報を渡す方法をユーザーが把握していることを確認します。本番環境でソース ID の提供をユーザーに要求する期限を設定します。
1. **本番ポリシーの設定**：本番環境のポリシーを構成し、本番ユーザーおよびロールに追加します。
1. **アクティビティのモニタリング**— CloudTrail ログを使用して、本番ロールのアクティビティをモニタリングします。
## ソースアイデンティティについて知っておくべきこと
ソース ID を使用する際には、次の点に注意してください。
+ ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。ロール信頼ポリシーでこのアクセス許可を持たないロールの場合、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用できます。その後、個別の IdP に接続されているロールにのみ `sts:SetSourceIdentity` アクセス許可を追加します。
+ アイデンティティーがソースアイデンティティを設定する場合、`sts:SourceIdentity` キーはリクエストに存在します。ロールセッション中に実行される後続のアクションでは、`aws:SourceIdentity` キーがリクエストに存在します。AWS は、`sts:SourceIdentity` または `aws:SourceIdentity` キーのソース ID の値を制御しません。ソース ID を要求する場合は、ユーザーまたは IdP に提供する属性を選択する必要があります。セキュリティ上の理由から、これらの値の提供方法を制御できることを確認する必要があります。
+ ソース ID の値は、2 〜 64 文字の長さである必要があり、英数字、アンダースコア、および 、**. , \$1 = @ -**(ハイフン) のみを含めることができます。テキスト **aws:** から開始するタグキーや値を作成することはできません。このプレフィックスは AWS の内部使用のために予約されています。
+ AWS サービスまたはサービスにリンクされたロールがフェデレーション ID またはワーカー ID に代わってアクションを実行する場合、ソース ID 情報は CloudTrail によってキャプチャされません。
**重要**
AWS マネジメントコンソール でロールを切り替えるには、ロールを引き受けるときにソース ID を設定する必要があります。このようなロールを引き受けるには、AWS CLI または AWS API を呼び出して `AssumeRole` オペレーションを実行し、ソース ID パラメーターを指定します。
## ソース ID を設定するために必要なアクセス許可
API オペレーションに一致するアクションに加えて、ポリシーには次のアクセス許可のみのアクションが必要です。
```
sts:SetSourceIdentity
```
+ ソース ID を指定するには、プリンシパル (IAM ユーザーとロール) に `sts:SetSourceIdentity` へのアクセス許可が必要です。管理者は、ロールの信頼ポリシーとプリンシパルのアクセス許可ポリシーでこれを設定できます。
+ 別のロールでロールを引き受ける場合、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれるアクセス許可 `sts:SetSourceIdentity` は、ロールを引き受けるプリンシパルのアクセス許可ポリシーと、ターゲットロールのロール信頼ポリシーの両方で必要です。そうしない場合、ロールの引き受け操作は失敗します。
+ ソース ID を使用している場合、ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。このアクセス許可なしで IdP に接続されているロールでは、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用し、`sts:SetSourceIdentity` アクセス許可は、個別の IdP に接続されているロールにのみ付与されます。
+ アカウントの境界を越えてソースIDを設定するには、2 箇所に `sts:SetSourceIdentity` アクセス許可を含める必要があります。これは、元のアカウントのプリンシパルのアクセス許可ポリシーと、ターゲットアカウントのロールのロール信頼ポリシーにある必要があります。例えば、ロールが[ロールの連鎖](id_roles.md#iam-term-role-chaining)を使用して別のアカウントでロールを引き受けるために使用される場合、これを行う必要がある場合があります。
アカウント管理者として、アカウントの IAM ユーザー`DevUser`が同じアカウントの `Developer_Role` を引き継ぐことを許可したいとします。ただし、ユーザーがソース ID を自分の IAM ユーザー名に設定している場合にのみ、このアクションを許可します。その場合、IAM ユーザーに以下のポリシーをアタッチできます。
**Example DevUser にアタッチされた ID ベースのポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
許容可能なソース ID 値を適用するには、次のロール信頼ポリシーを設定します。このポリシーは、IAM ユーザー `DevUser` にロールを引き受けてソースIDを設定するためのアクセス許可を与えます。`sts:SourceIdentity`条件キーは、許容可能なソース ID 値を定義します。
**Example ソース ID のロール信頼ポリシーの例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
ユーザーは、IAMユーザー `DevUser` の認証情報を使用して、次の `DeveloperRole` リクエストを使用して、AWS CLI を受け入れようとしています。
**Example AssumeRole CLI リクエストの例**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
AWS がリクエストを評価するとき、リクエストコンテキストには `sts:SourceIdentity` の `DevUser` が含まれます。
## ロールを引き受けるときのソース ID の指定
AWS STS `AssumeRole*` API操作の1つを使用してロールの一時的なセキュリティクレデンシャルを取得するときに、ソースIDを指定できます。使用する API オペレーションは、ユースケースによって異なります。例えば、IAMロールを使用して、IAMユーザーに通常はアクセスできない AWS リソースへのアクセスを許可する場合は、`AssumeRole` オペレーションを使用できます。エンタープライズ ID フェデレーションを使用してワークフォースユーザーを管理する場合は、この `AssumeRoleWithSAML` オペレーションを使用できます。OIDC フェデレーションを使用して、エンドユーザーがモバイルまたはウェブアプリケーションにアクセスできるようにする場合は、`AssumeRoleWithWebIdentity` オペレーションを使用できます。このセクションでは、オペレーションごとにソース ID を使用する方法について説明します。一時的な認証情報の一般的なシナリオの詳細については、「[一時的な認証情報の一般的なシナリオ](id_credentials_temp.md#sts-introduction)」を参照してください。。
## AssumeRole でのソース ID の使用
`AssumeRole` オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して `AssumeRole` を呼び出すことができます。ロールを引き受けるときにセッションタグを渡すには、`-–source-identity` AWS CLI オプションまたは `SourceIdentity` AWS API パラメータを使用します。次の例は、AWS CLI を使用してソースIDを指定する方法を示しています。
**Example AssumeRole CLI リクエストの例**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## AssumeRoleWithSAML を使用したソース ID の使用
`AssumeRoleWithSAML` オペレーションを呼び出すプリンシパルは、SAMLベースのフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。SAML ベースのフェデレーションを使用して AWS マネジメントコンソール にアクセスする方法の詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。AWS CLI または AWS API アクセスの詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。Active Directory ユーザーの SAML フェデレーションを設定するチュートリアルについては、AWS セキュリティブログの「[Active Directory フェデレーションサービスを使用した AWS フェデレーション認証 (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/)」を参照してください。
管理者は、企業ディレクトリのメンバーに AWS STS `AssumeRoleWithSAML` オペレーションを使用しての AWS フェデレーションを許可できます。これを行うには、以下のタスクを完了する必要があります。
1. [組織での SAML プロバイダーの構成](id_roles_providers_saml_3rd-party.md)。
1. [IAM で SAML プロバイダーを作成するには](id_roles_providers_create_saml.md)
1. [SAML フェデレーティッドプリンシパルにロールおよびアクセス許可を AWS で設定します。](id_roles_create_for-idp_saml.md)
1. [SAML IdP の設定を終了し、SAML 認証レスポンスのアサーションを作成する](id_roles_providers_create_saml_assertions.md)
ソース ID の SAML 属性を設定するには、`Attribute` 属性が `Name` に設定されている `https://aws.amazon.com/SAML/Attributes/SourceIdentity` 要素を含めます。`AttributeValue` 要素を使用して、ソース ID の値を指定します。例えば、次の ID 属性をソース ID として渡すとします。
`SourceIdentity:DiegoRamirez`
これらの属性を渡すには、SAML アサーションに以下の要素を含めます。
**Example SAML アサーションのスニペットの例**
```
DiegoRamirez
```
## AssumeRoleWithWebIdentity によるソース ID の使用
`AssumeRoleWithWebIdentity` オペレーションを呼び出すプリンシパルは、OpenID Connect (OIDC) 準拠のフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS マネジメントコンソール アクセスに OIDC フェデレーションを使用する方法の詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
OpenID Connect (OIDC) からソース ID を渡すには、JSON ウェブトークン (JWT) にソース ID を含める必要があります。`AssumeRoleWithWebIdentity` リクエストを送信するときに、トークンの `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` 名前空間にセッションタグを含めます。OIDC トークンとクレームの詳細については、「Amazon Cognito 開発者ガイド」の「[ユーザープールでのトークンの使用](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)」を参照してください。
例えば、次のデコードされた JWT は、`AssumeRoleWithWebIdentity` ソースIDで `Admin` を呼び出すために使用されるトークンです。
**Example デコードされた JSON ウェブトークンの例**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## ソース ID 情報を使用してアクセスを制御する
ソース ID が最初に設定されると、[sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity)キーがリクエストに存在します。ソース ID が設定されると、[aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)キーは、ロールセッション中に行われた後続のすべての要求に存在します。管理者は、ソース ID 属性の存在または値に基づいて AWS アクションを実行するための条件付き承認を付与するポリシーを作成できます。
開発者にソースIDを設定して、本番環境の重要な AWS リソースへの書き込み権限を持つ重要なロールを引き受けるようにリクエストするとします。また、AWS を使用してワークフォース ID への `AssumeRoleWithSAML` アクセスを許可するとします。上級開発者の Saanvi と Diego にロールへのアクセス権のみを与えるため、ロールに対して次の信頼ポリシーを作成します。
**Example ソース ID のロール信頼ポリシーの例 (SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
信頼ポリシーには、重要なロールを引き受けるために Saanvi または Diego のソース ID を必要とする、`sts:SourceIdentity` の条件が含まれています。
または、OIDC フェデレーションに OIDC プロバイダーを使用していて、`AssumeRoleWithWebIdentity` によってユーザーが認証される場合、信頼ポリシーは次のようになります。
**Example ソース ID のロール信頼ポリシーの例 (OIDC プロバイダー)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### ロールチェーンとクロスアカウント要件
`CriticalRole` を想定したユーザーが別のアカウントで `CriticalRole_2` を想定できるようにしたいとします。引き受けるために取得されたロールセッションの資格情報`CriticalRole`は、[ロールの連鎖](id_roles.md#iam-term-role-chaining)を 2 番目のロール、`CriticalRole_2`別のアカウントで。ロールは、アカウントの境界を越えて引き継がれています。したがって、`sts:SetSourceIdentity`のアクセス許可は、`CriticalRole` のアクセス許可ポリシーと`CriticalRole_2`のロール信頼ポリシーの両方で付与する必要があります。
**Example CriticalRoleのアクセス権限ポリシーの例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
アカウントの境界を越えてソースIDの設定を保護するために、次のロール信頼ポリシーは、`CriticalRole` のロールプリンシパルのみを信頼してソース ID を設定します。
**Example CriticalRole\$12 のロール信頼ポリシーの例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
ユーザーは、CriticalRole を引き受けることで取得したロールセッション資格情報を使用して、次の呼び出しを行います。ソース ID は、CriticalRole の仮定時に設定されているので、明示的に再度設定する必要はありません。ユーザーがソース ID を設定しようとした場合、`CriticalRole` が想定された場合、ロールの引き受けリクエストは拒否されます。
**Example AssumeRole CLI リクエストの例**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
呼び出し元プリンシパルがロールを引き受けると、リクエスト内のソース ID は、最初に引き受けたロールセッションから保持されます。したがって、`aws:SourceIdentity` キー と `sts:SourceIdentity` キーの両方がリクエストコンテキストに存在します
## CloudTrail でのソースアイデンティティの表示
CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。AWS でアクションを実行するための役割またはユーザーのリクエストを表示することもできます。CloudTrail ログファイルには、引き受けたロールまたはフェデレーティッドユーザーセッションのプリンシパルタグに関する情報が含まれます。詳細については、[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)を参照してください。
例えば、ユーザーが AWS STS `AssumeRole` リクエストを行い、ソースIDを設定するとします。`sourceIdentity` 情報は、CloudTrail ログの `requestParameters` キーで見つけることができます。
**Example AWS CloudTrail ログの requestParameters セクションの例**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
ユーザーが引き受けたロールセッションを使用してアクションを実行する場合、ソース ID 情報は `userIdentity` キーを CloudTrail ログに追加します。
**Example AWS CloudTrail ログの userIdentity キーの例**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
AWS STS CloudTrail ログの API イベントの例を見るには、「[CloudTrail ログの IAM API イベントの例](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api)」を参照してください。CloudTrail ログファイルに含まれる情報の詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) の「*CloudTrail イベントリファレンス*」を参照してください。
# GetFederationToken のアクセス権限
`GetFederationToken` オペレーションは、IAM ユーザーによって呼び出され、そのユーザーの一時的な認証情報を返します。このオペレーションでは、ユーザーを*フェデレーション*します。AWS STS フェデレーションユーザーが割り当てられたアクセス権限は、次の 2 ヶ所のいずれかで定義されます。
+ `GetFederationToken` API コールのパラメータとして渡されるセッションポリシー。（こちらが普通です)。
+ ポリシーの `Principal` 要素で AWS STS フェデレーションユーザーのセッションを明示的に指名するリソースベースのポリシー。(こちらはそれほど一般的ではありません)。
セッションポリシーは、一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。AWS STS フェデレーションユーザーのセッションを作成してセッションポリシーを渡すと、結果として得られるセッションのアクセス許可はユーザーのアイデンティティベースのポリシーおよびセッションポリシーの共通部分です。セッションポリシーを使用して、フェデレーションされているユーザーのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。
ほとんどの場合、`GetFederationToken` API 呼び出しでポリシーを渡さなければ、返される一時的なセキュリティ認証情報はアクセス権限を持ちません。ただし、リソースベースのポリシーでは、セッションに追加のアクセス許可を提供できます。セッションを許可されたプリンシパルとして指定するリソースベースのポリシーを使用してリソースにアクセスできます。
次の図は、ポリシーがどのように相互作用して、`GetFederationToken` の呼び出しによって返される一時的なセキュリティ認証情報のアクセス権限が決まるかを視覚的に示しています。
![\[IAM ユーザー次の図は、セッション許可がユーザーの ID ベースのポリシーとセッションポリシーで共通していることを示すチェックマークを示しています。セッション許可は、ユーザーの ID ベースのポリシーとリソースベースのポリシーで共通している場合もあります。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## 例: GetFederationToken を使用してアクセス権限を割り当てる
`GetFederationToken` API アクションをさまざまなポリシーと共に使用できます。ここにいくつか例を挙げます。
### ポリシーを IAM ユーザーにアタッチするには
この例では、2 つのバックエンドウェブサービスに頼ったブラウザベースのクライアントアプリケーションがあります。1 つのバックエンドサービスは、独自の ID システムを使用してクライアントアプリケーションを認証する独自の認証サーバーです。もう 1 つのバックエンドサービスは、クライアントアプリケーションの機能の一部を提供する AWS サービスです。クライアントアプリケーションはサーバーによって認証され、サーバーは適切なアクセス許可ポリシーを作成または取得します。サーバーは、続いて、`GetFederationToken` API を呼び出して一時的なセキュリティ認証情報を取得し、その認証情報をクライアントアプリケーションに返します。クライアントアプリケーションは、その後、一時的なセキュリティ認証情報を使って AWS サービスに対してリクエストを直接行うことができます。このアーキテクチャでは、AWS 長期的認証情報を埋め込まなくても、クライアントアプリケーションが AWS リクエストを実行できます。
認証サーバーは、`GetFederationToken` という名前の IAM ユーザーの長期的なセキュリティ認証情報を使用して `token-app` API を呼び出します。ただし、長期的な IAM ユーザー認証情報はサーバーにとどまり、決してクライアントには配布されません。次のポリシーの例は `token-app` IAM ユーザーにアタッチされ、AWS STS フェデレーションユーザー (クライアント) が必要とする最も広範囲なアクセス権限を定義します。AWS STS フェデレーションユーザーの一時的なセキュリティ認証情報を取得するには、認証サービスに `sts:GetFederationToken` アクセス許可が必要になることに注意してください。
**Example `token-app` を呼び出す IAMユーザー `GetFederationToken` にアタッチされたポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
前述のポリシーは、IAM ユーザーに複数のアクセス許可を付与します。ただし、このポリシーだけで AWS STS フェデレーションユーザーにアクセス許可が付与されることはありません。この IAM ユーザーが `GetFederationToken` を呼び出して、API コールのパラメータとしてポリシーを渡さない場合、結果として得られる AWS STS フェデレーションユーザーには有効なアクセス許可がありません。
### パラメータとして渡されたセッションポリシー
AWS STS フェデレーションユーザーに適切なアクセス許可を確実に割り当てる最も一般的な方法は、`GetFederationToken` API コールでセッションポリシーを渡すことです。前の例を拡張して、`GetFederationToken` が IAM ユーザー `token-app` の認証情報を使用して呼び出されると仮定します。次に、API 呼び出しのパラメータとして以下のセッションポリシーを渡すとします。結果として得られる AWS STS フェデレーションユーザーには、`productionapp` という名前の Amazon S3 バケットのコンテンツを一覧表示するアクセス許可があります。ユーザーは、`productionapp` バケット内の項目に対して Amazon S3 `GetObject`、`PutObject`、および `DeleteObject` アクションを実行できません。
アクセス許可は IAM ユーザーポリシーとユーザーが渡すセッションポリシーとの共通部分であるため、フェデレーティッドユーザーにはこれらのアクセス許可が割り当てられます。
AWS STS フェデレーションユーザーは、Amazon SNS、Amazon SQS、Amazon DynamoDB、`productionapp` を除くすべての S3 バケットでアクションを実行できませんでした。これらのアクションは、このアクセス許可が `GetFederationToken` コールに関連付けられている IAM ユーザーに付与されている場合でも拒否されます。
**Example `GetFederationToken` API 呼び出しのパラメータとして渡されるセッションポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### リソースベースのポリシー
一部の AWS リソースはリソースベースのポリシーをサポートし、これらのポリシーは AWS STS フェデレーションユーザーにアクセス許可を直接付与する別の仕組みを実現します。一部の AWS サービスのみでリソースに基づくポリシーをサポートしています。たとえば、Amazon S3 にはバケット、Amazon SNS にはトピック、Amazon SQS にはキューがあり、これらにポリシーをアタッチできます。リソースベースのポリシーをサポートするすべてのサービスのリストについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照の上、テーブルの「リソースベースのポリシー」列を確認してください。リソースベースのポリシーを使用し、AWS STS フェデレーションユーザーに直接アクセス許可を割り当てることができます。リソースベースのポリシーの `Principal` 要素で AWS STS フェデレーションユーザーの Amazon Resource Name (ARN) を指定します。以下の例では、これを表し、また `productionapp` という名前の S3 バケットを使用して前の例を拡張しています。
次のリソースベースのポリシーは、バケットにアタッチされています。このバケットポリシーでは、Carol という名前の AWS STS フェデレーションユーザーに対してバケットへのアクセスを許可します。以前に説明したポリシーの例が `token-app` IAM ユーザーにアタッチされると、Carol という名前の AWS STS フェデレーションユーザーは `productionapp` という名前のバケットに対し、`s3:GetObject`、`s3:PutObject`、`s3:DeleteObject` のアクションを実行するアクセス許可があります。これは、`GetFederationToken` API コールのパラメータとしてセッションポリシーが渡されていない場合にも当てはまります。この場合、Carol という名前の AWS STS フェデレーションユーザーは、次のリソースベースのポリシーによってアクセス権限が明示的に付与されているからです。
IAM ユーザー***と*** AWS STS フェデレーションユーザーの両方にアクセス許可が明示的に付与されている場合に限り、AWS STS フェデレーションユーザーにアクセス許可が付与されることについて覚えておきましょう。次の例のように、ポリシーの `Principal` 要素で AWS STS フェデレーションユーザーを明示的に指名するリソースベースのポリシーによって (アカウント内で) 付与することもできます。
**Example フェデレーティッドユーザーにアクセスを許可するバケットポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
ポリシーの評価方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
# GetSessionToken のアクセス権限
`GetSessionToken` API オペレーション、あるいは `get-session-token` CLI を呼び出す主な場面は、ユーザーを多要素認証 (MFA) で認証する必要がある場合です。MFA で認証されたユーザーが要求した場合にのみ、特定のアクションを許可するポリシーを作成することができます。MFA 認可チェックを正常に渡すには、ユーザーはまず `GetSessionToken` を呼び出し、オプションの `SerialNumber` および `TokenCode` パラメータを含める必要があります。ユーザーが MFA デバイスで正常に認証されている場合、`GetSessionToken` API オペレーションで返される認証情報には MFA コンテキストが含まれています。このコンテキストは、ユーザーが MFA で認証され、MFA 認証を必要とする API オペレーションへのアクセス権限があることを示します。
## GetSessionToken に必要なアクセス権限
ユーザーがセッショントークンを取得するために必要なアクセス権限はありません。`GetSessionToken` オペレーションの目的は、MFA を使用してユーザーを認証することです。認証オペレーションを制御するためにポリシーを使用することはできません。
ほとんどの AWS オペレーションを実行するためのアクセス権限を付与するには、ポリシーに同じ名前のアクションを追加します。たとえば、ユーザーを作成するには、`CreateUser` API オペレーション、`create-user` CLI コマンド、または AWS マネジメントコンソール を使用する必要があります。これらのオペレーションを実行するには、`CreateUser` アクションにアクセスできるポリシーを持っている必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
ポリシーに `GetSessionToken` アクションを含めることはできますが、これはユーザーが `GetSessionToken` オペレーションを実行する権限に影響を及ぼしません。
## GetSessionToken によるアクセス権限付与
`GetSessionToken` が IAM ユーザーの認証情報によって呼び出された場合、一時的なセキュリティ認証情報は IAM ユーザーと同じアクセス権限を持ちます。同様に、`GetSessionToken` が AWS アカウントのルートユーザー 認証情報によって呼び出された場合、一時的なセキュリティ認証情報は ルートユーザーのアクセス許可を持ちます。
**注記**
`GetSessionToken` は、ルートユーザー認証情報を使用して呼び出さないようお勧めします。代わりに、[ベストプラクティス](best-practices-use-cases.md)に従って、必要なアクセス許可を持つ IAM ユーザーを作成します。AWS との日常的なやり取りには、これらの IAM ユーザーを使用します。
`GetSessionToken` を呼び出すときに取得する一時的な認証情報には、次の機能と制限があります。
+ フェデレーションのシングルサインオンエンドポイント `https://signin.aws.amazon.com/federation` に認証情報を渡すことで AWS マネジメントコンソール にアクセスできます。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
+ 認証情報を使用して IAM または AWS STS API オペレーションを呼び出すことは**できません**。認証情報を使用してその他の ** サービスの API オペレーションを呼び出すことは**できますAWS。
[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md) で、この API オペレーションおよびその制限と機能を、一時的なセキュリティ認証情報を作成する他の API と比較してください。
`GetSessionToken` を使用した MFA 保護 API アクセスの詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。
# 一時的なセキュリティ認証情報のアクセス権限を無効にする
一時的なセキュリティ認証情報は、期限が切れるまで有効です。これらの認証情報は、900 秒 (15 分) から最大 129,600 秒 (36 時間) までの指定された期間有効です。デフォルトのセッション時間は 43,200 秒 (12 時間) です。これらの認証情報は取り消すことができますが、認証情報を漏洩させて悪意あるアカウントの活動に利用されないようにIAM ユーザーまたはロールのアクセス許可を変更する方法もあります。一時的なセキュリティ認証情報に割り当てられるアクセス許可は、AWS のリクエストの実行に使用されるたびに評価されます。認証情報からすべてのアクセス許可を削除すると、それらを使用している AWS のリクエストは失敗します。
ポリシーの更新が有効になるまでには、数分かかる場合があります。IAM ロール セッションの場合、ロールの一時的なセキュリティ認証情報を取り消し、ロールを引き受けるすべてのユーザーに新しい認証情報の再認証およびリクエストを強制します。詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)」を参照してください。
AWS アカウントのルートユーザー のアクセス許可を変更することはできません。同様に、ルートユーザーとしてサインインしているときに `GetFederationToken` または `GetSessionToken` を呼び出して作成した一時的セキュリティ認証情報のアクセス許可を変更することはできません。そのため、ルートユーザーとして `GetFederationToken` または `GetSessionToken` を呼び出さないようお勧めします。
IAM ユーザーのアクセス許可を変更する手順については、「[IAM ユーザーのアクセス許可を変更する](id_users_change-permissions.md)」を参照してください。
IAM ロールのアクセス許可を変更する手順については、「[ロールに対するアクセス許可を更新する](id_roles_update-role-permissions.md)」を参照してください。
**重要**
IAM アイデンティティセンターのアクセス許可セットから作成された IAM のロールを編集することはできません。IAM アイデンティティセンターでユーザーのアクティブなアクセス許可セットセッションを取り消す必要があります。詳細については、「IAM Identity Center ユーザーガイド」の「[Revoke active IAM role sessions created by permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)」を参照してください。
**Topics**
+ [ロールに関連するすべてのIAM ロールセッションに対するアクセスを拒否する](#deny-access-to-all-sessions)
+ [IAM ロールセッションへのアクセスを拒否する](#deny-access-to-specific-session)
+ [条件コンテキストキーを使用した一時的なセキュリティ認証情報セッションへのアクセスを拒否する](#deny-access-to-specific-session-condition-key)
+ [リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する](#deny-access-with-resource-based)
## ロールに関連するすべてのIAM ロールセッションに対するアクセスを拒否する
この手順は、ロールに関連付けられた**すべての** IAM ロールセッションに対するアクセス許可を拒否します。次のような不審なアクセスが懸念される場合は、この方法を使用します。
+ クロスアカウントアクセスを使用している別のアカウントのプリンシパル
+ アカウント内の AWS リソースへのアクセス許可を持つ外部ユーザー ID
+ OIDC プロバイダーを使用して、モバイルまたはウェブアプリケーションで認証されているユーザー
`AssumeRole`、`AssumeRoleWithSAML`、または `AssumeRoleWithWebIdentity`、`GetFederationToken`、または `GetSessionToken` を呼び出して取得した一時的なセキュリティ認証情報に割り当てたアクセス許可を変更または削除するには、ロールのアクセス許可を定義する ID ベースのポリシーを編集または削除します。
**重要**
また、プリンシパルのアクセスを許可するリソースベースのポリシーがある場合、そのリソースに対する明示的な拒否を追加する必要があります。詳細については、「[リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する](#deny-access-with-resource-based)」を参照してください。
**ロールに関連する**すべて**の IAM ロールセッションへのアクセスを拒否する**
1. AWS マネジメントコンソール にサインインし、IAM コンソール を開きます。
1. ナビゲーションペインで **[ロール]** を選択します。
1. 編集するロールの名前を選択します。検索ボックスを使用してリストをフィルタリングします。
1. **[アクセス許可]** タブを選択します。
1. 編集する関連ポリシーを選択します。カスタマー管理ポリシーを編集する前に、**[エンティティアタッチ]** タブを確認して、同じポリシーがアタッチされている可能性のある他のアイデンティティへのアクセスを中断しないようにします。
1. **[JSON]** タブを選択してポリシーを更新し、すべてのリソースとアクションを拒否します。
**注記**
これらのアクセス許可は、AWS 管理ポリシー [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) のアクセス許可と同じです。この AWS 管理ポリシーは、すべてのアクセスを拒否する IAM ユーザーまたはロールにアタッチできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. **[確認]** ページで、ポリシーの **[概要]** を確認してから、**[変更の保存]** を選択して作業を保存します。
ロールのポリシーを更新すると、変更内容はそのロールに関連付けられているすべての一時的なセキュリティ認証情報のアクセス許可に影響します。これには、ロールのアクセス許可ポリシーを変更する前に発行された認証情報も含まれます。
ポリシーを更新すると、[ロールの一時的なセキュリティ認証情報を取り消し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)、ロールが発行した認証情報に対するすべてのアクセス許可をすぐに取り消すことができます。
## IAM ロールセッションへのアクセスを拒否する
IAM ロールをすべて拒否ポリシーで更新したり、ロールを完全に削除したりすると、そのロールにアクセスできるすべてのユーザーのアクセスが中断されます。ロールに関連付けられている他のすべてのセッションのアクセス許可に影響を与えずに、アクセスを拒否できます。
`Principal` は、[条件コンテキストキー](#deny-access-to-specific-session-condition-key)または[リソースベースのポリシー](#deny-access-with-resource-based)を使用してアクセス許可を拒否できます。
**ヒント**
AWS CloudTrail ログを使用して、フェデレーションユーザーの ARN を確認できます。詳細については、「[AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/)」を参照してください。
## 条件コンテキストキーを使用した一時的なセキュリティ認証情報セッションへのアクセスを拒否する
認証情報を作成した IAM ユーザーまたはロールのアクセス許可に影響を与えることなく、特定の一時的なセキュリティ認証情報へのアクセスを拒否したい場合は、アイデンティティベースのポリシーで条件コンテキスト キーを使用できます。IAM ロールの場合、ポリシーの更新後は、[ロールの一時的なセキュリティ認証情報を取り消し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)、すべての発行された認証情報をすぐに取り消すこともできます。
条件コンテキストキーの詳細については、「[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md)」を参照してください。
### aws:PrincipalArn
ID ベースのポリシーで条件コンテキストキー [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) を使用して、Amazon リソースネーム (ARN) による特定のプリンシパルへのアクセスを拒否できます。これを行うには、ポリシーの Condition 要素で、一時的なセキュリティ認証情報が関連付けられている IAM ユーザー、ロール、または AWS STS フェデレーションユーザーセッションの ARN を指定します。
**ARN による特定のプリンシパルへのアクセスを拒否するには**
1. IAM コンソールのナビゲーションペインで、**[ユーザー]** または**[ロール]** を選択します。
1. 編集する IAM ユーザーまたはロールの名前を選択します。検索ボックスを使用してリストをフィルタリングします。
1. **[アクセス許可]** タブを選択します。
1. 編集する関連ポリシーを選択します。カスタマー管理ポリシーを編集する前に、**[エンティティアタッチ]** タブを確認して、同じポリシーがアタッチされている可能性のある他のアイデンティティへのアクセスを中断しないようにします。
1. **[JSON]** タブを選択し、次の例に示すようにプリンシパル ARN の拒否ステートメントを追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. **[確認]** ページで、ポリシーの **[概要]** を確認してから、**[変更の保存]** を選択して作業を保存します。
### aws:SourceIdentity
ID ベースのポリシーで条件コンテキストキー [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) を使用すると、IAM ロールセッションに関連付けられている特定のソース ID へのアクセスを拒否できます。これは、プリンシパルが任意の AWS STS `assume-role`\$1 CLI コマンドまたは AWS STS `AssumeRole`\$1 API オペレーションを使用してロールを引き受けるときに、`SourceIdentity` リクエストパラメータを設定することでロールセッションを発行したのであれば、必ず適用されます。このためには、一時的なセキュリティ認証情報が関連付けられているソース ID をポリシーの `Condition` 要素に指定します。
コンテキストキー [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname) とは異なり、ソース ID を設定した後は、値を変更できません。`aws:SourceIdentity` キーは、ロールが実行するすべてのアクションのリクエストコンテキストに存在します。セッション認証情報を使用して別のロールを引き受けた場合、ソース ID は後続のロールセッションに引き継がれます。別のロールからあるロールを引き受けると、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。
次のポリシーは、条件コンテキストキー `aws:SourceIdentity` を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。ロールセッションに関連付けられたソース ID を指定した場合、認証情報を作成したロールのアクセス許可に影響を与えることなく、その指定されたソース ID に関連付けられたロールセッションが拒否されます。この例の場合、ロールセッションの発行時にプリンシパルによって設定されたソース ID は `nikki_wolf@example.com` です。ポリシーの Condition にソース ID が含まれ、ポリシーの Effect が `Deny` に設定されているため、`nikki_wolf@example.com` ソース ID とのロールセッションで行われるリクエストは拒否されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
ID ベースのポリシーで条件コンテキストキー [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) を使用して、IAM ユーザーまたはロールに関連する一時的なセキュリティ認証情報のすべてまたは特定のセッションへのアクセスを拒否できます。これを行うには、一時的なセキュリティ認証情報がポリシーの `Condition` 要素に関連付けられている IAM ユーザー、ロール、または AWS STS フェデレーションユーザーの一意の識別子 (ID) を指定します。
次のポリシーは、条件コンテキストキー `aws:userid` を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。
+ `AIDAXUSER1` は、IAM ユーザー用の一意の ID を表します。コンテキストキー `aws:userid` の値として IAM ユーザーの一意の ID を指定すると、IAM ユーザーへのアクセスが拒否されます。これには、 `GetSessionToken` API を呼び出して作成された一時的なセキュリティ認証情報セッションが含まれます。
+ `AROAXROLE1:*` は、IAM ロールに関連付けられたすべてのセッションの一意の ID を表します。コンテキストキー `aws:userid` の値として、caller-specified-role-session-name の部分に IAM ロールの一意の ID とワイルドカード (\$1) 文字を指定すると、ロールに関連付けられたすべてのセッションが拒否されます。
+ `AROAXROLE2:` は、assumed-role セッション用の一意の ID を表します。assumed-role の一意の ID の caller-specified-role-session-name の部分で、ロールのセッション名を指定するか、StringLike 条件演算子を使用する場合はワイルドカード文字を指定できます。ロールのセッション名を指定すると、認証情報を作成したロールのアクセス許可に影響を与えずに、指定されたロールのセッションが拒否されます。ロールのセッション名にワイルドカード文字を指定すると、そのロールに関連するすべてのセッションが拒否されます。
**注記**
呼び出し側で指定したロールセッション名 (引き受けたロールセッションの一意の識別子の一部) は、ロールの連鎖の際に変更できます。ロールの連鎖は、あるロールが別のロールを引き受けると発生します。ロールセッション名は、プリンシパルが AWS STS `AssumeRole` API オペレーションを使用してロールを引き受けるときに、`RoleSessionName` リクエストパラメータを使用して設定します。
+ `account-id:` は、AWS STS フェデレーションユーザーのセッション用の一意の ID を表します。IAM ユーザーは `GetFederationToken` API を呼び出してこのセッションを作成します。AWS STS フェデレーションユーザーのセッションに一意の ID を指定すると、認証情報を作成した IAM ユーザーのアクセス許可に影響を与えることなく、指名されたフェデレーティッドセッションが拒否されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
プリンシパルキーの値の具体的な例については、「[プリンシパルキーの値](reference_policies_variables.md#principaltable)」を参照してください。IAM 一意の ID とその取得方法については、「[一意の識別子](reference_identifiers.md#identifiers-unique-ids)」を参照してください。
## リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する
リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを制限するには、 `Condition` 要素で条件コンテキストキー [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) または [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) を使用できます。リソースベースのポリシーは、リソースにアタッチされたアクセス許可ポリシーであり、リソースにアクセスできるユーザーとそのリソースに対して実行できるアクションを制御します。
`aws:PrincipalARN` コンテキストキーを使用する場合は、ポリシーの Condition 要素で一時的なセキュリティ認証情報に関連付けられた IAM ユーザー、ロール、または AWS STS フェデレーティッドユーザーセッションの ARN を指定します。次のポリシー例は、リソースベースのポリシーで `aws:PrincipalARN` コンテキストキーを使用する方法を示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
`aws:SourceIdentity` コンテキストキーを使用する場合は、ポリシーの `Condition` 要素でロールの一時的なセキュリティ認証情報に関連付けられたソース ID 値を指定します。これは、プリンシパルが任意の AWS STS `assume-role`\$1 CLI コマンドまたは AWS STS `AssumeRole`\$1 API オペレーションを使用してロールを引き受けるときに、`SourceIdentity` リクエストパラメータを設定することでロールセッションを発行したのであれば、必ず適用されます。次の例は、リソースベースのポリシーで `aws:SourceIdentity` コンテキストキーを使用する方法を示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
プリンシパルの ID ベースのポリシーのみを更新しても、リソースベースのポリシーで許可されるアクションを実行できます。ただし、これらのアクションが ID ベースのポリシーで明示的に拒否されている場合を除きます。
**リソースベースのポリシーで特定のプリンシパルへのアクセスを拒否するには**
1. サービスがリソースベースのポリシーをサポートしているかどうかについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を確認してください。
1. AWS マネジメントコンソール にサインインして、サービスのコンソールを開きます。ポリシーをアタッチするコンソール内の場所は、サービスごとに異なります。
1. リソースベースのポリシーを編集します。拒否ポリシー ステートメントを追加して、認証情報の識別する情報を指定します。
1. `Principal` 要素にワイルドカード (\$1) を入力します。プリンシパルは `Condition` 要素で制限されます。
1. `Effect` 要素に「Deny」と入力します。
1. `Action` に、サービスの名前空間と拒否するアクションの名前を入力します。すべてのアクションを拒否するには、ワイルドカード (\$1) 文字を使用します。例: `"s3:*"`。
1. `Resource` 要素に、ターゲットリソースの ARN を入力します。例: `"arn:aws:s3:::amzn-s3-demo-bucket"`。
1. `Condition` 要素で、 `aws:PrincipalARN` または `aws:SourceIdentity` コンテキストキーを指定します。
`aws:PrincipalARN` コンテキストキーを使用する場合は、アクセスを拒否するプリンシパルの ARN を入力します。
`aws:SourceIdentity` コンテキストキーを使用する場合は、ロールセッションで設定されたソース ID 値を入力してアクセスを拒否します。
1. 作業内容を保存します。
# 一時的なセキュリティ認証情報を作成するためのアクセス権限の付与
デフォルトで、IAM ユーザーには AWS STS フェデレーションユーザーおよびロールに一時的なセキュリティ認証情報を作成するアクセス許可がありません。ユーザーに上記の権限を提供するポリシーを使用する必要があります。ユーザーに直接アクセス権限を付与できますが、アクセス権限はグループに付与することを強くお勧めします。これによって、アクセス権限の管理が容易になります。ユーザーがアクセス権限に関連付けられているタスクを実行する必要がなくなった場合には、そのユーザーをグループから削除するだけです。他のユーザーがそのタスクを実行する必要がある場合には、そのユーザーをグループに追加して、アクセス権限を付与します。
AWS STS フェデレーションユーザーのセッションまたはロールに一時的なセキュリティ認証情報を作成するアクセス許可を IAM グループに付与するには、次の権限の少なくとも 1 つを付与するポリシーをアタッチします。
+ OIDC および SAML フェデレーティッドプリンシパルが IAM ロールにアクセスするには、AWS STS `AssumeRole` にアクセス許可を付与します。
+ ロールが不要な AWS STS フェデレーションユーザーには、AWS STS `GetFederationToken` にアクセス許可を付与します。
`AssumeRole` および `GetFederationToken` の API オペレーションの違いの詳細については、「[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)」を参照してください。
また、IAM ユーザーは、一時的なセキュリティ認証情報を作成するために [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) を呼び出すこともできます。ユーザーが `GetSessionToken` を呼び出すためには、アクセス権限を必要としません。このオペレーションの目的は、MFA を使用してユーザーを認証することです。認証を制御するためにポリシーを使用することはできません。つまり、IAM ユーザーが `GetSessionToken` を呼び出して、一時的な認証情報を作成することを回避することはできません。
**Example ロールを引き受けるアクセス許可を付与するポリシー**
以下のポリシーの例では、AWS アカウント `123123123123` の `UpdateApp` ロールに対して `AssumeRole` を呼び出すアクセス許可が与えられます。`AssumeRole` を使用する場合、フェデレーティッドユーザーの代わりにセキュリティ認証情報を作成するユーザー (またはアプリケーション) は、ロールのアクセス許可ポリシーに指定されていないあらゆるアクセス許可を委任することができません。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example フェデレーティッドユーザーの一時的なセキュリティ認証情報を作成するアクセス権限を付与するポリシーの例**
次のポリシーの例では、`GetFederationToken` にアクセスできるアクセス許可が付与されます。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**重要**
IAM ユーザーが `GetFederationToken` を持つ AWS STS フェデレーションユーザーに対して一時的なセキュリティ認証情報を作成するためにアクセス権限を付与する場合、そのユーザーが独自のアクセス権限を委任できるようになりますので注意してください。IAM ユーザーや AWS アカウント へのアクセス許可の委任については、「[アクセス権を委任するポリシーの例](id_roles_create_policy-examples.md)」を参照してください。一時的なセキュリティ認証情報のアクセス許可を制御する方法の詳細については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。
**Example フェデレーティッドユーザーの一時的セキュリティ認証情報を作成するユーザーを限定するアクセス許可を付与するポリシーの例**
IAM ユーザーが `GetFederationToken` 呼び出しをできるようにする場合、IAM ユーザーに委任できる権限を制限することがベストプラクティスです。例えば次のポリシーでは、名前が「*Manager*」で始まる AWS STS フェデレーションユーザーのみに対し、IAM ユーザーが一時的なセキュリティ認証情報を作成できるようにする方法を示します。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# ID 拡張コンソールセッションを使用するための許可の付与
ID 拡張コンソールセッションでは、ユーザーがサインインするときに、AWS IAM アイデンティティセンター ユーザーとセッション ID をユーザーの AWS セッションに含めることができます。例えば、Amazon Q Developer Pro は ID 拡張コンソールセッションを使用して、サービスエクスペリエンスをパーソナライズします。ID 拡張コンソールセッションの詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[ID 拡張セッションの有効化](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html)」を参照してください。Amazon Q Developer のセットアップについては、「Amazon Q Developer ユーザーガイド」の「[Setting up Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html)」を参照してください。
ユーザーが ID 拡張コンソールセッションを利用できるようにするには、ID ベースのポリシーを使用して、ユーザー自身のコンソールセッションを表すリソースに対する `sts:SetContext` 許可を IAM プリンシパルに付与する必要があります。
**重要**
デフォルトで、ユーザーには ID 拡張コンソールセッションのコンテキストを設定する許可がありません。これを許可するには、以下のポリシー例に示すように、ID ベースのポリシーで `sts:SetContext` アクセス許可を IAM プリンシパルに付与する必要があります。
次の ID ベースのポリシー例は、`sts:SetContext` 許可を IAM プリンシパルに付与することで、プリンシパルがプリンシパル自身の AWS コンソールセッションに ID 拡張コンソールセッションコンテキストを設定できるようにします。ポリシーリソース `arn:aws:sts::account-id:self` は、呼び出し元の AWS セッションを表します。IAM Identity Center のアクセス許可セットを使用してこのポリシーをデプロイする場合など、同じアクセス許可ポリシーが複数のアカウントにデプロイされる場合は、`account-id` ARN セグメントをワイルドカード文字 `*` に置き換えることができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------
# AWS リージョン で AWS STS を管理する
リージョンエンドポイントは、AWS Web Services の特定のリージョン内のエントリポイントの URL です。 AWS では、レイテンシーの短縮、冗長性の構築、セッショントークンの有効性の向上のために、グローバルエンドポイントではなく、リージョンの AWS Security Token Service (AWS STS) エンドポイントを使用することをお勧めします。グローバル (レガシー) AWS STS エンドポイント `https://sts.amazonaws.com` は高い可用性を備えていて、単一の AWS リージョン、米国東部 (バージニア北部）、および他のエンドポイントと同様にホストされますが、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されません。
+ **レイテンシーの低減** – お客様のサービスやアプリケーションに地理的に近いエンドポイントに対して AWS STS の呼び出しを実行することにより、より低いレイテンシーとより高速な応答時間で AWS STS サービスにアクセスできます。
+ **冗長性の構築** – 予測可能な範囲に影響を封じ込めることによって、ワークロード内の障害の影響を限られた数のコンポーネントに限定できます。リージョン AWS STS エンドポイントを使用すると、コンポーネントの範囲をセッショントークンの範囲に合わせることができます。この信頼性の柱の詳細については、「AWS Well-Architected Framework」の「[障害部分を切り離してワークロードを保護する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)」を参照してください。
+ **セッショントークンの有効性を向上させる** – リージョンの AWS STS エンドポイントからのセッショントークンはすべての AWS リージョン で有効です。グローバル STS エンドポイントからのセッショントークンは、デフォルトで有効になっている AWS リージョン でのみ有効です。アカウントで新しいリージョンを有効にする場合、リージョン別 AWS STS エンドポイントからのセッショントークンを使用できます。グローバルエンドポイントの使用を選択した場合、グローバルエンドポイントに対する AWS STS セッショントークンのリージョンの互換性を変更する必要があります。これにより、トークンはすべての AWS リージョン で有効になります。
AWS STS リージョンのリストとエンドポイントの詳細については、「[AWS STS のリージョンとエンドポイント](id_credentials_temp_region-endpoints.md)」を参照してください。
**注記**
回復性とパフォーマンスを向上させるために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。グローバルエンドポイントへの AWS STS リクエストは、ワークロードと同じ AWS リージョン で自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。適切な AWS STS リージョンエンドポイントを使用することをお勧めします。詳細については、「[AWS STS グローバルエンドポイントの変更](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes)」を参照してください。
**Topics**
+ [AWS リージョン での AWS STS のアクティブ化と非アクティブ化](#sts-regions-activate-deactivate)
+ [AWS STS リージョンを使用するコードの記述](#id_credentials_temp_enable-regions_writing_code)
+ [グローバルエンドポイントセッショントークンの管理](#sts-regions-manage-tokens)
## AWS リージョン での AWS STS のアクティブ化と非アクティブ化
リージョンに対して AWS STS エンドポイントを有効にすると、AWS STS は、AWS STS リクエストを行うアカウントのユーザーとロールに一時的な認証情報を発行できます。その後、これらの認証情報は、デフォルトで有効であるリージョン、または手動で有効にされているリージョンで使用できます。デフォルトで有効になっているリージョンでは、一時認証情報が生成されるアカウントでリージョン AWS STS エンドポイントをアクティブ化する必要があります。リクエストを行うときに、ユーザーが同じアカウントにサインインしたかまたは別のアカウントにサインインしたかは関係ありません。手動で有効化されたリージョンを使用して別の AWS アカウント のロールの一時的な認証情報をリクエストする場合、ターゲットアカウント (ロールを含むアカウント) は、AWS STS オペレーションのためにそのリージョン有効にする必要があります。これで一時的なセキュリティ認証情報が正しく生成されます。
例えば、アカウント A 内のあるユーザーが [AWS STS リージョンのエンドポイント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com` に `sts:AssumeRole` API リクエストを送信するとします。このリクエストは、アカウント B にある `Developer` という名前のロールの一時的な認証情報を求めるものです。これはアカウント B 内のエンティティの認証情報を作成するリクエストであるため、アカウント B が `ap-southeast-3` リージョンを有効にする必要があります。アカウント A (または他のアカウント) のユーザーは、`ap-southeast-3` AWS STS エンドポイントを呼び出して、自分のアカウントでこのリージョンがアクティブ化されているかどうかに関わらず、アカウント B の認証情報をリクエストできます。詳細については、「[Enable or disable AWS リージョン in your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。
**注記**
アクティブなリージョンはそのアカウントで一時的な認証情報を使用するすべてのユーザーが利用できます。どの IAM ユーザーまたはロールがリージョンにアクセスできるかを制御するには、アクセス許可ポリシーで、`aws:RequestedRegion` 条件キーを使用します。
**デフォルトで有効なリージョンで AWS STS をアクティブ化または非アクティブ化するには (コンソール)**
1. IAM 管理タスクを実行するアクセス許可があるルートユーザーまたはユーザーとしてサインインします。
1. [IAM コンソール](https://console.aws.amazon.com/iam/home?#home)を開き、ナビゲーションペインで [[https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings)] を選択します。
1. **[Security Token Service (STS)]** セクションの **[Endpoints]** (エンドポイント) で、設定するリージョンを見つけ、**[STS status]** (STS ステータス) 列で **[Active]** (アクティブ) または **[Inactive]** (非アクティブ) を選択します。
1. 表示されたダイアログボックスで、**[Activate]** (有効化) または **[Deactivate]** (無効化) を選択します。
有効にする必要があるリージョンの場合、リージョンを有効にすると AWS STS が自動的にアクティブになります。リージョンを有効にすると、AWS STS はそのリージョンに対して常にアクティブになり、非アクティブ化することはできません。デフォルトで無効になっているリージョンを有効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。
## AWS STS リージョンを使用するコードの記述
リージョンをアクティブ化すると、そのリージョンに AWS STS API 呼び出しを割り振ることができます。次の Java コードスニペットは、欧州 (ミラノ)(eu-south-1) リージョンにリクエストを送信するように `AWSSecurityTokenService` オブジェクトを設定する方法を示しています。
```
EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1");
AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard()
.withCredentials(credentials)
.withEndpointConfiguration(regionEndpointConfig)
.build();
```
AWS STS では、リージョンのエンドポイントへの呼び出しを推奨します。手動でリージョンを有効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。
この例では、最初の行は `regionEndpointConfig` という `EndpointConfiguration` オブジェクトをインスタンス化し、エンドポイントの URL と AWS リージョン をパラメータとして渡します。
AWS SDK の環境変数を使用して AWS STS のリージョンエンドポイントを設定する方法については、「AWS SDK とツールリファレンスガイド」の「[AWS STS リージョンエンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)」を参照してください。
他のすべての言語とプログラミング環境の組み合わせについては、「[関連する SDK のドキュメント](https://aws.amazon.com/tools/)」を参照してください。
## グローバルエンドポイントセッショントークンの管理
ほとんどの AWS リージョン はデフォルトですべての AWS のサービス のオペレーションに有効になっています。これらのリージョンは、AWS STS で使用できるように自動的にアクティブ化されます。アジアパシフィック (香港) など一部のリージョンは、手動で有効にする必要があります。AWS リージョン を有効および無効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。これらの AWS リージョンを有効にすると、AWS STS で使用できるように、自動的にアクティブ化されます。無効になっているリージョンの AWS STS エンドポイントをアクティブ化することはできません。すべての AWS リージョン で有効なセッショントークンには、デフォルトで有効になっているリージョンで有効なトークンを超える文字が含まれています。この設定を変更すると、一時的にトークンを保存する既存のシステムに影響する可能性があります。
この設定は、AWS マネジメントコンソール、AWS CLI、または AWS API を使用して変更できます。
**グローバルエンドポイント (コンソール) に対するセッショントークンの リージョンの互換性を変更するには**
1. IAM 管理タスクを実行するアクセス許可があるルートユーザーまたはユーザーとしてサインインします。セッショントークンの互換性を変更するには、`iam:SetSecurityTokenServicePreferences` アクションを許可するポリシーがある必要があります。
1. [[IAM コンソール]](https://console.aws.amazon.com/iam/home?#home) を開きます。ナビゲーションペインで **[アカウント設定]** を選択します。
1. **[Security Token Service (STS)]** セクションの **[Session Tokens from the STS endpoints]** (STS エンドポイントからのセッショントークン)。**[Global endpoint]** (グローバルエンドポイント) は `Valid only in AWS リージョン enabled by default` を示します。[**Change**] を選択します。
1. **[Change region compatibility]** (リージョンの互換性を変更) ダイアログボックスで、**[All AWS リージョン]** を選択します。次に、**変更の保存**を選択します。
**注記**
すべての AWS リージョン で有効なセッショントークンには、デフォルトで有効になっているリージョンで有効なトークンを超える文字が含まれています。この設定を変更すると、一時的にトークンを保存する既存のシステムに影響する可能性があります。
**グローバルエンドポイント (AWS CLI) に対するセッショントークンの リージョンの互換性を変更するには**
セッショントークンのバージョンを設定します。バージョン 1 トークンは、デフォルトで利用できる AWS リージョン でのみ有効です。これらのトークンは、アジアパシフィック (香港) など、手動で有効になっているリージョンでは動作しません。バージョン 2 のトークンはすべてのリージョンで有効です。ただし、バージョン 2 トークンにはさらに多くの文字が含まれており、一時的にトークンを保存するシステムに影響する可能性があります。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html)
**グローバルエンドポイント (AWS API) に対するセッショントークンの リージョンの互換性を変更するには**
セッショントークンのバージョンを設定します。バージョン 1 トークンは、デフォルトで利用できる AWS リージョン でのみ有効です。これらのトークンは、アジアパシフィック (香港) など、手動で有効になっているリージョンでは動作しません。バージョン 2 のトークンはすべてのリージョンで有効です。ただし、バージョン 2 トークンにはさらに多くの文字が含まれており、一時的にトークンを保存するシステムに影響する可能性があります。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html)
# AWS STS のリージョンとエンドポイント
**注記**
回復性とパフォーマンスを向上させるために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。グローバルエンドポイントへの AWS STS リクエストは、ワークロードと同じ AWS リージョン で自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。適切な AWS STS リージョンエンドポイントを使用することをお勧めします。詳細については、「[AWS STS グローバルエンドポイントの変更](#reference_sts_global_endpoint_changes)」を参照してください。
次の表に、リージョンとそのエンドポイントを一覧表示します。ここには、デフォルトでアクティブ化されるものや、ユーザーがアクティブ化または非アクティブ化できるものが示されています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)
¹リージョンで使用するには、[リージョンを有効にする](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)必要があります。これにより、AWS STS が自動的にアクティブになります。これらのリージョンで AWS STS を手動でアクティブ化または非アクティブ化することはできません。
²中国で AWS を使用するには、中国内の AWS に特化されたアカウントと認証情報が必要です。
## AWS STS グローバルエンドポイントの変更
耐障害性およびパフォーマンスを強化するために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。以前、AWS STS グローバルエンドポイントへのすべてのリクエストは、単一の AWS リージョン である米国東部 (バージニア北部) によって処理されていました。[デフォルトで有効化された](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)リージョンでは、AWS STS グローバルエンドポイントへのリクエストは、米国東部 (バージニア北部) リージョンではなく、リクエスト元のリージョンで自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。
この変更により、AWS STS は、リクエスト元のリージョンと使用された DNS リゾルバーに基づいてリクエストを処理します。AWS STS グローバルエンドポイントへのリクエストは、AWS STS グローバルエンドポイントの DNS リクエストがデフォルトで有効になっているリージョンの Amazon DNS サーバーによって処理される場合、AWS デプロイされたワークロードと同じリージョンで処理されます。リクエストがオプトインリージョンから行われた場合、またはリクエストが Amazon DNS サーバー以外の DNS リゾルバーを使用して解決された場合、AWS STS グローバルエンドポイントへのリクエストは米国東部 (バージニア北部) リージョンで引き続き処理されます。詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[Amazon DNS サーバー](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS)」を参照してください。
次の表は、DNS プロバイダーに基づいて AWS STS グローバルエンドポイントへのリクエストをルーティングする方法を示します。
| DNS リゾルバー | AWS STS グローバルエンドポイントへのリクエストはローカル AWS リージョン にルーティングされますか? |
| --- | --- |
| デフォルトで有効になっているリージョンの Amazon VPC の Amazon DNS リゾルバー | はい |
| オプトインリージョンの Amazon VPC の Amazon DNS リゾルバー | いいえ、リクエストは米国東部 (バージニア北部) リージョンにルーティングされます |
| ISP、パブリック DNS プロバイダー、その他の DNS プロバイダーによって提供される DNS リゾルバー | いいえ、リクエストは米国東部 (バージニア北部) リージョンにルーティングされます |
既存のプロセスの中断を最小限に抑えるため、AWS で次の対策が実施しました。
+ AWS STS グローバルエンドポイントに対して行われたリクエストの AWS CloudTrail ログは、米国東部 (バージニア北部) リージョンに送信されます。AWS STS リージョンエンドポイントによって処理されたリクエストの CloudTrail ログは、CloudTrail のそれぞれのリージョンに引き続きログ記録されます。
+ AWS STS グローバルエンドポイントおよびリージョンエンドポイントによって実行されるオペレーションの CloudTrail ログには、リクエストを処理したエンドポイントおよびリージョンを示す追加フィールド `endpointType` および `awsServingRegion` が含まれます。CloudTrail ログの例については、「[CloudTrail ログファイルのグローバルエンドポイントを使用した AWS STS API イベントの例](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint)」を参照してください。
+ リクエストを処理するリージョンとは関係なく、AWS STS グローバルエンドポイントに対して行われるリクエストでは `aws:RequestedRegion` 条件キーに `us-east-1` の値が含まれます。
+ AWS STS グローバルエンドポイントによって処理されたリクエストでは、リージョンの AWS STS エンドポイントと 1 秒あたりのリクエストクォータが共有されません。
オプトインリージョンでワークロードがあり、AWS STS グローバルエンドポイントをまだ使用している場合、耐障害性およびパフォーマンスを強化するために AWS STS リージョンのエンドポイントに移行することをお勧めします。リージョン AWS STS エンドポイントの設定の詳細については、「*AWS SDK およびツールリファレンスガイド*」の「[AWS STS リージョンエンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)」を参照してください。
## AWS CloudTrail とリージョンのエンドポイント
リージョンのエンドポイントとグローバルエンドポイントへの呼び出しは、AWS CloudTrail の [`tlsDetails`] フィールドに記録されます。`us-east-2.amazonaws.com` などのリージョンのエンドポイントへの呼び出しは、CloudTrail で適切なリージョンに記録されます。グローバルエンドポイント `sts.amazonaws.com` への呼び出しは、グローバルサービスへの呼び出しとして記録されます。グローバル AWS STS エンドポイントのイベントは us-east-1 に記録されます。
**注記**
`tlsDetails` は、このフィールドをサポートするサービスに対してのみ表示できます。AWS CloudTrail ユーザーガイドの「[CloudTrail で TLS の詳細をサポートするサービス](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html)」を参照してください。
詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。
# AWS コンソールへのカスタム ID ブローカーアクセスを有効にする
組織のネットワークにサインインするユーザーに対して AWS マネジメントコンソール への安全なアクセスを許可するには、そのための URL を生成するコードを記述して実行できます。この URL は、AWS から取得したサインイントークンを含み、それを使って AWS に対してユーザーを認証します。結果のコンソールセッションには、フェデレーションに起因する明確な `AccessKeyId` が含まれる場合があります。関連する CloudTrail イベントを介したフェデレーションサインインのアクセスキーの使用状況を追跡するには、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」と「AWS マネジメントコンソール サインインイベント」を参照してください。
**注記**
組織で、SAML と互換性のある ID プロバイダー (IdP) を使用している場合は、コードを記述せずにコンソールにアクセスできます。これは、Microsoft の Active Directory フェデレーションサービスやオープンソースの Shibboleth などのプロバイダーで機能します。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。
組織のユーザーによる AWS マネジメントコンソール へのアクセスを許可するには、以下の手順を実行するカスタム *ID ブローカー*を作成できます。
1. ユーザーがローカル ID システムによって認証されていることを確認する。
1. AWS Security Token Service (AWS STS) の [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) (推奨) または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API オペレーションを呼び出して、ユーザーの一時的セキュリティ認証情報を取得する。ロールを引き受ける別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。セキュリティ認証情報を取得するときにオプションのセッションタグを渡す方法については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
+ `AssumeRole*` API オペレーションのいずれかを使用してロールの一時的なセキュリティ認証情報を取得した場合、この呼び出しに `DurationSeconds` パラメータを含めることができます。このパラメータは、ロールセッションの期間を 900 秒 (15 分) からそのロールの最大セッション期間設定まで指定します。`AssumeRole*` オペレーションで `DurationSeconds` を使用する場合、長期的な認証情報を持つ IAM ユーザーとして呼び出す必要があります。それ以外の場合は、ステップ 3 のフェデレーションエンドポイントへの呼び出しが失敗します。ロールの最大値を確認または変更する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。
+ `GetFederationToken` API オペレーションを使用して認証情報を取得するには、呼び出しに `DurationSeconds` パラメータを含めることができます。このパラメータは、ロールセッションの継続期間を指定します。値の範囲は 900 秒 (15 分) から 129,600 秒 (36 時間) です。この API コールは、IAM ユーザーの AWS 長期的セキュリティ認証情報を使用することでのみ行うことができます。AWS アカウントのルートユーザー 認証情報を使用してこれらの呼び出しを行うこともできますが、推奨されません。ルートユーザーとしてこの呼び出しを行うと、デフォルトのセッションの継続期間は 1 時間です。900 秒 (15 分) から最長 3,600 秒 (1 時間) までセッションを指定できます。
1. AWS フェデレーションエンドポイントを呼び出し、一時的なセキュリティ認証情報を指定して、サインイントークンをリクエストする。
1. トークンを含むコンソールの URL を生成する:
+ URL で `AssumeRole*` API オペレーションのいずれかを使用する場合、`SessionDuration` HTTP パラメータを含めることができます。このパラメータはコンソールセッションの継続期間を 900 秒 (15 分) から 43200 秒 (12 時間) までの間で指定します。
+ URL で `GetFederationToken` API オペレーションを使用する場合、`DurationSeconds` パラメータを含めることができます。このパラメータは、フェデレーテッドコンソールセッションの継続期間を指定します。値の範囲は 900 秒 (15 分) から 129,600 秒 (36 時間) です。
**注記**
`SessionDuration` は、引き受けるロールの最大セッション期間より短く設定する必要があります。例えば、引き受けるロールの最大セッション時間を 5 時間に設定するとします。`SessionDuration` パラメータは 16524 秒、または 4 時間 59 秒にすることができます。
`GetFederationToken` を使用して一時的な認証情報を取得した場合は、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
1 つのロールの認証情報を使用して別のロールを引き受けることは、[*ロールの連鎖*](id_roles.md#iam-term-role-chaining)と呼ばれます。ロールの連鎖を使用すると、新しい認証情報は最長期間である 1 時間に制限されます。ロールを使用して [EC2 インスタンスで実行されるアプリケーションにアクセス許可を付与する](id_roles_use_switch-role-ec2.md)場合、これらのアプリケーションにはこの制限が適用されません。
ロールの連鎖を通じて一時的な認証情報を取得するときは、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
1. URL をユーザーに渡すか、ユーザーに代わって URL を呼び出す。
フェデレーションエンドポイントによって渡される URL はその作成後から 15 分間、有効です。これは、URL に関連付けられた一時的セキュリティ認証情報の期間 (秒) とは異なります。これらの認証情報は、認証情報の作成時から、作成時に指定した期間だけ有効です。
**重要**
URL は、関連付けられた一時的セキュリティ認証情報でアクセス許可を有効にした場合、AWS マネジメントコンソール を介した AWS リソースへのアクセスを許可することを忘れないでください。そのため、この URL は機密情報として扱う必要があります。例えば、SSL 接続による 302 HTTP レスポンスステータスコードを使用して、安全なリダイレクトによって URL を返すことをお勧めします。302 HTTP レスポンスステータスコードの詳細については、「[RFC 2616 セクション 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3)」を参照してください。
これらのタスクを完了するために、[AWS Identity and Access Management (IAM) と [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/) のHTTPS クエリ API ](https://docs.aws.amazon.com/IAM/latest/APIReference/)を使用できます。または、Java、Ruby、C\$1 などのプログラミング言語を該当する [AWS SDK](https://aws.amazon.com/tools/) と共に使用できます。これらの方法のそれぞれについて、以下のトピックで説明します。
**Topics**
+ [IAM クエリ API オペレーションを使用したコード例](#STSConsoleLink_manual)
+ [Python を使用したコード例](#STSConsoleLink_programPython)
+ [Java を使用したコード例](#STSConsoleLink_programJava)
+ [URL の作成方法を示す例 (Ruby)](#STSConsoleLink_programRuby)
## IAM クエリ API オペレーションを使用したコード例
ロールやフェデレーティッドプリンシパルに対して AWS マネジメントコンソール への直接アクセスを許可する URL を作成できます。このタスクでは、IAM と AWS STS の HTTPS クエリ API を使用します。クエリリクエストの詳細については、「[クエリリクエストを行う](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html)」を参照してください。
**注記**
以下の手順は、テキスト文字列の例を含んでいます。読みやすくするために、長い例の一部では改行が追加されています。これらの文字列をご自分で使用するときは、改行をすべて削除してください。
**ロールやフェデレーティッドプリンシパルに対して AWS マネジメントコンソール のリソースへのアクセスを許可する方法**
1. ID および認可システムでユーザーを認証します。
1. ユーザーの一時的なセキュリティ認証情報を取得します。一時的な認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。一時的な認証情報の作成方法の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。
一時的な認証情報を取得するには、AWS STS の [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API (推奨) または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API を呼び出します。これらの API オペレーションの違いの詳細については、AWS セキュリティブログの「[AWS アカウントへのアクセスを安全に委任する API オプションの理解](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account)」を参照してください。
**重要**
[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API を使用して一時的セキュリティ認証情報を作成する場合、ロールを引き受けるユーザーに認証情報を提供するアクセス許可を指定する必要があります。`AssumeRole*` で始まるいずれの API オペレーションでも、IAM ロールを使用してアクセス許可を割り当てます。その他の API オペレーションでは、この方法は API によって異なります。詳細については、[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)を参照してください。さらに、`AssumeRole*` API オペレーションを使用する場合、長期的な認証情報を使用する IAM ユーザーとして呼び出す必要があります。それ以外の場合は、ステップ 3 のフェデレーションエンドポイントへの呼び出しが失敗します。
1. 一時的なセキュリティ認証情報を取得した後、この情報から JSON セッション文字列を生成して、サインイントークンに置き換えられるようにします。以下の例は、認証情報のエンコード方法を示しています。プレースホルダーテキストを、先ほどの手順で取得した認証情報の該当する値に置き換えます。
```
{"sessionId":"*** temporary access key ID ***",
"sessionKey":"*** temporary secret access key ***",
"sessionToken":"*** session token ***"}
```
1. 前の手順からのセッション文字列を [URL エンコード](https://en.wikipedia.org/wiki/Percent-encoding)します。エンコードする情報は機密であるため、このエンコードにウェブサービスを利用しないことをお勧めします。代わりに、開発ツールキットのローカルにインストールされた関数または機能を使用して、この情報を安全にエンコードします。Python では `urllib.quote_plus` 関数、Java では `URLEncoder.encode` 関数、Ruby では `CGI.escape` 関数を使用できます。このトピックの後の例を参照してください。
1.
**注記**
ここで AWS は POST リクエストをサポートします。
AWS フェデレーションエンドポイントにリクエストを送信します。
`https://region-code.signin.aws.amazon.com/federation`
実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。任意で、以下のデフォルトの AWS サインイン フェデレーション エンドポイントが使用できます。
`https://signin.aws.amazon.com/federation`
以下の例のように、リクエストには、`Action` および `Session` パラメータを含める必要があります。[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを (オプションで) 使用する場合は、`SessionDuration` HTTP パラメータを含める必要があります。
```
Action = getSigninToken
SessionDuration = time in seconds
Session = *** the URL encoded JSON string created in steps 3 & 4 ***
```
**注記**
このステップで以下の手順は、GET リクエストを使用する場合にのみ機能します。
`SessionDuration` HTTP パラメータは、コンソールセッションの継続期間を指定します。これは、`DurationSeconds` パラメータを使用して指定する一時的な認証情報の期間とは異なります。`SessionDuration` の最大値を 43200 (12 時間) に指定できます。`SessionDuration` パラメータがない場合は、セッションはステップ 2 で AWS STS から取得した認証情報の期間 (デフォルトは 1 時間) をデフォルトに設定します。`DurationSeconds` パラメータを使用した期間の指定方法の詳細については、[`AssumeRole` API のドキュメント](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)を参照してください。1 時間より長いコンソールセッションを作成する機能は、フェデレーションエンドポイントの `getSigninToken` オペレーションに組み込まれます。
**注記**
`SessionDuration` は、引き受けるロールの最大セッション期間より短く設定する必要があります。例えば、引き受けるロールの最大セッション時間を 5 時間に設定するとします。`SessionDuration` パラメータは 16524 秒、または 4 時間 59 秒にすることができます。
`GetFederationToken` を使用して一時的な認証情報を取得した場合は、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
1 つのロールの認証情報を使用して別のロールを引き受けることは、[*ロールの連鎖*](id_roles.md#iam-term-role-chaining)と呼ばれます。ロールの連鎖を使用すると、新しい認証情報は最長期間である 1 時間に制限されます。ロールを使用して [EC2 インスタンスで実行されるアプリケーションにアクセス許可を付与する](id_roles_use_switch-role-ec2.md)場合、これらのアプリケーションにはこの制限が適用されません。
ロールの連鎖を通じて一時的な認証情報を取得するときは、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
長時間にわたってコンソールセッションを有効にすると、認証情報が漏洩するリスクが高くなります。このリスクを軽減するには、IAM コンソールページの **[ロールの概要]** で、**[セッションの無効化]** を選択して、どのロールのアクティブなコンソールセッションもすぐに無効にできます。詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。
以下に示しているのは、リクエストの具体的な例です。ここでは読みやすいように改行していますが、リクエストは 1 行の文字列として送信する必要があります。
```
https://signin.aws.amazon.com/federation
?Action=getSigninToken
&SessionDuration=1800
&Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22
%3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2
2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW
AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8
FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5
PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C
UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D
```
フェデレーションエンドポイントからの応答は、`SigninToken` 値を含む JSON ドキュメントです。実際には次のようになります。
```
{"SigninToken":"*** the SigninToken string ***"}
```
1.
**注記**
ここで AWS は POST リクエストをサポートします。
最後に、ユーザーが AWS マネジメントコンソール にアクセスするために使用できる URL を作成します。URL は、「[Step 5](#STSConsoleLink_manual_step5)」で使用した同じフェデレーション URL エンドポイントに以下のパラメータを追加したものです。
```
?Action = login
&Issuer = *** the form-urlencoded URL for your internal sign-in page ***
&Destination = *** the form-urlencoded URL to the desired AWS console page ***
&SigninToken = *** the value of SigninToken received in the previous step ***
```
**注記**
このステップの以下の手順は、GET API を使用する場合にのみ機能します。
以下の例は、最終的な URL がどのようになるかを示します。URL は、作成時から 15 分間、有効です。URL 内に組み込まれた一時的なセキュリティ認証情報とコンソールセッションは、認証情報の初回リクエスト時に `SessionDuration` HTTP パラメータで指定した期間、有効です。
```
https://signin.aws.amazon.com/federation
?Action=login
&Issuer=https%3A%2F%2Fexample.com
&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F
&SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1
WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm
0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC
RNhujg
```
## Python を使用したコード例
次の例では、Python を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。ここでは、以下の 2 つの例を示します。
+ GET リクエスト経由で AWS にフェデレートします
+ POST リクエスト経由で AWS にフェデレートします
どちらの例でも、[AWS SDK for Python (Boto3)](https://aws.amazon.com/tools/) や [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を使用して、一時的なセキュリティ認証情報を取得します。
`AssumeRoleSession` 認証情報がロールの連鎖からのものである場合は、`SessionDuration` を含めないでください。`SessionDuration` を含めると、オペレーションは失敗します。
### GET リクエストの使用
```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
# Step 1: Authenticate user in your own identity system.
# Step 2: Using the access keys for an IAM user in your AWS アカウント,
# call "AssumeRole" to get temporary access keys for the role or federated principal
# Note: Calls to AWS STS AssumeRole must be signed using the access key ID
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables,
# or in a configuration file, and will be discovered automatically by the
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
sts_connection = boto3.client('sts')
assumed_role_object = sts_connection.assume_role(
RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
RoleSessionName="AssumeRoleSession",
)
# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)
# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
if sys.version_info[0] < 3:
def quote_plus_function(s):
return urllib.quote_plus(s)
else:
def quote_plus_function(s):
return urllib.parse.quote_plus(s)
request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)
# Step 5: Create URL where users can use the sign-in token to sign in to
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
request_parameters = "?Action=login"
request_parameters += "&Issuer=Example.org"
request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
# Send final URL to stdout
print (request_url)
```
### POST リクエストの使用
```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
import os
from selenium import webdriver # 'pip install selenium', 'brew install chromedriver'
# Step 1: Authenticate user in your own identity system.
# Step 2: Using the access keys for an IAM user in your AAWS アカウント,
# call "AssumeRole" to get temporary access keys for the role or federated principal
# Note: Calls to AWS STS AssumeRole must be signed using the access key ID
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables,
# or in a configuration file, and will be discovered automatically by the
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
if sys.version_info[0] < 3:
def quote_plus_function(s):
return urllib.quote_plus(s)
else:
def quote_plus_function(s):
return urllib.parse.quote_plus(s)
sts_connection = boto3.client('sts')
assumed_role_object = sts_connection.assume_role(
RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
RoleSessionName="AssumeRoleDemoSession",
)
# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)
# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials
# as parameters.
request_parameters = {}
request_parameters['Action'] = 'getSigninToken'
request_parameters['SessionDuration'] = '43200'
request_parameters['Session'] = json_string_with_temp_credentials
request_url = "https://signin.aws.amazon.com/federation"
r = requests.post( request_url, data=request_parameters)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)
# Step 5: Create a POST request where users can use the sign-in token to sign in to
# the console. The POST request must be made within 15 minutes after the
# sign-in token was issued.
request_parameters = {}
request_parameters['Action'] = 'login'
request_parameters['Issuer']='Example.org'
request_parameters['Destination'] = 'https://console.aws.amazon.com/'
request_parameters['SigninToken'] =signin_token['SigninToken']
jsrequest = '''
var form = document.createElement('form');
form.method = 'POST';
form.action = '{request_url}';
request_parameters = {request_parameters}
for (var param in request_parameters) {{
if (request_parameters.hasOwnProperty(param)) {{
const hiddenField = document.createElement('input');
hiddenField.type = 'hidden';
hiddenField.name = param;
hiddenField.value = request_parameters[param];
form.appendChild(hiddenField);
}}
}}
document.body.appendChild(form);
form.submit();
'''.format(request_url=request_url, request_parameters=request_parameters)
driver = webdriver.Chrome()
driver.execute_script(jsrequest)
input("Press Enter to close the browser window...")
```
## Java を使用したコード例
次の例では、Java を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。以下のコード例では、[AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/) を使用しています。
```
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;
/* Calls to AWS STS API operations must be signed using the access key ID
and secret access key of an IAM user or using existing temporary
credentials. The credentials should not be embedded in code. For
this example, the code looks for the credentials in a
standard configuration file.
*/
AWSCredentials credentials =
new PropertiesCredentials(
AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));
AWSSecurityTokenServiceClient stsClient =
new AWSSecurityTokenServiceClient(credentials);
GetFederationTokenRequest getFederationTokenRequest =
new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(1800);
getFederationTokenRequest.setName("UserName");
// A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console.
String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," +
"\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";
getFederationTokenRequest.setPolicy(policy);
GetFederationTokenResult federationTokenResult =
stsClient.getFederationToken(getFederationTokenRequest);
Credentials federatedCredentials = federationTokenResult.getCredentials();
// The issuer parameter specifies your internal sign-in
// page, for example https://mysignin.internal.mycompany.com/.
// The console parameter specifies the URL to the destination console of the
// AWS Management Console. This example goes to Amazon SNS.
// The signin parameter is the URL to send the request to.
String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
// Create the sign-in token using temporary credentials,
// including the access key ID, secret access key, and session token.
String sessionJson = String.format(
"{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
"sessionId", federatedCredentials.getAccessKeyId(),
"sessionKey", federatedCredentials.getSecretAccessKey(),
"sessionToken", federatedCredentials.getSessionToken());
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary
// credentials as parameters.
String getSigninTokenURL = signInURL +
"?Action=getSigninToken" +
"&DurationSeconds=43200" +
"&SessionType=json&Session=" +
URLEncoder.encode(sessionJson,"UTF-8");
URL url = new URL(getSigninTokenURL);
// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();
BufferedReader bufferReader = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
String returnContent = bufferReader.readLine();
String signinToken = new JSONObject(returnContent).getString("SigninToken");
String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8");
// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.
String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");
// Finally, present the completed URL for the AWS console session to the user
String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
signinTokenParameter + issuerParameter + destinationParameter;
```
## URL の作成方法を示す例 (Ruby)
次の例では、Ruby を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。このコード例では、[AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/) を使用しています。
```
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'
# Create a new STS instance
#
# Note: Calls to AWS STS API operations must be signed using an access key ID
# and secret access key. The credentials can be in EC2 instance metadata
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK.
sts = Aws::STS::Client.new()
# The following call creates a temporary session that returns
# temporary security credentials and a session token.
# The policy grants permissions to work
# in the AWS SNS console.
session = sts.get_federation_token({
duration_seconds: 1800,
name: "UserName",
policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}",
})
# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"
# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
:sessionId => session.credentials[:access_key_id],
:sessionKey => session.credentials[:secret_access_key],
:sessionToken => session.credentials[:session_token]
}.to_json
# Call the federation endpoint, passing the parameters
# created earlier and the session information as a JSON block.
# The request returns a sign-in token that's valid for 15 minutes.
# Signing in to the console with the token creates a session
# that is valid for 12 hours.
get_signin_token_url = signin_url +
"?Action=getSigninToken" +
"&SessionType=json&Session=" +
CGI.escape(session_json)
returned_content = URI.parse(get_signin_token_url).read
# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)
# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param +
issuer_param + destination_param
```