CUI保護における鍵管理の本当の要件とは

防衛請負業者向けのプラットフォームベンダーは、CUIが暗号化されていると口を揃えて言います。しかし、その主張は本質的な保護の決め手、つまり「誰が鍵を保持しているか」という点を隠しています。ベンダーが鍵を保持している場合、暗号化は外部からの制御データの保護にはなっても、ベンダー自身や、ベンダーに復号を法的に強制できる者からはデータを守れません。

これは、輸出規制対象の技術データをサードパーティプラットフォーム経由でやり取りする請負業者にとって、仮定の話ではありません。ベンダーが合鍵を持ち、外国当局から要請があればすぐに渡してしまうようでは、鍵付きキャビネットに意味はありません。本記事では、鍵の管理権限が防衛請負業者にとって実際に何を変えるのか、なぜ多くのセキュリティレビューでこの詳細が見落とされがちなのか、そして本当の意味で顧客が鍵を所有するために必要な実務要件（誰がいつ鍵をローテーションできるのかまで）を解説します。

エグゼクティブサマリー

CUIを扱うプラットフォームのセキュリティレビューは、暗号化アルゴリズムや鍵長で止まってしまうことが多く、AES-256であれば輸出管理要件を自動的に満たすかのように扱われがちです。しかし実際にはそうではありません。本質的な保護を決めるのは「誰が鍵を管理しているか」であり、鍵を管理する者がデータを制御できるのです。ベンダーが請負業者の代わりに鍵を生成・保管・管理している場合、ベンダーは理由を問わず、いつでも制御技術データを閲覧できる技術的能力を保持し続けます。たとえ請負業者が同意していない理由であっても、事後的に知らされることすらあります。ハードウェアによる顧客所有の鍵管理は、その能力自体を完全に排除します。プログラムのセキュリティ担当者にとって、これは暗号化を単なる書類上の項目から、CMMCや輸出管理レビュー時にアセッサーが直接検証できる、具体的かつテスト可能なアーキテクチャ上の事実へと再定義するものです。

主なポイント

1. 暗号化は、鍵を持たない者からのみデータを保護します。ベンダーが鍵を保持している場合、CUIの保護は暗号化そのものではなく、ベンダーの善意に依存します。
2. BYOK（Bring Your Own Key）モデルは、ベンダーの復号能力を完全に排除し、輸出管理要件を直接サポートします。ベンダー管理の鍵では、どんなアルゴリズムを使っていても、提案書でどう説明されていても、その能力は残ったままです。
3. ハードウェアセキュリティモジュール（HSM）は、鍵の所有をポリシーではなく物理的な事実にします。請負業者が管理するHSMで生成・保管された鍵は、データをホストするプラットフォームが管理者権限を持っていても抽出できません。
4. オンデマンドでの鍵ローテーションは、本当の所有権の一部です。請負業者が自分のタイミングで鍵をローテーションできない場合、制御技術データに対する完全な運用上のコントロールはありません。
5. どれだけ強力な暗号化でも、誤った者が鍵を持っていれば意味がありません。CUIにとって重要なのは、誰が復号できるかであり、暗号の強度ではありません。

CUIにおいて暗号強度が本質的な問いでない理由

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

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

暗号化されたCUIファイルと平文での閲覧を分ける唯一のものが「鍵」です。その鍵を持つ者は、データを読んだり、他人のために復号したり、法的手続きで復号を強制されたりできます。強力な暗号とベンダー保持の鍵で暗号化されたファイルは、暗号が弱い場合と比べて、ベンダーからの保護という観点では本質的に大差ありません。どちらも「ベンダーが読もうと思えば読める」「命令されれば復号できる」点が変わらないからです。

なぜベンダーはこの違いを強調しないのか

ベンダーのドキュメントは「業界標準のアルゴリズムで保存時・転送時ともに暗号化」といった、いかにも十分な説明に聞こえる表現を使いがちです。これは正確ですが不十分です。誰が鍵を生成したのか、どこに保管されているのか、ベンダー自身のインフラから鍵にアクセスできるのかどうかなど、輸出管理レビューがまさに明らかにしようとするポイントについては何も語っていません。

本当の顧客所有鍵管理に必要なもの

