SCS-5.4認証情報、シークレット、暗号化キーマテリアルを保護するためのコントロールを設計し、実装する。

ヒントボタン

FIPS 140-2 Level 3 が必須という時点で、AWS Key Management Service の標準 CMK や Parameter Store ではレベル 2 相当止まりです。Level 3 を担保するには CloudHSM が前提になり、KMS カスタムキーストアとして紐付けることで、鍵は AWS 管理 HSM の外ではなく顧客専用 HSM 内に生成・保管されるため PCI DSS の厳格な鍵保持要件を自然に満たせます。さらに KMS API をそのまま呼び出せるためアプリ改修も最小、マルチ AZ クラスタで冗長化やパッチ適用もサービス任せにできます。

クライアント側暗号化を採るなら AWS Encryption SDK がサポートするエンベロープ方式が有効です。KMS キーリングを介して CloudHSM 内の CMK から毎回新しい DEK を払い出しつつ、暗号文にキー情報を封入するので復号時の解決も自動化できます。月次スケジュールで CMK とは別に DEK のみを生成し直して新規オブジェクトに使えば、既存 5TB/日のログを再暗号化せずにローテーション要件を満たし、Encrypt-then-MAC も SDK が標準で実装しています。

鍵を発行するたびに生成される GenerateDataKey や Decrypt の呼び出しは AWS CloudTrail へ自動記録されるため、別リージョンの集中ログバケットに統合しても監査証跡が途切れません。CloudWatch Alarm で API 使用量を監視すれば運用は監査と月次スクリプトの確認程度で済み、重いバッチや手作業を追加せず 1,500TPS の負荷にも対応できます。FIPS Level3、月次ローテーション、クライアント側暗号、集中監査、低運用負荷という五つの要件を同時にかなえる構成は CloudHSM＋KMS カスタムキーストア＋Encryption SDK＋CloudTrail を軸に据えた組み合わせが最も整合的といえるでしょう。

ヒントボタン

子会社アカウントに新しい KMS CMK を置かず親 CMK を共有したまま EC2 Auto Scaling から暗号化 EBS を高速起動させるなら、親で CreateGrant を発行し grantee principal に arn:aws:iam::222222222222:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling を指定し Encrypt Decrypt GenerateDataKey* DescribeKey だけ許可する構成が、起動テンプレートが単に CMK ARN を参照するだけで済みサービスリンクロールの既定権限内で動作する点で最小権限に近づきます。
キーの使用を秒単位で止めたい場合は KMS DisableKey よりも RevokeGrant のほうが即時性が高くローリング運用にも向き、親アカウントが grant-id を制御していれば子会社は再付与できないため、キーの有効化／無効化を 15 分以内という RTO で行いたい今回の要件に合致します。
キーポリシーでルートや AmazonEC2FullAccess を丸ごと許す設計や replica-key・インポートで別 CMK を持たせる方法はガバナンスと迅速停止の両立が難しいため、CreateGrant を使って親が鍵の所有と統制を維持し子会社はサービスリンクロールだけで EBS 暗号化を実行する形が複数要件をバランス良く満たす総合的な選択となります。

ヒントボタン

Amazon RDS が自動スナップショットを暗号化するときに KMS へ要求するのは GenerateDataKey* と Decrypt だけで、Encrypt は呼び出されません。従ってキーポリシーはこれら 2 つの Action だけを Allow し、Condition に kms:ViaService=rds.ap-northeast-1.amazonaws.com と aws:SourceAccount=222222222222 を併用するとリージョン外や別アカウントからの利用を確実に遮断できます。

KMS ではサービスが呼び出す場合でも実際の Principal はアカウントの arn:aws:iam:::root として到着します。よってポリシーの Principal を rds.amazonaws.com のようなサービスプリンシパルにすると評価されず拒否される点が落とし穴です。さらに Encrypt を含めると管理者 IAM ロールが直接暗号化 API を使える余地が残るため、最小権限の観点からも GenerateDataKey* と Decrypt のみに絞ることが重要です。

以上を総合すると、Principal にアプリケーションアカウントのルートを指定し、kms:ViaService と aws:SourceAccount の 2 条件で RDS 経由の呼び出しだけを許可しつつ Action を GenerateDataKey* と Decrypt に限定するステートメントが、他サービス・他アカウント・人間の Encrypt API いずれも排除しつつ RDS 自動スナップショットの暗号化要件を満たす最適解となります。

ヒントボタン

1. まず「顧客提供のキーマテリアルを 6 か月ごとに更新し、期限が来たら自動的に使えなくなる」という部分に着目してください。AWS KMS で import-key-material を実行すると、validTo で有効期限を 180 日後に指定でき、有効期限到来後は CMK が自動的に無効化されます。また reimport-key-material を使えば 90 日以内に同一素材をインポートして元の KeyId のまま復旧できるため、アプリケーションの暗号化・復号 API を変更せずに運用できます。

2. 「運用負荷と可用性を最小化」というキーワードからは、フルマネージドの KMS と EventBridge の組み合わせが候補になります。対して CloudHSM や手動で CMK を作り替える方法は、HSM クラスタの保守やキー ID 差し替えなど作業が多く、リスクも増えがちです。さらに KMS 自動ローテーションは周期が固定で AWS 生成キーのみ対象のため「顧客提供キーを 6 か月ごとに必ず更新」という規制には適合しません。

