SEC02-BP02 一時的な認証情報を使用する - AWS Well-Architected フレームワーク
実装のガイダンスリソース

SEC02-BP02 一時的な認証情報を使用する

何らかの認証を行う際、認証情報が誤って開示、共有、盗難されたりなどのリスクを軽減または排除するには、長期的認証情報ではなく一時的な認証情報を使うことが推奨されます。

期待される成果: 長期的認証情報のリスクを軽減するには、人的および機械両方の ID にできるだけ一時的な認証情報を使用するようにします。長期認証情報は、公開リポジトリへのアップロードによる情報漏洩など、多くのリスクが発生します。一時的な認証情報を使うことにより、認証情報が侵害されるリスクが大幅に減少します。

一般的なアンチパターン:

  • 開発者が、フェデレーションを使って CLI から一時的な認証情報を取得するのではなく、IAM ユーザーからの長期的なアクセスキーを使用する。

  • 開発者がコードに長期的アクセスキーを埋め込んで、そのコードをパブリック Git リポジトリにアップロードする。

  • 開発者が、モバイルアプリに長期的アクセスキーを埋め込んで、アプリストアで公開する。

  • ユーザーが長期的アクセスキーを他のユーザー、または従業員と共有し、長期的アクセスキーを所有したまま離職する。

  • 一時的認証情報を使用できるのに、マシン ID に対して長期的なアクセスキーを使用する。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

すべての AWS API と CLI リクエストに対して、長期的認証情報ではなく一時的なセキュリティ認証情報を使用します。AWS サービスに対する API および CLI リクエストは、ほとんどの場合、AWS アクセスキーを使って署名する必要があります。これらのリクエストの署名に使用する認証情報は、一時的でも長期的でもかまいません。長期的認証情報 (長期的アクセスキー) を使用すべき唯一の状況は、IAM ユーザーまたは AWS アカウントルートユーザーを使用している場合です。AWS に対してフェデレーションを行うか、または他の方法により IAM ロールを担う場合、一時的認証情報が生成されます。サインイン認証情報を使って AWS Management Consoleにアクセスしても、AWS サービスへのコールを行うために一時的な認証情報が生成されます。長期的認証情報が必要な状況はほとんどなく、一時的な認証情報でほとんどのタスクを遂行できます。

一時的な認証情報を優先して長期的な認証情報の使用を回避することは、フェデレーションと IAM ロールを優先して IAM ユーザーの使用を減少させる戦略と一致していなければなりません。IAM ユーザーは過去に人的とマシン ID 両方に対して使用されましたが、長期的アクセスキー使用におけるリスクを回避するため、それを使用しないよう推奨しています。

実装手順

人的 ID

従業員、管理者、デベロッパー、およびオペレーターなどのワークフォース ID の場合:

サードパーティー ID の場合:

ウェブブラウザ、クライアントアプリケーション、モバイルアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースにアクセスするユーザー ID:

  • 消費者や顧客向けのアプリケーションに AWS リソースへのアクセスを許可する必要がある場合、Amazon Cognito アイデンティティプールまたは Amazon Cognito ユーザープールを使用して、一時的な認証情報を提供できます。認証情報に対するアクセス許可は、IAM ロールを介して設定されます。また、認証されていないゲストユーザーに対して、権限が制限された個別の IAM ロールを定義することもできます。

マシン ID

マシン ID の場合、長期的認証情報を使用しなければならない場合があります。これらの場合、IAM ロールで AWS にアクセスする際に、ワークロードが一時的な認証情報を使用するよう義務付ける必要があります。

一時的な認証情報がサポートされていないシナリオがあり、その場合は長期認証情報を使用する必要があります。これらの状況では、定期的にこれらの認証情報を監査してローテーションし、さらに定期的にアクセスキーをローテーションします。制限の厳しい IAM ユーザーアクセスキーについては、以下の追加のセキュリティ対策を検討してください。

  • 次のように、制限の厳しいアクセス許可を付与します。

    • 最小特権の原則 (アクション、リソース、条件を具体的に指定します) に従います。

    • IAM ユーザーに、特定の 1 つのロールに対する AssumeRole オペレーションのみを付与することを検討してください。オンプレミスアーキテクチャの一部では、このアプローチを使用することにより、長期 IAM 認証情報を分離して安全に保護できます。

  • IAM ロール信頼ポリシーで許可されるネットワークソースと IP アドレスを制限します。

  • 使用状況をモニタリングし、未使用のアクセス許可や誤使用に対してアラートを設定します (AWSCloudWatch Logs メトリクスフィルターとアラームを使用)。

  • アクセス許可の境界 を適用します (サービスコントロールポリシー (SCP) は粗く、アクセス許可の境界はきめ細かく、相互に補完する関係にあります)。

  • 認証情報をプロビジョニングして、安全に (オンプレミスのボールトに) 保存するプロセスを実装します。

長期認証情報が必要なシナリオのその他のオプションには、次のようなものがあります。

  • (Amazon API Gateway を使用して) 独自のトークン供給 API を構築する。

  • 長期認証情報や AWS アクセスキー以外の認証情報 (データベースログインなど) を使用する必要があるシナリオでは、AWS Secrets Manager など、シークレット管理を処理するために設計されたサービスを使用できます。Secrets Manager は、暗号化されたシークレットの管理、ローテーション、安全なストレージを簡素化します。多くの AWS サービスでは、Secrets Manager との直接統合をサポートしています。

  • マルチクラウド統合では、ソース認証情報サービスプロバイダー (CSP) の認証情報に基づいた ID フェデレーションを使用できます (「AWS STS AssumeRoleWithWebIdentity」を参照)。

長期的認証情報のローテーションについては、「アクセスキーのローテーション」を参照してください。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画: