カスタマー所有型とカスタマーマネージド型暗号鍵：違いと重要性

機密データを復号する鍵を管理しているのは誰でしょうか？この問いへの答えが、組織が本当のデータプライバシーを実現できているのか、それとも単なるセキュリティの幻想に過ぎないのかを決定づけます。クラウドプロバイダーはデフォルトで暗号化を提供しており、多くの組織はファイルが暗号化されている限りデータは保護されていると考えがちです。しかし、暗号化の強度よりも鍵の管理権限の方がはるかに重要です。なぜなら、クラウドプロバイダーが暗号鍵に技術的にアクセスでき、組織が知らないうちにデータを復号できてしまう場合、真のプライバシーは確保できないからです。

暗号鍵管理には、プロバイダー管理型鍵、顧客管理型鍵（BYOK）、顧客所有型鍵（HYOK）の3つのモデルがあります。それぞれ、暗号化されたデータへのアクセス権限に異なるレベルのコントロールを提供します。鍵を「管理」することと「所有」することの違いは、政府機関から召喚状が発行された場合や、データ主権の証明が求められるコンプライアンスフレームワーク、あるいはクラウドプロバイダーでさえ機密情報にアクセスできないことを証明する必要がある場合に、極めて重要となります。

Executive Summary

主なポイント： 顧客管理型暗号鍵（BYOK）はクラウドプロバイダーの環境内に保管され、プロバイダーが法的要請に応じてアクセス可能ですが、顧客所有型鍵（HYOK）は顧客の専有管理下にあり、プロバイダーによるアクセスを完全に防ぎます。

なぜ重要か： プロバイダー管理型またはBYOK暗号化を利用している組織は、CLOUD法による政府のアクセス要請、プロバイダー内部の脅威、GDPR（Schrems II後）やCMMCレベル3など真のデータ主権が求められるフレームワークでのコンプライアンス不履行といったデータプライバシーリスクに直面します。

5つの重要なポイント

1. BYOKとHYOKは名前が似ていても、根本的に異なるセキュリティモデルです。 BYOKは顧客が生成した鍵をプロバイダーの鍵管理サービスに保管し、プロバイダーが技術的にアクセス可能です。一方、HYOKは鍵をオンプレミスのHSMやプライベートインフラで顧客が専有管理します。

2. CLOUD法により、米国の法執行機関は世界中どこに保存されていてもクラウドプロバイダーに顧客データの復号を強制でき、多くの場合顧客への通知なしに実行されます。 この法的枠組みにより、BYOK暗号化はクラウドプロバイダー経由での合法的な政府アクセスに対して保護を提供できません。データの物理的な保存場所に関係なく適用されます。

3. データ主権とデータプライバシーは異なる概念であり、異なる技術的コントロールが必要です。 データを特定の地理的地域に保存しても、プロバイダーが暗号鍵を管理している限りアクセスを防げません。真のプライバシー保護には鍵の所有が不可欠です。

4. Schrems II判決以降、コンプライアンスフレームワークは顧客所有型暗号鍵を求める傾向が強まっています。 GDPR、NIS2、CMMCレベル3、FedRAMP Highなどは、プロバイダーが顧客データにアクセスできない暗号化モデルを事実上義務付けています。

5. 顧客所有型鍵の運用上のトレードオフは、セキュリティや機能ではなく、複雑さとコストにあります。 HYOKを導入することで同等の暗号強度やアプリケーションパフォーマンスを維持しつつ、真のプライバシー保護を実現できますが、鍵管理には追加のインフラや専門知識が必要です。

3つの暗号鍵管理モデル

プロバイダー管理型暗号鍵とは？

プロバイダー管理型暗号化は、クラウドプロバイダーがすべての暗号鍵を自社インフラ内で生成・保管・管理するデフォルトのモデルです。