3. 期限管理と自動化という観点では、EventBridge ルールで validTo の 30 日前を検知し、Lambda から reimport-key-material を呼び出すだけで更新を無停止化できます。KMS 側ではキー ID が変わらず、S3 SSE-KMS や RDS 暗号化の設定もそのまま維持できます。こうした複数の要件—顧客提供キーの継続利用、6 か月ごとの自動無効化と 90 日以内の復旧、アプリ改修不要、最小の運用負荷—を並べて評価すると、フルマネージドで再インポート機能を備えた KMS インポートキー＋EventBridge＋Lambda の構成が唯一すべてを同時に満たすことがわかります。

ヒントボタン

KMSのカスタマー管理キーを作成してImportKeyMaterialで社内HSM生成の256ビット鍵を注入し、ExpirationModelをKEY_MATERIAL_EXPIRESで90日後に設定すると、その期日にキーマテリアルのみが自動消去されキーはDisabledとなりEncryptが失敗するため、手動操作なしで「クラウド保持は90日まで」と「期限後は暗号化を停止」を同時に実現できます。
期限終了後でも同じキー識別子を1年間維持したい場合はReImportKeyMaterialを使い、最初のインポートから365日以内なら同一CMKへ同じ鍵を再投入してEnableKeyで再有効化できるので、システムや監査ログに記録されたKeyIdを変更せず再導入でき、運用の手間とリスクを大きく減らせます。
完全に廃棄したいときはScheduleKeyDeletionで7〜30日の猶予を設定してキーIDごと削除でき、CloudHSMやXKSの構築、EnableKeyRotation周期制限、90日ごとに新CMKを作成してアプリ設定を更新するといった重い作業を避けられるため、複数要件を俯瞰してもインポート型CMKが最もシンプルです。

ヒントボタン

AWS Key Management Service のキーポリシーで使える kms:ViaService 条件キーは、リクエストが特定のサービス経由かどうかを判定する仕組みです。たとえば dynamodb.ap-northeast-1.amazonaws.com と lambda.ap-northeast-1.amazonaws.com だけを許可にすると、DynamoDB と Lambda からの暗号化／復号だけ通し、開発者が AWS CLI や SDK で KMS Decrypt を呼んでも条件不一致でブロックされます。さらに KMS 呼び出しは CloudTrail に完全に記録されるので、不正アクセス検知の要件も同時に満たせます。

最小権限を徹底したい場合、キーポリシーの Principal を本番用の IAM ロールなど 1 つに限定し、そのロールを Lambda 関数に付与して DynamoDB へアクセスさせる構成が効果的です。デフォルトキーポリシーを使うとアカウントの管理者や開発者にも Encrypt/Decrypt を許す余地が生まれるため、PAN の平文を取得できる経路が残ります。サービス統合型 SSE-KMS は 1 桁ミリ秒程度のレイテンシで、50 rps のトラフィックでもボトルネックにならない点も確認しておきましょう。

今回求められるのは、CMK を用いた DynamoDB の SSE-KMS、Lambda からの低レイテンシ復号、CloudTrail 監査、そして開発者が直接平文を得られない最小権限の四要件を同時にかなえる設計です。kms:ViaService で経路を DynamoDB と Lambda に限定し、Principal を本番ロールに絞ったキーポリシーを採用すれば、パフォーマンスを犠牲にせずガバナンスとセキュリティを両立できる総合的な最適解になります。

ヒントボタン

AWS KMS で customer managed key を DisableKey 状態にすると当該 KeyId を保持する EBS や SSE-KMS の S3 オブジェクトは Decrypt が失敗し EC2 起動や PUT/GET が止まりますが、ScheduleKeyDeletion には 7〜30 日の猶予があるため CancelKeyDeletion で即座に取り消し、続けて EnableKey を実行すればキーマテリアルはそのまま維持され数秒でサービスが復旧し RTO 30 分を容易に満たせます。
S3 レプリケーションや新しい CMK と alias 付け替えを検討しても、既存データや暗号化 EBS は固定された KeyId を参照し DisableKey 状態では読み出し自体が KMS エラーで始まらず、100 TB のオブジェクト再暗号化や 20 TiB のボリューム再生成にはネットワーク転送・再暗号化の時間が加わり RTO を大幅に超える点に注意が必要です。
以上のように AWS KMS の CancelKeyDeletion と EnableKey という最小限の操作で即時復旧でき、キーマテリアルの外部露出を避けつつ S3・EBS・EC2 の継続利用を確保できる方法が、可用性・セキュリティ・時間制約を総合的に俯瞰して最も合理的な選択となります。

ヒントボタン

kms disable-key と kms schedule-key-deletion を続けて実行すると CMK は Disabled かつ PendingDeletion になり、SSM Parameter Store が発行する GetParameter は即座に復号失敗となりますが、猶予期間中であれば AWS CLI の kms cancel-key-deletion と kms enable-key でキーを Enabled に戻し復号を再開できる点を思い出してください。
既に KMS 内部で生成された CMK が PendingDeletion に入った後は kms import-key-material でキーマテリアルを差し替えても暗号化当時の鍵とは一致せず復号不可で、replicate-key で複製しても Parameter Store が自動再暗号化することはないため、これらの手法は障害の即時解消にはつながらないことがポイントです。
キーライフサイクルの中で復号不能期間を最短に抑えられる操作は cancel-key-deletion による削除カウントダウンの取り消しと再有効化だけです。Parameter Store の可用性、金融監査の要求、復旧時間目標を総合的に俯瞰すると、猶予期間を利用して削除をキャンセルしキーをすぐに有効化する対応が最も合理的と判断できます。

