暗号鍵・秘密情報管理とKMS・HSMの運用

暗号化された給与レポートが流出しても、鍵が別に保管されていれば安全と言い切れるでしょうか。この記事では、架空の給与システムがレポートR-42を暗号化して保存し、後から復号するまでを追います。暗号鍵と認証用シークレット、KMSとHSM、鍵の生成・配布・保管・更新・失効、秘密分散を一つの構成で説明します。

科目B（午後）では『KMSを使う』『鍵をローテーションする』という対策名だけで足りません。誰がどの権限で復号できるか、鍵と暗号文の両方を攻撃者が得たか、旧鍵で守るデータが残るか、復旧時に何を検証するかを条件から答えます。以下の名称、時刻、ID、ログはすべて教材用の架空例です。

1. 何を守り、どの鍵を使うか

給与システムは、アプリ実行ロールpayroll-app、オブジェクト保管領域reports-prod、KMS上の論理鍵K-payroll、秘密情報管理サービス上のDB接続資格情報S-payroll-dbから構成されます。レポートR-42には従業員情報が含まれるとします。アプリはオブジェクトへの読書きと、KMSの限定された暗号操作だけを許可されます。

鍵、資格情報、権限は別の対象です。KEK素材がHSMから取り出せなくても、payroll-appにKMSのDecrypt権限とC-42の読取り権限があれば、その実行ロールを奪った攻撃者は正規APIを使って平文へ近づけます。設計の評価には鍵素材の保管場所と利用権限の両方が必要です。

2. エンベロープ暗号化の保存フロー

アプリはKMSへK-payrollを指定してDEK生成を依頼します。この構成例のKMSは、平文D-42と、K-payrollの現行版v1で包んだE-42を返します。アプリはD-42を用い、認証付き暗号AES-GCMでR-42をC-42へ変えます。暗号化処理に必要なnonceと認証タグも保存します。

図ではアプリ内部のAES-GCM暗号化を矢印にしていません。順序は、DEK受取り→nonceを選んで暗号化→C-42、E-42、nonce、認証タグなどを保存→アプリメモリの平文D-42を使い終える、です。平文DEKを確実に消去できるかは言語・実行環境に依存するため、メモリダンプやクラッシュログにも出さない設計が必要です。

record_id: R-42
ciphertext: C-42                      # レポートの暗号文
encrypted_data_key: E-42             # K-payroll v1で包んだD-42
kms_key_id: K-payroll
kms_key_version: v1
algorithm: AES-256-GCM
nonce: <R-42用の一意な値>
auth_tag: <認証タグ>
context: { purpose: payroll, report_id: R-42 }

認証付き暗号では、C-42と認証タグの整合が確認できなければ平文を採用しません。KMSのcontextでE-42の用途を結び付けても、レポート本文側のC-42を別レコードへ差し替える攻撃まで自動的に防ぐとは限りません。アプリ側のAES-GCMでもreport_idや用途をAADに結び付け、C-42とメタデータの対応を検証します。

GenerateDataKeyのAPI結果には平文DEKが含まれる設計例です。『鍵はHSM内にしかない』という説明をするなら、それがKEK素材についてなのか、DEKについてなのか明確にします。平文DEKをアプリへ返さない暗号サービスやストレージ暗号化方式では境界が異なります。

3. 復号フローと鍵・暗号文の分離

アプリがR-42を表示するとき、reports-prodからC-42、E-42、nonce、認証タグ、contextを読みます。次にKMSへE-42と同じcontextでDecryptを依頼し、平文D-42を得ます。アプリはC-42の認証タグを検証しながら復号し、認可された利用者へ結果を返します。

KMSがDecryptを許可したことは、画面を見る利用者がR-42を閲覧してよいことの証明ではありません。アプリは利用者の業務権限とR-42の所有・対象範囲を独立に確認します。またKMSへの要求者は通常アプリの実行ロールであり、業務利用者本人のIDがKMSログへ自動記録されるとは限りません。

『鍵と暗号文を別に置く』には、物理的な置き場所だけでなく、アクセス制御の分離が必要です。同じバックアップへ平文D-42、C-42、実行ロール資格情報をまとめて保存すれば、保管先を分けた効果は失われます。オブジェクト権限、KMS権限、IAM権限を別々に管理し、管理者が両方を広く得られる経路も確認します。