組織がクラウドストレージにデータをアップロードすると、プロバイダーは自社が管理する鍵で自動的に暗号化します。この方式は顧客側の設定が不要で、透過的に動作します。鍵のローテーションやバックアップ、ライフサイクル管理もプロバイダーが担当します。顧客は暗号化されたストレージを、暗号化の専門知識や鍵管理インフラなしで利用できます。

しかし、このモデルには根本的なプライバシー上の脆弱性があります。プロバイダーは暗号化されたデータと復号用の鍵の両方を保持しているため、任意のタイミングで顧客データにアクセスでき、法的要請があれば復号して提供することも可能です。法執行機関はプロバイダーに対して顧客データの復号・提出を命じることができます。適切な権限を持つプロバイダー従業員も暗号化情報を閲覧できます。プロバイダーシステムのセキュリティ侵害が発生した場合、データと鍵が同時に漏洩するリスクもあります。

プロバイダー管理型鍵が許容されるケース：

• 規制要件のない非機密データ
• 社内開発・テスト環境
• 完全性保護のみが必要な公開情報
• クラウドプロバイダーのセキュリティと法令遵守を全面的に信頼できる場合

BYOK（Bring Your Own Key）とは？

BYOK暗号化は、顧客が自分の環境で暗号鍵を生成し、それをクラウドプロバイダーの鍵管理サービスにアップロードできるモデルです。

顧客は独自の暗号化ツールで鍵を作成し、その鍵をAWS KMS、Azure Key Vault、Google Cloud KMSなどプロバイダーのKMSインフラに転送します。プロバイダーは顧客鍵を自社生成鍵とは分離して保管し、追加のアクセス制御を適用します。顧客は鍵をプロバイダーKMSから削除・失効させることでデータを読めなくできます。このモデルは鍵のライフサイクル管理において顧客のコントロールを強化しつつ、鍵の保管や暗号化処理の運用面はプロバイダーが担います。

重要な制約は、BYOK鍵がプロバイダーの環境内に存在することです。すべての暗号化・復号処理はプロバイダーのシステム上で実行されるため、プロバイダーインフラが鍵情報にアクセスできる必要があります。プロバイダーは厳格なアクセス制御や監査ログを導入していますが、技術的には顧客鍵を利用可能です。法執行機関はプロバイダーに対し、BYOK鍵を使って顧客データを復号するよう強制できます。十分な権限を持つプロバイダー管理者は鍵情報にアクセスできます。プロバイダーKMSインフラのセキュリティ侵害が発生すれば、顧客鍵が漏洩するリスクもあります。

BYOK導入プロセス：

1. 顧客がローカルの暗号化ツールやHSMで暗号鍵を生成
2. 顧客が暗号化通信経路でプロバイダーKMSに鍵を安全に転送
3. プロバイダーがKMSインフラに顧客専用のアクセス制御付きで鍵を保管
4. すべての暗号化・復号処理はプロバイダー環境内で顧客鍵を使用して実行
5. 顧客はプロバイダー管理画面から鍵のローテーション、失効、削除が可能

BYOKのプライバシー保護上の制限：

• 鍵はプロバイダーKMSインフラに保管される
• 法令遵守や管理目的、侵害時にプロバイダーが鍵にアクセス可能
• CLOUD法により顧客通知なしでプロバイダー経由で政府アクセスが可能
• 適切な権限を持つプロバイダー従業員が鍵を使ってデータを復号できる

HYOK（Hold Your Own Key）とは？

HYOKは暗号鍵をオンプレミスのハードウェアセキュリティモジュールやプライベートクラウドインフラなど、顧客が専有管理する環境下にのみ保管し、プロバイダーが一切アクセスできないモデルです。

顧客は自社のHSMや鍵管理システムで鍵を生成・保管します。クラウドアプリケーションが暗号化・復号を必要とする場合、プロバイダー管理鍵ではなく、顧客の鍵管理インフラにリクエストを送信します。暗号鍵はプロバイダー環境に一切入らず、プロバイダーは技術的にアクセスできません。このアーキテクチャにより、法的要請があってもプロバイダーが顧客データを復号できないゼロナレッジシステムが実現します。

