ベンダーが保持する鍵は、ベンダーが読み取れる設計ファイルです

製造業向けのプラットフォームベンダーは、設計ファイルが暗号化されていると口を揃えて言います。しかし、その主張の裏にある本質的な保護の違いは「誰が鍵を保持しているか」です。ベンダーが鍵を持っている場合、暗号化は外部からの設計情報の保護にはなっても、ベンダー自身や裁判所命令でベンダーに復号を強制できる者からの保護にはなりません。

これは、CADファイルや部品表、サプライヤーデータをグローバルなサプライチェーンで共有する製造業にとって、仮定の話ではありません。金庫に鍵をかけても、ベンダーが合鍵を持ち、要請があればすぐに渡してしまうなら意味がありません。本記事では、鍵の管理権限が製造業にどのような影響を与えるのか、なぜ多くのセキュリティレビューでこの点が見落とされるのか、そして真の顧客所有型鍵管理には実際に何が必要なのか（誰が鍵をローテーションできるのか、どのタイミングでできるのかまで）を解説します。

Executive Summary

エンジニアリングデータを扱うプラットフォームのセキュリティレビューでは、暗号化アルゴリズムや鍵長で評価が止まりがちですが、AES-256であれば設計ファイルが安全だというわけではありません。本当に保護を左右するのは「誰が鍵を管理しているか」です。鍵を管理する者がデータを制御でき、暗号化の有無に関わらず、鍵を持つベンダーは製造業者が知らない理由や同意していない理由でも、いつでも設計ファイルを閲覧できる技術的能力を持ちます。ハードウェアによる顧客所有型鍵管理は、この能力を完全に排除します。エンジニアリングやITリーダーにとって、暗号化はベンダーの主張ではなく、具体的かつ検証可能なアーキテクチャ上の事実として捉え直すべきです。

Key Takeaways

1. 暗号化は鍵を持たない第三者からのみデータを保護します。ベンダーが鍵を持つ場合、設計情報の保護は暗号化そのものではなく、ベンダーの善意に依存します。
2. BYOK（Bring Your Own Key）モデルはベンダーの復号能力を完全に排除します。ベンダー管理型の鍵では、どんなアルゴリズムやマーケティング文句であっても、復号能力はベンダーに残ります。
3. ハードウェアセキュリティモジュール（HSM）は、鍵の所有をポリシーではなく物理的な事実にします。製造業者が管理するHSMで生成・保存された鍵は、データをホストするプラットフォームからも、管理者権限があっても取り出せません。
4. オンデマンドでの鍵ローテーションは真の所有権の一部です。自社のタイミングで鍵をローテーションできない場合、製造業者は営業秘密を完全にコントロールできているとは言えません。
5. 暗号化の強度は、間違った者が鍵を持っていれば無意味です。営業秘密の観点で重要なのは「誰が復号できるか」であり、暗号の強さではありません。

設計データにおいて暗号強度が本質的な問いでない理由

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

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

暗号化された設計ファイルと平文の間に立ちはだかる唯一のものが「鍵」です。その鍵を持つ者は、データを閲覧したり、他者のために復号したり、法的手続きで復号を強制されたりします。強力な暗号でベンダーが鍵を持つ場合も、弱い暗号の場合も、どちらも制限要因は同じです。ベンダーが望めば、または命令されれば、データを読めるという点で違いはありません。

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

ベンダーの資料は「業界標準のアルゴリズムで保存・転送時に暗号化」といった、完結した印象を与える説明が多いですが、これは正確でありながら不十分です。誰が鍵を生成し、どこに保存し、ベンダーのインフラが鍵にアクセスできるかどうかは一切触れられていません。この説明だけに頼ると、サプライヤー向けのセキュリティレビューで実質的な回答ができません。

真の顧客所有型鍵管理に必要な条件

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

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

ベンダー管理型では、プラットフォームが自社インフラの一部として鍵を生成・保存し、製造業者は鍵そのものを一度も目にしない場合もあります。顧客所有型では、製造業者が鍵の生成・保存を管理し、通常は自社管理または専用アクセス権を持つHSMを利用します。この違いは、ベンダーが技術的に設計ファイルを復号できるか否かという決定的な違いであり、暗号強度に関するベンダーのマーケティング文句とは無関係です。

HSMが言葉以上に重要な理由

HSMは、暗号鍵の生成・保存・管理を、管理者権限を持つ者であっても取り出せないように設計された専用の物理デバイスです。鍵管理をアプリケーションと同じソフトウェア上でなくHSMと統合することで、鍵の所有は設定項目ではなく物理的な制約となります。適切に統合されたHSMは、ポリシーではなく設計によって、密かに鍵を抜き取る可能性を排除します。

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

一度鍵を持つことと、継続的に制御することは別物です。実運用で真の鍵所有と、仕様書上は正しく見えても実際には機能しない主張を分けるのは、2つの運用上のポイントです。

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

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

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

特定の暗号スイートやTLSバージョンの有効・無効を自社のタイミングで制御できることも、ベンダーのスケジュールに依存しない独立した制御権限の一つです。

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

エンジニアリングやITチームがベンダーを評価する際、実際に問うべきことはシンプルですが、時間に追われると見落とされがちです。鍵の生成者は誰か、どこに保存されているか、HSMが使われているか、誰がどのタイミングでローテーションできるかを確認しましょう。すべての質問に明確に答え、製造業者が全工程を制御できるベンダーであれば、堅牢な鍵管理モデルと言えます。アルゴリズムや鍵長だけを答えるベンダーは、暗号化後の設計情報の実質的な管理者が誰かを明らかにしていません。

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

顧客所有型鍵管理は、プラットフォームのアーキテクチャに組み込まれて初めて本来の機能を発揮します。多くの導入で省略されるアドオン機能では不十分です。鍵管理を基盤機能とするデータコントロールプレーンは、ベンダーが設計ファイルを復号できないことを、メール、ファイル共有、API、AIエージェントなど、あらゆるデータ流通チャネルで保証します。

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

現在のベンダーの鍵管理モデルをこの基準で検証したい製造業者は、カスタムデモを予約し、自社の設計データやサプライチェーン要件に対する顧客管理型HSM統合の適用例をご確認いただけます。