

# IAM の一時的な認証情報
<a name="id_credentials_temp"></a>

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。
+ 一時的セキュリティ認証情報は、その名前が示すとおり、*使用期限が短く*なっています。有効期限は数分から数時間に設定できます。認証情報が失効すると、AWS はそれらを認識しなくなります。また、その認証情報によって作成された API リクエストによるあらゆるタイプのアクセスが許可されなくなります。
+ 一時的セキュリティ認証情報はユーザーとともに保存されることはなく、ユーザーのリクエストに応じて動的に生成され、提供されます。一時的セキュリティ認証情報が失効すると（または失効する前でも）、ユーザーは新しい認証情報をリクエストできます。ただし、リクエストするユーザーがまだその権限を持っている場合に限ります。

そのため、一時的な認証情報には、長期の認証情報よりも次の利点があります。
+ アプリケーションの長期の AWS セキュリティ認証情報を配布したり埋め込んだりする必要がありません。
+ ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できます。一時的認証情報は[ロール](id_roles.md)および [ID フェデレーション](id_roles_providers.md)の基本となります。
+ 一時的セキュリティ認証情報の有効期限は限られているので、認証情報が不要になった際に更新したり、明示的に取り消したりする必要がありません。一時的セキュリティ認証情報の有効期限が切れると、再利用することはできません。認証情報が有効な期間を、最大限度まで指定できます。

## AWS STS と AWS リージョン
<a name="sts-regionalization"></a>

一時的な認証情報は AWS STS によって生成されます。デフォルトでは、AWS STS は `https://sts.amazonaws.com` に 1 つのエンドポイントのあるグローバルサービスです。ただし、他のサポートされているリージョンにあるエンドポイントへの AWS STS API 呼び出しを実行することもできます。地理的に近い場所にあるリージョンのサーバーに対してリクエストを送信することによって、レイテンシー (サーバーのラグ) を低減できます。認証情報を取得したリージョンに関係なく、認証情報はグローバルに使用できます。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。

## 一時的な認証情報の一般的なシナリオ
<a name="sts-introduction"></a>

一時的な認証情報は、ID フェデレーション、委任、クロスアカウントアクセス、および IAM ロールが使用されるシナリオで便利です。

### ID フェデレーション
<a name="id-federation"></a>

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 互換の任意のプロバイダーなど) を使用したサインインを求めることができます。モバイルまたはウェブアプリケーションの場合、カスタムサインインコードを作成したり独自のユーザー 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)」を参照してください。

### クロスアカウントアクセスのロール
<a name="role_cross-account"></a>

多くの組織は、複数の 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 の ロール
<a name="role_ec2"></a>

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 サービス
<a name="other-services"></a>

一時的セキュリティ認証情報を使用して、ほとんどの AWS サービスにアクセスできます。一時的セキュリティ認証情報を受け入れるサービスのリストは、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。

## 一時認証情報を使用するサンプルアプリケーション
<a name="id_credentials_temp_sample-apps"></a>

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 Active Directory (AD)、Active Directory Federation Services (ADFS) 2.0、SAML (Security Assertion Markup Language) 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 フェデレーションのサンプル
<a name="sts-sample-apps-wif"></a>

次のサンプルアプリケーションは、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)」を参照してください。

## 一時的なセキュリティ認証情報のための追加リソース
<a name="id_credentials_temp_related-topics"></a>

以下のシナリオやアプリケーションは、一時的なセキュリティ認証情報の使用時に役立ちます。
+ [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)」を参照してください。