HYOKは、プロバイダーが復号権限を持たないため、本物のプライバシー保護を提供します。プロバイダーに対する法的召喚状が発行されても、プロバイダーは暗号鍵を持たないため復号済みデータを提出できません。プロバイダーのセキュリティ侵害でも鍵情報は漏洩しません。プロバイダー管理者は権限レベルに関係なく暗号化コンテンツにアクセスできません。暗号鍵の利用タイミングや方法は顧客組織のみがコントロールします。

HYOK導入アプローチ：

• オンプレミスHSMとクラウドワークロードの連携
• 顧客がインフラ全体を管理するプライベートクラウド展開
• 顧客鍵サーバとプロバイダー計算リソースのハイブリッド構成
• 最高レベルのセキュリティ要件向けエアギャップシステム

HYOKのプライバシー上の利点：

• 鍵が顧客管理下から一切離れない
• プロバイダーは技術的にデータを復号できない
• プロバイダー経由の合法的な政府アクセスから保護
• 鍵のライフサイクル管理を顧客が全てコントロールできる

なぜプロバイダーの鍵アクセスはデータプライバシーを破壊するのか

CLOUD法はどのように顧客に通知せず政府アクセスを可能にするのか？

Clarifying Lawful Overseas Use of Data（CLOUD）法は、米国の法執行機関が、データの物理的な保存場所に関係なく、米国のテクノロジー企業に世界中のデータの提供を強制できる法律です。

2018年に成立したCLOUD法は、米国の令状が海外サーバに保存されたデータの提出を企業に強制できるかどうかという法的論争を解決しました。この法律により、米国拠点のクラウドプロバイダーは、管理下にあるすべてのデータについて有効な米国の法的手続きに従う義務があり、プロバイダーが暗号鍵を保有している場合、地理的なデータ保存場所は無関係となります。法執行機関はプロバイダーに対して、データの復号および提出を命じる令状や召喚状を取得できます。データが欧州やアジアなどどこに保存されていても、プロバイダーは従う必要があります。

国家安全保障書簡には、プロバイダーが顧客にデータアクセスを通知することを禁じるギャグオーダーが含まれることが多く、プロバイダー管理型やBYOK暗号化を利用している顧客は、法執行機関が機密情報を復号・閲覧したことに気付かない場合があります。プロバイダーは暗号鍵を利用する技術的能力を持ち、法執行機関はその利用を強制する法的権限を持ち、顧客はアクセスを防ぐ技術的手段を持ちません。

この枠組みにより、データを特定の地理的地域に保存するなどのデータ主権対策は、プロバイダーが暗号鍵を管理している限りプライバシー保護にはなりません。米国クラウドプロバイダーが暗号鍵を保有している場合、欧州サーバに保存された欧州データも米国法執行機関がアクセス可能です。

CLOUD法が暗号化モデルに与える影響：

• プロバイダー管理型鍵：プロバイダーは有効な法的手続きでデータを復号可能
• プロバイダーKMS内のBYOK鍵：法的強制時にプロバイダーが顧客鍵でデータを復号可能
• 顧客管理下のHYOK鍵：プロバイダーは鍵を持たないためデータを復号できない

SHIELD法とは？なぜ十分ではないのか？

Securing and Handling of Internet and Electronic Data（SHIELD）法案は、まだ成立していませんが、クラウドプロバイダー経由で外国政府が米国データにアクセスすることを防ぐことを目的としています。

この法案は、米国裁判所の承認なしにクラウドプロバイダーが外国政府の米国人データへのアクセス要請に応じることを禁止します。CLOUD法が米国法執行機関による外国保存データへのアクセスを可能にしているのと同様の相互保護を目指しています。しかし、仮に成立しても、米国政府による顧客データへのアクセスや、プロバイダーの技術的な復号能力の排除、プロバイダー管理型暗号鍵の根本的なプライバシー脆弱性の解消にはなりません。