ヒントボタン

要件は「インシデント発生から5分以内にキーマテリアルを恒久消去し復旧を不要とする」ことです。AWS KMS に外部HSMの256-bit AES鍵をインポートすると、キーマテリアルだけを瞬時に削除できる専用APIが存在します。このAPI呼び出し後は CMK のメタデータだけが残り、Amazon S3 や Amazon RDS に保存された暗号化データは復号できず暗号消去が成立します。削除後にキーマテリアルを再インポートしない限り鍵は永続的に使用不可であり、ロールバック操作は想定されません。したがって運用手順にはこのAPIを自動実行するステップを含めることが最重要です。

同じく AWS KMS には DisableKey と ScheduleKeyDeletion というオプションもありますが、DisableKey は kms:EnableKey を許可すれば即復活でき、ScheduleKeyDeletion は最短7日待機が必要です。またインポート時に有効期限を付ける方式では期限値を後から短縮できず、5分以内の消去に間に合いません。こうした仕様差を理解すると、自動化ですべき唯一のアクションが絞り込めます。

リージョンごとに独立したカスタマー管理キーを用意している場合でも、DeleteImportedKeyMaterial と kms:DisableKey を呼ぶだけの Lambda を最小権限 IAM ロールで実行すれば2回のAPI呼び出しで済みます。CloudTrail は CMK メタデータが残るため監査ログを保持できます。運用・セキュリティ・時間要件を俯瞰すると、この設計が最小手数で全要件を同時に満たすと判断できます。

ヒントボタン

オンプレミスHSMから持ち込んだキーマテリアルを使うBYOK方式のAWS KMSでは、カスタマー管理キーにEnableKeyRotationを設定しても実際にはローテーションできない制約があります。自動ローテーションが効くのはKMS側で生成したCMKやサービスデフォルトキーのみです。したがって90日ごとに世代を増やすには新しいCMKを用意するか再インポートを検討しますが、再インポートは旧マテリアルが即時失効するため復号期間を残したい要件との相性に注意が必要です。

決済APIは常にalias/pay-keyを指定してkms:Encryptを呼び出しているため、コードを変えずに鍵を入れ替える最短経路は、新しいCMKへImportKeyMaterialで256-bitキーを登録し終えた後にUpdateAlias APIでエイリアスだけを数ミリ秒で付け替える手法です。エイリアスはエンドポイントと同じURLの役割を果たすので切替瞬間以外の呼び出しには影響がなく、2,000 TPSのワークロードでも暗号化失敗をほぼ起こさず、許容停止時間60秒未満というSLAを守れます。

監査の「90日ごとにローテーションし旧キーは1年間復号に利用可能」という要求を満たすには、四半期ごとに新CMKを作成してキーマテリアルをインポートし、alias/pay-keyを最新CMKに更新、旧CMKはDisableKey後にScheduleKeyDeletionで365日保管する運用がPCI DSSのベストプラクティスと一致します。鍵単位で世代管理することで復号要求・停止時間・AWS KMS機能制限を同時にバランス良く満たせる点が総合判断の決め手となります。

ヒントボタン

アプリ側が CMK の ARN を動かせず毎秒 5,000 件の AWS KMS 呼び出しがあるうえ停止許容が 15 分という条件では、鍵を作り直して ARN を変える方法では要件を満たせませんので、既存のカスタマー管理キーを数分だけ無効化して ImportKeyMaterial で新キーマテリアルを再インポートし完了後すぐ有効化する流れが現実的です。
BYOK 方式での再インポートは毎回 AWS KMS から最新の WrappingKey と ImportToken を取得するのが前提で、これらは 24 時間の有効期限があるため過去にダウンロードしたファイルを使い回すとアップロード時に失敗します。外部 HSM でラップする際もこの新しいペアを用いることで整合性が確保できます。
監査の 48 時間以内更新、RTO/RPO 0、停止 15 分未満という複数条件を俯瞰すると、削除や自動キーローテーションは時間超過や非対応で除外され、ImportToken 更新を伴う再インポートと CMK の一時無効化・迅速な再有効化を組み合わせる手順が総合的に最適だと判断できます。

ヒントボタン

PCI DSS が求める「12 か月ごとの鍵更新」と「CloudTrail への証跡」を両立させるには、Amazon S3 を SSE-KMS で暗号化する際に AWS KMS で自分が管理権限を持つカスタマーマネージド CMK を作成し Auto Key Rotation を有効化する方法が有効です。365 日ごとに物理鍵だけが入れ替わり CMK の ARN は変わらないため、アプリケーションの設定変更なしで RotateKey イベントが CloudTrail に残り、監査要件と継続稼働の両方を満たせます。

