AWS Secrets Managerでシークレットを管理する

アプリケーションがデータベースや外部APIへ接続するには、パスワード、APIキー、トークンなどの機密値が必要です。これらをソースコード、コンテナイメージ、AMI、デプロイスクリプトに固定してしまうと、値の更新のたびにアプリケーションを変更・再配布することになり、複製されたファイルやログから漏えいする危険も高まります。環境変数に設定する場合も、値をアプリケーションの外部へ置いただけで安全になるわけではありません。保存場所、参照できる主体、ログへの出力、更新時の配布方法を管理する必要があります。

AWS Secrets Managerは、シークレットを一元的に保管し、暗号化、アクセス制御、取得、バージョン管理、ローテーションを行うフルマネージドサービスです。アプリケーションは実行時にサービスから必要な値を取得するため、認証情報をソースへ書かずに済みます。たとえば、EC2で動く在庫分析アプリケーションが Amazon RDS for PostgreSQL へ接続する場合、接続ユーザーとパスワードをSecrets Managerに保存し、EC2のIAMロールを使って実行時に読み取る構成にできます。

管理できる値と導入する効果

Secrets Managerでは、データベース認証情報のほか、外部サービスのAPIキー、OAuthアクセストークンなど、アプリケーションが必要とするシークレットを管理できます。秘密値を一か所に集約すると、値を使う側へ必要な権限だけを付け、更新履歴を監査し、定期的な変更を自動化しやすくなります。

値をコードに固定した場合、認証情報を交換するにはコード変更、ビルド、デプロイが必要になることがあります。Secrets Managerから実行時に値を読む方式なら、シークレットの更新とアプリケーションのリリースを分離できます。ただし、アプリケーションが取得した値をログへ出したり、プロセス内に必要以上に長く保持したりしないように設計します。また、実行時取得を採用しても、サービスがシークレットを読めるIAM権限そのものは厳密に制御しなければなりません。

秘密鍵や証明書、SSH接続については、値をSecrets Managerに格納できるかどうかだけで判断せず、用途に合ったサービスを選びます。AWSはSSH接続にはEC2 Instance Connect、秘密鍵や証明書にはAWS Certificate Managerなど、それぞれの用途に適したサービスも提供しています。

保存時の暗号化とKMS

Secrets Managerは、シークレット値をAWS Key Management Service（AWS KMS）のキーで保護します。AWS管理キーaws/secretsmanagerを利用する方法と、要件に応じてカスタマー管理の対称KMSキーを指定する方法があります。カスタマー管理キーを選ぶと、キーのポリシー、監査、利用権限などをより細かく管理できます。

暗号化はエンベロープ暗号化で行われます。KMSキーがシークレットの値を直接暗号化するのではなく、KMSがデータキーを生成して保護し、そのデータキーでSecrets Managerがシークレット値を暗号化します。平文のデータキーは暗号化処理の間だけ扱われ、保存されるデータキーはKMSキーで暗号化された状態です。値が更新されると、新しいバージョンを保護するためのデータキーが使われます。

アプリケーションが値を取得すると、Secrets ManagerはKMSを使ってデータキーを復号し、シークレット値を返します。そのため、シークレットを取得する権限だけでなく、暗号化キーの利用条件も整っている必要があります。特にカスタマー管理キーを使うときは、Secrets Managerがキーを利用できる設定、取得する主体の認可、キーの有効状態を確認します。キーを無効化したり、必要なKMS権限を削除したりすると、シークレット値を取得できなくなる可能性があります。

IAMとリソースベースポリシーによるアクセス制御

シークレットへのアクセスは、IAMのアイデンティティベースポリシーと、シークレットに設定できるリソースベースポリシーなどで制御します。前者はユーザーやロールなどの主体に付け、後者は対象のシークレットに付けます。両方を使うと、誰がどのシークレットへアクセスできるかを、主体側とリソース側の観点から細かく表現できます。明示的な拒否や、組織ポリシーなどの上位制約がある場合はそれらも評価されます。

たとえば、集計アプリケーション用のEC2インスタンスには専用のインスタンスプロファイルを割り当て、そのロールに対象シークレットの読み取りだけを許可します。ほかのサービスの認証情報や、シークレットの作成・削除・ポリシー変更まで許可する必要はありません。アプリケーションが参照すべきシークレットのARNを限定し、必要な操作に権限を絞ります。

制御対象	主な設定	確認すること
呼び出し主体	IAMロールに付けるアイデンティティポリシー	対象シークレットに対する読み取り操作だけが許可されているか
シークレット	シークレットのリソースベースポリシー	許可・拒否するPrincipalや条件が意図した対象に限定されているか
暗号化キー	KMSキーポリシーと必要なIAM許可	Secrets Managerによる暗号化・復号を妨げていないか
実行環境	EC2インスタンスプロファイルなどのIAMロール	長期アクセスキーをインスタンスに置かずに認証できるか

リソースポリシーを広く許可すると、シークレットを読み取る主体が意図せず増えるおそれがあります。リソースポリシーを設定した場合も、最終的にどのPrincipalがどのAPI操作を実行できるかを確認してください。クロスアカウントでシークレットを共有する場合は、リソースポリシーだけで完結するとは限らず、呼び出し元側のIAM許可とKMSキー側のクロスアカウント利用条件も合わせて設計します。