データプライバシーを重視する組織は、成立するかどうか分からず、根本的な問題を解決しない法案に頼るべきではありません。顧客所有型暗号鍵による技術的コントロールこそが、法改正に左右されず確実なプライバシー保護を実現します。

技術的コントロールを法規制で代替できない理由：

• 法律は変更・廃止される可能性がある
• 執行状況は管轄や政治情勢によって異なる
• ギャグオーダーにより顧客がアクセス発生を知ることができない
• HYOKのような技術的コントロールなら法的枠組みに関係なくプロバイダーのアクセス能力を排除できる

Schrems II判決はデータ主権要件をどう変えたか？

2020年の欧州司法裁判所によるSchrems II判決は、米国企業によるEU個人データの米国移転を認めていたプライバシーシールド枠組みを無効としました。

裁判所は、特にFISA第702条や大統領令12333などの米国監視法がEU市民のデータに十分な保護を提供していないと判断しました。米国法の適用を受ける米国クラウドプロバイダーは、EUデータが米国政府からプライバシーを守られることを保証できません。判決では、米国法が米国企業の保有データに対して情報機関による十分な司法監督や救済措置なしにアクセスを認めている点が特に指摘されました。

この決定により、欧州組織はクラウド暗号化のアプローチを根本的に見直す必要が生じました。単にデータをEUリージョンに保存するだけでは、米国プロバイダーが暗号鍵を管理し、米国法に基づき復号を強制される場合、GDPR要件を満たしません。判決は、プロバイダーのアクセスを防ぐ技術的対策が必要であることを事実上求めており、顧客所有型暗号鍵やプライベート展開モデルへの移行を促しています。

Schrems II判決が鍵管理に与える影響：

• EU組織は契約上のデータ保護合意だけに頼ることができない
• プロバイダーのアクセスを防ぐ技術的コントロールが米国-EU間のデータ移転に必須
• 顧客所有型暗号鍵はプロバイダーのアクセス能力を排除し、GDPR準拠を可能にする
• NIS2指令は重要分野の組織に対する要件を強化

どのコンプライアンスフレームワークが顧客鍵の所有を求めているか？

規制要件は、特に政府請負業者、重要インフラ、EU個人情報を扱う組織に対して、プロバイダーが顧客データにアクセスできない暗号化モデルをますます義務付けています。

防衛請負業者が対象防衛情報（CUI）を扱う場合のCMMCレベル3では、伝送中および保存中の不正開示を防ぐ暗号化メカニズムの使用が求められます。CUI保護への重点とNIST 800-172の強化されたセキュリティ要件との整合性から、プロバイダーが分類情報や機密防衛情報にアクセスできないようにする顧客管理型鍵が事実上義務付けられています。

FedRAMP High認証やDoDインパクトレベル5ワークロードでは、クラウドプロバイダーが顧客データにアクセスできない暗号化保護が求められます。これらのフレームワークは、連邦機関や防衛システムで扱われるデータは、ホスティングプロバイダーを含む顧客組織以外のすべての関係者から保護される必要があると想定しています。

GDPR第32条は適切な技術的対策によるデータセキュリティを求めており、Schrems II以降のガイダンスでは、プロバイダーが鍵を管理し外国法で復号を強制される場合、暗号化だけでは不十分とされています。十分なデータ保護法がない国へのEU個人データ移転には補完的な対策が必須であり、顧客所有型暗号鍵はこの要件を満たす数少ない技術的コントロールの一つです。

顧客鍵の所有を重視するコンプライアンスフレームワーク：

• 防衛サプライチェーンにおけるCUI保護のためのCMMCレベル3
• 連邦機関データ向けFedRAMP HighおよびDoD IL5
• Schrems II以降の第三国へのEU個人データ移転におけるGDPR
• 重要分野の組織に対するNIS2
• ドイツBDSGおよびフランスのデータ主権要件

