SEC02-BP03 シークレットを安全に保存して使用する - セキュリティの柱
実装のガイダンスリソース

SEC02-BP03 シークレットを安全に保存して使用する

ワークロードには、データベース、リソース、およびサードパーティーサービスにアイデンティティを証明するための自動機能が必要となります。これは、API アクセスキー、パスワード、および OAuth トークンなどの、シークレットアクセス認証情報を使って実現されます。これらの認証情報を保存、管理、ローテーションする専用のサービスを使用することで、認証情報が侵害される可能性を低減することができます。

期待される成果: 次の目標を達成するアプリケーションの認証情報を安全に管理するメカニズムを実装します。

  • ワークロードに必要なシークレットを特定する。

  • 長期的認証情報を短期的認証情報と置き換える (可能な場合) ことによりその数を減らす。

  • 安全なストレージと、残りの長期的認証情報の自動化されたローテーションを確立する。

  • ワークロードに存在するシークレットへのアクセスを監査する。

  • 開発プロセス中、ソースコードに組み込まれたシークレットがないことを継続的に監視する。

  • 認証情報が誤って開示される可能性を減らす。

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

  • 認証情報をローテーションしない。

  • ソースコードまたは設定ファイルに長期的認証情報を保管する。

  • 認証情報を暗号化せずに保管する。

このベストプラクティスを活用するメリット:

  • シークレットが、保管時と転送時に暗号化される。

  • 認証情報へのアクセスが、API (認証情報の自動販売機として捉える) 経由でゲート化される。

  • 認証情報へのアクセス (読み出しと書き込み) が監査およびログ記録される。

  • 懸念事項の分離: 認証情報のローテーションは、アーキテクチャの他の部分から分離できる別のコンポーネントによって実行されます。

  • シークレットは、ソフトウェアコンポーネントに対してオンデマンドで配布され、中央ロケーションでローテーションが発生する。

  • 認証情報へのアクセスは、非常にきめ細やかに制御できます。

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

実装のガイダンス

従来、データベースやサードパーティーの API、トークンなどの認証に使用する認証情報は、ソースコードや環境ファイルに埋め込まれている場合がありました。AWS は、これらの認証情報を安全に保管し、自動的にローテーションし、その使用を監査するメカニズムを複数提供しています。

シークレット管理に対する最善のアプローチは、削除、置換、ローテーションのガイダンスに従うことです。最も安全な認証情報は、保管、管理、処理が不要なものです。認証情報によっては、ワークロードの機能にとって不要となった、安全に削除できるものもあります。

ワークロードの正常な機能に依然として必要な認証情報については、長期的認証情報を一時的または短期的な認証情報と置換する機会があるかもしれません。例えば、AWS シークレットアクセスキーをハードコーディングする代わりに、IAM ロールを使って長期的認証情報を一時的認証情報と置換することを検討してみてください。

存続期間の長いシークレットによっては、削除も置換もできないものがあります。これらのシークレットは、AWS Secrets Manager などのサービスに保管して、一元的に保管、管理したり、定期的にローテーションしたりすることができます。

ワークロードのソースコードと設定ファイルの監査を行うと、さまざまなタイプの認証情報が明らかになる可能性があります。次の表は、一般的なタイプの認証情報を取り扱うための戦略をまとめたものです。

認証情報のタイプ 説明 推奨される戦略
IAM アクセスキー ワークロード内で IAM ロールを引き受けるために使用される AWS IAM アクセスとシークレットキー 置き換え: 代わりに、コンピューティングインスタンス (Amazon EC2 や AWS Lambda など) に割り当てられた IAM ロールを使用します。AWS アカウント内のリソースへのアクセスを必要とするサードパーティーとの相互運用性については、AWS クロスアカウントアクセスをサポートしているかどうかを確認してください。モバイルアプリの場合は、Amazon Cognito アイデンティティプール (フェデレーティッド ID) を介して一時的な認証情報を使用することを検討してください。AWS の外部で実行されているワークロードについては、IAM Roles Anywhere または AWS Systems Manager ハイブリッドアクティベーションを検討してください。コンテナについては、「Amazon ECS タスクの IAM ロール」または「Amazon EKS ノードの IAM ロール」を参照してください。
SSH キー Linux EC2 インスタンスへの手動または自動プロセスの一環としてのログインに使用されるセキュアシェルプライベートキー 置き換え: AWS Systems Manager または EC2 Instance Connect を使用して、IAM ロールを使用して EC2 インスタンスへのプログラムおよび人間によるアクセスを提供します。
アプリケーションとデータベースの認証情報 パスワード – プレーンテキスト文字列 ローテーション: 認証情報を AWS Secrets Manager に保存し、可能であれば自動ローテーションを確立します。
Amazon RDS と Aurora 管理データベースの認証情報 パスワード – プレーンテキスト文字列 置き換え: Secrets Manager と Amazon RDS または Amazon Aurora の統合を使用します。さらに、一部の RDS データベースタイプでは、一部のユースケースでパスワードの代わりに IAM ロールを使用できます (詳細については、「IAM データベース認証」を参照してください)。
OAuth トークン シークレットトークン – プレーンテキスト文字列 ローテーション: トークンを AWS Secrets Manager に保存し、自動ローテーションを設定します。
API トークンとキー シークレットトークン – プレーンテキスト文字列 ローテーション: AWS Secrets Manager に保存し、可能であれば自動ローテーションを確立します。

