AWS SDK とツールを使用した認証とアクセス - AWS SDK とツール
アプリケーションコードを認証する方法の選択認証方法AWS ビルダー ID

AWS SDK とツールを使用した認証とアクセス

AWS SDK アプリケーションを開発したり、AWS ツールを使用して AWS のサービスを使用するときは、コードまたはツールが AWS で認証する方法を確立する必要があります。コードを実行する環境と利用可能な AWS のアクセスに応じて、AWS リソースへのプログラムによるアクセスはさまざまな方法で設定できます。

以下のオプションは、認証情報プロバイダーチェーンの一部です。つまり、共有 AWS config ファイルと credentials ファイルを適切に設定することで、AWS SDK またはツールはその認証方法を自動的に検出して使用します。

アプリケーションコードを認証する方法の選択

アプリケーションが AWS に対して行う呼び出しの認証方法を選択します。

コードを AWS で実行している場合、認証情報はアプリケーションで自動的に使用できるようになります。例えば、アプリケーションが Amazon Elastic Compute Cloud でホストされていて、そのリソースに関連付けられた IAM ロールがある場合、認証情報はアプリケーションで自動的に使用可能になります。同様に、Amazon ECS または Amazon EKS コンテナを使用する場合、IAM ロールの認証情報セットは、SDK の認証情報プロバイダーチェーンを介してコンテナ内で実行されるコードによって自動的に取得できます。

IAM ロールを使用して Amazon EC2 にデプロイされたアプリケーションを認証する — IAM ロールを使用して、Amazon EC2 インスタンスでアプリケーションを安全に実行します。

Lambda 関数を作成するときに、Lambda により最小限のアクセス許可で実行ロールが作成されます。AWS SDK またはツールは、実行時に Lambda 実行環境を介して Lambda にアタッチされた IAM ロールを自動的に使用します。

タスク用の IAM ロールを使用します。タスクロールを作成し、Amazon ECS タスク定義でそのロールを指定する必要があります。AWS SDK またはツールは、実行時にタスクに割り当てられた IAM ロールを Amazon ECS メタデータを介して自動的に使用します。

Amazon EKS Pod Identity を使用することをお勧めします。

注: サービスアカウントの IAM ロール (IRSA) が自身のニーズに適していると思われる場合は、「Amazon EKS ユーザーガイド」の「EKS Pod Identity と IRSA の比較」を参照してください。

「Using identity-based policies for CodeBuild」を参照してください。

AWS のサービスの専用のガイドを参照してください。AWS でコードを実行すると、SDK 認証情報プロバイダーチェーンは認証情報を自動的に取得して更新できます。

AWS へのアクセスを必要とするモバイルアプリケーションまたはクライアントベースのウェブアプリケーションを作成する場合は、ウェブ ID フェデレーションを使用して AWS 一時的なセキュリティ認証情報を動的に要求するようにアプリを構築してください。

ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP) (例: Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換の IdP) を使用してサインインすることができます。認証トークンを受け取ったら、そのトークンを AWS アカウント のリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。

SDK またはツールへ設定する方法については、「ウェブ ID または OpenID Connect を持つロールを引き受けて AWS SDK とツールを認証する」を参照してください。

モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。Amazon Cognito は ID ブローカーとして機能し、ユーザーの代わりに多くのフェデレーション作業を行います。詳細については、「IAM ユーザーガイド」の「モバイルアプリに対する Amazon Cognito の使用」を参照してください。

IAM Identity Center を使用して AWS SDK とツールを認証するをお勧めします。

セキュリティのベストプラクティスとして、AWS Organizations と IAM Identity Center を使用して、すべての AWS アカウントにわたってアクセスを管理することをお勧めします。AWS IAM Identity Center でユーザーを作成するか、Microsoft Active Directory を使用するか、SAML 2.0 ID プロバイダー (IdP) を使用するか、または IdP を AWS アカウント に個別にフェデレーションすることができます。お使いのリージョンが IAM Identity Center をサポートしているかどうかを確認するには、Amazon Web Services 全般のリファレンス の「AWS IAM Identity Center エンドポイントとクォータ」を参照してください。

(推奨) ターゲットロールへの sts:AssumeRole アクセス許可を持つ最小特権の IAM ユーザーを作成します。次に、そのユーザーのためにセットアップされた source_profile を使用してロールを引き受けるようにプロファイルを設定します。