技術的実装：各モデルの仕組み

クラウドプロバイダーはBYOKをどう実装しているか？

クラウドプロバイダーは、顧客が生成した鍵を受け入れつつ、暗号化インフラの運用管理権限を維持する鍵管理サービスを通じてBYOKを実装しています。

顧客はOpenSSLやクラウドプロバイダーCLI、ハードウェアセキュリティモジュールなどのローカルツールで暗号鍵を生成します。その後、TLS暗号化などで保護された安全なAPIコールを使い、プロバイダーKMSに鍵情報をアップロードします。プロバイダーは顧客鍵をFIPS 140-2認証済みHSMなどのKMSインフラに保管し、どの顧客アカウントやサービスが各鍵を利用できるかをアクセス制御します。

アプリケーションがデータを暗号化する必要がある場合、プロバイダーのKMS APIを呼び出して処理を実行します。KMSは顧客鍵でデータを暗号化し、暗号文を返します。復号も同様で、アプリケーションが暗号文をKMSに送り、KMSが顧客鍵で復号して平文を返します。すべての暗号処理は、プロバイダーインフラ内で顧客鍵を使って実行されます。

BYOKのワークフロー：

1. 顧客がローカル暗号化ツールで鍵を生成
2. 顧客が暗号化APIコールでプロバイダーKMSに鍵をアップロード
3. プロバイダーがKMS内に顧客専用のアクセス制御付きで鍵を保管
4. アプリケーションがプロバイダーKMSに暗号化・復号処理をリクエスト
5. プロバイダーKMSが顧客鍵で暗号処理を実行
6. プロバイダーがアプリケーションに結果を返却

HYOKはどのように顧客コントロールを維持するか？

HYOKの実装では、暗号鍵を顧客管理インフラに保管し、暗号処理もプロバイダー環境外で実行します。

顧客はオンプレミスHSMや鍵管理システムを導入し、鍵をプロバイダーインフラに同期させません。クラウドアプリケーションが暗号化・復号を必要とする際は、安全なネットワーク接続で顧客鍵管理システムに接続します。暗号処理は顧客インフラで実行され、鍵がプロバイダー管理下を離れることはありません。プライベートクラウド展開では、顧客がインフラスタック全体を管理することで、プロバイダーのアクセスを技術的に不可能にします。

高度なHYOKアーキテクチャでは、クライアントデバイス側でデータを暗号化してからクラウドストレージに送信するアプリケーション層暗号化を実装します。クラウドプロバイダーは暗号文のみを受信し、復号の手段を持ちません。この方式により、法的強制があってもプロバイダーが顧客データにアクセスできないゼロナレッジシステムが実現します。

HYOKのワークフロー：

1. 顧客が自社インフラにHSMや鍵管理システムを導入
2. 顧客がすべての暗号鍵をローカルで生成・保管
3. クラウドアプリケーションが顧客鍵管理システムに接続
4. 顧客システムが暗号化・復号処理を実行
5. 鍵が顧客管理下から一切離れず、プロバイダー環境に入らない
6. プロバイダーは暗号化データのみを受信し、復号できない

セキュリティとコンプライアンスへの影響

顧客鍵の所有が防ぐ脅威とは？

顧客所有型暗号鍵は、プロバイダー管理型やBYOKモデルでは対処できない脅威を根本から排除します。

プロバイダーが復号能力を持たないため、法執行機関経由のアクセス（CLOUD法シナリオ）は消滅します。プロバイダーに対する召喚状や令状が発行されても、暗号鍵を持たないため復号済みデータを提出できません。情報機関による監視強制も、プロバイダーが技術的に協力できないため実現しません。この保護は、どの国の政府からの要請であっても、またどの法的枠組みであっても有効です。