RTO が 5 分以内という高可用性条件では、暗号鍵の更新でサービスが停止しないことが重要です。AWS KMS のカスタマーマネージド CMK で行う自動ローテーションはロジカルキー ID が不変なので、SSE-KMS を使用する Amazon S3 バケットは切替中も同じキー ARN を参照し続けられます。インポートキーや SSE-C のように毎年新しい KeyId やヘッダーを配布する方式では追加オーケストレーションが必要となり、この RTO を守る難易度が高まります。

運用負荷を最小に抑える観点では、自動ローテーション周期、CloudTrail への自動ログ出力、アプリ再設定不要の三点を同時に満たす組み合わせが望ましいです。AWS 管理キーはローテーションが約 3 年周期で詳細イベントが記録されない一方、カスタマーマネージド CMK はスイッチ一つで 1 年周期と監査証跡が確保できます。Secrets Manager や Lambda による鍵配布ワークフローは柔軟ですが作業や失効管理が増えるため総合コストが高くなりがちです。これらの要素を俯瞰すると、自動ローテーション機能を備えたカスタマーマネージド CMK が要件達成と運用最適化のバランスを最も取れる選択肢と判断できます。

ヒントボタン

CMK のキーポリシーを触らずに Lambda の毎日入れ替わる実行ロールへ最小限の kms:Decrypt を付与するには、AWS KMS の Grant 機能を思い出してください。Grant は kms:CreateGrant API で作成でき、有効期限 Expiration を 24h に設定することで自動失効します。さらに GrantToken を AWS Step Functions や AWS Lambda に渡すと CloudTrail にトークンが記録され、どの復号操作がどの一時権限に紐づくかを後から追跡できます。これによりマルチアカウント間での転送でもトレーサビリティを確保しつつ、キーの恒久開放やポリシー変更を避けられます。

Grant を発行する主体はバッチ開始時に起動される IAM ユーザーまたは AWS Step Functions から Assume されたロールで構いません。この主体に kms:CreateGrant と kms:RetireGrant だけを許可し、作成時に granteePrincipal として当日使われる AWS Lambda の実行ロール ARN を設定します。ジョブ開始直後に 24 時間有効の Grant と GrantToken を生成してワークフローに渡せば、その日中に何度ロールが置き換わっても Decrypt が成功し、終了後は期限切れか RetireGrant で即時無効化できます。IAM ポリシーや CMK ポリシーを日次で書き換える作業が一切不要になるのが利点です。

要件を整理すると①CMK のポリシーは固定②権限は 24 時間以内に自動消滅③マルチアカウントで CloudTrail に完全な証跡を残す、です。IAM ロールへ恒久的な kms:Decrypt を付与したり、キーマテリアルを Lambda レイヤーに埋め込んだり、CMK ポリシーを毎日編集する方法は、いずれかの条件を満たせません。期限付き Grant と GrantToken はポリシーを触らずに短期権限を渡し、CloudTrail で Principal・CMK・GrantId を結び付けて記録するため、金融監査水準の三条件を唯一同時にクリアできる設計だと総合的に判断できます。

ヒントボタン

まず、AWS KMS の自動ローテーションは対称 CMK だけが対象で、ECC_NIST_P256 のような非対称鍵には適用できません。ECDSA P-256 署名を継続しつつ 90 日周期で鍵を入れ替えるには、Sign/Verify API をそのまま使いながら新しい非対称 CMK を定期生成し、alias を付け替える独自ワークフローを組む必要があります。生成や付替えのイベントを CloudTrail に記録することで監査証跡も確保できます。

アプリ側の ARN を変えられないときは、固定名の alias を経由して KMS を呼び出す設計が有効です。alias はポインタのように機能するため、新しい CMK を作成して alias を付替えればクライアント設定はそのまま鍵だけ更新できます。Step Functions と AWS Lambda を組み合わせれば、90 日ごとに新 CMK を作成し alias を更新し、完了通知までを自動化でき、1 日 1 億回の Sign/Verify も停止なく処理できます。

監査要件で求められる過去 3 世代の鍵管理には、CloudTrail や AWS Config を有効にして CMK の CreateKey や UpdateAlias を追跡し、Step Functions で古い 4 世代目を無効化するロジックを加えると管理が容易です。Secrets Manager に鍵を置いたり対称 CMK を利用する場合は署名アルゴリズムや保管場所の適合性を丁寧に確認する必要があります。非対称 CMK の自動生成と alias 付替えを組み込み、CloudTrail で証跡を残す仕組みが複数要件を満たす総合的に最適なアプローチと言えます。

ヒントボタン

AWS KMS で作るカスタマー管理キーには「AWS 生成キーマテリアル」と「ImportKeyMaterial」による二方式があります。前者は EnableKeyRotation を有効にするだけで 1 年ごとに新しいキーバージョンが自動作成・切替され、運用はほぼ放置で済みますが、後者は自動ローテーション対象外のため毎年キー生成・再インポートの手順を組む必要があります。自動化と保守負荷の観点でどちらが要件に合うか考えてみてください。

Amazon S3 の SSE-KMS はオブジェクトに使用した CMK のキー ID をメタデータに格納しているため、バケットのデフォルト暗号化キーを新しい CMK に変更しても既存データは保存時のキーで透過復号されます。したがってコピーや再暗号化を行わずとも、新規アップロード分だけが新キーで暗号化される状態を簡単に実現できます。日次 5,000 件程度のログなら、設定変更だけで継続運用が可能になります。

