保存データ暗号化の設計 — どこまで暗号化し、鍵を誰が持つか

保存データの暗号化は「対策済み」と言い切りやすい施策だが、実装層・脅威モデル・鍵管理の設計が噛み合っていない構成では、インシデント発生時に暗号化がまったく機能しないという事態が起きる。この記事では「どの層で暗号化するか」「鍵を誰が持つか」という2軸の判断フレームを整理し、暗号化を積み上げるほど復旧できなくなる境界線を示す。脅威を特定せずに全層に暗号化を施す設計は、セキュリティ向上より鍵管理コストと復旧リスクを増やす結果になりやすい点が、この設計判断の核心だ。

「暗号化済み」の一言で守れた気になる構造

暗号化の「層」が違えば守るものが違う

暗号化には、ディスク全体暗号化（FDE）、ファイルシステムレベル暗号化、アプリケーション層暗号化という3つの主要な実装層がある。それぞれが保護する対象と脅威モデルはまったく異なるにもかかわらず、「ストレージを暗号化した」という一文で三者をまとめて語る現場は珍しくない。ディスク全体暗号化が防げるのは、主に物理メディアの持ち出し・紛失シナリオだ。稼働中のOSが鍵を保持している状態では、そのOSに侵入した攻撃者はデータを平文で読める。ランサムウェアやリモートからの不正アクセスに対してはほとんど機能しておらず、「暗号化済み」という言葉の安心感だけが残る構造になりやすい。

OSが起動している間はディスク暗号化は透明になる

FDEが有効であっても、OSがブート時に鍵を展開した瞬間からファイルシステムは平文でマウントされる。バックアップツール、エージェント、モニタリングプロセスがroot権限で動いている環境では、暗号化の有無にかかわらずファイルへのアクセスが可能だ。20台以上のオンプレミスサーバーを管理する現場で「FDEを入れたから安心」という前提のもと、バックアップの転送経路を平文のままにしていたという話をよく聞く。脅威モデルと暗号化層の対応関係を整理しないまま「済み」と判断すると、こうしたギャップが積み重なる。

「守りたい脅威」を先に決めないと暗号化は形骸化する

設計の起点は「何から守るか」という脅威モデルの定義だ。物理盗難、不正アクセス、内部不正、クラウドプロバイダーからの保護、それぞれで有効な暗号化層が異なる。脅威を定義せずに「全部やる」と決めると、鍵管理の複雑度だけが上がり、復旧時のボトルネックが増え続ける。どの脅威をどの層で受け持つかを設計段階で明示することが、後の運用設計を安定させる基点になり、後述するチェックフレームの起点にもなる。

暗号化が要る領域と要らない領域の判断

データの感度分類が判断の前提になる

暗号化の適用範囲を決める前に、格納されるデータの感度を分類する必要がある。個人情報・認証情報・決済データは規制要件（PCI DSS、GDPRなど）によって暗号化が義務化されているケースがあり、判断の余地は少ない。一方で、パブリックに公開されているコンテンツのキャッシュや、不特定多数がアクセスできる静的ファイルに対してアプリ層の暗号化を施しても、実質的なセキュリティ向上はほとんど見込めない。データの感度分類を最初に行い、「どのデータが漏洩したときに実害が発生するか」を基準に適用範囲を絞ることが、設計の無駄を減らす第一歩になる。

アクセス経路と保管場所の組み合わせで判断する

同じデータであっても、アクセス経路と保管場所の組み合わせによって暗号化の要否は変わる。クラウドのマネージドDBに保管し、VPC内の専用エンドポイント経由でのみアクセスするデータと、汎用ストレージにオブジェクトとして置きCDN経由で配信するデータとでは、優先度が異なる。前者はネットワーク境界とIAMで制御できているなら、追加の暗号化コストと鍵管理の負荷を比較検討する余地がある。後者は意図せず公開範囲が広がるリスクがあるため、暗号化よりアクセス制御の徹底を先に置くべきだ。アクセス経路が絞られているほど、暗号化以外の制御を先行させる設計が有効になる。

「暗号化しない」と決める基準を明文化する

「暗号化しない」という判断を設計書に明示することも、設計責任のひとつだ。現場では「とりあえず暗号化しておく」という選択が積み重なると鍵の種類が増加し、インシデント対応時に復号を担当できる人間が不在という状況が起きやすい。適用しない理由を「データ感度が低い」「ネットワーク経路で保護済み」「復旧コストが守るべき価値を上回る」の3軸で評価し、ドキュメントに残す運用が、後からの監査にも耐えられる設計をつくる。明示した非適用の根拠は、要件変更時の再判断のトリガーとしても機能する。

比較: ディスク全体 / ファイルシステム / アプリ側暗号化

各層の保護範囲と適用シナリオ

3つの実装層はそれぞれ有効な脅威シナリオが異なるため、「何から守るか」の答えによって選ぶ層が決まる。以下の比較表を設計判断の参照軸として使うことができる。

暗号化層	有効な脅威シナリオ	有効でない脅威シナリオ	主な適用シナリオ	鍵管理の主体
ディスク全体暗号化（FDE）	物理メディアの持ち出し・紛失、廃棄時の情報漏洩	OS起動後の不正アクセス、ランサムウェア、内部不正	オンプレミスサーバー、ラップトップ、廃棄予定ドライブ	OS / TPM / ブートパスワード
ファイルシステム暗号化	特定ディレクトリへの不正アクセス、マルチテナント環境での論理分離	暗号化パーティションをマウント中のプロセスからの読み取り	機密ファイルのみ分離保護、共有サーバーの論理分離	OSユーザー鍵 / 外部KMS連携
アプリケーション層暗号化	DBアクセス権を持つ内部者・侵害されたDBアカウントからの読み取り	アプリケーション自体の侵害、メモリダンプからの取得	個人情報・認証情報の個別カラム保護、規制対応	アプリ / KMS / HSM

実装工数と運用負荷の現実

ディスク全体暗号化はOSレベルで有効化する手順が確立されており、既存のサーバー10台程度であれば設定作業自体は数時間で終わるケースが多い。ただしブート時の鍵入力やTPMとの連携設計が必要で、無人再起動ができなくなるリスクを運用設計に織り込む必要がある。ファイルシステム暗号化はディレクトリ単位で制御できる柔軟性がある一方、マウント管理とパーミッション設計が複雑になり、設計誤りによるデータ消失リスクが上がる。アプリ側暗号化は最も細粒度で制御できるが、暗号化・復号処理のコードがアプリに入ることでテスト工数と保守コストが増える。50テーブル規模のDBに対して個別カラム暗号化を適用した場合、移行工数が当初見積もりの3倍を超えたという事例もある。

層を重ねる場合の役割分担の考え方

複数の層を重ねること自体は選択肢として存在するが、重ねる場合は「どの層が何の脅威を担当するか」の責任範囲を明示したうえで設計する必要がある。FDEで物理盗難を防ぎ、アプリ層で内部不正を防ぐという役割分担は合理的な構成だ。しかし「念のため全部やる」という判断で重ねた場合、各層に対応する鍵の数が増え、復旧時の解決ステップが複雑になる。層を増やすごとに「その鍵を誰が管理し、どのタイミングで使うか」を復旧手順書に追記することが、後の運用で破綻しない設計の前提になる。

鍵の保管場所と持ち主をどう決めるか

自前KMS vs マネージドKMSの判断軸

鍵管理システム（KMS）の選択は、コントロールの粒度とオペレーション負荷のトレードオフだ。クラウドプロバイダーのマネージドKMSを使うと、鍵のローテーション・監査ログ・権限管理がAPIで統一的に扱える。一方で、クラウドプロバイダー自体を信頼境界の外に置く必要がある環境（政府系・金融規制対応など）では、HSM（ハードウェアセキュリティモジュール）を自前で運用するか、プロバイダーが提供するCMK（Customer Managed Key）オプションを選ぶことになる。ここでの判断は「誰がデータに最終的にアクセスできる立場を持つか」という問いへの答えで整理できる。自前HSMを選択した場合、HSM自体の冗長化・バックアップ・担当者育成が新たな設計課題として加わる点も見込んでおく必要がある。

鍵の所有者と利用者を分離する設計

鍵を作成・管理する主体と、鍵を使って暗号化・復号する主体を分離することが、内部不正や誤操作のリスクを下げる基本設計だ。マネージドKMSでは、IAMポリシーとKMSキーポリシーの2層で権限を制御し、「鍵の作成・削除ができるロール」と「鍵を使ってデータを暗号化できるロール」を別のIAMエンティティに割り当てる。この分離がないと、アプリケーションサービスアカウントが鍵を削除できる状態になり、バグや侵害時の影響範囲が不必要に広がる。分離設計は最小権限の原則をKMS層でも徹底する判断であり、構築初期から組み込まないと後からの変更コストが高くなる。

マルチクラウド・ハイブリッド環境での鍵管理の複雑化

オンプレミスとクラウドを組み合わせる環境では、鍵のストアが複数に分散しやすい。オンプレミスのHSMで生成した鍵をクラウドへのデータ移行時に使い、クラウド側ではマネージドKMSを使うという構成になった結果、鍵の棚卸しを担当できる人間が組織に1人しかいないという状況が生まれた現場がある。単一障害点として鍵管理担当者が存在することは、事業継続の観点からも設計リスクとして明示しておく必要がある。鍵管理の属人化を防ぐには、鍵の一覧・保管先・用途・有効期限を記した鍵台帳を整備し、複数人が参照・更新できる状態を維持することが求められる。

鍵のローテーションと復旧手順をどこまで作るか

ローテーション頻度の設計と再暗号化コスト

鍵のローテーションは「古い鍵で暗号化されたデータを新しい鍵で再暗号化する」か、「鍵自体だけを入れ替えてデータの再暗号化は行わない（エンベロープ暗号化）」かで運用コストが大きく変わる。マネージドKMSのエンベロープ暗号化では、データを暗号化したDEK（データ暗号化鍵）をKEK（鍵暗号化鍵）で暗号化する構造を採り、KEKのローテーションだけで完結するため、データ量に依存しないローテーションが可能になる。アプリ側で独自に暗号化しているケースでは、ローテーション時に全データの再暗号化が発生し、数百GBのテーブルでは夜間バッチでも処理しきれない規模になることがある。ローテーション頻度と再暗号化コストの試算は設計段階で行う必要がある。

鍵を失ったときの復旧手順を設計する

「鍵を失ったらデータは完全に失われる」という前提を設計書に書いておくことが、復旧手順設計の出発点だ。バックアップデータが暗号化されていて鍵が失われると、バックアップ自体が使えなくなる。KMSの削除保護（削除保留期間）が無効化されていたためにキーが消失し、バックアップが復元不能になったケースが現場で報告されている。鍵のエスクロー（別系統での保管）、削除保護の必須化、鍵失効時のデータ影響範囲のドキュメント化を、復旧手順設計の3点セットとして整備することが求められる。この3点が揃っていない状態で暗号化を本番に適用するのは、バックアップのない本番構築と同様のリスクをはらむ。

本番環境での復旧テストを組み込む

鍵ローテーション後に復号できるかを確認するテストを、定期的な本番環境の運用サイクルに組み込んでいる現場は少ない。構築時には動作確認を行っても、ローテーションのたびにテストを実施する手順が整備されていないケースが多い。年1回程度の復旧演習で「鍵ローテーション→バックアップからの復元→データの整合性確認」を通しで実施する計画を設計段階で立案しておくことで、運用フェーズでの形骸化を防ぐことができる。演習の結果を復旧手順書にフィードバックして更新する仕組みをセットで設計に含めることが重要だ。

暗号化を積み上げて復旧できなくなる境界

多層暗号化が生む複合依存関係

FDE・ファイルシステム暗号化・アプリ側暗号化を重ねると、復旧時に「どの層の鍵が有効か」を確認するステップが増える。OSが起動しない状態でディスクを別のホストにマウントして復旧しようとした場合、FDEの鍵がTPMに紐づいていると取り出せない。さらにその上でファイルシステム暗号化が動いていると、FDEを解除しても次の層で立ち止まる。複数の暗号化層が絡むと復旧のデシジョンツリーが複雑になり、インシデント対応中の判断に時間がかかる状況が生まれやすい。緊急時こそ手順が単純であることが復旧速度に直結するため、多層設計は「緊急時の手順の複雑さ」とのバランスで選択する必要がある。