EC2アプリケーションから安全に取得する

EC2上のアプリケーションがデータベースへ接続する場合、データベースのユーザー名とパスワードをSecrets Managerに保存し、インスタンスプロファイルを通じて認証します。インスタンスプロファイルはEC2にIAMロールを関連付ける仕組みで、アプリケーションはAWS SDKの標準認証情報プロバイダーなどから一時的な認証情報を利用できます。固定のAWSアクセスキーを設定ファイルに保存する必要はありません。

処理の流れは次のとおりです。

1. データベースの認証情報をSecrets Managerに保存する。接続先やユーザー名などをシークレット値として管理する。
2. EC2インスタンスにインスタンスプロファイルを関連付ける。アプリケーションには長期AWSアクセスキーではなくロールの一時認証情報を使わせる。
3. アプリケーションがAWS SDKなどで対象シークレットを要求する。IAMポリシー、シークレットのリソースポリシー、必要なKMS権限によって認可される。
4. Secrets Managerが暗号化されたシークレットを復号し、許可されたアプリケーションへ値を返す。アプリケーションはそれを使ってデータベースへ接続する。
5. 自動ローテーションを設定している場合は、スケジュールに従って認証情報とデータベース側の認証情報が更新される。

取得した値をログや例外メッセージに含めず、アプリケーションのメモリ内で扱う範囲を必要最小限にします。頻繁に取得するワークロードでは、AWS提供のキャッシュ機能を利用してAPI呼び出しを減らす方法がありますが、キャッシュにより値が更新後もしばらく古いまま利用される可能性を理解し、キャッシュの有効期間やアプリケーション側の再接続動作を設計します。

自動ローテーションの方式

ローテーションとは、シークレットに保存された認証情報だけを変更するのではなく、シークレットの値と、その値を検証する接続先サービス側の認証情報の両方を更新することです。保管値だけを更新してデータベース側を変更しなければ、アプリケーションは接続できなくなります。定期的に新しい認証情報へ切り替えることで、長期間同じ値を使い続けるリスクを抑えられます。

Secrets Managerの自動ローテーションは、主に次の方式で実装します。

方式	更新処理を担うもの	主な対象と特徴
AWSによるマネージドローテーション	AWSサービス側	対応するマネージドシークレット向け。利用者がLambda関数を構築・運用せずに更新できる。対象サービスや条件はシークレットの種類により異なる
Lambda関数によるローテーション	Secrets Managerが起動するLambda関数	マネージド方式の対象外となるシークレットや独自要件に利用する。関数がシークレットとデータベース／外部サービスの双方を更新する

マネージドローテーションでは、対応するデータベースなどの対象に対してローテーションスケジュールを設定します。対応対象はサービスやエンジン、構成によって異なるため、設定時に現在のサポート条件を確認します。AWSが管理するマネージドローテーションはLambda関数を使いません。

Lambda方式では、ローテーション関数が認証情報を作成し、接続先へ反映し、接続を検証してから新しい値を現在値として確定します。Secrets ManagerはLambda関数用のテンプレートを提供しており、関数にはシークレットを読み書きし、接続先を更新するための権限が必要です。Lambdaからデータベースへ接続する構成では、関数のVPC配置、セキュリティグループ、サブネット、データベース側の到達性も確認します。

ローテーションスケジュールは、一定間隔または cron 式で指定できます。スケジュールを設定するだけで独自アプリケーションのあらゆる認証情報が自動で更新されるわけではなく、対応するマネージド方式を使うか、更新処理を担うLambda関数を構成します。ローテーションの実行中も、アプリケーションが新旧どちらの認証情報を使うか、接続プールの再接続がどう動くかを考慮します。

Lambdaローテーションの基本段階

Lambdaローテーションでは、バージョンラベルを使って処理途中の値と利用中の値を区別します。一般的な処理は次の段階で進みます。

1. 新しい値を準備する：新しいシークレットバージョンを作成し、処理中を示すAWSPENDINGラベルを付ける。
2. 接続先へ反映する：Lambda関数がデータベースやサービスへ接続し、新しい認証情報を登録する。
3. 新しい値を検証する：AWSPENDINGの値で接続できることを確認し、値と接続先が一致することを検証する。
4. 現在値を切り替える：検証に成功したら新しいバージョンへAWSCURRENTラベルを移し、利用中の値として確定する。

検証に失敗した値をそのまま現在値にしてはいけません。失敗時に再実行できるか、既存の認証情報でアプリケーションが稼働し続けるか、Lambda関数や接続先のエラーをどこで調べるかを運用手順に含めます。定期実行のスケジュールだけでなく、ローテーション失敗の監視と復旧方法も必要です。

Parameter Storeとの使い分け

AWS Systems Manager Parameter Storeも、設定値や機密情報を名前付きのパラメーターとして集中的に保存・取得できます。機密値はSecureStringとして保存でき、AWS KMSによる暗号化を利用できます。一方で、Parameter StoreにはSecrets Managerと同じ組み込みの認証情報自動ローテーション機能はありません。外部の自動化を構築して値を更新することはできますが、Parameter Store自体が接続先のパスワード変更まで担うローテーション機能を提供するわけではありません。