PCI-DSS の「12 か月以内に自動ローテーション」と「運用負荷を最小化」という二条件を両立させるには、CloudHSM や Lambda を組み合わせた複雑な仕組みより、AWS KMS で新規に AWS 生成キーマテリアルの CMK を作成して EnableKeyRotation を有効化し、Amazon S3 の既定キーをその CMK に差し替える方法が最もシンプルです。ネイティブ機能で長期的な自動化が維持できるかを総合判断しましょう。

ヒントボタン

Amazon S3 で 1 億オブジェクトを PUT 5,000 件/秒で取り込むとしても、SSE-KMS を有効にすればアップロード時に自動で Envelope 暗号化が働きます。AWS KMS のカスタマー管理 CMK は「自動ローテーションを 365 日間隔」に設定できるので年次更新作業が不要です。CloudTrail は kms:Encrypt や kms:GenerateDataKey など全 API 呼び出しを記録し、誰がどの鍵を使ったかを後から正確に追跡できます。さらに KMS は内部でスループットを水平分散しており、大量 PUT に対するレイテンシ増を S3 がリトライで吸収するため性能面の心配も小さいです。

鍵の作成と削除を Security 部門だけに許可するには、KMS キーポリシーでその IAM ロールのみに kms:* をフル許可し、開発者や委託業者ロールには kms:Encrypt など最低限の使用権限だけを与えます。SSE-S3 では alias/aws/s3 という AWS 管理鍵が固定のためポリシー制御やローテーション周期を利用者が触れず、SSE-C ではクライアントが毎回 256 ビットキーを送信するためそもそも鍵マテリアルが委託業者に渡る構図になります。ポリシーによる厳格な分離と自律的ローテーションを同時に実現できる点で KMS 連携の方式が適しています。

オンプレミス HSM や Systems Manager Parameter Store に鍵を置く構成、あるいは SDK でクライアント側暗号化を施して SSE-C を利用する構成は、鍵のライフサイクル管理・監査ログ連携・高速 PUT へのスケーリングをすべて自前で担う必要があり運用負荷が大きくなります。CloudTrail による統合監査が欠如する、委託業者が鍵を保持してしまう、ローテーション自動化がスクリプト頼みになるなど複数要件でギャップが残るため、S3 と KMS のネイティブ連携を用いる構成が全条件を最小の運用コストでカバーする総合解として導き出せます。

ヒントボタン

鍵を共有したい場合、AWS KMS の鍵ポリシーを更新する方法と Grant を発行する方法がありますが、鍵ポリシーは恒久的な権限になりがちで申請フローも複雑です。一方 Grant は CreateGrant API だけで付与でき、RetireGrant で容易に失効させられます。鍵ポリシーを変えず短期間だけ権限を渡したいシナリオでは、この一時権限モデルが自動化との相性も良好です。

子会社側では AWS STS の AssumeRole で得た一時クレデンシャルだけを使い、CI/CD パイプラインから KMS Encrypt／Decrypt を呼び出したい状況です。アカウント2222に作成した IAM ロール ARN を Grant の principal として登録すると、そのロールを引き受けたセッションでも中央 CMK へのアクセスが許可されます。ロール資格情報は24時間後に無効化でき、長期アクセスキーを保持せずに済むためセキュリティも向上します。

求められる条件は「鍵ポリシーを変更しない」「クロスアカウントで中央 CMK を利用」「24時間で自動付与・自動失効」「1時間あたり1000件の S3 Put/Get に耐える」「運用負荷を最小化」の五つです。AWS KMS Grant を EventBridge もしくは Lambda で定期作成し、終了時に RetireGrant API で無効にする構成がこれらの要件を最もバランスよく満たすかを総合的に検討してみてください。

ヒントボタン

開発者が平文パスワードを一切見られないようにするには、KMS の暗号化と IAM ポリシーで kms:Decrypt を拒否し、EKS の IRSA でアプリケーション用ロールに SecretsManager:GetSecretValue だけを許可すると、コンソールや CLI からも復号できず CloudTrail で証跡が残ります。さらに SDK のキャッシュ機能が自動で最新値を取得するためポッド再起動なしで常に新しい資格情報を利用でき、接続エラーや調整運用も不要となり、ライブラリ差し替えだけでコードにパスワードを埋め込まない安全設計が実現します。

30 日ごとの自動パスワード生成・適用までを無停止で実行してくれるのは Secrets Manager の RDS ローテーション機能だけで、Systems Manager Parameter Store スタンダードでは Lambda と EventBridge を自作する必要があり、ロールバック設計や監査ログの分散など運用が煩雑になります。特にローリングアップデートなしでパスワードを適用するには EKS ポッドが Secrets Provider Class や SDK キャッシュを通じ都度 API を呼び出す方式がシンプルで、監査・鍵管理まで一元的に自動化できる点が比較ポイントです。

CMK を年１回ローテーションしながら CloudTrail で kms:Decrypt を監査し、かつ 300 本の同時コネクションを維持するには、ポッドが再デプロイなしで最新シークレットを取り込めるキャッシュ方式と、IAM ロールを GetSecretValue のみに絞る最小権限設計の組み合わせが不可欠です。複数要件を俯瞰するとフルマネージドでローテーション機能とカスタマー管理キー指定を兼ね備えたサービスを利用する構成が最も運用負荷を抑えつつ要件①〜④を一括で満たせると判断できます。