4. KMSとHSMは何を守り、何を守らないか

KMSは鍵の識別、版、利用権限、暗号操作、監査ログ、利用停止を運用しやすくします。HSMは特定の鍵素材や暗号処理をハードウェア境界内に閉じ込めるために使います。クラウドKMSがHSMを使う場合も、どの鍵がエクスポート可能か、平文DEKがAPIへ返るか、鍵の持込みがあるかはサービスと設定次第です。

HSMがFIPS 140-3認証を取得しているかは、該当する具体的な暗号モジュールと構成の証明書で確認します。『HSM製品を使った』というだけで、アプリのIAM設計、復号API濫用、平文DEKのメモリ露出が解消されるわけではありません。

4-1. 秘密情報管理サービスは暗号鍵管理の代用品か

S-payroll-dbを保存する秘密情報管理サービスは、アプリのDBログイン用資格情報を適切に渡し、必要ならローテーションを自動化します。KMSはそのシークレットの保存時暗号化に使われる場合があります。しかしDBパスワードの有効・無効を決めるのはDB側です。保管サービスの旧値を消しただけでは、DBで旧パスワードが使える状態が残るかもしれません。

APIトークンでも同様に、発行先のサービスで旧トークンを取り消し、新トークンを配布したアプリが動くことを確認します。暗号鍵の再暗号化と認証シークレットの再発行・無効化は別の手順です。どちらも漏えい時に『保存場所の値だけを置き換えた』では不十分です。

4-2. 鍵の利用権限と管理権限を分ける

payroll-appに必要なのは、R-42を扱うための限定された暗号操作です。鍵ポリシーの変更、鍵の削除予定設定、他ロールへの利用許可を同じ実行ロールへ与える必要はありません。運用者にも、作成・運用・監査・緊急復旧を職務ごとに分け、強い認証と操作承認を設けます。

攻撃者がDecrypt権限を持たなくても、IAMポリシーやKMS鍵ポリシー、grantを変更できれば、自分に復号権限を付けてから利用する可能性があります。したがってDecryptの成功ログだけでなく、直前の権限変更、ロールの引受け、サービス間の代理操作、鍵の無効化や削除予定操作を同じ時間軸で調べます。

contextを条件にする場合、呼出し側が任意の値を送れる点にも注意します。『purpose=payrollなら許可』だけでは、盗んだロールが同じ値を付けて別レポートを復号する余地があります。アプリの認可、対象オブジェクトの制限、KMS側の用途条件を重ね、contextと実データの対応を検証します。

5. 更新・失効・破棄で旧データはどうなるか

時刻10:00にK-payrollの新規暗号化用版をv1からv2へ切り替えたとします。以後の新しいレポートではv2で包んだEDKを作れます。一方、既存R-42のE-42はv1で包まれたままです。v1を使った復号が許されている間は読めますが、v1を無効化又は破棄すると読めなくなる可能性があります。

多くのKMS製品での『鍵ローテーション』は新規暗号化に使う鍵素材の版変更です。既存のDEKやデータを再暗号化する処理とは別です。製品によって旧版の保持・失効・破棄方法が違うため、計画には製品の実際の状態遷移を記載します。

鍵が漏れた場合、単なる定期ローテーションと同じ手順では足りません。旧鍵を持った攻撃者は、既に取得したE-42やC-42のコピーを後で復号できる可能性があります。新しい鍵へ再ラップ又は再暗号化しても、攻撃者の手元にある過去のコピーは消えません。影響期間とデータ流出の可能性を別に評価します。

どの鍵を交換するかは漏れた対象で決めます。KEK素材が漏れたなら、その版で包まれたすべてのEDKを対象にします。D-42だけが漏れたなら、まずD-42で暗号化したデータの範囲を調べます。ロール資格情報が漏れたなら、資格の停止とKMS操作履歴の調査が先です。事故対象を確定しないまま全鍵を一斉に破棄すると、証拠と復旧手段まで失うおそれがあります。

5-1. 再暗号化を安全に切り替える条件

1. 旧版で読める状態を維持しつつ、レコードごとに新EDK又は新暗号文を作る。暗号文・EDK・nonce・タグ・context・鍵版を一組として書き込む。

