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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このベストプラクティスが確立されていない場合のリスクレベル: 高

実装のガイダンス

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

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

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

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

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

Credential type Description Suggested strategy
IAM access keys AWS IAM access and secret keys used to assume IAM roles inside of a workload Replace: Use IAM ロール assigned to the compute instances (such as Amazon EC2 or AWS Lambda) instead. For interoperability with third parties that require access to resources in your AWS アカウント, ask if they support AWS クロスアカウントアクセス. For mobile apps, consider using temporary credentials through Amazon Cognito ID プール (フェデレーティッドアイデンティティ). For workloads running outside of AWS, consider IAM Roles Anywhere or AWS Systems Manager ハイブリッドアクティベーション.
SSH keys Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process Replace: Use AWS Systems Manager or EC2 Instance Connect to provide programmatic and human access to EC2 instances using IAM roles.
Application and database credentials Passwords – plain text string Rotate: Store credentials in AWS Secrets Manager and establish automated rotation if possible.
Amazon RDS and Aurora Admin Database credentials Passwords – plain text string Replace: Use the Amazon RDS との Secrets Manager 統合 or Amazon Aurora. In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see IAM データベース認証).
OAuth tokens Secret tokens – plain text string Rotate: Store tokens in AWS Secrets Manager and configure automated rotation.
API tokens and keys Secret tokens – plain text string Rotate: Store in AWS Secrets Manager and establish automated rotation if possible.

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

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

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

実装手順

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

    • 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 から取得したシークレットをアプリケーションコードに統合します。

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

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

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

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

リソース

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

関連するドキュメント:

関連動画:

関連ワークショップ: