翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS SDKs とツールを使用した認証とアクセス
AWS SDK アプリケーションを開発するとき、または使用する AWS ツールを使用する場合は AWS のサービス、コードまたはツールの認証方法を確立する必要があります AWS。 AWS リソースへのプログラムによるアクセスは、コードが実行される環境と利用可能な AWS アクセスに応じて、さまざまな方法で設定できます。
以下のオプションは、[認証情報プロバイダーチェーン](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)の一部です。つまり、共有 AWS `config`ファイルと `credentials` ファイルを適切に設定することで、 AWS SDK またはツールはその認証方法を自動的に検出して使用します。
## アプリケーションコードを認証する方法の選択
アプリケーション AWS によって に対して行われた呼び出しを認証する方法を選択します。
### コード INSIDE AWS のサービス (Amazon EC2、Lambda、Amazon ECS、Amazon EKS、CodeBuild など) を実行していますか?
コードが実行されると AWS、アプリケーションが認証情報を自動的に使用できるようになります。例えば、アプリケーションが Amazon Elastic Compute Cloud でホストされていて、そのリソースに関連付けられた IAM ロールがある場合、認証情報はアプリケーションで自動的に使用可能になります。同様に、Amazon ECS または Amazon EKS コンテナを使用する場合、IAM ロールの認証情報セットは、SDK の[認証情報プロバイダーチェーン](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)を介してコンテナ内で実行されるコードによって自動的に取得できます。
#### コードは Amazon Elastic Compute Cloud インスタンスにありますか?
[IAM ロールを使用して Amazon EC2 にデプロイされたアプリケーションを認証する](access-iam-roles-for-ec2.md) — IAM ロールを使用して、Amazon EC2 インスタンスでアプリケーションを安全に実行します。
#### コードは AWS Lambda 関数にありますか?
[Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)ときに、Lambda により最小限のアクセス許可で実行ロールが作成されます。 AWS SDK またはツールは、実行時に Lambda 実行環境を介して Lambda にアタッチされた IAM ロールを自動的に使用します。
#### コードは Amazon Elastic Container Service (Amazon EC2 または Amazon ECS AWS Fargate の場合) にありますか?
タスク用の IAM ロールを使用します。[タスクロールを作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)し、[Amazon ECS タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)でそのロールを指定する必要があります。 AWS SDK またはツールは、実行時にタスクに割り当てられた IAM ロールを Amazon ECS メタデータを介して自動的に使用します。
#### コードは Amazon Elastic Kubernetes Service にありますか?
[Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) を使用することをお勧めします。
注: [サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) が自身のニーズに適していると思われる場合は、「**Amazon EKS ユーザーガイド**」の「[EKS Pod Identity と IRSA の比較](https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html#service-accounts-iam)」を参照してください。
#### コードは で実行されていますか AWS CodeBuild
「[Using identity-based policies for CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)」を参照してください。
#### コードは別の AWS のサービスにありますか?
AWS のサービスの専用のガイドを参照してください。でコードを実行すると AWS、SDK [認証情報プロバイダーチェーン](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)は認証情報を自動的に取得して更新できます。
### モバイルアプリケーションまたはクライアントベースのウェブアプリケーションを作成していますか?
アクセスを必要とするモバイルアプリケーションまたはクライアントベースのウェブアプリケーションを作成する場合は AWS、ウェブ ID フェデレーションを使用して一時的な AWS セキュリティ認証情報を動的にリクエストするようにアプリケーションを構築します。
ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP) (例: Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換の IdP) を使用してサインインすることができます。認証トークンを受け取り、そのトークンを の一時的なセキュリティ認証情報と交換して、 AWS のリソースを使用するアクセス許可を持つ IAM ロールにマッピングできます AWS アカウント。
SDK またはツールへ設定する方法については、「[ウェブ ID または OpenID Connect でロールを引き受けて AWS SDKsとツールを認証する](access-assume-role-web.md)」を参照してください。
モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。Amazon Cognito は ID ブローカーとして機能し、ユーザーの代わりに多くのフェデレーション作業を行います。詳細については、「*IAM ユーザーガイド*」の「[モバイルアプリに対する Amazon Cognito の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html)」を参照してください。
### コードをローカルで開発して実行していますか?
[コンソール認証情報を使用して AWS SDKsとツールを認証する](access-login.md)をお勧めします。
ブラウザベースの迅速な認証フローの後、 は CLI AWS Tools for PowerShell や SDK AWS などのローカル開発ツールで動作する一時的な認証情報 AWS を自動的に生成します。 AWS SDKs
#### AWS アカウントアクセスに Identity Center を使用する場合
AWS アカウントへのアクセス権が既にある場合、またはワークフォースのアクセスを管理する必要がある場合は、IAM Identity Center を使用して AWS SDK とツールを認証します。セキュリティのベストプラクティスとして、IAM Identity Center AWS Organizations で を使用して、すべての AWS アカウントへのアクセスを管理することをお勧めします。IAM Identity Center でユーザーを作成するか、Microsoft Active Directory を使用するか、SAML 2.0 ID プロバイダー (IdP) を使用するか、IdP を個別に AWS アカウントにフェデレーションできます。リージョンが IAM アイデンティティセンターをサポートしているかどうかを確認するには、Amazon Web Services 全般のリファレンスの[IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md)「IAM アイデンティティセンターのエンドポイントとクォータ」を参照してください。
#### 他の認証方法をお探しの場合
ターゲットロール`sts:AssumeRole`への アクセス許可を持つ最小特権の IAM ユーザーを作成します。次に、そのユーザーの `source_profile` セットアップを使用してロールを引き受けるようにプロファイルを設定します。
環境変数または共有認証情報ファイルを介して一時的な IAM AWS 認証情報を使用することもできます。「 AWS SDKs」を参照してください。
注: サンドボックス環境または学習環境でのみ、長期的な認証情報を使用して AWS SDKsとツールを認証することを検討できます。
### このコードはオンプレミスまたはハイブリッド/オンデマンド VM (Amazon S3 から読み書きするサーバーやクラウドにデプロイする Jenkins など) で実行されていますか?
#### X.509 クライアント証明書を使用していますか?
はい:「[IAM Roles Anywhere を使用した AWS SDKsとツールの認証](access-rolesanywhere.md)」を参照してください。IAM Roles Anywhere を使用して、 の外部で実行されるサーバー、コンテナ、アプリケーションなどのワークロードの一時的なセキュリティ認証情報を IAM で取得できます AWS。IAM Roles Anywhere を使用するには、ワークロードで X.509 証明書を使用する必要があります。
#### 環境は、フェデレーティッド ID プロバイダー (Microsoft Entra や Okta など) に安全に接続して一時的な AWS 認証情報をリクエストできますか?
##### はい:「[プロセス認証情報プロバイダー](feature-process-credentials.md)」を使用します
[プロセス認証情報プロバイダー](feature-process-credentials.md) を使用して、実行時に認証情報を自動的に取得します。これらのシステムでは、ヘルパーツールまたはプラグインを使用して認証情報を取得し、`sts:AssumeRole` を使用してバックグラウンドで IAM ロールを引き受ける場合があります。
##### いいえ: 経由で挿入された一時的な認証情報を使用する AWS Secrets Manager
経由で挿入された一時的な認証情報を使用します AWS Secrets Manager。有効期間の短いアクセスキーを取得するオプションについては、「*IAM ユーザーガイド*」の「[一時的なセキュリティ認証情報をリクエストする](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)」を参照してください。これらの一時的な認証情報を保存するオプションについては、「[AWS アクセスキー](feature-static-credentials.md)」を参照してください。
これらの認証情報を使用して、本番環境のシークレットまたは有効期間の長いロールベースの認証情報を保存できる [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) からより広範なアプリケーションのアクセス許可を安全に取得できます。
### にないサードパーティー製ツールを使用していますか AWS?
認証情報を取得するための最適なガイダンスについては、サードパーティープロバイダーが作成したドキュメントを使用してください。
#### サードパーティーがドキュメントを提供していない場合、一時的な認証情報を安全に挿入できますか?
はい: 環境変数と一時的な AWS STS 認証情報を使用します。
いいえ: 暗号化されたシークレットマネージャー に保存されている静的アクセスキーを使用します (最後の手段)。
## 認証方法
** AWS 環境内で実行されるコードの認証方法 **
コードが実行されると AWS、アプリケーションが認証情報を自動的に使用できるようになります。例えば、アプリケーションが Amazon Elastic Compute Cloud でホストされていて、そのリソースに関連付けられた IAM ロールがある場合、認証情報はアプリケーションで自動的に使用可能になります。同様に、Amazon ECS または Amazon EKS コンテナを使用する場合、IAM ロールの認証情報セットは、SDK の認証情報プロバイダーチェーンを介してコンテナ内で実行されるコードによって自動的に取得できます。
+ [IAM ロールを使用して Amazon EC2 にデプロイされたアプリケーションを認証する](access-iam-roles-for-ec2.md) — IAM ロールを使用して、Amazon EC2 インスタンスでアプリケーションを安全に実行します。
+ IAM Identity Center AWS を使用して、次の方法でプログラムで とやり取りできます。
+ [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/) コンソールから AWS CLI コマンドを実行するには、 を使用します。
+ ソフトウェア開発チーム向けのクラウドベースのコラボレーションスペースを試すには、「[Amazon CodeCatalyst](https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html)」 のご使用を検討ください。
**ウェブベースのアイデンティティープロバイダーによる認証 - モバイルまたはクライアントベースのウェブアプリケーション**
アクセスを必要とするモバイルアプリケーションまたはクライアントベースのウェブアプリケーションを作成する場合は AWS、ウェブ ID フェデレーションを使用して一時的な AWS セキュリティ認証情報を動的にリクエストするようにアプリケーションを構築します。
ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP) (例: Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換の IdP) を使用してサインインすることができます。認証トークンを受け取り、そのトークンを の一時的なセキュリティ認証情報と交換して、 AWS のリソースを使用するアクセス許可を持つ IAM ロールにマッピングできます AWS アカウント。
SDK またはツールへ設定する方法については、「[ウェブ ID または OpenID Connect でロールを引き受けて AWS SDKsとツールを認証する](access-assume-role-web.md)」を参照してください。
モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。Amazon Cognito は ID ブローカーとして機能し、ユーザーの代わりに多くのフェデレーション作業を行います。詳細については、「*IAM ユーザーガイド*」の「[モバイルアプリに対する Amazon Cognito の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html)」を参照してください。
**ローカル ( AWS以外) で実行されるコードの認証オプション**
+ [コンソール認証情報を使用して AWS SDKsとツールを認証する](access-login.md) – この機能は コマンドラインインターフェイスと Tools for PowerShell AWS の両方で動作し、 AWS CLI、Tools for PowerShell、 などのローカル開発ツールで動作する更新可能な認証情報を提供します AWS。
+ [IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md) – セキュリティのベストプラクティスとして、IAM Identity Center AWS Organizations で を使用して、すべての へのアクセスを管理することをお勧めします AWS アカウント。でユーザーを作成する AWS IAM アイデンティティセンターか、Microsoft Active Directory を使用するか、SAML 2.0 ID プロバイダー (IdP) を使用するか、IdP を個別にフェデレーションできます AWS アカウント。お使いのリージョンが IAM Identity Center をサポートしているかどうかを確認するには、*Amazon Web Services 全般のリファレンス* の「[AWS IAM アイデンティティセンター エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/sso.html)」を参照してください。
+ [IAM Roles Anywhere を使用した AWS SDKsとツールの認証](access-rolesanywhere.md) – IAM Roles Anywhere を使用して、 の外部で実行されるサーバー、コンテナ、アプリケーションなどのワークロードの一時的なセキュリティ認証情報を IAM で取得できます AWS。IAM Roles Anywhere を使用するには、ワークロードで X.509 証明書を使用する必要があります。
+ [AWS SDKsとツールを認証するための AWS 認証情報を持つロールの引き受け](access-assume-role.md) – IAM ロールを引き受けて、それ以外の場合はアクセスできない AWS リソースに一時的にアクセスできます。
+ [AWS アクセスキーを使用して AWS SDKsとツールを認証する](access-users.md) – 利便性が低い、または AWS リソースのセキュリティリスクが高まる可能性があるその他のオプション。
**アクセス管理に関する詳細情報**
*IAM ユーザーガイド*には、 AWS リソースへのアクセスを安全に制御するための以下の情報が記載されています。
+ [IAM ID (ユーザー、ユーザーグループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) — での ID の基本を理解します AWS。
+ [IAM におけるセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) —「[責任分担モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)」 に従って AWS アプリケーションを開発する際に従うべきセキュリティ上の推奨事項。
*Amazon Web Services 全般のリファレンス* には、以下に関する基本的な基本事項があります。
+ [AWS 認証情報の理解と取得](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) — コンソールアクセスとプログラムアクセスの両方に関するアクセスキーオプションと管理プラクティス。
** AWS のサービスにアクセスするための IAM Identity Center の信頼できる ID の伝播 (TIP) プラグイン**
+ [TIP プラグインを使用して にアクセスする AWS のサービス](access-tip.md) – Amazon Q Business または信頼できる ID の伝播をサポートする他のサービス用のアプリケーションを作成し、 AWS SDK for Java または を使用している場合は AWS SDK for JavaScript、TIP プラグインを使用して認可を合理化できます。
## AWS ビルダー ID
は、すでに所有 AWS アカウント している、または作成する可能性のあるものを AWS ビルダー ID 補完します。は作成した AWS リソースのコンテナ AWS アカウント として機能し、それらのリソースのセキュリティ境界を提供しますが、 はユーザーを個人として AWS ビルダー ID 表します。を使用してサインイン AWS ビルダー ID すると、Amazon Q や Amazon CodeCatalyst などの開発者ツールやサービスにアクセスできます。
+ *AWS サインイン ユーザーガイド*の「 [でサインイン AWS ビルダー ID](https://docs.aws.amazon.com/signin/latest/userguide/sign-in-aws_builder_id.html)する – を作成して使用する方法 AWS ビルダー ID と、ビルダー ID が提供する内容について説明します。
+ [CodeCatalyst の概念 - *Amazon CodeCatalyst ユーザーガイド*での AWS ビルダー ID](https://docs.aws.amazon.com/codecatalyst/latest/userguide/concepts.html#sign-in-concept) – CodeCatalyst での AWS ビルダー IDの使用方法について説明します。
# コンソール認証情報を使用して AWS SDKsとツールを認証する
ローカル環境やその他のAWS 非コンピューティングサービス環境で AWS アプリケーションを開発するときは、コンソール AWS 認証情報を使用することをお勧めします。Amazon Elastic Compute Cloud (Amazon EC2) や AWS CloudShell などの AWS リソースで開発する場合は、代わりにそのサービスから認証情報を取得することをお勧めします。
IAM Identity Center を使用して認証することもできます[IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md)。このオプションは、組織がワークフォースのアクセスを管理する一般的な方法であり、アイデンティティセンターを有効にする必要があります。
## 動作の仕組み
[コンソール認証情報を使用して AWS ローカル開発にログイン](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html)すると、既存の AWS マネジメントコンソールのサインイン認証情報を使用して AWS サービスにプログラムでアクセスできます。ブラウザベースの認証フローの後、 は CLI、Tools for PowerShell、SDK AWS などのローカル開発ツールで動作する一時的な認証情報 AWS を生成します。 AWS SDKs この機能は、特に長期的なアクセスキーの管理よりもインタラクティブ認証を希望する場合、CLI AWS 認証情報の設定と管理のプロセスを簡素化します。
このプロセスでは、最初のアカウント設定時に作成されたルート認証情報、IAM ユーザー、または ID プロバイダーからのフェデレーティッド ID を使用して認証できます。
開発に SDKs を使用する場合、SDK クライアントは を介して一時的な認証情報を使用します[AWS SDKs標準化された認証情報プロバイダー](standardized-credentials.md)。を設定することもできます[ログイン認証情報プロバイダー](feature-login-credentials.md)。
ログインコマンドによる認証は、CLI と Tools for PowerShell AWS の両方でサポートされています。
+ [コンソール認証情報を使用して AWS ローカル開発にログインする](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html)
+ AWS Tools for PowerShell ユーザーガイドの[コンソール認証情報を使用してログイン](https://docs.aws.amazon.com/powershell/v5/userguide/creds-idc.html#login-con-creds)する
# IAM Identity Center を使用して AWS SDK とツールを認証する
AWS IAM アイデンティティセンター は、AWS 非コンピューティングサービス環境でアプリケーションを開発する AWS ときに AWS 認証情報を提供するために使用できます。Amazon Elastic Compute Cloud (Amazon EC2) や などの AWS リソースで開発している場合は AWS Cloud9、代わりにそのサービスから認証情報を取得することをお勧めします。
AWS アカウントアクセスに Identity Center を既に使用している場合、または組織のアクセスを管理する必要がある場合は、IAM Identity Center 認証を使用します。
このチュートリアルでは、IAM Identity Center アクセスを確立し、 AWS アクセスポータルと を使用して SDK またはツール用に設定します AWS CLI。
+ AWS アクセスポータルは、IAM アイデンティティセンターに手動でサインインするウェブの場所です。URL のフォーマットは `d-xxxxxxxxxx.awsapps.com/start`、または `your_subdomain.awsapps.com/start` です。 AWS アクセスポータルにサインインすると、そのユーザー用に設定された ロール AWS アカウント と ロールを表示できます。この手順では、 AWS アクセスポータルを使用して、SDK/ツール認証プロセスに必要な設定値を取得します。
+ AWS CLI は、コードによって行われた API コールに IAM アイデンティティセンター認証を使用するように SDK またはツールを設定するために使用されます。この 1 回限りのプロセスでは、共有 AWS `config`ファイルが更新され、コードの実行時に SDK またはツールによって使用されます。
## 前提条件
この手順を開始する前に、次の手順を完了しておく必要があります。
+ がない場合は AWS アカウント、 [にサインアップします AWS アカウント](https://portal.aws.amazon.com/billing/signup)。
+ IAM Identity Center をまだ有効にしていない場合は、「*AWS IAM アイデンティティセンター ユーザーガイド*」の手順に従って [IAM Identity Center を有効にします](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。
## IAM Identity Center を使用してプログラムによるアクセスを設定します
### ステップ 1：アクセスを確立し、適切なアクセス許可セットを選択します
AWS 認証情報にアクセスするには、次のいずれかの方法を選択します。
#### IAM Identity Center 経由のアクセスを確立していません
1. 「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)」の手順に従って、ユーザーを追加し、管理アクセス許可を追加します。
1. `AdministratorAccess` アクセス許可セットは、通常の開発には使用しないでください。代わりに、雇用主がこの目的のためにカスタムアクセス許可セットを作成していない限り、定義済みの `PowerUserAccess` アクセス許可セットを使用することをお勧めします。
再度同じ「[Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)」の手順に従います。ただし今回は次のようにします。
+ `Admin team` グループを作成する代わりに `Dev team` グループを作成し、その後の手順ではこれを代わりに使用します。
+ 既存のユーザーを使用できますが、そのユーザーを新しい `Dev team` グループに追加する必要があります。
+ `AdministratorAccess` アクセス許可セットを作成する代わりに `PowerUserAccess` アクセス許可セットを作成し、その後の手順ではこれを代わりに使用します。
完了したら、以下があるはずです。
+ `Dev team` グループ。
+ `Dev team` グループにアタッチされた `PowerUserAccess` アクセス許可セット。
+ `Dev team` グループに追加されたユーザー。
1. ポータルを終了し、再度サインインして、 `Administrator`または の AWS アカウント および オプションを確認します`PowerUserAccess`。ツール/SDK を使用する場合は `PowerUserAccess` を選択します。
#### 雇用主が管理するフェデレーティッド ID プロバイダー (Microsoft Entra や Okta など) AWS を通じて に既にアクセスしている
ID プロバイダーのポータル AWS から にサインインします。クラウド管理者がユーザー `PowerUserAccess` (開発者) にアクセス許可を付与している場合は、アクセスできる AWS アカウント とアクセス許可セットが表示されます。アクセス許可セットの名前の横に、そのアクセス許可セットを使用してアカウントに手動またはプログラムでアクセスするオプションが表示されます。
カスタム実装では、アクセス許可セット名が異なるなど、エクスペリエンスが異なる場合があります。どのアクセス許可セットを使用すればよいかわからない場合は、IT チームにお問い合わせください。
#### 雇用主が管理する AWS アクセスポータル AWS から に既にアクセスできる
AWS アクセスポータル AWS から にサインインします。クラウド管理者から `PowerUserAccess` (開発者) アクセス許可を付与されている場合は、アクセス権のある AWS アカウント とアクセス許可セットが表示されます。アクセス許可セットの名前の横に、そのアクセス許可セットを使用してアカウントに手動またはプログラムでアクセスするオプションが表示されます。
#### 雇用主が管理するフェデレーティッドカスタム ID プロバイダー AWS を通じて に既にアクセスできる
サポートについては、IT チームにお問い合わせください。
### ステップ 2：IAM Identity Center を使用するように SDK とツールを設定します
1. 開発マシンに最新の AWS CLIをインストールします。
1. 「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
1. (オプション) AWS CLI が動作していることを確認するには、コマンドプロンプトを開き、 `aws --version` コマンドを実行します。
1. AWS アクセスポータルにサインインします。この URL は、雇用主から提供されたり、「**ステップ 1: アクセスを確立する**」の後に E メールで取得したりする場合があります。これ以外の場合は、[https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) の**ダッシュボード**で **AWS アクセスポータル URL** を確認できます。
1. AWS アクセスポータルの **アカウント** タブで、管理する個々のアカウントを選択します。ユーザーのロールが表示されます。**[アクセスキー]** を選択して、適切なアクセス許可セットのコマンドラインまたはプログラムによるアクセスの認証情報を取得します。事前定義された `PowerUserAccess` 許可セットを使用するか、またはユーザーもしくは雇用主が開発のために最小特権の許可を適用するために作成した許可セットを使用してください。
1. **[認証情報の取得]** ダイアログボックスで、オペレーティングシステムに応じて、**[MacOS と Linux]** または **[Windows]** を選択します。
1. **[IAM Identity Center 認証情報]** メソッドを選択して、次のステップに必要な `Issuer URL` と `SSO Region` の値を取得します。注: `SSO Start URL` は `Issuer URL` と置き換えて使用できます。
1. AWS CLI コマンドプロンプトで、 `aws configure sso` コマンドを実行します。プロンプトが表示されたら、前のステップで収集した設定値を入力します。この AWS CLI コマンドの詳細については、[`aws configure sso`「ウィザードでプロファイルを設定する](https://docs.aws.amazon.com/cli/latest/userguide/sso-configure-profile-token.html#sso-configure-profile-token-auto-sso)」を参照してください。
1. プロンプト `SSO Start URL` で、`Issuer URL` 用に取得した値を入力します。
1. **[CLI プロファイル名]**には、開始時に*デフォルト*を入力することをお勧めします。デフォルト以外の（名前付き）プロファイルとそれに関連する環境変数を設定する方法については、「[プロファイル](file-format.md#file-format-profile)」を参照してください。
1. (オプション) AWS CLI コマンドプロンプトで、 `aws sts get-caller-identity` コマンドを実行してアクティブなセッション ID を確認します。レスポンスには、設定した IAM Identity Center アクセス許可セットが表示されるはずです。
1. AWS SDK を使用している場合は、開発環境で SDK 用のアプリケーションを作成します。
1. 一部の SDK では、IAM Identity Center 認証を使用する前に、`SSO` や `SSOOIDC` などの追加パッケージをアプリケーションに追加する必要があります。詳細については、具体的な SDK を参照してください。
1. へのアクセスを以前に設定している場合は AWS、共有 AWS `credentials`ファイルで を確認します[AWS アクセスキー](feature-static-credentials.md)。[認証情報プロバイダーチェーンを理解する](standardized-credentials.md#credentialProviderChain) 優先順位により、SDK またはツールが IAM Identity Center の認証情報を使用する前に、静的認証情報をすべて削除する必要があります。
SDK とツールがこの設定を使用して認証情報を使用および更新する方法についての詳細は、「[AWS SDKsとツールの IAM Identity Center 認証の解決方法](understanding-sso.md)」を参照してください。
IAM Identity Center プロバイダー設定を共有 `config` ファイルで直接設定するには、このガイドの「[IAM Identity Center 認証情報プロバイダー](feature-sso-credentials.md)」を参照してください。
## ポータルアクセスセッションを更新する
アクセスはいずれ期限切れになり、SDK またはツールで認証エラーが発生します。この有効期限は、設定したセッションの長さによって異なります。必要に応じてアクセスポータルセッションを再度更新するには、 AWS CLI を使用して `aws sso login` コマンドを実行します。
IAM Identity Center アクセスポータルのセッション期間とアクセス許可セットのセッション期間の両方を延長できます。これにより、 AWS CLIに手動でサインインし直す必要が出るまでにコードを実行できる時間が長くなります。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の以下のトピックを参照してください。
+ **IAM Identity Center セッション期間** – [ユーザーが AWS ポータルにアクセスするセッションの期間を設定します](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-user-session.html)
+ **アクセス許可セットセッション期間** – [セッション期間を設定します](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html)
# AWS SDKsとツールの IAM Identity Center 認証の解決方法
## IAM Identity Center の関連条項
以下の用語は、 AWS IAM アイデンティティセンターの背後にあるプロセスと設定を理解するのに役立ちます。 AWS SDK APIs のドキュメントでは、これらの認証概念の一部に IAM Identity Center とは異なる名前を使用しています。両方の名前を知っておくと役に立ちます。
次の表は、別名の相互関係を示しています。
| IAM アイデンティティセンターの名前 | SDK API の名前 | 説明 |
| --- | --- | --- |
| アイデンティティセンター | sso | AWS Single Sign-On の名前は変更されますが、ssoAPI 名前空間は下位互換性のために元の名前を保持します。詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[What is IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html#renamed)」(IAM Identity Center とは) を参照してください。 |
| IAM Identity Center コンソール管理コンソール | | シングルサインオンの設定に使用するコンソール。 |
| AWS アクセスポータル URL | | IAM Identity Center のアカウントに一意の URL（https://xxx.awsapps.com/start など）。IAM Identity Center のサインイン認証情報を使用してこのポータルにサインインします。 |
| IAM Identity Center アクセスポータルセッション | 認証セッション | 発信者がベアラーアクセストークンを取得できます。 |
| アクセス許可設定セッション | | SDK が内部的に AWS のサービス 呼び出しに使用する IAM セッション。非公式な議論では、このセッションが誤って「ロールセッション」と呼ばれることがあります。 |
| アクセス許可セット認証情報 | AWS 認証情報sigv4 認証情報 | SDK がほとんどの AWS のサービス 呼び出し (特にすべての sigv4 AWS のサービス 呼び出し) に実際に使用する認証情報。非公式な議論では、このセッションが誤って「ロール認証情報」と呼ばれることがあります。 |
| IAM Identity Center 認証情報プロバイダー | SSO 認証情報プロバイダー | 認証情報の取得方法（機能を提供するクラスやモジュールなど）。 |
## の SDK 認証情報解決を理解する AWS のサービス
IAM Identity Center API は、ベアラートークンの認証情報を sigv4 の認証情報と交換します。ほとんど AWS のサービス は sigv4 APIs、 Amazon CodeWhisperer や などのいくつかの例外があります Amazon CodeCatalyst。以下では、 を通じてアプリケーションコードのほとんどの AWS のサービス 呼び出しをサポートするための認証情報解決プロセスについて説明します AWS IAM アイデンティティセンター。
### AWS アクセスポータルセッションを開始する
+ まず、認証情報を使用してセッションにサインインします。
+ AWS Command Line Interface () で `aws sso login` コマンドを使用しますAWS CLI。アクティブなセッションがまだない場合は、新しい IAM Identity Center セッションが開始されます。
+ 新しいセッションを開始すると、IAM Identity Center から更新トークンとアクセストークンを受け取ります。 AWS CLI また、 は SSO キャッシュ JSON ファイルを新しいアクセストークンと更新トークンで更新し、SDKs で使用できるようにします。
+ 既にアクティブなセッションがある場合、 AWS CLI コマンドは既存のセッションを再利用し、既存のセッションの有効期限が切れるたびに期限切れになります。IAM Identity Center セッションの長さを設定する方法については、「 *AWS IAM アイデンティティセンター ユーザーガイド*」の[「ユーザーの AWS アクセスポータルセッションの期間を設定する](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-user-session.html)」を参照してください。
+ 頻繁にサインインする必要性を減らすため、セッションの最大期間が 90 日間に延長されました。
### SDK が AWS のサービス 呼び出しの認証情報を取得する方法
SDKsは、サービスごとにクライアントオブジェクトをインスタンス化 AWS のサービス するときに へのアクセスを提供します。共有 AWS `config`ファイルの選択したプロファイルが IAM アイデンティティセンターの認証情報解決用に設定されている場合、IAM アイデンティティセンターを使用してアプリケーションの認証情報を解決します。
+ [認証情報解決プロセス](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)は、ランタイムにクライアントが作成されるときに完了します。
IAM Identity Center のシングルサインオンを使用して sigv4 API の認証情報を取得するために、SDK は IAM Identity Center のアクセストークンを使用して IAM セッションを取得します。この IAM セッションはアクセス許可セットセッションと呼ばれ、IAM ロールを引き受けることで SDK AWS へのアクセスを提供します。
+ アクセス許可セットのセッション期間は IAM Identity Center のセッション期間とは独立して設定されます。
+ アクセス許可セットのセッション期間を設定する方法については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[セッション期間の設定](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html)」を参照してください。
+ アクセス許可セット認証情報は、ほとんどの AWS SDK API ドキュメントで*AWS 認証情報*と *sigv4 認証情報*とも呼ばれることに注意してください。
アクセス許可セットの認証情報は、IAM Identity Center API の [getRoleCredentials](https://docs.aws.amazon.com/singlesignon/latest/PortalAPIReference/API_GetRoleCredentials.html) への呼び出しから SDK に返されます。SDK のクライアントオブジェクトは、引き受けた IAM ロールを使用して AWS のサービス、アカウントのバケットを一覧表示するように Amazon S3 に依頼するなど、 を呼び出します。クライアントオブジェクトは、アクセス許可セットセッションの有効期限が切れるまで、それらのアクセス許可セット認証情報を使用して操作を続けることができます。
### セッションの有効期限と更新
[SSO トークンプロバイダー設定](feature-sso-credentials.md#sso-token-config) を使用する場合、IAM Identity Center から取得した 1 時間単位のアクセストークンは、更新トークンを使用して自動的に更新されます。
+ SDK がアクセストークンを使用しようとしたときにそのアクセストークンの有効期限が切れている場合、SDK は更新トークンを使用して新しいアクセストークンの取得を試みます。IAM Identity Center は、更新トークンを IAM Identity Center のアクセスポータルのセッション期間と比較します。更新トークンの有効期限が切れていない場合、IAM Identity Center は別のアクセストークンで応答します。
+ このアクセストークンは、既存のクライアントのアクセス許可セットセッションを更新したり、新しいクライアントの認証情報を解決したりするために使用できます。
ただし、IAM Identity Center アクセスポータルセッションの有効期限が切れると、新しいアクセストークンは付与されません。そのため、アクセス許可セットの有効期間は更新できません。既存のクライアントのキャッシュされたアクセス許可セットセッションの長さがタイムアウトになると、有効期限が切れます（アクセスも失われます）。
IAM Identity Center セッションの有効期限が切れるとすぐに、新しいクライアントを作成するコードは認証に失敗します。これは、アクセス許可セットの認証情報がキャッシュされないためです。有効なアクセストークンが得られるまで、コードで新しいクライアントを作成したり、認証情報解決プロセスを完了したりすることはできません。
まとめると、SDK が新しいアクセス許可セット認証情報を必要とする場合、SDK はまず有効な既存の認証情報を確認し、それらを使用します。これは、認証情報が新しいクライアントのものか、認証情報の有効期限が切れた既存のクライアントのものかに関係なく適用されます。認証情報が見つからない、または有効でない場合、SDK は IAM Identity Center API を呼び出して新しい認証情報を取得します。API を呼び出すには、アクセストークンが必要です。アクセストークンの有効期限が切れている場合、SDK は更新トークンを使用して、IAM Identity Center サービスから新しいアクセストークンを取得しようとします。このトークンは、IAM Identity Center アクセスポータルセッションの有効期限が切れていない場合に付与されます。
# IAM Roles Anywhere を使用した AWS SDKsとツールの認証
IAM Roles Anywhere を使用して、 の外部で実行されるサーバー、コンテナ、アプリケーションなどのワークロードの一時的なセキュリティ認証情報を IAM で取得できます AWS。IAM Roles Anywhere を使用するには、ワークロードで X.509 証明書を使用する必要があります。IAM Roles Anywhere を認証情報プロバイダーとして設定するのに必要な証明書とプライベートキーは、クラウド管理者が提供する必要があります。
## ステップ 1：IAM Roles Anywhere を設定します
IAM Roles Anywhere は、 の外部で実行されるワークロードまたはプロセスの一時的な認証情報を取得する方法を提供します AWS。認証機関との間でトラストアンカーが確立され、関連する IAM ロールの一時的な認証情報を取得できます。このロールは、コードが IAM Roles Anywhere で認証されるときにワークロードが持つアクセス許可を設定します。
トラストアンカー、IAM ロール、IAM Roles Anywhere プロファイルを設定する手順については、IAM Roles Anywhere *ユーザーガイド*の[AWS Identity and Access Management 「Roles Anywhere でのトラストアンカーとプロファイルの作成](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html)」を参照してください。
**注記**
「*IAM Roles Anywhere ユーザーガイド*」の*プロファイル*は、IAM Roles Anywhere サービス内の独特の概念を指しています。共有 AWS `config`ファイル内のプロファイルとは関係ありません。
## ステップ 2：IAM Roles Anywhere の使用
IAM Roles Anywhere から一時的なセキュリティ認証情報を取得するには、IAM Roles Anywhere にある認証情報ヘルパーツールを使用してください。この認証情報ツールは IAM Roles Anywhere の署名プロセスを実装します。
認証情報ヘルパーツールをダウンロードする手順については、IAM [AWS Identity and Access Management Roles Anywhere ユーザーガイドの「Roles Anywhere から一時的なセキュリティ認証情報を取得する](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html)**」を参照してください。
AWS SDKs と で IAM Roles Anywhere の一時的なセキュリティ認証情報を使用するには AWS CLI、共有 AWS `config`ファイルで `credential_process` 設定を設定できます。SDKs と は、 が認証`credential_process`に使用するプロセス認証情報プロバイダー AWS CLI をサポートします。`credential_process` を設定する一般的な構造を以下に示します。
```
credential_process = [path to helper tool] [command] [--parameter1 value] [--parameter2 value] [...]
```
ヘルパーツールの `credential-process` コマンドは、`credential_process` 設定と互換性のある標準 JSON 形式で一時的な認証情報を返します。コマンド名にはハイフンが含まれていますが、設定名にはアンダースコアが含まれていることに注意してください。コマンドには以下のパラメータが必要となります。
+ `private-key` – リクエストに署名したプライベートキーへのパス。
+ ` certificate` – 証明書へのパス。
+ `role-arn` – 一時的な認証情報を取得するロールの ARN。
+ `profile-arn` – 指定されたロールのマッピングを行うプロファイルの ARN。
+ `trust-anchor-arn` – 認証に使用するトラストアンカーの ARN。
クラウド管理者は、証明書とプライベートキーを提供する必要があります。3 つの ARN 値はすべて AWS マネジメントコンソールからコピーできます。次の例は、ヘルパーツールから一時的な認証情報を取得するように設定した共有 `config` ファイルを示しています。
```
[profile dev]
credential_process = ./aws_signing_helper credential-process --certificate /path/to/certificate --private-key /path/to/private-key --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID --role-arn arn:aws:iam::account:role/ROLE_ID
```
オプションのパラメータとその他のヘルパーツールの詳細については、GitHub の「[IAM Roles Anywhere 認証情報ヘルパー](https://github.com/aws/rolesanywhere-credential-helper#readme)」を参照してください。
SDK 設定自体とプロセス認証情報プロバイダーの詳細については、このガイドの「[プロセス認証情報プロバイダー](feature-process-credentials.md)」を参照してください。
# AWS SDKsとツールを認証するための AWS 認証情報を持つロールの引き受け
ロールでは、他の方法ではアクセスできない AWS リソースへのアクセスに、一時的なセキュリティ認証情報のセットを使用する必要があるとします。これらの一時的な認証情報は、アクセスキー ID、シークレットアクセスキー、およびセキュリティトークンで構成されています。 AWS Security Token Service (AWS STS) API リクエストの詳細については、「*AWS Security Token Service API リファレンス*」の「[アクション](https://docs.aws.amazon.com/STS/latest/APIReference/API_Operations.html)」を参照してください。
ロールを引き受けるように SDK またはツールを設定するには、まず引き受けるのための特定の*ロール*を作成または特定する必要があります。IAM ロールは、ロール (Amazon リソースネーム (「[ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)」 )で一意に識別されます。ロールは別のエンティティとの信頼関係を確立します。ロールを使用する信頼されたエンティティは、 AWS のサービス または別のエンティティである可能性があります AWS アカウント。ロールの作成と使用の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールを使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールが特定されると、そのロールから信頼されている場合は、そのロールによって付与された権限を使用するように SDK またはツールを設定できます。
**注記**
可能な限りリージョンエンドポイントを使用し、 を設定することが AWS ベストプラクティスです[AWS リージョン](feature-region.md)。
## IAM ロールの継承
ロールを引き受けると、 は一時的なセキュリティ認証情報のセット AWS STS を返します。これらの認証情報は、別のプロファイル、またはコードが実行されているインスタンスまたはコンテナから取得されます。通常、このタイプのロールの引き受けは、あるアカウントで AWS 認証情報を持っているが、アプリケーションが別のアカウントのリソースにアクセスする必要がある場合に使用されます。
### ステップ 1: IAM ロールを設定する
ロールを引き受けるように SDK またはツールを設定するには、まず引き受けるのための特定のロールを作成または特定する必要があります。IAM ロールはロール「[ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)」 を使用して一意に識別されます。ロールは別のエンティティとの信頼関係を確立します。通常はアカウント内またはクロスアカウントアクセス用です。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」の「*IAM ロールの作成*」を参照してください。
### ステップ 2: SDK またはツールを設定する
`credential_source` または `source_profile` から認証情報を取得するように SDK またはツールを設定します。
`credential_source` を使用してAmazon ECS コンテナ、Amazon EC2 インスタンス、または環境変数から認証情報を取得します。
`source_profile` を使用して別のプロファイルから認証情報を取得します。 `source_profile` はまた、ロールチェイニングもサポートしています。ロールチェイニングとは、引き受けたロールを使って別のロールを引き受けるプロファイルの階層構造です。
プロファイルでこれを指定すると、SDK またはツールは対応する AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API コールを自動的に実行します。ロールを引き受けて一時的な認証情報を取得して使用するには、共有 AWS `config`ファイルで次の設定値を指定します。これらの設定の詳細については、「[ロール認証情報プロバイダーを引き受けます](feature-assume-role-credentials.md#feature-assume-role-credentials-settings)」を参照してください。
+ `role_arn` - ステップ 1 で作成された IAM ロール
+ `credential_source` または `source_profile` のいずれかを設定します
+ (オプション) `duration_seconds`
+ (オプション) `external_id`
+ (オプション) `mfa_serial`
+ (オプション) `role_session_name`
次の例は、 `config` 共有ファイル内の 2 つの引き受けロールオプションの設定を示しています。
```
role_arn = arn:aws:iam::123456789012:role/my-role-name
credential_source = Ec2InstanceMetadata
```
```
[profile-with-user-that-can-assume-role]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token=IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE
[profile dev]
region = us-east-1
output = json
role_arn = arn:aws:iam::123456789012:role/my-role-name
source_profile = profile-with-user-that-can-assume-role
role_session_name = my_session
```
すべての引き受けロールの認証情報プロバイダーの設定の詳細については、このガイドの「[ロール認証情報プロバイダーを引き受けます](feature-assume-role-credentials.md)」を参照してください。
# ウェブ ID または OpenID Connect でロールを引き受けて AWS SDKsとツールを認証する
ロールでは、他の方法ではアクセスできない AWS リソースへのアクセスに、一時的なセキュリティ認証情報のセットを使用する必要があるとします。これらの一時的な認証情報は、アクセスキー ID、シークレットアクセスキー、およびセキュリティトークンで構成されています。 AWS Security Token Service (AWS STS) API リクエストの詳細については、「*AWS Security Token Service API リファレンス*」の「[アクション](https://docs.aws.amazon.com/STS/latest/APIReference/API_Operations.html)」を参照してください。
ロールを引き受けるように SDK またはツールを設定するには、まず引き受けるのための特定の*ロール*を作成または特定する必要があります。IAM ロールは、ロール (Amazon リソースネーム (「[ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)」 )で一意に識別されます。ロールは別のエンティティとの信頼関係を確立します。ロールを使用する信頼できるエンティティは、ウェブ ID プロバイダーまたは OpenID Connect (OIDC)、または SAML フェデレーションである可能性があります。IAM ロールの詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
SDK で IAM ロールを設定した後、そのロールが ID プロバイダーを信頼するように設定されている場合は、一時的な AWS 認証情報を取得するために、そのロールを引き受けるように SDK をさらに設定できます。
**注記**
可能な限りリージョンエンドポイントを使用し、 を設定することが AWS ベストプラクティスです[AWS リージョン](feature-region.md)。
## ウェブアイデンティティまたは OpenID Connect でのフェデレーション
Login With Amazon、Facebook、Google などのパブリック ID プロバイダーの JSON ウェブトークン (JWTs) を使用して、 を使用して一時的な AWS 認証情報を取得できます`AssumeRoleWithWebIdentity`。使用方法によって、これらの JWT は ID トークンまたはアクセストークンと呼ばれます。EntraId や PingFederate などの OIDC の検出プロトコルと互換性のある ID プロバイダー (IdP) から発行された JWT を使用することもできます。
Amazon Elastic Kubernetes Service を使用している場合、この機能により、Amazon EKS クラスターのサービスアカウントごとに異なる IAM ロールを指定できます。この Kubernetes 機能はJWTs をポッドに配布します。ポッドは、一時的な AWS 認証情報を取得するためにこの認証情報プロバイダーによって使用されます。この Amazon EKS の設定の詳細については、「**Amazon EKS ユーザーガイド**」の「[サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)」を参照してください。ただし、より単純なオプションとして、[SDK がサポートしている](feature-container-credentials.md#feature-container-credentials-sdk-compat)場合は、代わりに [Amazon EKS Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) を利用することをお勧めします。
### ステップ 1: ID プロバイダーと IAM ロールを設定する
外部 IdP とのフェデレーションを設定するには、IAM ID プロバイダーを使用して、外部 IdP とその設定 AWS について に通知します。これにより、 AWS アカウント と外部 IdP 間の*信頼*が確立されます。認証のために JSON Web Token (JWT) を使用するように SDK を設定する前に、まず ID プロバイダー (IdP) と、それにアクセスするための IAM ロールを設定する必要があります。これらを設定するには、「*IAM ユーザーガイド*」の「[ウェブ OpenID Connect フェデレーション用のロールの作成 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)」 を参照してください。
### ステップ 2: SDK またはツールを設定する
AWS STS 認証に からの JSON ウェブトークン (JWT) を使用するように SDK またはツールを設定します。
プロファイルでこれを指定すると、SDK またはツールは対応する AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API コールを自動的に実行します。ウェブ ID フェデレーションを使用して一時的な認証情報を取得して使用するには、共有 AWS `config`ファイルに次の設定値を指定します。これらの設定の詳細については、「[ロール認証情報プロバイダーを引き受けます](feature-assume-role-credentials.md#feature-assume-role-credentials-settings)」を参照してください。
+ `role_arn` - ステップ 1 で作成された IAM ロール
+ `web_identity_token_file`-外部 IdP から
+ (オプション) `duration_seconds`
+ (オプション) `role_session_name`
ウェブ IDを使用してロールを引き受ける `config` 共有ファイル設定の例を次に示します。
```
[profile web-identity]
role_arn=arn:aws:iam::123456789012:role/my-role-name
web_identity_token_file=/path/to/a/token
```
**注記**
モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。Amazon Cognito は ID ブローカーとして機能し、ユーザーの代わりに多くのフェデレーション作業を行います。ただし、Amazon Cognito ID プロバイダーは、他の ID プロバイダーのように SDK やツールのコアライブラリには含まれていません。Amazon Cognito API にアクセスするには、SDK またはツールのビルドまたはライブラリに Amazon Cognito サービスクライアントを含めてください。 AWS SDKs*Amazon Cognito デベロッパーガイド*」の[「コード例](https://docs.aws.amazon.com/cognito/latest/developerguide/service_code_examples.html)」を参照してください。
すべての引き受けロールの認証情報プロバイダーの設定の詳細については、このガイドの「[ロール認証情報プロバイダーを引き受けます](feature-assume-role-credentials.md)」を参照してください。
# AWS アクセスキーを使用して AWS SDKsとツールを認証する
AWS アクセスキーの使用は、 AWS SDKsとツールを使用する場合の認証のオプションです。
## 短期の認証情報を使用します
セッション期間の長いオプションを使用するには、[IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md) を使用するように SDK またはツールを設定することをお勧めします。
ただし、SDK またはツールの一時認証情報を直接設定する方法については、「[短期認証情報を使用して AWS SDKsとツールを認証する短期の認証情報](access-temp-idc.md)」を参照してください。
## 長期認証情報の使用
**警告**
セキュリティリスクを避けるため、専用ソフトウェアを開発するときや実際のデータを扱うときは、IAM ユーザーを認証に使用しないでください。代わりに、[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) などの ID プロバイダーとのフェデレーションを使用してください。
### 間のアクセスを管理する AWS アカウント
セキュリティのベストプラクティスとして、IAM Identity Center AWS Organizations で を使用して、すべての へのアクセスを管理することをお勧めします AWS アカウント。詳細については、「*IAM ユーザーガイド*」の「[IAM でのセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
IAM アイデンティティセンターでユーザーを作成するか、Microsoft Active Directory を使用するか、SAML 2.0 ID プロバイダー (IdP) を使用するか、IdP を個別にフェデレーションできます AWS アカウント。これらのアプローチのいずれかを使用して、ユーザーにシングルサインオンのエクスペリエンスを提供できます。多要素認証 (MFA) を適用し、一時的な認証情報を使用して AWS アカウント アクセスすることもできます。これは IAM ユーザーとは異なります。IAM ユーザーは、共有できる長期的な認証情報であり、 AWS リソースに対するセキュリティリスクが高まる可能性があります。
### サンドボックス環境専用の IAM ユーザーを作成する
を初めて使用する場合は AWS、テスト IAM ユーザーを作成し、それを使用してチュートリアルを実行し、 が提供する AWS ものを調べることができます。学習中はこの種の資格情報を使用しても問題ありませんが、サンドボックス環境以外では使用しないことをお勧めします。
以下のユースケースでは、 で IAM ユーザーの使用を開始するのが理にかなっている場合があります AWS。
+ AWS SDK またはツールの使用を開始し、 AWS のサービス サンドボックス環境で探索する。
+ 学習の一環として、人間によるサインインプロセスをサポートしない、スケジュールされたスクリプト、ジョブ、その他の自動プロセスを実行する。
これらのユースケース以外で IAM ユーザーを使用している場合は、IAM Identity Center に移行するか、ID プロバイダーを AWS アカウント できるだけ早く にフェデレーションします。詳細については、「[AWSでの ID フェデレーション](https://aws.amazon.com/identity/federation/)」を参照してください。
### IAM ユーザーのアクセスキーを保護する
IAM ユーザーのアクセスキーは定期的に更新する必要があります。「*IAM ユーザーガイド*」の「[Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)」のガイダンスに従ってください。IAM ユーザーのアクセスキーを誤って共有したと思われる場合は、アクセスキーを更新してください。
IAM ユーザーアクセスキーは、ローカルマシンの共有 AWS `credentials`ファイルに保存する必要があります。IAM ユーザーのアクセスキーをコードに保存しないでください。IAM ユーザーのアクセスキーを含む設定ファイルは、いずれのソースコード管理ソフトウェアにも含めないでください。オープンソースプロジェクトの [git-secrets](https://github.com/awslabs/git-secrets) などの外部ツールを使用すると、機密情報を誤って Git リポジトリにコミットすることを防ぐことができます。詳細については、「*IAM ユーザーガイド*」の「[IAM アイデンティティ (ユーザー、ユーザーグループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」を参照してください。
はじめに IAM ユーザーを設定するには、「[長期認証情報を使用して AWS SDKsとツールを認証する](access-iam-users.md)」を参照してください。
# 短期認証情報を使用して AWS SDKsとツールを認証する
拡張セッション期間オプション[IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md)で使用するように AWS SDK またはツールを設定することをお勧めします。ただし、 AWS アクセスポータルで利用可能な一時的な認証情報をコピーして使用できます。有効期限が切れたら、新しい認証情報をコピーする必要があります。一時的な認証情報は、プロファイルで使用することも、システムプロパティや環境変数の値として使用することもできます。
ベストプラクティス: 認証情報ファイル内のアクセスキーとトークンを手動で管理する代わりに、アプリケーションでは以下から配信される一時的な認証情報を使用することをお勧めします。
+ Amazon Elastic Compute Cloud または でアプリケーションを実行するなどのコンピューティング AWS サービス AWS Lambda。
+ [IAM Identity Center を使用して AWS SDK とツールを認証する](access-sso.md) などの、認証情報プロバイダーチェーンの別のオプション。
+ または [プロセス認証情報プロバイダー](feature-process-credentials.md) を使用して一時的な認証情報を取得します。
**AWS アクセスポータルから取得した短期認証情報を使用して認証情報ファイルを設定する**
1. [認証情報の共有ファイルの作成](https://docs.aws.amazon.com/sdkref/latest/guide/file-location.html)。
1. 認証情報ファイルに、作業用の一時認証情報を貼り付けるまで、次のプレースホルダーテキストを貼り付けます。
```
[default]
aws_access_key_id=
aws_secret_access_key=
aws_session_token=
```
1. ファイルを保存します。これで、`~/.aws/credentials` ファイルはローカルの開発システムに存在しているはずです。このファイルには、特定の名前付きプロファイルが指定されていない場合に SDK またはツールが使用する [[デフォルト] プロファイル](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html#file-format-profile)が含まれています。
1. [AWS アクセスポータルにサインインします](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosignin.html)。
1. アクセス AWS ポータルから IAM ロールの[認証情報をコピーするには、認証情報の手動更新](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html#how-to-get-temp-credentials)の手順に従います。
1. リンク先の手順のステップ 4 で、開発ニーズに合ったアクセスを許可する IAM ロールの名前を選択します。通常、このロールには **PowerUserAccess** や **Developer** などの名前が付いています。
1. リンク先の手順のステップ 7 で、**[ AWS 認証情報ファイルにプロファイルを手動で追加]** オプションを選択し、内容をコピーします。
1. コピーした認証情報をローカル `credentials` ファイルに貼り付けます。`default` プロファイルを使用する場合、生成されたプロファイル名は必要ありません。ファイルは以下のようになります。
```
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token=IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE
```
1. `credentials` ファイルを保存します。
SDK は、サービスクライアントを作成するときに、これらの一時的な認証情報にアクセスしてリクエストごとに使用します。ステップ 5a で選択した IAM ロールの設定により、[一時的な認証情報の有効期間](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html)が決まります。最大期間は 12 時間です。
一時的な認証情報の有効期限が切れたら、ステップ 4～7 を繰り返します。
# 長期認証情報を使用して AWS SDKsとツールを認証する
**警告**
セキュリティリスクを避けるため、専用ソフトウェアを開発するときや実際のデータを扱うときは、IAM ユーザーを認証に使用しないでください。代わりに、[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) などの ID プロバイダーとのフェデレーションを使用してください。
IAM ユーザーを使用してコードを実行する場合、開発環境の SDK またはツールは、共有 AWS `credentials`ファイルで長期的な IAM ユーザー認証情報を使用して認証します。「[IAM トピックのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」 を確認し、できるだけ早く IAM Identity Center またはその他の一時的な認証情報に移行してください。
## 認証情報に関する重要な警告とガイダンス
**認証情報に関する警告**
+ お使いのアカウントのルート認証情報を使用して AWS リソースにアクセス***しないでください***。これらの認証情報は無制限のアカウントアクセスを提供し、取り消すのが困難です。
+ アプリケーションファイルにリテラルアクセスキーや認証情報を***配置しないでください***。これを行うと、パブリックリポジトリにプロジェクトをアップロードするなど、誤って認証情報が公開されるリスクが発生します。
+ プロジェクト領域に認証情報を含むファイルを***含めないでください***。
+ 共有 AWS `credentials`ファイルに保存されている認証情報はすべてプレーンテキストで保存されることに注意してください。
**認証情報を安全に管理するための追加のガイダンス**
AWS 認証情報を安全に管理する方法の一般的な説明については、『』の[AWS 「アクセスキーを管理するためのベストプラクティス](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)」を参照してください[AWS 全般のリファレンス](https://docs.aws.amazon.com/general/latest/gr/)。そこでの説明に加えて、以下の点を考慮してください。
+ Amazon Elastic Container Service (Amazon ECS) タスクで、[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)を使用します。
+ Amazon EC2 インスタンスで実行中のアプリケーションに対して、[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を使用します。
## 前提条件: AWS アカウントを作成する
IAM ユーザーを使用して AWS サービスにアクセスするには、 AWS アカウントと AWS 認証情報が必要です。
1. **アカウントを作成する。**
AWS アカウントを作成するには、「 *AWS アカウント管理 リファレンスガイド*」の[「開始方法: 初めての AWS ユーザーですか?](https://docs.aws.amazon.com/accounts/latest/reference/welcome-first-time-user.html)」を参照してください。
1. **管理者ユーザーを作成します。**
マネジメントコンソールとサービスへのアクセスには、root ユーザーアカウント (作成した初期アカウント) を使用しないでください。代わりに、「*IAM ユーザーガイド*」の「[管理ユーザーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin)」で説明されているように、管理ユーザーアカウントを作成します。
管理ユーザーアカウントを作成してログインの詳細を記録したら、**ルートユーザーアカウントから確実にサインアウトし**、管理者アカウントを使用して再度サインインします。
これらのアカウントはいずれも、 での開発 AWS や でのアプリケーションの実行には適していません AWS。そのためには、これらのタスクに適したユーザー、アクセス許可セットまたはサービスロールを作成する必要があります。詳細については、「*IAM ユーザーガイド*」の「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
## ステップ 1: IAM ユーザーを作成する
+ 「*IAM ユーザーガイド*」の「[IAM ユーザーの作成 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)」の手順に従って IAM ユーザーを作成します。IAM ユーザーを作成する場合:
+ **[ AWS マネジメントコンソールへのユーザーアクセスを提供]** を選択することをお勧めします。これにより、 AWS CloudTrail 診断ログの確認や Amazon Simple Storage Service へのファイルのアップロードなど、ビジュアル環境で実行しているコードに関連する AWS のサービス を表示できます。これは、コードをデバッグするときに役立ちます。
+ **[アクセス許可を設定]** - **[アクセス許可オプション]** で、このユーザーにアクセス許可を割り当てる方法として **[ポリシーを直接アタッチする]** を選択します。
+ ほとんどの「開始方法」 SDK チュートリアルでは、Amazon S3 サービスを例として使用しています。アプリケーションに Amazon S3 へのフルアクセスを提供するには、このユーザーにアタッチする `AmazonS3FullAccess` ポリシーを選択します。
+ アクセス許可の境界またはタグの設定に関する手順のオプションのステップは無視できます。
## ステップ 2: アクセスキーを取得する
1. IAM コンソールのナビゲーションペインで **[ユーザー]** を選択し、以前に作成したユーザーの **User name** を選択します。
1. ユーザーのページで、**[セキュリティ認証情報]** ページを選択します。次に、**[アクセスキー]** で **[アクセスキーの作成]** を選択します。
1. **[アクセスキーを作成ステップ1]**で、**[コマンドラインインターフェイス (CLI)]**または**[ローカルコード]**を選択します。どちらのオプションも、 AWS CLI と SDKs の両方で使用するのと同じタイプのキーを生成します。
1. **[アクセスキーの作成ステップ 2]** で、オプションのタグを入力して **[次へ]** を選択します。
1. **[アクセスキーの作成ステップ 3]** で、**[.csv ファイルをダウンロード]** を選択し、IAM ユーザーのアクセスキーとシークレットアクセスキーを含む `.csv` ファイルを保存します。この情報は後で必要になります。
**警告**
適切なセキュリティ対策を講じてこれらの認証情報を安全に保管してください。
1. **[完了]** を選択します。
## ステップ 3: `credentials` 共有ファイルを更新する
1. 共有 AWS `credentials` ファイルを作成するか、開きます。このファイルは、`~/.aws/credentials` Linux および macOS システム、および `%USERPROFILE%\.aws\credentials` Windows 上にあります。詳細については、「[認証情報ファイルの場所](https://docs.aws.amazon.com/credref/latest/refdocs/file-location.html)」 を参照してください。
1. 共有 `credentials` ファイルに次のテキストを追加します。ID 値の例とキー値の例を、先にダウンロードした `.csv` ファイルの値に置き換えます。
```
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
1. ファイルを保存します。
認証情報を保存する最も一般的な方法は `credentials` 共有ファイルです。これらは環境変数として設定することもできます。[AWS アクセスキー](feature-static-credentials.md)の環境変数名を参照してください。これは始めるための方法ですが、IAM Identity Center やその他の一時的な認証情報にできるだけ早く移行することをお勧めします。長期認証情報の使用から移行した後は、必ず `credentials` 共有ファイルからこれらの認証情報を削除してください。
# IAM ロールを使用して Amazon EC2 にデプロイされたアプリケーションを認証する
この例では、Amazon Elastic Compute Cloud インスタンスにデプロイされたアプリケーションで使用する Amazon S3 アクセスを持つ AWS Identity and Access Management ロールの設定について説明します。
Amazon Elastic Compute Cloud インスタンスで AWS SDK アプリケーションを実行するには、IAM ロールを作成し、Amazon EC2 インスタンスにそのロールへのアクセス権を付与します。詳細については、*Amazon EC2 ユーザーガイド*の「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)」を参照してください。
## IAM ロールを作成する
開発する AWS SDK アプリケーションは、アクションを実行 AWS のサービス するために少なくとも 1 つにアクセスする可能性があります。アプリケーションを実行するために必要なアクセス許可を付与する IAM ロールを作成します。
この手順では、例として Amazon S3 への読み取り専用アクセスを付与するロールを作成します。多くの AWS SDK ガイドには、Amazon S3 から読み取る「開始方法」チュートリアルがあります。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. ナビゲーションペインで **[ロール]**、**[ロールを作成]** の順に選択します。
1. **[信頼されたエンティティタイプ]** で **[信頼されたエンティティを選択]** するため、**[AWS のサービス］**を選択します。
1. **[Use case]** (ユースケース) で **[Amazon EC2]** を選択し、**[Next]** (次へ) を選択します。
1. **[権限の追加]** では、ポリシーリストから ** [Amazon S3 読み取り専用アクセス］** のチェックボックスを選択し、**[次へ]** を選択します。
1. ロールの名前を入力し、[**ロールの作成**] を選択します。*この名前は Amazon EC2 インスタンスを作成するときに必要になるため、忘れないようにしてください。*
## Amazon EC2 インスタンスを起動して IAM ロールを指定します
IAM ロールを使用して Amazon EC2 インスタンスを作成し、起動するには、次の手順を実行します。
+ 「*Amazon EC2 ユーザーガイド*」の「[インスタンスをすばやく起動する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html#liw-quickly-launch-instance)」に従います。ただし、最後の送信のステップの前に、以下も実行します。
+ **[高度な詳細]** の **[IAM インスタンスプロファイル]** で、前のステップで作成したロールを選択します。
この IAM と Amazon EC2 のセットアップで、Amazon EC2 インスタンスにアプリケーションをデプロイすることができます。これにより、アプリケーションに Amazon S3 サービスへの読み取りアクセスが付与されます。
## EC2 インスタンスへの接続
Amazon EC2 インスタンスに接続することで、アプリケーションをそのインスタンスに転送して、アプリケーションを実行できるようにします。インスタンスを作成した際に **[キーペア (ログイン)]** で使用したキーペアのプライベート部分を含むファイル、すなわち PEM ファイルが必要になります。
これを行うには、お使いのインスタンスタイプ向けのガイダンス、「[SSH を使用した Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)」または「[RDP を使用した Windows インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」に従います。接続する際は、開発マシンからインスタンスにファイルを転送できるように接続してください。
**注記**
Linux または macOS ターミナルでは、セキュアコピーコマンドを使用してアプリケーションをコピーできます。キーペアで `scp` を使用するには、次のコマンドを使用します。`scp -i path/to/key file/to/copy ec2-user@ec2-xx-xx-xxx-xxx.compute.amazonaws.com:~`
Windows の詳細については、「[RDP を使用して Windows インスタンスにファイルを転送する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instanceWindowsFileTransfer.html)」を参照してください。
Toolkit を使用している場合は、 AWS Toolkit を使用してインスタンスに接続することもできます。詳細については、 ご利用されている Toolkit の特定のユーザーガイドをご参照ください。
## EC2 インスタンスでのアプリケーションの実行
1. ローカルドライブから Amazon EC2 インスタンスにアプリケーションファイルをコピーします。
1. アプリケーションを起動し、開発マシンと同じ実行結果が得られることを確認します。
1. （オプション）アプリケーションで、IAM ロールによって提供されている認証情報が使用されていることを確認します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. インスタンスを選択してください。
1. **[アクション]**、**[セキュリティ]**、**[IAM ロールを変更]** の順に選択します。
1. **[IAM ロール]** では、**[IAM ロールなし]** を選択して IAM ロールをデタッチします。
1. **[IAM ロールの更新]** を選択してください。
1. アプリケーションを再度実行して、認可エラーが返されることを確認します。
# TIP プラグインを使用して にアクセスする AWS のサービス
信頼できる ID 伝達 (TIP) は、 の管理者がグループの関連付けなどのユーザー属性に基づいてアクセス許可 AWS のサービス を付与 AWS IAM アイデンティティセンター できるようにする の機能です。信頼できる ID の伝播により、ID コンテキストが IAM ロールに追加され、 AWS リソースへのアクセスをリクエストしているユーザーを識別します。このコンテキストは他の AWS のサービスに伝達されます。
ID コンテキストは、 がアクセスリクエストを受信したときに承認の決定を行うために AWS のサービス 使用する情報で構成されます。この情報には、リクエスタ (IAM Identity Center ユーザーなど）、アクセスがリクエスト AWS のサービス される (Amazon Redshift など）、アクセス範囲 (読み取り専用アクセスなど) を識別するメタデータが含まれます。受信側 AWS のサービス は、このコンテキストとユーザーに割り当てられたアクセス許可を使用して、そのリソースへのアクセスを承認します。詳細については、「 AWS IAM アイデンティティセンター ユーザーガイド」の[「信頼できる ID の伝播の概要」の](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overview.html)「」を参照してください。
TIP プラグインは、信頼できる ID の伝播 AWS のサービス をサポートする で使用できます。リファレンスユースケースとして、「*Amazon Q Business User Guide*」の「[Configuring an Amazon Q Business application using AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/create-application.html)」を参照してください。
**注記**
Amazon Q Business を使用している場合は、「[Configuring an Amazon Q Business application using AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/create-application.html)」でサービス固有の手順を参照してください。
## TIP プラグインを使用するための前提条件
プラグインを機能させるには、次のリソースが必要です。
1. AWS SDK for Java または のいずれかを使用する必要があります AWS SDK for JavaScript。
1. 使用しているサービスが信頼できる ID の伝播をサポートしていることを確認します。
「*AWS IAM アイデンティティセンター ユーザーガイド*」にある「[AWS managed applications that integrate with IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/awsapps-that-work-with-identity-center.html)」の表の「**Enables trusted identity propagation through IAM Identity Center**」列を参照してください。
1. IAM Identity Center と信頼できる ID の伝播を有効にします。
「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[TIP prerequisites and considerations](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html)」を参照してください。
1. Identity-Center-integrated アプリケーションが必要です。
「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[AWS managed applications](https://docs.aws.amazon.com/singlesignon/latest/userguide/awsapps-quick-start-setting-up-identity-center-to-test-awsmanagedapps.html)」または「[Customer managed applications](https://docs.aws.amazon.com/singlesignon/latest/userguide/customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2.html)」を参照してください。
1. 信頼できるトークン発行者 (TTI) を設定し、サービスを IAM Identity Center に接続する必要があります。
「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[Prerequisites for trusted token issuers](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-apps-with-trusted-token-issuer.html#trusted-token-issuer-prerequisites)」および「[Tasks for setting up a trusted token issuer](https://docs.aws.amazon.com/singlesignon/latest/userguide/setuptrustedtokenissuer.html#setuptrustedtokenissuer-tasks)」を参照してください。
## コードで TIP プラグインを使用するには
1. 信頼できる ID の伝播プラグインのインスタンスを作成します。
1. とやり取りするためのサービスクライアントインスタンスを作成し AWS のサービス 、信頼できる ID 伝達プラグインを追加してサービスクライアントをカスタマイズします。
TIP プラグインは以下の入力パラメータを使用します。
+ **`webTokenProvider`**: 外部 ID プロバイダーから OpenID トークンを取得するためにお客様が実装する関数。
+ **`accessRoleArn`**: ユーザーの ID コンテキストを使用してプラグインが引き受ける IAM ロール ARN。ID 拡張認証情報を取得します。
+ **`applicationArn`**: クライアントまたはアプリケーションの一意の識別子文字列。この値は、OAuth 許可が設定されたアプリケーション ARN です。
+ **`ssoOidcClient`**: (オプション) [https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/ssooidc/SsoOidcClient.html](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/ssooidc/SsoOidcClient.html) for Java や [https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-client-sso-oidc/](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-client-sso-oidc/) for JavaScript など、お客様が定義した設定の SSO OIDC クライアント。指定しない場合、`applicationRoleArn` を使用する OIDC クライアントがインスタンス化されて使用されます。
+ **`stsClient`**: (オプション) お客様が定義した設定の AWS STS クライアント。ユーザーの ID コンテキストで `accessRoleArn` を引き受けるために使用されます。指定しない場合、 を使用する AWS STS クライアント`applicationRoleArn`はインスタンス化されて使用されます。
+ **`applicationRoleArn`**: (オプション) OIDC と AWS STS クライアントをブートストラップ`AssumeRoleWithWebIdentity`できるように で引き受ける IAM ロール ARN。
+ 指定しない場合は、`ssoOidcClient` と `stsClient` のパラメータの**両方**を指定する必要があります。
+ 指定した場合、`applicationRoleArn` は `accessRoleArn` のパラメータと同じ値にすることはできません。 `applicationRoleArn` は accessRole を引き受けるために使用される stsClient の構築に使用されます。`applicationRole` と の両方に同じロールが使用されている場合`accessRole`、ロールを使用してそれ自体を引き受ける (自己ロールの引き受け) ことを意味します。これは推奨されません AWS。詳細については、[お知らせ](https://aws.amazon.com/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/)を参照してください。
### `ssoOidcClient`、`stsClient`、および `applicationRoleArn` のパラメータに関する考慮事項
TIP プラグインを設定するときは、指定するパラメータに基づいて、次のアクセス許可要件を考慮してください。
+ `ssoOidcClient` と `stsClient` を指定する場合:
+ `ssoOidcClient` の認証情報には、アイデンティティセンターを呼び出してアイデンティティセンター固有のユーザーコンテキストを取得するための `oauth:CreateTokenWithIAM` アクセス許可が必要です。
+ `stsClient` の認証情報には、`sts:AssumeRole` と、`accessRole` の `sts:SetContext` のアクセス許可が必要です。また、`accessRole` には、`stsClient` の認証情報との信頼関係を構成する必要があります。
+ `applicationRoleArn` を指定する場合:
+ `applicationRole` は OIDC および STS クライアントの構築に使用されるため、必要なリソース (IdC インスタンス、`accessRole`) での `oauth:CreateTokenWithIAM`、`sts:AssumeRole`、および `sts:SetContext` のアクセス許可が必要です。
+ `webToken` はプラグインによる [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 呼び出しを介して applicationRole を引き受けるために使用されるため、`applicationRole` は、`webToken` の生成に使用される ID プロバイダーとの信頼関係が必要です。
**ApplicationRole 構成の例:**
ウェブトークンプロバイダーとの信頼ポリシー:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/IDENTITY_PROVIDER_URL"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"IDENTITY_PROVIDER_URL:aud": "CLIENT_ID_TO_BE_TRUSTED"
}
}
}
]
}
```
アクセス許可ポリシー:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetContext"
],
"Resource": [
"accessRoleArn"
]
},
{
"Effect": "Allow",
"Action": [
"sso-oauth:CreateTokenWithIAM"
],
"Resource": [
"*"
]
}
]
}
```
## TIP を使用したコードの例
以下の例は、 AWS SDK for Java または を使用してコードに TIP プラグインを実装する方法を示しています AWS SDK for JavaScript。
------
#### [ Java ]
AWS SDK for Java プロジェクトで TIP プラグインを使用するには、プロジェクトの `pom.xml` ファイルで TIP プラグインを依存関係として宣言する必要があります。
```
software.amazon.awsidentity.trustedIdentityPropagation
aws-sdk-java-trustedIdentityPropagation-java-plugin
2.0.0
```
ソースコードに、`software.amazon.awssdk.trustedidentitypropagation` に必要なパッケージステートメントを含めます。
次の例は、信頼できる ID の伝播プラグインのインスタンスを作成し、サービスクライアントに追加する 2 つの方法を示しています。どちらの例も Amazon S3 をサービスとして使用し、 `S3AccessGrantsPlugin`を使用してユーザー固有のアクセス許可を管理しますが、信頼できる ID 伝達 (TIP) AWS のサービス をサポートする任意の に適用できます。
**注記**
これらの例では、S3 Access Grants からユーザー固有のアクセス許可を設定する必要があります。詳細については、[S3 Access Grants のドキュメント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html)を参照してください。
**オプション 1: OIDC クライアントと STS クライアントを構築して渡す**
```
SsoOidcClient oidcClient = SsoOidcClient.builder()
.region(Region.US_EAST_1)
.credentialsProvider(credentialsProvider).build();
StsClient stsClient = StsClient.builder()
.region(Region.US_EAST_1)
.credentialsProvider(credentialsProvider).build();
TrustedIdentityPropagationPlugin trustedIdentityPropagationPlugin = TrustedIdentityPropagationPlugin.builder()
.webTokenProvider(() -> webToken)
.applicationArn(idcApplicationArn)
.accessRoleArn(accessRoleArn)
.ssoOidcClient(oidcClient)
.stsClient(stsClient)
.build();
S3AccessGrantsPlugin accessGrantsPlugin = S3AccessGrantsPlugin.builder()
.build();
S3Client s3Client =
S3Client.builder().region(Region.US_EAST_1)
.crossRegionAccessEnabled(true)
.addPlugin(trustedIdentityPropagationPlugin)
.addPlugin(accessGrantsPlugin)
.build();
final var resp = s3Client.getObject(GetObjectRequest.builder()
.key("path/to/object/fileName")
.bucket("bucketName")
.build());
```
**オプション 2: applicationRoleArn を渡してクライアント作成をプラグインに任せる**
```
TrustedIdentityPropagationPlugin trustedIdentityPropagationPlugin = TrustedIdentityPropagationPlugin.builder()
.webTokenProvider(() -> webToken)
.applicationArn(idcApplicationArn)
.accessRoleArn(accessRoleArn)
.applicationRoleArn(applicationRoleArn)
.build();
S3AccessGrantsPlugin accessGrantsPlugin = S3AccessGrantsPlugin.builder()
.build();
S3Client s3Client =
S3Client.builder().region(Region.US_EAST_1)
.crossRegionAccessEnabled(true)
.addPlugin(trustedIdentityPropagationPlugin)
.addPlugin(accessGrantsPlugin)
.build();
final var resp = s3Client.getObject(GetObjectRequest.builder()
.key("path/to/object/fileName")
.bucket("bucketName")
.build());
```
詳細とソースについては、GitHub の「[trusted-identity-propagation-java](https://github.com/aws-sdk-plugin/trusted-identity-propagation-java)」を参照してください。
------
#### [ JavaScript ]
次のコマンドを実行して、TIP 認証プラグインパッケージを AWS SDK for JavaScript プロジェクトにインストールします。
```
$ npm i @aws-sdk-extension/trusted-identity-propagation
```
最後の `package.json` には、次のような依存関係を含める必要があります。
```
"dependencies": {
"@aws-sdk-extension/trusted-identity-propagation": "^2.0.0"
},
```
ソースコードで、必要な `TrustedIdentityPropagationExtension` 依存関係をインポートします。
次の例は、信頼できる ID の伝播プラグインのインスタンスを作成し、サービスクライアントに追加する 2 つの方法を示しています。どちらの例も Amazon S3 をサービスとして使用し、Amazon S3 Access Grants を使用してユーザー固有のアクセス許可を管理しますが、信頼できる ID 伝達 (TIP) AWS のサービス をサポートする任意の に適用できます。
**注記**
これらの例については、Amazon S3 Access Grants からユーザー固有のアクセス許可を設定する必要があります。詳細については、[S3 Access Grants のドキュメント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html)を参照してください。
**オプション 1: OIDC クライアントと STS クライアントを構築して渡す**
```
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { S3ControlClient, GetDataAccessCommand } from "@aws-sdk/client-s3-control";
import { TrustedIdentityPropagationExtension } from "@aws-sdk-extension/trusted-identity-propagation";
const s3ControlClient = new S3ControlClient({
region: "us-east-1",
extensions: [
TrustedIdentityPropagationExtension.create({
webTokenProvider: async () => {
return 'ID_TOKEN_FROM_YOUR_IDENTITY_PROVIDER';
},
ssoOidcClient: customOidcClient,
stsClient: customStsClient,
accessRoleArn: accessRoleArn,
applicationArn: applicationArn,
}),
],
});
const getDataAccessParams = {
Target: "S3_URI_PATH",
Permission: "READ",
AccountId: ACCOUNT_ID,
InstanceArn: S3_ACCESS_GRANTS_ARN,
TargetType: "Object",
};
try {
const command = new GetDataAccessCommand(getDataAccessParams);
const response = await s3ControlClient.send(command);
const credentials = response.Credentials;
// Create a new S3 client with the temporary credentials
const temporaryS3Client = new S3Client({
region: "us-east-1",
credentials: {
accessKeyId: credentials.AccessKeyId,
secretAccessKey: credentials.SecretAccessKey,
sessionToken: credentials.SessionToken,
},
});
// Use the temporary S3 client to perform the operation
const s3Params = {
Bucket: "BUCKET_NAME",
Key: "S3_OBJECT_KEY",
};
const getObjectCommand = new GetObjectCommand(s3Params);
const s3Object = await temporaryS3Client.send(getObjectCommand);
const fileContent = await s3Object.Body.transformToString();
// Process the S3 object data
console.log("Successfully retrieved S3 object:", fileContent);
} catch (error) {
console.error("Error accessing S3 data:", error);
}
```
**オプション 2: applicationRoleArn を渡してクライアント作成をプラグインに任せる**
```
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { S3ControlClient, GetDataAccessCommand } from "@aws-sdk/client-s3-control";
import { TrustedIdentityPropagationExtension } from "@aws-sdk-extension/trusted-identity-propagation";
const s3ControlClient = new S3ControlClient({
region: "us-east-1",
extensions: [
TrustedIdentityPropagationExtension.create({
webTokenProvider: async () => {
return 'ID_TOKEN_FROM_YOUR_IDENTITY_PROVIDER';
},
accessRoleArn: accessRoleArn,
applicationRoleArn: applicationRoleArn,
applicationArn: applicationArn,
}),
],
});
// Same S3 AccessGrants workflow as Option 1
const getDataAccessParams = {
Target: "S3_URI_PATH",
Permission: "READ",
AccountId: ACCOUNT_ID,
InstanceArn: S3_ACCESS_GRANTS_ARN,
TargetType: "Object",
};
try {
const command = new GetDataAccessCommand(getDataAccessParams);
const response = await s3ControlClient.send(command);
const credentials = response.Credentials;
const temporaryS3Client = new S3Client({
region: "us-east-1",
credentials: {
accessKeyId: credentials.AccessKeyId,
secretAccessKey: credentials.SecretAccessKey,
sessionToken: credentials.SessionToken,
},
});
const s3Params = {
Bucket: "BUCKET_NAME",
Key: "S3_OBJECT_KEY",
};
const getObjectCommand = new GetObjectCommand(s3Params);
const s3Object = await temporaryS3Client.send(getObjectCommand);
const fileContent = await s3Object.Body.transformToString();
console.log("Successfully retrieved S3 object:", fileContent);
} catch (error) {
console.error("Error accessing S3 data:", error);
}
```
詳細とソースについては、GitHub の「[trusted-identity-propagation-js](https://github.com/aws-sdk-plugin/trusted-identity-propagation-js)」を参照してください。
------