環境変数または共有 AWS credentials ファイルを介して一時的な IAM 認証情報を使用することもできます。「短期認証情報を使用して AWS SDK とツールを認証する」を参照してください。

注: サンドボックス環境または学習環境でのみ、 長期認証情報を使用して AWS SDK とツールを認証する を検討できます。

はい:「IAM Roles Anywhere を使用して AWS SDK とツールを認証する」を参照してください。IAM Roles Anywhere を使用すると、サーバー、コンテナ、アプリケーションなど、AWS の外部で実行されるワークロードに関する一時的なセキュリティ認証情報を、IAM で取得することがきます IAM Roles Anywhere を使用するには、ワークロードで X.509 証明書を使用する必要があります。

プロセス認証情報プロバイダー を使用して、実行時に認証情報を自動的に取得します。これらのシステムでは、ヘルパーツールまたはプラグインを使用して認証情報を取得し、sts:AssumeRole を使用してバックグラウンドで IAM ロールを引き受ける場合があります。

AWS Secrets Manager 経由で挿入された一時的な認証情報を使用します。有効期間の短いアクセスキーを取得するオプションについては、「IAM ユーザーガイド」の「一時的なセキュリティ認証情報をリクエストする」を参照してください。これらの一時的な認証情報を保存するオプションについては、「AWS アクセスキー」を参照してください。

これらの認証情報を使用して、本番環境のシークレットまたは有効期間の長いロールベースの認証情報を保存できる Secrets Manager からより広範なアプリケーションのアクセス許可を安全に取得できます。

認証情報を取得するための最適なガイダンスについては、サードパーティープロバイダーが作成したドキュメントを使用してください。

はい: 環境変数と一時的な AWS STS 認証情報を使用します。

いいえ: 暗号化されたシークレットマネージャー (最後の手段) に保存されている静的アクセスキーを使用します。

認証方法

AWS 環境内で実行されるコードの認証オプション

コードを AWS で実行している場合、認証情報はアプリケーションで自動的に使用できるようになります。例えば、アプリケーションが Amazon Elastic Compute Cloud でホストされていて、そのリソースに関連付けられた IAM ロールがある場合、認証情報はアプリケーションで自動的に使用可能になります。同様に、Amazon ECS または Amazon EKS コンテナを使用する場合、IAM ロールの認証情報セットは、SDK の認証情報プロバイダーチェーンを介してコンテナ内で実行されるコードによって自動的に取得できます。

ウェブベースのアイデンティティープロバイダーによる認証 - モバイルまたはクライアントベースのウェブアプリケーション

AWS へのアクセスを必要とするモバイルアプリケーションまたはクライアントベースのウェブアプリケーションを作成する場合は、ウェブ ID フェデレーションを使用して AWS 一時的なセキュリティ認証情報を動的に要求するようにアプリを構築してください。

ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP) (例: Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換の IdP) を使用してサインインすることができます。認証トークンを受け取ったら、そのトークンを AWS アカウント のリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。

SDK またはツールへ設定する方法については、「ウェブ ID または OpenID Connect を持つロールを引き受けて AWS SDK とツールを認証する」を参照してください。

モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。Amazon Cognito は ID ブローカーとして機能し、ユーザーの代わりに多くのフェデレーション作業を行います。詳細については、「IAM ユーザーガイド」の「モバイルアプリに対する Amazon Cognito の使用」を参照してください。

ローカル (AWS 以外) で実行されるコードの認証オプション

アクセス管理に関する詳細情報

「IAM ユーザーガイド」には、AWS リソースにアクセスするためのアクセス許可を安全に制御するための以下の詳細情報があります。

Amazon Web Services 全般のリファレンス には、以下に関する基本的な基本事項があります。

  • AWS 認証情報の理解と取得 — コンソールアクセスとプログラムアクセスの両方に関するアクセスキーオプションと管理プラクティス。

AWS のサービスにアクセスするための IAM Identity Center の信頼できる ID の伝播 (TIP) プラグイン

AWS ビルダー ID

すでに所有している、または作成したい AWS アカウント を AWS ビルダー ID で補完します。AWS アカウント は作成する AWS リソースのコンテナとして機能し、それらのリソースにセキュリティ境界を設けるのに対し、AWS ビルダー ID ユーザー個人を表します。AWS ビルダー ID を使用してサインインし、Amazon Q や Amazon CodeCatalyst などの開発者ツールやサービスにアクセスできます。