ヒントボタン

EKS の Pod が Aurora MySQL の資格情報を取り出す際、ServiceAccount に IRSA を設定して arn:aws:secretsmanager:*:getSecretValue など最小権限のみ許可した IAM ロールを渡せば、ワーカーノードや開発者用 IAM ユーザが KMS で復号済みの平文を読む操作を直接実行できず、クラスター外からの意図的・偶発的な漏えい経路を封じられます; さらに公式 SDK の SecretCache を併用すれば初回取得だけ API を呼び、その後はメモリキャッシュでレスポンスが数ミリ秒になるため、Pod 起動遅延を 5 秒以内に抑えることも容易です。
コンプライアンスで FIPS 140-2 認証済みハードウェアの利用を求められ、将来マルチリージョン展開時も同じ鍵で復号したい場合は、AWS KMS で作成できるマルチリージョン対応の対称カスタマーマネージドキーを選択し、Secrets Manager の暗号化キーに指定するのが王道です; この構成なら暗号化・復号とも FIPS 準拠の HSM 内で処理され、複製先リージョンでもキー ID が変わらずアプリ側の設定変更を最小化できます。
12 時間ごとの自動ローテーション、FIPS 準拠暗号化、IRSA による外部遮断、SecretCache での高速起動、そしてマルチリージョン展開という複数要件を同時に満たせる組み合わせは「AWS Secrets Manager＋Lambda ローテータ＋マルチリージョン CMK＋IRSA＋Pod 内キャッシュ」だけが追加開発なく網羅でき、他サービスを選ぶと必ずどこかで補完実装や制約超過が発生する点を整理して判断してください。

ヒントボタン

5,000 回/秒という読取り性能と暗号化保存を両立させるには、Secrets Manager がデフォルトで KMS により暗号化されたシークレットを高スループットで提供し、EKS 側は IAM Roles for Service Accounts（IRSA）で GetSecretValue のみ許可する IAM ロールを ServiceAccount に割り当てることで、復号キーを最小範囲に限定したまま Aurora MySQL 接続情報を Pod 数千から効率良く取得できます。
30 日ごとの自動ローテーションと 1 年間の操作履歴保持という要件は、Secrets Manager の RDS ローテーションテンプレートが生成する Lambda に任せることでパスワードを無停止更新し、CloudTrail で記録した API コールを Lake Formation 経由で S3 に保存しオブジェクトロックやライフサイクルで 365 日確実に保持する構成がフルマネージドで実装工数を抑えられます。
Parameter Store のスループット制限や自作 Lambda／CodeBuild の保守、ALB ヘッダーでの配布リスクなど各案を俯瞰すると、Secrets Manager＋KMS＋IRSA＋CloudTrail の組み合わせだけが暗号化、最小権限、自動更新、365 日監査、運用負荷最小化という複数要件をバランス良く満たすと総合判断できます。

ヒントボタン

30日ごとに鍵を自動回転しつつ Amazon Aurora MySQL と接続する50の ECS Fargate タスクを止めないためには、AWS Secrets Manager が備える自動ローテーションとバージョニングが最もシンプルです。KMS CMK で暗号化されたシークレットを一元管理し、SDK 呼び出しで常に最新版を取得すれば再デプロイも不要です。Systems Manager Parameter Store や S3 ファイルで同等の仕組みを自作すると Lambda や CodePipeline が増え、要件4の運用負荷最小化が難しくなります。

人が平文を閲覧できずタスクだけが取得できる状態をつくるには、IAM ポリシーで GetSecretValue のみをタスクロールに許可し他のアクションを Deny するのが効果的です。Secrets Manager はこの細粒度制御を容易に設定でき、すべての API 呼び出しが CloudTrail に記録されます。証跡を Amazon S3 にエクスポートしバージョニングとライフサイクルで7年保持すれば監査要件を満たし、KMS で S3 オブジェクト自体を暗号化すれば金融ガイドラインにも対応できます。

Secrets Manager の MySQL 用ローテーション Lambda テンプレートは数クリックで30日周期の自動更新を有効化でき、Aurora 側のユーザーを安全に切り替えます。更新後も既存の ECS Fargate タスクは次回取得時に透過的に新しい認証情報へ移行するためダウンタイムは発生しません。CloudTrail・CMK と組み合わせた設計により、暗号化、最小権限、完全追跡、自動ローテーションという複数の要件を追加開発なく同時に実現できる総合的メリットが得られます。

ヒントボタン

Amazon Secrets Manager には Amazon RDS for PostgreSQL とのネイティブ連携と Lambda テンプレート付きの自動ローテーション機能があり、30 日周期でも接続を切らずに oldPassword と newPassword を段階的に切り替えられます。API やパイプラインを自作せずにゼロダウンタイムと暗号化保存を同時に実現できる点に注目してください。

Amazon ECS on Fargate のタスク定義で secrets パラメータを使うと、起動時に Secrets Manager から GetSecretValue で値を注入し、その後も AWS SDK が必要に応じて最新シークレットを取得できます。500 タスクが同時稼働していても再デプロイやローリング再起動をせずに新しい認証情報が行き渡り、平文環境変数のリスクも排除できます。