比較項目	AWS Secrets Manager	Systems Manager Parameter Store
主な位置付け	認証情報やAPIキーなどのシークレット管理	アプリケーション設定を含む汎用的なパラメーター管理
機密値の暗号化	KMSキーを使ったエンベロープ暗号化	SecureStringをKMSで暗号化
シークレットの自動ローテーション	対応。マネージド方式またはLambda方式	組み込みの認証情報自動ローテーションはない
値の更新と接続先の同期	ローテーション機能でシークレットと接続先の更新を連携できる	外部の自動化を用意しない限り、パラメーター値と接続先は別々に管理する
主な選択場面	データベース認証情報、APIキーなど、変更・監査・ローテーションが重要	エンドポイント、環境ごとの設定値、リソースIDなどを含む幅広い設定情報
料金の考え方	シークレットの保管数やAPI利用などに応じて課金	標準パラメーターには追加料金なし。高度なパラメーターや追加機能は課金対象になり得る

Parameter Storeには標準・アドバンストのティアがあり、パラメーターサイズや数、パラメーターポリシー、アカウント間共有などの機能と料金が異なります。標準ティアには追加料金なしで利用できる機能が多く、設定管理全般に幅広く使えます。ただし、SecureStringで暗号化できることと、認証情報を自動ローテーションできることは別の機能です。

選択時は「値が機密かどうか」だけではなく、「接続先の認証情報と合わせて変更する必要があるか」「変更周期や監査要件があるか」「標準的な設定値を低コストで共有したいか」を考えます。認証情報の更新とライフサイクル管理が中心ならSecrets Manager、一般的な設定値や環境パラメーターを管理するならParameter Storeが有力です。現在の料金とティアの制限は、利用するリージョンの最新情報で確認してください。

監査と運用上の確認

Secrets ManagerのAPI呼び出しはAWS CloudTrailにイベントとして記録されます。コンソールやSDKからの操作、シークレットの取得、変更、ローテーション関連の操作を追跡し、誰が、いつ、どのシークレットに対して操作したかを調査できます。継続的な記録が必要な場合はCloudTrailの証跡を構成し、ログの保存先、保持期間、参照権限を適切に管理します。

運用では、次の点を確認します。

• ソースコード、リポジトリ、コンテナイメージ、AMI、ログに秘密値が含まれていない。
• アプリケーションはIAMロールを使い、対象のシークレットだけを読み取れる。
• シークレットのリソースポリシーに意図しない広いPrincipalや許可がない。
• カスタマー管理KMSキーを使う場合、Secrets Managerと正規の利用主体に必要な権限があり、鍵が有効である。
• 自動ローテーションの対象、頻度、実行主体、Lambdaのネットワーク経路、失敗時の通知と復旧手順が明確である。
• アプリケーションが新しい値を取得し直せる。接続プールなどが古い値を保持する場合の更新動作も検証されている。
• CloudTrailのイベントを監査でき、ログ保管先自体のアクセス制御と保護が設定されている。

DVA試験での判断ポイント

• シークレットのハードコーディングを避け、Secrets Managerから実行時に値を取得する。EC2からの取得では、固定アクセスキーではなくインスタンスプロファイルのIAMロールを使う。
• Secrets Managerは保存時にKMSで保護する。KMSキーはシークレット値を直接暗号化するのではなく、データキーを保護するエンベロープ暗号化を行う。
• 読み取り許可はIAMアイデンティティポリシー、シークレットのリソースポリシー、必要なKMS権限の関係を確認する。アクセス許可をシークレット全体や全主体へ過剰に広げない。
• 自動ローテーションには、AWSが管理するマネージドローテーションとLambda関数による方式がある。AWSによるマネージドローテーションはLambdaを使用せず、Lambda方式は関数がシークレットと接続先の双方を更新する。
• ローテーションは秘密値の保管先だけを変える処理ではない。接続先の認証情報との同期、更新後の接続確認、失敗時の復旧が重要である。
• Parameter StoreのSecureStringはKMS暗号化に対応するが、それだけでSecrets Managerの自動ローテーション機能が使えるわけではない。設定値中心ならParameter Store、ローテーションを含む認証情報管理ならSecrets Managerを検討する。
• Parameter Storeは標準ティアに追加料金のない機能が多い一方、高度なティアは容量やポリシー、共有機能などに応じて課金される。料金・制限はティアとリージョンで確認する。
• Secrets Managerの操作はCloudTrailで追跡できる。シークレットの参照や変更を監査できるよう、記録とログ保護を整える。

AWS公式ドキュメント

• AWS Secrets Managerとは
• Secrets Managerのシークレットローテーション
• Secrets Managerでのシークレットの暗号化と復号
• Secrets ManagerのイベントをCloudTrailで記録する
• Secrets Managerからシークレットを取得する
• AWS Systems Manager Parameter Store
• Parameter StoreのSecureStringをKMSで暗号化する