クラウドプロバイダー内部の悪意ある関係者も、鍵がプロバイダーインフラ外にある限り顧客データにアクセスできません。プロバイダーの管理システムやKMSインフラ、バックアップシステムが侵害されても、暗号鍵が漏洩せずデータ復号も不可能です。第三者監査人やマネージドサービスプロバイダーなど、プロバイダーシステムにアクセスできる他者も顧客データを復号できません。

顧客鍵の所有で軽減される脅威：

• プロバイダー経由の合法的な政府アクセス（CLOUD法シナリオ）
• プロバイダー内部者による暗号化データへのアクセス
• プロバイダーのセキュリティ侵害によるデータと鍵の同時漏洩
• データ主権対策を迂回する越境データアクセス
• プロバイダーシステムやパートナー経由の第三者アクセス

運用上のトレードオフは？

顧客所有型暗号鍵は、プライバシーやコンプライアンス上の利点と引き換えに、運用面での複雑さやコスト増をもたらします。

パフォーマンスへの影響は実装方式によって異なります。HYOKでクラウドワークロードから顧客鍵管理システムへのネットワーク通信が必要な場合、プロバイダーKMSに比べて暗号処理に遅延が発生します。クラウドワークロードとオンプレミス鍵管理インフラ間の安定したネットワーク接続も必要です。ただし、顧客がインフラ全体を管理するプライベート展開モデルでは、ネットワーク遅延を排除しつつ鍵の所有を維持できます。

可用性や災害復旧も、顧客が暗号鍵を管理する場合はより複雑になります。HSMの冗長化や鍵バックアップ、リカバリ手順をプロバイダーに頼らず自前で実装する必要があります。鍵管理には専門知識が必要であり、多くの組織は社内に十分なノウハウを持っていません。HSMハードウェアや安全な設備、専門人材のコストは、プロバイダー管理型暗号化の追加コストゼロに比べて高くなります。

運用上の考慮点：

• パフォーマンス：プロバイダーKMSに比べ、ネットワーク越しの鍵操作で遅延が発生する可能性
• 可用性：鍵インフラの冗長化・災害復旧を顧客が担う必要
• 複雑さ：暗号化の専門知識や鍵ライフサイクル管理手順が必要
• コスト：HSMハードウェア、設備、人材費用 vs. プロバイダー管理型暗号化の無償

HYOKやプライベート展開が必須となるケースは？

特定のコンプライアンス要件、脅威モデル、データの機密性レベルによっては、顧客所有型暗号鍵がオプションではなく必須となります。

CMMCレベル3でCUIを扱う防衛契約では、プロバイダーアクセスを防ぐ強化セキュリティ要件を満たす必要があります。インパクトレベル5データを処理する連邦機関やFedRAMP High認証を目指す場合も、プロバイダーが情報を復号できない暗号化保護が必要です。Schrems II以降、欧州組織が米国プロバイダーに個人データを移転する場合も、米国政府によるプロバイダー経由のアクセスを防ぐ技術的対策が必須です。

すべてのネットワークセグメントやサービスプロバイダーを潜在的に侵害されていると想定するゼロトラストアーキテクチャでも、顧客所有型鍵が求められます。国家レベルの脅威アクターがプロバイダーへの協力を強制する可能性がある敵対的環境でも、プロバイダーが技術的に協力できない暗号化モデルが必要です。NIS2要件下の重要インフラ組織も、クラウドプロバイダーがセキュリティインシデントや法的強制に直面しても本質的に保護されることを証明しなければなりません。

顧客鍵の所有が必須となるシナリオ：

• 防衛請負業者のCMMCレベル3 CUI保護
• 連邦機関ワークロードのFedRAMP HighおよびDoD IL5
• Schrems II以降のGDPR準拠EU-米国データ移転
• 政府・防衛の機密情報システム
• 金融サービスの知的財産や取引アルゴリズム
• 外部関係者から患者プライバシーを守る医療システム

データプライバシーの要件は、他の暗号鍵選択肢よりも最優先される