一般的なアンチパターンは、ソースコード、設定ファイル、またはモバイルアプリ内に IAM アクセスキーを埋め込むことです。AWS サービスと通信するために IAM アクセスキーが必要な場合は、一時的な (短期的な) セキュリティ認証情報を使用します。これらの短期認証情報は、EC2 インスタンスの IAM ロール、Lambda 関数の実行ロール、モバイルユーザーアクセス用の Cognito IAM ロール、および IoT デバイス用の IoT Core ポリシーを通じて提供できます。サードパーティーとやり取りする場合は、IAM ユーザーをサーバーして、サードパーティーにそのユーザー向けのシークレットアクセスキーを送信するよりも、アカウントのリソースへの必要なアクセス権を持つ IAM ロールにアクセスを委譲する方法を優先します。

ワークロードに、他のサービスやリソースとの相互運用に必要なシークレットの保管が必要となるケースが多数あります。AWS Secrets Manager は、これらの認証情報の安全な管理、さらには API トークン、パスワード、およびその他の認証情報の保管、使用、ローテーション専用です。

AWS Secrets Manager には、機密認証情報の安全なストレージと処理を確保するための 5 つの主要な機能があります。保管時の暗号化、転送中の暗号化、包括的な監査、きめ細かなアクセスコントロール、および拡張可能な認証情報ローテーションです。AWS パートナーによるその他のシークレット管理サービス、または類似の機能や保証を提供するローカルで開発されたソリューションも使用できます。

シークレットを取得するときに、Secrets Manager のクライアント側のキャッシュコンポーネントを使用して、将来使用するためにキャッシュすることができます。キャッシュされたシークレットの取得は、Secrets Manager からの取得よりも高速です。さらに、Secrets Manager API を呼び出すにはコストがかかるため、キャッシュを使用するとコストを削減できます。シークレットを取得するすべての方法については、「シークレットの取得」を参照してください。

注記

一部の言語では、クライアント側のキャッシュ用に独自のインメモリ暗号化を実装する必要がある場合があります。

実装手順

  1. Amazon CodeGuru などの自動ツールを使用して、ハードコードされた認証情報を含むコードパスを特定します。

    1. Amazon CodeGuru を使って、コードリポジトリをスキャンします。レビューが完了したら、CodeGuru で Type=Secrets をフィルタリングして、問題のあるコード行を見つけます。

  2. 削除または置換できる認証情報を特定します。

    1. 既に不要な認証情報を特定して、削除用にマークします。

    2. ソースコードに埋め込まれた AWS シークレットキーについては、必要なリソースに関連付けられた IAM ロールと置換します。ワークロードの一部が AWS 外であるにもかかわらず AWS リソースにアクセスする IAM 認証情報が必要な場合、IAM Roles Anywhere または AWS Systems Manager ハイブリッドアクティベーションを検討してください。

  3. ローテーション戦略を使用すべきその他のサードパーティー、存続期間の長いシークレットについては、Secrets Manager をコードに統合して、ランタイムにサードパーティーのシークレットを取得します。

    1. CodeGuru コンソールは、検出された認証情報を使って Secrets Manager にシークレットを作成できます。

    2. Secrets Manager から取得したシークレットをアプリケーションコードに統合します。

      1. サーバーレス Lambda 関数では、言語に依存しない Lambda 拡張機能を使用できます。

      2. EC2 インスタンスまたはコンテナに対しては、AWS が複数のよく使用されるプログラミング言語で、Secrets Manager からシークレットを取得するためのクライアント側コードの例を提供しています。

  4. 定期的にコードベースをレビューして再スキャンすることで、コードに新たなシークレットが追加されていないことを確認します。

    1. git-secrets などのツールを使って、ソースコードリポジトリに新しいシークレットがコミットされるのを防止することを検討してください。

  5. 予想外の使用、不適切なシークレットへのアクセス、またはシークレットの削除試行がないかどうか、Secrets Manager アクティビティをモニタリングします。

  6. 認証情報に対する人的曝露を減少させます。この目的に特化した IAM ロールに対する認証情報を読み出し、書き込み、および変更するためのアクセスを制限し、一部の運用ユーザーにのみ、その役割を担うためのアクセスを提供します。

リソース

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

関連ドキュメント:

関連動画:

関連するワークショップ: