市民記録と「誰が実際に復号できるのか」という問題

政府機関向けのプラットフォームベンダーは、すべて「市民データは暗号化されている」と謳います。しかし、その主張の裏にある本質的な保護の違いは「誰が鍵を保持しているか」です。ベンダーが鍵を持っている場合、暗号化は市民記録を外部から守るだけで、ベンダー自身や、ベンダーに法的に復号を強制できる第三者からは守れません。

これは、第三者プラットフォームを通じて市民記録を扱う機関にとって、仮定の話ではありません。アーカイブがロックされていても、ベンダーが合鍵を持ち、外国当局から要請があればすぐに渡してしまうなら、意味がありません。本記事では、鍵の管理権限が政府機関にとって何を変えるのか、なぜ多くのセキュリティレビューでこの点が見落とされがちなのか、そして本当の顧客所有型鍵管理には何が必要なのか、鍵のローテーション権限やそのタイミングまで、実務的な観点から解説します。

エグゼクティブサマリー

政府プラットフォームのセキュリティレビューは、暗号化アルゴリズムや鍵長で止まってしまうことが多く、AES-256なら市民データは安全だと誤解されがちです。しかし、実際に保護を左右するのは「誰が鍵を管理しているか」です。鍵を管理する者がデータを制御でき、暗号化の有無に関わらず、鍵を持つベンダーは、機関が同意していない理由や市民が承諾していない理由でも、いつでも市民記録を閲覧できる技術的能力を持ち続けます。ハードウェアによって裏付けられた顧客所有型鍵管理は、その能力を完全に排除します。公共部門のITリーダーにとって、暗号化は調達のチェックリストから、具体的かつ検証可能なアーキテクチャ上の事実へと再定義されます。

主なポイント

1. 暗号化は、鍵を持たない第三者からのみデータを守ります。 ベンダーが鍵を持つ場合、市民データの保護は暗号化そのものではなく、ベンダーの善意に依存します。
2. BYOK（Bring Your Own Key）モデルは、ベンダーの復号能力を完全に排除します。 ベンダー管理型の鍵では、どんなアルゴリズムを使っても、調達書類にどう記載されていても、ベンダーの復号能力は残ります。
3. ハードウェアセキュリティモジュール（HSM）は、鍵の所有権をポリシーではなく物理的な事実にします。 機関が管理するHSMで生成・保存された鍵は、データをホストするプラットフォームが管理者権限を持っていても取り出せません。
4. オンデマンドの鍵ローテーションも本当の所有権の一部です。 機関が自分のタイミングで鍵をローテーションできない場合、市民データを完全に制御しているとは言えません。
5. どれだけ強力な暗号化でも、間違った主体が鍵を持っていれば意味がありません。 市民の信頼にとって重要なのは「誰が復号できるか」であり、暗号の強度ではありません。

市民データ保護において暗号化強度が本質的な問いではない理由

セキュリティレビューでは常に暗号化について問われ、その回答はほぼ例外なく「保存時はAES-256、転送時はTLS 1.3」といったアルゴリズムの説明に終始します。これらの説明は事実ですが、本質からは外れています。

暗号化されたデータにも鍵の所有者がいる

暗号化された市民記録と平文の間に立ちはだかる唯一のものが「鍵」です。鍵を持つ者はデータを閲覧でき、他者のために復号したり、法的手続きによって復号を強制されたりします。強力な暗号でベンダーが鍵を持つファイルは、暗号が弱くてもベンダーが鍵を持つファイルと本質的な違いはありません。どちらも、ベンダーが望めば、または命令されれば、閲覧できるからです。

ベンダーがこの違いを強調しない理由

ベンダーのドキュメントは「業界標準のアルゴリズムで保存・転送時に暗号化」といった、包括的に聞こえる表現を使いがちです。これは正確ですが不十分です。誰が鍵を生成し、どこに保存し、ベンダーのインフラから鍵にアクセスできるかどうかについては何も触れていません。この主張だけに頼る機関は、議会の調査に対して十分な説明ができません。

本当の顧客所有型鍵管理に必要なこと

鍵の所有は、単なる機能ではなく、複数の条件がすべて満たされて初めて成立します。どれか一つでも欠ければ、機関の鍵管理は理論上のものとなり、実際の運用では機能しません。

BYOK（顧客所有型鍵）とベンダー管理型鍵の違い

ベンダー管理型モデルでは、プラットフォームが自社インフラ内で暗号鍵を生成・保存し、機関は鍵そのものを一度も目にしない場合もあります。顧客所有型モデルでは、機関が鍵の生成と保存を管理し、通常は自ら管理または専用アクセス権を持つハードウェアセキュリティモジュールを利用します。この違いは、ベンダーが技術的に市民データを復号できるか否かという決定的な差です。

ハードウェアセキュリティモジュールが持つ本当の意味

ハードウェアセキュリティモジュール（HSM）は、暗号鍵を生成・保存・管理するための専用物理デバイスであり、周辺システムの管理者権限を持つ者であっても鍵の取り出しが困難な設計になっています。ソフトウェアのみで「顧客所有型鍵」を謳っても、ベンダーが自社インフラに十分なアクセス権を持っていれば、実質的に覆される可能性があります。HSMを適切に統合することで、ポリシーではなく設計上、そのリスクを排除できます。

鍵のローテーションと暗号制御が所有権の本質を決める理由

一度鍵を持つことと、継続的に制御することは異なります。運用上の2つのポイントが、本当の鍵所有と、データシート上は正しく見えても実務で機能しない主張とを分けます。

オンデマンド鍵ローテーション

機関が鍵の漏洩や侵害を疑った場合、ベンダーのリリーススケジュールを待たず、即座に鍵をローテーションできる能力こそが、運用上意味のある鍵所有を実現します。

細かな暗号スイート・プロトコル制御

特定の暗号スイートを有効・無効にしたり、許可するTLSバージョンを制御したりできることも、別の形の制御権です。これも、ベンダーではなく機関自身のタイミングで行える必要があります。

ベンダー選定時のデューデリジェンスに鍵管理を組み込む

公共部門のITチームがベンダーを評価する際は、「誰が鍵を生成するか」「どこに保存されるか」「HSMが使われているか」「誰が、どのタイミングでローテーションできるか」を確認することが重要です。アルゴリズムや鍵長だけを答えるベンダーは、暗号化後の市民データの実質的な管理権について何も明かしていません。

データコントロールプレーンで鍵所有をアーキテクチャ上の保証に

Kiteworksのデータコントロールプレーンは、顧客所有型暗号鍵をハードウェアセキュリティモジュール経由で統合し、鍵の生成・保存をKiteworksの管理外に置きます。機関はオンデマンドで鍵をローテーションし、使用する暗号スイートやTLSバージョンを制御し、鍵管理が他の顧客環境と共有されないシングルテナントアーキテクチャで運用できます。メール、ファイル共有、API、AIエージェントなど、すべてのチャネルでの操作は、改ざん防止・無制限の監査ログとして記録され、SIEMツールに直接連携されます。これにより、鍵管理の主張が調達書類上の一文ではなく、実際の運用記録によって裏付けられます。

現在利用中のベンダーの鍵管理モデルがこの基準を満たしているか確認したい機関は、カスタムデモを予約し、自組織の市民データやコンプライアンス要件に対する顧客管理型HSM統合の適用例をご覧いただけます。