IAM の最小権限原則を満たすにはタスク実行ロールに secretsmanager:GetSecretValue と kms:Decrypt 程度を付与するだけで十分です。Parameter Store と EventBridge＋Lambda での自前更新や RDS IAM 認証の短命トークン更新は運用作業が増えがちです。自動ローテーション、即時反映、大量タスク同時起動という複数要件を総合的に満たせるマネージド手段を選びましょう。

ヒントボタン

FinTech の取引は停止が許されません。Systems Manager Parameter Store はマルチ AZ 冗長で RTO/RPO が実質ゼロに近く、ECS Fargate 上の５００タスクが同時に SecureString を取っても Standard ４０ TPS、Advanced １００ TPS に加え SDK キャッシュで待ち行列を緩和できるためスロットリングを避けやすいです。Secrets Manager も高性能ですが API 課金が膨らみやすく、S3＋プリサインド URL は鍵管理の追加運用が生じる点に留意しましょう。

KMS の呼び出しを CloudTrail で監査するガバナンス要件がある場合、customer managed key を選ぶかどうかが分岐点です。aws/ssm や aws/secretsmanager などの AWS 管理キーは履歴が詳細に残らないため金融監査には不十分になりがちです。Parameter Store の SecureString を CMK で暗号化し、運用ロールに ssm:PutParameter と kms:Encrypt、アプリケーションロールに ssm:GetParameter と kms:Decrypt を付けると、更新と参照を明確に分離した最小権限を実現できます。

冗長性・高スループット・最小権限・CloudTrail 監査・低コストという複数条件を総合的に眺めると、Systems Manager Parameter Store＋顧客管理 KMS キーの組み合わせが最もバランス良く要求を充足し、Secrets Manager の自動ローテーションや S3 ファイル格納よりトータルで優位に立つ判断になるでしょう。

ヒントボタン

PCI-DSS ではアクセスキーを 90 日ごとにローテーションしなければならず、その遵守状況を常時監視することも求められますが、AWS Config のマネージドルール access-keys-rotated は IAM ユーザーのキー発行日と最終ローテーション日時を自動で比較し、閾値を 1 日単位で変更できるため、スクリプトを一切書かずに継続的コンプライアンスを確保できます。
さらに 120 日を超えたキーを人手なしで無効化・削除するには、AWS Systems Manager Automation の標準 runbook UpdateAccessKey と DeleteAccessKey を Config の修復アクションとして関連付ければよく、非準拠判定を受けたキーだけに対して即時あるいは承認付きで実行可能なため、Lambda の開発や EventBridge ルールの保守は不要になります。
証跡の長期保存については、Config 配信チャネルを Amazon S3 バケットに向けておき、バケットライフサイクルで 7 年の保持と Glacier への自動移行を設定することで改ざん耐性とコスト最適化を両立できるので、EC2 や独自のログ管理システムを持たずとも要件を一括で満たせるという総合的な観点が最終判断の決め手になります。

ヒントボタン

FIPS 140-2 Level 3で鍵を守りつつAWS運用者を含む第三者の論理・物理アクセスを遮断するには、占有型ハードウェアをVPC内で運用できるAWS CloudHSMが本命になります。CloudHSMは単一テナントHSMなので証跡を示しやすく、鍵が平文でデバイス外へ出ない仕組みです。マルチテナント設計のAWS KMSはLevel 2相当で同等の証明を取る手順が増えるため、金融監査下では差が顕著になります。さらにCloudHSMはPKCS #11やJCE、OpenSSLをネイティブ提供し、アプリ側の既存コードをそのまま生かせる点も重要です。

毎秒5,000回という高速暗号処理をアプリケーションがPKCS #11経由で行う場合、SDK変更なしで処理量を吸収できるAWS CloudHSMのクライアントライブラリが有効です。HSM本体で生成したキーはラップして外部にエクスポートでき、社内オフライン保管の運用フローを公式手順で構成できます。AWS KMSはサービス仕様として鍵を外部に出さない設計であり、Secrets ManagerはHSM機能を持たないため、バックアップ可搬性や暗号API互換を一緒に満たすにはHSMネイティブな選択肢が望ましいです。

可用性99.99％とRTO15分を満たすには、2 AZに分散したAWS CloudHSMクラスタを組み、クライアント設定で自動フェイルオーバーを有効にすると鍵同期と障害時切替が透過的に行えます。この構成は複数ノード間で鍵を冗長化し、インフラ層が耐障害性を吸収するため、短時間でのサービス再開が現実的です。FIPSレベル、鍵エクスポート、PKCS #11互換、高スループット、マルチAZ可用性という複数要件を俯瞰すると、マネージドHSMを中心に据えたアーキテクチャが総合的に最適と判断できます。

ヒントボタン

Systems Manager パラメータストア SecureString に独自の 256 ビット鍵を割り当てる場合、年 1 回の自動ローテーションを設定できるのは Customer Managed CMK だけです。AWS managed key では rotateKey が無効でルートも復号できてしまうため、キーポリシーで厳格に Principal を絞りつつローテーション要件を満たせる構成としては自前 CMK が必須となります。また KMS はリージョンあたり 1 万 decrypt/秒の性能があるため、600 回/分というアクセス量は十分に処理できます。