鍵の所有は、単一の機能ではなく、すべてが満たされなければならない一連の条件によって成り立ちます。どれか一つでも欠ければ、請負業者の鍵に対するコントロールは理論上のものとなり、実運用では機能しません。

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

ベンダー管理鍵モデルでは、プラットフォームが自社インフラの一部として暗号鍵を生成・保管し、請負業者はその鍵を一度も目にしないこともあります。顧客所有鍵モデルでは、請負業者が鍵の生成・保管を管理し、通常は自ら管理する、または専用アクセス権を持つハードウェアセキュリティモジュールを利用します。この違いは、ベンダーがCUIを技術的に復号できるか否かという点であり、暗号強度についてベンダーのマーケティング資料が何を謳っていようと関係ありません。

ハードウェアセキュリティモジュールが言葉以上に重要な理由

ハードウェアセキュリティモジュール（HSM）は、暗号鍵の生成・保管・管理を、管理者権限を持つ者でも抽出できないように設計された専用の物理デバイスです。鍵管理をアプリケーションと同じソフトウェア上に置くのではなく、HSMと統合することで、鍵の所有は設定項目から物理的制約へと変わります。ソフトウェアのみで「顧客所有鍵」を謳っていても、ベンダーが自社インフラに十分な権限を持っていれば、実質的には密かに覆すことが可能です。適切に統合されたHSMは、ポリシーではなく設計上、その可能性を排除します。

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

一度鍵を持っただけでは、継続的にコントロールしていることにはなりません。運用上の2つのポイントが、本当の鍵所有と、データシート上は正しく見えてもアセッサーの質問で破綻する主張とを分けます。

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

万が一、鍵が漏洩した疑いがある場合（認証情報の漏洩、従業員の退職、侵害の疑いなど）、ベンダーのリリーススケジュールやサポート対応を待たずに、即座に鍵をローテーションできる能力こそが、制御データに対する鍵所有を運用上意味あるものにします。

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

特定の暗号スイートの有効・無効化や、許可するTLSバージョンのコントロールも、別の形の重要な制御です。特に、アセスメント前に非推奨の暗号を廃止する際など、ベンダーの都合ではなく請負業者自身のタイミングで実施できる必要があります。

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

ベンダーを評価するプログラムセキュリティチームにとって、実務上のポイントはシンプルでありながら、時間的余裕がないと見落とされがちです。「誰が鍵を生成するのか」「どこに保管されるのか」「HSMが使われているか」「誰がいつ鍵をローテーションできるか」を必ず確認しましょう。これらすべてに明確に答え、請負業者がすべての工程をコントロールできるベンダーであれば、防御可能な鍵管理モデルと言えます。逆に、アルゴリズムや鍵長だけしか答えないベンダーは、CUIが暗号化された後に誰が実際に制御しているかについて、請負業者に何も伝えていません。

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

顧客所有鍵管理は、プラットフォームのアーキテクチャに組み込まれて初めて、その本来の価値を発揮します。ほとんどの導入で省略されるオプション機能として提供されるだけでは不十分です。鍵管理を基盤的な特性として扱うデータコントロールプレーンは、ベンダーがCUIを復号できないという技術的制約を、メール、ファイル共有、API、AIエージェントなど、データが流れるすべてのチャネルで保証します。

Kiteworksのデータコントロールプレーンは、顧客所有の暗号鍵をハードウェアセキュリティモジュール経由で統合し、広く利用されているHSMプロバイダーにも対応しているため、鍵の生成・保管はKiteworksの管理範囲外となります。請負業者はオンデマンドで鍵をローテーションでき、利用する暗号スイートやTLSバージョンもコントロール可能。さらに、単一テナントアーキテクチャで他の顧客環境と鍵管理が共有されることもありません。その上で、データ認識型のゼロトラスト制御がすべての送信・共有・アクセス操作を全チャネルで統制し、すべての操作は改ざん防止かつ制限のない監査ログに記録され、SIEMツールに直接連携されます。これにより、鍵管理の主張は提案書の一文ではなく、実際の運用記録によって裏付けられます。

現在利用中のベンダーの鍵管理モデルがこの基準を満たしているかテストしたい請負業者は、カスタムデモを予約し、自社のCUIや輸出管理要件に対する顧客管理HSM統合の適用例を確認できます。