「全部やる」が最悪シナリオを生む判断

セキュリティ要件を満たすために暗号化を全層に適用した結果、復旧手順が誰も実行できない状態になることがある。構築を担当したエンジニアが異動・退職した場合、暗号化の設計意図と鍵の所在を知る人間が組織内に残らないケースもある。「全部やる」を選択するなら、各層の鍵管理責任者・バックアップ先・復旧手順書を最低2名が再現できる状態で維持することをセットで設計に含める必要がある。暗号化層の数と、それを運用できる体制のキャパシティは比例させておくことが原則だ。この前提を設計段階で確認しないまま構築を進めると、セキュリティ強化のはずが可用性リスクに転じる。

復旧不能を防ぐ設計の境界線を引く

どこで「これ以上積み上げない」という境界を引くかは、復旧SLAと鍵管理体制から逆算する。RTO（目標復旧時間）が4時間以内に設定されているなら、4時間以内に通しで実行できる復旧手順に収まる暗号化設計を選ぶ必要がある。その手順を担える体制がなければ、暗号化層を減らす判断が正しい。設計段階でRTOに対する復旧手順の実行可能性を検証し、「やれる体制があるか」を確認することが、積み上げ型の設計リスクを制御する方法になる。「暗号化するかどうか」ではなく、「その暗号化設計を運用できるか」を問うことが、設計の質を決める問いだ。

暗号化設計チェックフレーム

設計・レビュー時に使うチェックリスト

以下のチェックリストを設計レビュー時に使うことで、暗号化設計の抜け漏れを構造的に確認できる。「NO」が多い場合は、暗号化を適用する前に鍵管理と復旧設計を先に整備することが優先になる。

1. 脅威モデルの定義: 物理盗難 / 不正アクセス / 内部不正 / プロバイダーからの保護のどれに対して暗号化するかを設計書に明示しているか。
2. データ感度分類の完了: 格納データを感度レベルで分類し、暗号化対象と非対象を区別して記録しているか。
3. 暗号化しない領域の根拠明文化: 暗号化しないと決めた領域について、その根拠（感度・経路・コスト）を設計書に記載しているか。
4. 暗号化層と脅威の対応確認: 各暗号化層（FDE / FS / アプリ）が対応する脅威と、有効でない脅威を整理しているか。
5. 鍵の所有者と利用者の分離: 鍵の作成・削除権限と、鍵を使って暗号化する権限を別のIAMロール・エンティティに割り当てているか。
6. 鍵管理担当者の複数化: 鍵の棚卸し・ローテーション・エスクローを担当できる人間が最低2名存在するか。
7. 鍵台帳の整備: 鍵の一覧・保管先・用途・有効期限を記した台帳があり、複数人が参照・更新できる状態か。
8. 鍵削除保護の有効化: KMSの削除保留期間が有効化されており、誤削除・不正削除に対する猶予が設定されているか。
9. ローテーション方式と再暗号化コストの試算: エンベロープ暗号化を採用しているか。採用しない場合は再暗号化に要するデータ量・工数を試算しているか。
10. 復旧手順書の存在と最新性: 鍵失効・削除・漏洩の各シナリオで復旧手順書が存在し、最終更新日が明記されているか。
11. RTOとの整合性確認: 暗号化層の数と復旧手順の複雑度が、定めたRTO内で実行可能な範囲に収まっているか。
12. 復旧演習の計画: 年1回以上、鍵ローテーション後のバックアップ復元テストを実施する計画が運用スケジュールに組み込まれているか。

設計レビューのタイミングと更新サイクル

暗号化設計は構築時の一回限りではなく、環境変化に合わせて見直すサイクルを持つ必要がある。KMSポリシーの変更、IAMロールの組み替え、担当者の異動・退職がトリガーになるケースが多い。半年から1年に一度、上記のチェックリストを使って設計の棚卸しをする運用を設計段階で計画しておくことで、暗号化設計の形骸化を防ぐことができる。チェックリストは「現在の体制でこの暗号化設計を運用できるか」という問いに答えるためのツールとして機能し、暗号化の複雑さが増すたびに体制の追いつきを確認する手段として使い続けることが、設計の長期的な健全性を保つ方法になる。