Customer-Owned Keys：カストディ管理がクラウドデータセキュリティを左右する理由 鍵を持つ者がデータを制す：顧客所有の鍵なしの暗号化は保護とは言えない

はじめに

クラウドストレージを販売するベンダーは皆、「データは暗号化されています」と口を揃えます。しかし、その一言の裏に、本当に重要なポイントが隠されています。誰のための暗号化なのか？もしベンダーが鍵を保持している場合、暗号化は外部からの攻撃には有効でも、ベンダー自身や、ベンダーに法的な強制力を持つ第三者からデータを守ることはできません。

これは仮定の話ではありません。鍵付きのドアも、大家が合鍵を持ち、誰か公的な人物に頼まれたらすぐに渡してしまうなら、意味がありません。クラウドの暗号化も同様で、顧客ではなくプロバイダーが鍵を管理している限り、同じことが起こります。本記事では、鍵の管理権限が実際に何を変えるのか、なぜ多くのセキュリティレビューがこの点を見落としがちなのか、そして本当の意味で顧客が鍵を所有・管理するには何が必要なのかを解説します。

ポイント1：暗号化は、鍵を持たない者からのみデータを守ります。ベンダーが鍵を持っている場合、暗号化はベンダーやベンダーに強制力を持つ第三者から顧客を守ることはできません。

ポイント2：「持ち込み鍵（BYOK）」と「ベンダー管理鍵」は同じ管理レベルではありません。前者はベンダーが顧客データを復号できる権限を排除しますが、後者はその権限を完全に残します。

ポイント3：ハードウェアセキュリティモジュール（HSM）は、鍵の所有権をポリシーから物理的な事実へと変えます。顧客が管理するHSM内で生成・保存された鍵は、データをホストするプラットフォームが管理者権限を持っていても抽出できません。

ポイント4：鍵のローテーションや暗号スイートの制御ができるかどうかが、所有権が本物か名目上かを決めます。顧客が必要な時に鍵をローテーションできず、使用する暗号方式を選べない場合、実質的な運用管理はできていません。

ポイント5：どんなに強力な暗号でも、間違った相手が鍵を持っていれば意味がありません。ベンダーが管理する256ビット鍵は、弱い鍵と同様に、最も重要な脅威からは何も守れません。

エグゼクティブサマリー

データ暗号化の議論は多くの場合、アルゴリズムや鍵長で終わります。まるでAES-256なら安全だと言わんばかりです。しかし、実際に暗号化が組織を守るかどうかを決めるのは「誰が鍵を管理しているか」です。鍵を管理する者がデータを支配します。ベンダーが顧客の代わりに鍵を生成・保存・管理している場合、ベンダーはいつでも、どんな理由でも（たとえ自分が選ばなかった理由でも）データを読む技術的な能力を持ち続けます。ハードウェアによって裏付けられた顧客所有の鍵管理は、その能力を完全に排除します。エンタープライズのセキュリティチームにとって、暗号化は単なるチェック項目ではなく、「ベンダーが当社のデータを復号できるのか否か」という明確で検証可能なアーキテクチャ上の意思決定となります。

暗号強度だけを問うのは間違い

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

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

暗号化されたファイルと平文の間に立ちはだかるものは、唯一「鍵」です。その鍵を持つ者は、データを読み取ったり、他者のために復号したり、法的手続きで強制されて復号することもできます。暗号アルゴリズムの強度はこれらに何の影響も与えません。強力な暗号でベンダーが鍵を持つ場合と、弱い暗号でベンダーが鍵を持つ場合、ベンダーからの保護という観点では違いはありません。どちらも、ベンダーが望めば、あるいは命令されれば、データを読むことができるからです。

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

ベンダーのドキュメントは「業界標準のアルゴリズムで保存時・転送時ともに暗号化」といった、包括的に聞こえる表現を使いがちです。これは正確ですが不十分です。誰が鍵を生成し、どこに保存し、ベンダーのインフラから鍵にアクセスできるかどうかは一切触れていません。暗号化の主張だけを鵜呑みにし、鍵の管理権限について個別に確認しない場合、顧客は誤った安心感を抱くことになります。

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

鍵の所有は、単一の機能ではなく、一連の条件がすべて満たされて初めて成立します。どれか一つでも欠ければ、顧客の鍵管理は理論上のものに過ぎなくなります。

持ち込み鍵（BYOK）とベンダー管理鍵の違い

ベンダー管理鍵モデルでは、プラットフォームが自社インフラの一部として暗号鍵を生成・保存します。顧客が鍵そのものを見ることはありません。一方、持ち込み鍵（BYOK）や顧客所有鍵モデルでは、顧客が鍵の生成・保存を管理し、通常は顧客が管理する、または専用アクセス権を持つハードウェアセキュリティモジュール（HSM）を利用します。この違いは表面的なものではありません。ベンダーが顧客データを技術的に復号できるか否かという、本質的な違いです。ベンダーのマーケティング資料がどれほど暗号強度を謳っていても、そこは変わりません。

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

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

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

一度鍵を持ったからといって、継続的に管理できているとは限りません。実運用で本当の鍵所有権を持つか、データシート上だけの主張に終わるかは、2つの運用上のポイントで決まります。

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

万が一、認証情報の漏洩や従業員の退職、侵害の疑いなどで鍵が漏れた可能性がある場合、ベンダーのリリーススケジュールやサポート対応を待たず、即座に鍵をローテーションできることが、実運用上の鍵所有権を意味します。自分のタイミングで鍵をローテーションできない場合、所有権の書類がどうであれ、顧客は完全に管理できていません。

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

特定の暗号スイートを有効・無効にしたり、許可するTLSバージョンを制御できることも、別の形の重要なコントロールです。たとえば、コンプライアンスの期限前に非推奨の暗号を廃止したい場合や、TLS 1.3のみに制限したい場合、ベンダーに依頼して対応を待つ必要があってはなりません。このレベルの設定ができない場合、顧客は自社のセキュリティ方針ではなく、ベンダーのデフォルト設定に依存していることになります。

ベンダー選定時の「鍵管理」チェックポイント

セキュリティチームがベンダーを評価する際、実務上のポイントはシンプルですが、時間がないと見落としがちです。誰が鍵を生成するのか、どこに保存するのか、HSMが使われているか、誰がどのタイミングで鍵をローテーションできるのかを確認しましょう。これらすべてに明確に「顧客が全工程を管理」と答えられるベンダーは、防御可能な鍵管理モデルを持っています。アルゴリズムや鍵長だけしか答えられないベンダーは、暗号化後のデータ管理権限について何も明かしていません。

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

顧客所有の鍵管理は、プラットフォームのアーキテクチャに組み込まれて初めて本来の効果を発揮します。多くの導入で省略されがちなオプション機能ではなく、鍵管理を基盤的な特性として扱うデータコントロールプレーンは、メール、ファイル共有、API、AIエージェントなど、データが通過するすべてのチャネルで、ベンダーが顧客データを技術的に復号できない状態を保証します（顧客が細かく設定したチャネルだけでなく、すべてに適用されます）。

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

現在利用中のベンダーの鍵管理モデルをこの基準で検証したい場合は、カスタムデモを予約し、顧客管理型HSM統合が自社の暗号化・コンプライアンス要件にどう適用できるかご確認いただけます。