顧客管理型と顧客所有型暗号鍵の違いは、組織が本物のデータプライバシーを実現できるか、それとも単なるセキュリティの幻想にとどまるかを決定づけます。BYOKモデルで顧客生成鍵をプロバイダーインフラに保管しても、法的手続きでプロバイダーが協力を強制されたり、プロバイダーシステムが侵害された場合、プロバイダーアクセスを許してしまいます。CLOUD法や同様の法的枠組みにより、地理的なデータ保存場所は無関係となり、プロバイダーが暗号鍵を管理している限り、通知なしに顧客情報の復号を強制されるリスクがあります。

HYOK導入やプライベート展開による顧客所有型暗号鍵こそが、プロバイダー経由の合法的な政府アクセス、プロバイダー内部の脅威、プロバイダーが暗号化データにアクセスできることによるコンプライアンス不履行から組織を守る唯一のモデルです。CMMCレベル3、FedRAMP High、Schrems II以降のGDPR要件の対象となる組織では、顧客鍵の所有はオプションのセキュリティ強化から必須のコンプライアンス要件へと変化しています。

運用上のトレードオフは、セキュリティや機能ではなく、複雑さやコストにあります。顧客所有型鍵を導入しても、同等の暗号強度やアプリケーション機能を維持しつつ、コンプライアンスフレームワークが求めるプライバシー保護を実現できます。Kiteworksは、顧客が暗号鍵を完全に管理し、プロバイダーによる機密データアクセスを排除し、最も厳格な規制要件を満たす真のデータ主権を実現するプライベート展開オプションを提供しています。

Kiteworksによる顧客管理型暗号化の実現

Kiteworksは、顧客が暗号鍵とデータアクセスを完全に管理できるプライベート展開オプションによって、顧客所有型暗号化を実現しています。

プライベートデータネットワークアーキテクチャは、オンプレミス、プライベートクラウド、エアギャップネットワークなど、顧客がインフラ全体を管理する環境に展開可能です。AES-256暗号化により、すべての保存データを顧客インフラから一切離れない鍵で保護します。Kiteworksの従業員やサポート担当者も顧客の暗号鍵やデータを復号できず、真のゼロナレッジアーキテクチャを実現します。

ハードウェアセキュリティモジュール（HSM）連携により、暗号鍵をFIPS 140-2レベル3のタンパー耐性ハードウェアで顧客専有管理できます。顧客は独自の鍵管理手順やローテーションスケジュール、アクセス制御をKiteworksの関与なしで実装可能です。オンプレミスHSMアプライアンスと顧客管理型クラウドHSMサービスの両方に対応しています。

プライベート展開により、マルチテナントクラウドアーキテクチャに内在するデータプライバシーの脆弱性を排除します。法執行機関からKiteworksへの召喚状が発行されても、Kiteworksは暗号鍵を持たないため顧客データを復号できません。サービスプロバイダーが顧客暗号鍵を一切保有しない場合、CLOUD法は無関係となります。組織は、Schrems II以降のGDPR要件を満たす真のデータ主権を実現できます。

本プラットフォームは、セキュアメール、ファイル共有、マネージドファイル転送、Webフォームを統合し、一貫した暗号化とアクセス制御を提供します。これにより、異なる通信チャネルごとに異なる鍵管理モデルを使い分けることで生じるセキュリティギャップを排除します。

顧客所有型暗号鍵によるデータプライバシー最大化について詳しく知りたい方は、カスタムデモを予約してください。

追加リソース

• ブログ記事
  公開鍵暗号と秘密鍵暗号の違いを徹底解説
• ブログ記事
  データ暗号化のベストプラクティス集
• eBook データ暗号化の最新トレンド10選：AES-256の詳細分析
• ブログ記事
  E2EE（エンドツーエンド暗号化）の実例を徹底解説
• ブログ記事
  AES 256暗号化の完全ガイド：データ保護を強化し、破られないセキュリティを実現