Secrets Managerで認証情報を保存する

コードや設定ファイルにハードコードされたデータベースのパスワードや API キーは、情報漏えいの主な原因です。リポジトリ、ログ、バックアップを通じて漏えいします。

AWS Secrets Manager はシークレットを安全に保存し、IAM でアクセスを制御し、自動的にローテーションできます。そのため、シークレットをコード内に置く必要がありません。

Secrets Manager は、データベースの認証情報や API キーなどのシークレットを保存、暗号化、取得、ローテーションします。

• シークレットは KMS によって保存時に暗号化されます。
• アプリケーションはシークレットを埋め込むのではなく、実行時に API 呼び出しで取得します。

各シークレットは KMS key で暗号化され、IAM とオプションのリソースベースポリシーによって保護されます。

シークレットを必要とする特定のロールだけにアクセスを許可し、取得操作はすべて CloudTrail に記録されるため、完全な追跡性を確保できます。

特に重要な機能は自動ローテーションです。

• Lambda 関数がスケジュールに従ってシークレットを変更し、保存先を更新します。
• 組み込みのローテーションは RDS やその他のデータベースをサポートしています。

認証情報が漏えいした場合でも、ローテーションによって被害が及ぶ期間を短縮できます。

データベースでは通常、2 組の認証情報または交互にユーザーを切り替える方式を使用します。これにより、変更中にアプリケーションが無効なパスワードを参照することを防ぎます。

Lambda が新しいシークレット値を作成してテストし、その後に有効化します。正しく設定すれば、ダウンタイムなしで実行できます。

アプリケーションは必要なときに GetSecretValue を呼び出してシークレットを取得し、多くの場合は短時間キャッシュします。

アプリケーションは IAM ロールを使用するため、シークレットを取得するための静的な認証情報は必要ありません。これにより、長期的なキーをコードから排除する仕組みが完成します。

SSM Parameter Store も設定やシークレット（SecureString）を保存でき、標準パラメータであれば無料です。

• 自動ローテーションやアカウント間でのシークレット共有が組み込まれている Secrets Manager を選択します。
• ローテーションを必要としない、よりシンプルで無料の設定管理には Parameter Store を選択します。

Secrets Manager は、別のアカウントとシークレットを共有するためのリソースポリシーをサポートし、シークレットを他のリージョンにレプリケートできます。

これにより、マルチリージョンアプリケーションやディザスタリカバリに対応し、ワークロードが実行される場所で一貫したシークレットを利用できます。

CloudTrailでシークレットの使用状況（誰がシークレットを取得またはローテーションしたか）を監視し、異常を検出します。

たとえば、GuardDutyは通常とは異なるアクセスパターンを検出でき、Configルールはローテーションが有効になっているかを確認できます。これにより、シークレットの適切な管理状況を測定できます。

多くのAWSサービスは、Secrets Managerのシークレットをネイティブに利用できます。

• RDSとRedshiftでは、マスター認証情報をそこに保存して管理できます。
• ECS、Lambda、CodeBuildでは、実行時にシークレットを注入できます。

これにより、コードに認証情報を埋め込んだり、手動で取得したりすることなく、ワークロードに認証情報を安全に渡せます。

シークレットを安全に使用するには、次の点に従います。

• シークレットをハードコードしないで、Secrets Managerから取得します。
• ローテーションを有効にし、専用のKMSキーを使用します。
• シークレットごとに最小権限のアクセスを付与し、取得状況を監査します。

適切なサービスを選択してください。

Secrets Managerについて学びました。

• シークレットを保存、暗号化（KMSを使用）、自動ローテーションできます。
• アプリケーションは、IAMで制御されたAPI呼び出しによって実行時にシークレットを取得します。シークレットをハードコードする必要はありません。
• ローテーションまたはアカウント間共有が必要な場合は、Parameter StoreよりもSecrets Managerを選択します。