2. 新旧の混在期間にアプリが両版を読めることを確認する。処理件数、失敗件数、バックアップ内の旧版、オフライン複製を棚卸しする。

3. 新しい版だけで代表データとバックアップから復旧できることを実際に試験する。その後で旧版の復号を停止し、保管義務と復旧要件を満たした時点で破棄を判断する。

移行途中でE-42だけv2へ変更し、C-42を別DEKで暗号化したデータへ取り違えると、認証タグ検証に失敗して読めません。移行トランザクションや版付きメタデータ、ロールバック計画を設けます。失敗を単に『鍵が違う』と片付けず、ID・版・context・タグを突き合わせます。

6. 秘密分散は復旧用の鍵をどう守るか

通常運用のDEKを毎回人手で分けるのではなく、災害時の暗号化されたオフライン復旧資料を開く鍵K-recoveryを保管する例を考えます。Shamirのしきい値秘密分散でK-recoveryを3個の分散片に分け、担当者A・B・Cに渡し、任意の2個の分散片で復元できる2-of-3構成とします。1個の分散片だけから元の秘密は復元できません。

このK-recoveryは、HSMからエクスポートできないK-payrollの鍵素材を魔法のように復元する鍵ではありません。K-payrollの可用性は導入したKMS/HSMの正規のバックアップ、複製、災害復旧手順に依存します。どの資産をどの復旧鍵で戻せるかを台帳に明記します。

『2人の管理者が承認する』という運用上の二人承認と、暗号学的な2-of-3秘密分散は違います。また復元時にK-recoveryを一台の端末上で平文に戻すなら、その端末の侵害によって鍵が漏れます。HSMへの安全なインポートなど、復元先・作業後の消去・監査まで設計します。

Shamir方式の情報理論上の性質は、正しい実装と十分な乱数で生成した多項式の前提で成立します。分散片をメールで全員へ配る、写真を同じスマートフォンに保存する、分散片の番号を失うなどの運用ミスは防ぎません。秘密分散は通常の鍵バックアップ、権限制御、監査を置き換えません。

6-1. 分散片の更新と復元試験

担当者Bが退職した場合、Bの分散片を回収しただけでは、過去に作られた複製まで消えたとは言えません。旧分散片で旧秘密を復元できなくするには、復旧用秘密そのものを交換し、旧秘密に依存する鍵・暗号文・バックアップを移行します。同じ秘密を新しい分散片へ分け直すだけでは、残存する旧分散片を無効化できません。

復元試験では、許可された二人が所定時間内に集まり、分散片の真正性を確かめ、隔離した環境で復旧鍵を復元します。復元した値で実際にバックアップを読めるか確認し、作業後に平文秘密が端末、ログ、作業メモに残らないようにします。試験だけで本番鍵を長時間露出させない手順が必要です。

秘密分散が守るのは、保管中の復旧用秘密が一人・一拠点から復元される危険です。通常のpayroll-appが日々使うKMS Decrypt権限の濫用は止めません。この二つの経路を混同せず、通常運用の権限管理と非常時の秘密分散を別の防御点として記述します。

7. 架空の設定・ログから何が言えるか

次はR-42を一回読んだ架空ログの要約です。UTC時刻で、値の形は製品固有の記法ではありません。目的はオブジェクト読取りとKMS操作の関係を見ることです。平文DEK、DBパスワード、本文はログへ出していません。

10:05:01 object-store
  actor=payroll-app action=GetObject
  object=reports-prod/R-42 result=allow
10:05:02 kms
  actor=payroll-app action=Decrypt key=K-payroll
  context={purpose:payroll,report_id:R-42}
  result=success request=req-42
10:05:02 app
  user=hr-17 report=R-42 authorization=allow
  tag_check=ok response=success request=req-42

鍵の漏えい調査では、KMSログだけで結論を出しません。オブジェクト読取り、実行ロールの認証情報発行、KMSの許可・拒否、アプリの利用者認可、ネットワーク出口、バックアップ取得、鍵ポリシー変更を時系列で結びます。時刻がずれ、request IDが別サービスへ伝わらない場合は、相関の確度を明示します。

8. 漏えい時は何が失われたかで対処を変える

KMS Decryptの成功回数は被害推定の材料ですが、成功した要求が必ずデータ流出したとは限りません。逆に成功ログがないだけで安全とも言えず、平文キャッシュ、既に漏れたDEK、別環境の復号経路を調べます。ログ保持期間や監査設定の欠落があれば、不明範囲として明示します。