ECS タスクのみが復号可能で開発者やルートユーザーが鍵を直接呼び出せないようにするには、CMK のキーポリシーでタスク実行ロールを Principal に設定し、Condition に kms:ViaService=”ssm..amazonaws.com” を追加して Parameter Store 経由のアクセスに限定するのが有効です。この方法なら IAM ユーザーの CLI からの kms:Decrypt を遮断しつつ、タスクの起動時に必要な GetParameter がシームレスに成功し、最小権限とゼロトラストの原則を同時に満たせます。

KMS の Decrypt API をリアルタイムで監査し異常時に CloudWatch アラームを鳴らすには、CloudTrail を有効化して KMS イベントを CloudWatch Logs に配信し、メトリクスフィルタでしきい値を検知するフローが推奨です。CloudWatch Events だけでは Decrypt を捕捉できず、CloudTrail を無効化すると証跡も消えるため要件と矛盾します。鍵管理、アクセス制御、監査、スケーラビリティという複数要素を俯瞰し、すべてを一つの設計で網羅できる案を選ぶ視点が合格への近道です。

ヒントボタン

RDS のユーザ名やパスワードを 30 日周期で自動ローテーションし、その取得操作を CloudTrail で監査しつつ Lambda 側のコードを一切変えたくないなら、AWS Secrets Manager の RDS 連携テンプレートを用いて組み込み Lambda を自動生成させる方法が最もシンプルで、GetSecretValue 呼び出しは cmk-fintech という KMS カスタマー管理キーで暗号化され、Parameter Store で同等機能を実装する場合に必要な EventBridge とカスタム関数の開発運用コストを丸ごと削減できるという比較がポイントになります。
一方でアプリ設定のように頻繁に変わらずローテーション対象でもない小さなキーが 20 項目ある場合、Systems Manager Parameter Store Standard の SecureString へまとめて登録し同じ cmk-fintech を指定すれば無料枠も活用でき、Lambda は SDK で動的取得するだけなのでコード修正は不要、Secrets Manager に細分化して保存すると 1 シークレットごとに課金が発生して月額が跳ね上がるため、機能と料金モデルを見比べて保存先を使い分ける設計が推奨です。
つまり、ローテーションが必要な RDS 認証情報は Secrets Manager で自動化し、静的設定は Parameter Store Standard に集約、どちらも cmk-fintech で暗号化し CloudTrail で呼び出し履歴を残すという二段構えにすることで、KMS、Lambda、VPC 外実行、課金体系、運用自動化という複数の要求をバランスよく充足できるかを総合的に判断してください。

ヒントボタン

APIキーのようなシークレットを安全に扱うには、KMS CMKと連携するSecureStringを提供するSSM Parameter Storeか、自動ローテーションが強みのSecrets Managerが候補になります。毎秒レベルで呼び出す用途では取得課金のないParameter Store（スタンダード）の方が運用コストを抑えやすく、タグで細かな権限分離も行えるため金融系の厳格な環境にも適合します。Secrets Managerは高機能ですが呼び出し課金があるので、アクセス頻度と費用のバランスを意識して比較しましょう。
IAMインスタンスプロファイルにssm:GetParameterのみを許可すればEC2単位で最小権限を実現できます。Interface VPCエンドポイント経由でParameter Storeを呼び出せばインターネットを通らずレイテンシは数十ミリ秒以下となり、1秒以内取得の性能要件を支援します。組織CloudTrailをS3に保存してAthenaで検索すれば400日以上の監査証跡が確保でき、誰がいつパラメータにアクセスしたかを容易に追跡できます。
暗号化保管はKMS、低コスト取得はParameter Store、アクセス制御はIAMロール、低遅延はVPCエンドポイント、長期監査はCloudTrail＋Athenaと役割を整理すると、提示された五つの要件を追加作業や余計な費用を増やさずに同時達成できる構成が見えてきます。

ヒントボタン

鍵ポリシーで DynamoDB だけに復号を許すには、KMS の条件キーに注目すると効果的です。SSE-KMS が実行されると、dynamodb.ap-northeast-1.amazonaws.com という値を持つ kms:ViaService が自動で付きます。これを StringEquals で限定し Encrypt と Decrypt を許可すれば、アプリは透過的に暗号化されつつ他サービスやリージョン、CLI からの直接呼び出しは届きません。最小構成で制御が完結する点も強みです。

さらに Principal の扱いも鍵です。KMS では IAM ロールを作っても DynamoDB からは呼ばれないため、鍵ポリシーには自社アカウント ID を Principal として指定し、条件でアクセス経路を絞る方式が扱いやすいです。アカウント内の管理者であっても kms:ViaService が一致しなければ Decrypt は失敗するので、IAM ポリシーだけを変更する対策より確実性が高まります。将来のスケールにも柔軟に対応できることを意識しましょう。

追加の Lambda@Edge や GuardDuty を組み込む案は魅力的に見えますが、PCI DSS の観点では予防的制御が第一であり、運用負荷やコストを上げずにリスクを減らすことが優先されます。KMS キーポリシーだけでサービス・リージョン・ユーザー経路を制御できるなら、DynamoDB の SSE-KMS と組み合わせた素直な構成が、透過暗号化の維持、直接復号の禁止、クロスリージョン遮断という複数要件をバランス良く満たせるかを総合的に判断してみてください。