再開条件は、侵害されたロールと派生したセッションが使えないこと、過大な権限が修正済みであること、影響したデータ・鍵・シークレットの範囲が把握され移行済みであることです。正常なR-42復号に加え、別用途context、不正ロール、旧資格情報の拒否、バックアップからの復元を試します。

9. 科目B（午後）の記述演習

演習1：暗号文だけが流出

条件：C-42とE-42を保存する領域が外部公開された。KMSログに不審なDecryptはなく、平文コピーの有無は未調査。問い：確定事項と追加調査を述べよ。

解答：暗号文と包まれたDEKの流出は確定するが、平文閲覧はまだ確定しない。公開期間、平文コピー、KMS権限・ログ欠落・DEKキャッシュを調べる。誤答『暗号化済みなので事故ではない』は無断持出しと別の復号経路を無視する。

演習2：鍵版の定期更新

条件：K-payrollの新規暗号化版をv2へ切り替えた。R-42のE-42はv1で包まれたまま。問い：v1を今すぐ破棄してよいか。

解答：R-42やバックアップがv1に依存するため、そのまま破棄すると復号不能になり得る。再ラップ又は再暗号化、旧版依存調査、復元試験後に判断する。誤答『ローテーションで全暗号文がv2へ移った』は既存データの処理を飛ばしている。

演習3：DEK漏えいと再ラップ

条件：D-42の平文と旧C-42が攻撃者へ渡った。運用者はE-42だけを新KEKで包み直した。問い：対策の不足を述べよ。

解答：既に漏れたD-42で旧C-42を読めるため、E-42の再ラップだけでは不十分。新DEKでR-42を再暗号化し、持出し済みデータの影響を評価する。誤答『KEKを替えたので過去のコピーも安全』は攻撃者の手元の旧DEKを消せない。

演習4：HSMとKMS権限

条件：KEK素材は非エクスポートのHSM内にあるが、窃取されたpayroll-appロールにはGetObjectとKMS Decryptがある。問い：漏えいの成立条件と防御点を述べよ。

解答：攻撃者がそのロールで両サービスへ到達し、対象の条件を満たせばE-42を復号してC-42を読める。ロール資格情報の停止、権限とcontext・対象制限、API・出口監査が必要。誤答『HSMから鍵を取り出せないから読めない』は復号APIを見落としている。

演習5：DBパスワード更新

条件：S-payroll-dbの旧値が漏れ、秘密情報管理サービスには新値を登録したが、DBでは旧値を無効化していない。問い：残る危険と復旧試験を述べよ。

解答：攻撃者が旧値でDBへログインできる可能性が残る。DB側で旧資格を取り消し、新値での正常接続と旧値の拒否、監査ログを確認する。誤答『保管サービスを更新したので失効した』は認証先の状態を混同している。

演習6：秘密分散のしきい値

条件：K-recoveryを2-of-3で分散し、Aの分散片だけが漏れた。問い：直ちに分かること、まだ言えないこと、確認事項を述べよ。

解答：正しい方式ならAの1個の分散片だけでは秘密を復元できない。ただしB・Cの分散片や復元端末まで侵害された可能性は未確認。保管先、アクセス記録、分散片の複製を調べ、必要なら秘密を交換・再分散する。誤答『分散片が1個漏れたので必ず鍵が復元された』はしきい値を無視する。

10. 一次資料と確認先

以下は鍵ライフサイクル、暗号モジュール、エンベロープ暗号化、鍵版の更新、秘密分散の根拠です。製品ごとのAPI・ログ項目・失効状態は導入製品の仕様と実機で確認します。

NIST SP 800-57 Part 1 Rev. 5：鍵管理の全般的な指針

NIST FIPS 140-3：暗号モジュールの要件

NIST SP 800-38D：GCMと認証付き暗号

AWS KMS：鍵階層とデータ鍵の扱い

AWS KMS：ローテーションで変わるもの・変わらないもの

AWS KMS：暗号化コンテキストと監査

AWS KMS：最小権限での鍵利用許可

Google Cloud KMS：鍵更新後の既存データ再暗号化

Adi Shamir：How to Share a Secret（原論文）