サードパーティデータ共有におけるデータ主権の実践ガイド：ベンダー、下請け業者、多国籍環境

データ主権は、データが単一の組織や法域内にとどまっている場合は管理しやすいものです。しかし、データが共有される瞬間—ベンダー、下請け業者、地域子会社、または異なる法制度下で運営されるパートナーと—ガバナンスの課題が生じます。

多くの組織は、主要なコンプライアンス層は適切に管理できているものの、主権を失うのは周縁部です。たとえば、ベンダーチェーン、多国籍企業内の国境を越えた内部転送、そして大半の機密データが正式な主権管理フレームワーク外に流出するメールやファイル共有チャネルなどが挙げられます。

本ガイドでは、データが第三者との関係に移る際に伴う規制上の義務、中央集権型多国籍データモデルにおける主権リスク、移動中の非構造化データという見落とされがちな主権リスク面、ベンダー契約に必須の要件と代替できない事柄、そして第三者主権を技術的に担保する暗号化アーキテクチャについて解説します。

エグゼクティブサマリー

主旨： データ管理者は、契約チェーンがどれほど深くても、プロセッサーやサブプロセッサーによるデータの取り扱いについて責任を負い続けます。主権の失敗は、主要なクラウドプロバイダーではなく、ベンダーチェーン、多国籍企業内の内部転送、そして正式な主権管理外で大量の機密データがやり取りされる非構造化データチャネル（メール、ファイル共有、MFT）で最も多く発生します。技術的な基盤となるのは、顧客所有の暗号鍵です。データ所有者がベンダーが一切保持しない鍵を管理することで、ベンダーは法的強制があっても可読なコンテンツにアクセス・開示できず、契約だけでは埋められないギャップを解消します。

なぜ重要か： GDPR第28条のプロセッサー義務、DORAのICTサードパーティリスク要件（2025年1月施行）、NIS 2のサプライチェーンセキュリティ義務は、グローバル売上高の4%に及ぶ罰則や経営層の個人責任を伴う重複した説明責任を課しています。これらの義務は、メールやファイル共有内の非構造化データにも、データベース内の構造化データと同様に適用されますが、多くの組織はこの区別を運用レベルで実現できていません。

主なポイント

1. データ管理者は処理チェーン全体に対して責任を負う。 GDPR第28条により、管理者はプロセッサーおよびサブプロセッサーのコンプライアンスについて、契約層がいくつ重なっていても責任を負います。4次下請け業者による違反や主権侵害も、管理者の規制リスクとなります。
2. 多国籍企業内の内部転送もGDPR上は国際転送。 米国にある中央集権型データストアに欧州子会社がアクセスする場合、それは第V章の要件が適用される第三国への転送です。企業所有であっても法域上の例外にはなりません。
3. メールやファイル共有も構造化データと同じ主権義務が課される。 GDPR、NIS 2、DORAはいずれもデータ形式で区別しません。多くの主権プログラムはデータベースに集中し、実際に機密データが移動するチャネルを見落としています。
4. 顧客所有の暗号鍵こそがベンダー主権を技術的に担保する管理策。 データ所有者がベンダーが一切保持しない鍵を管理することで、ベンダーは法的要求があっても可読なデータにアクセス・開示できません。ベンダーの内部アクセス制御や主権コミットメントを信頼する必要がなくなります。
5. 大手クラウドプロバイダーが提供するBYOKや顧客管理型鍵スキームは、顧客所有鍵とは同等ではない。 BYOK/BYOEでは、プロバイダーのインフラが復号処理を担い、技術的なアクセス権限を保持します。そのため、有効な召喚状があれば可読データが開示されます。顧客所有鍵の場合、プロバイダーは復号能力を一切持たず、CLOUD Actや政府アクセスリスクを本質的に排除できる唯一の仕組みです。

なぜ第三者とのデータ共有が最もリスクの高い主権イベントなのか

データが組織の直接管理を離れると、主権リスクは飛躍的に高まります。データ管理者は、GDPR第28条に基づき、ベンダーチェーン全体でのデータ処理について完全な規制責任を負いますが、実際にはインフラやアクセス方針、法的管轄権をコントロールできません。この責任と管理のギャップこそが、主権失敗の主因です。

CLOUD Act問題は、特にベンダーチェーンで深刻です。EU組織が主権インフラを慎重に設計しても、米国本社のベンダーと機密データを共有すれば、そのインフラはCLOUD Actの強制力下に置かれます。主権アーキテクチャは組織の境界で途切れ、ベンダーの米国法人構造がEU組織が排除したはずのアクセスリスクを生み出します。主権のための効果的な第三者リスク管理には、ベンダー側で同等の管理策が監査可能な技術的証拠として示されるか、そもそもベンダーが可読データを一切保持しないアーキテクチャが必要です。

規制フレームワーク：データとともに移動する義務

GDPR第28条は、プロセッサーによる処理がGDPR同等の義務を課す拘束力のある契約下でのみ行われることを求めており、サブプロセッサーにも適用されます。管理者はサブプロセッサーの利用を承認し、義務をチェーン全体に流し、サブプロセッサーが要件を満たさない場合も完全な責任を負います。ベンダーが主権管理策について監査対応可能な証拠を提供できない場合、契約内容にかかわらず第28条要件を満たしていません。

DORA第30条は、EU金融機関に対し、データローカライゼーション、データレジデンシー、暗号鍵管理、インシデント対応可用性、終了時のデータ移行策などを含むICT契約条項を義務付けています。DORAは、ICTプロバイダーが第三国政府によるアクセスから保護できるかどうかの評価を明示的に求めており、CLOUD Actリスクへの直接的な言及です。鍵管理が適切でないベンダーは、金融機関にDORA違反リスクをもたらします。

NIS 2第21条は、重要サービス事業者に対し、サプライチェーンの直接的なサプライヤーやサービスプロバイダーの主権状況を評価し、文書化するサプライチェーンセキュリティ対策を義務付けています。この義務はチェーン全体に及び、下請け業者が主権リスクを持ち込めば、最上位の重要サービス事業者にNIS 2リスクが発生します。

多国籍企業の中央集権型ストレージ：見落とされがちな主権リスク

多国籍企業は、データウェアハウスや統合CRM、中央HRプラットフォームなど、データストレージを一元化し、複数国の子会社がアクセスすることが一般的です。EU個人データが中央集権型の非EUストアからアクセスされるたびに、それはGDPR第V章の対象となる国際転送です。企業所有であっても例外にはならず、EU子会社が米国親会社の中央ストアにアクセスする場合、適正性認定、SCC+TIA、または他の有効な仕組みが必要です。CLOUD Actリスクは、どの子会社のデータであっても、その中央ストアの米国プロバイダーに適用されます。

中央集権型モデルはリスクも集中させます。CLOUD Actによる一度の要求や規制当局の執行で、すべての子会社のデータが同時に対象となります。NIS 2やDORAの複数加盟国適用企業にとっては、中央集権型主権失敗が複数法域で同時に規制リスクを生じさせます。主権対応策は、中央集権をやめることではなく、データ層で顧客所有暗号化を適用し、中央ストアには暗号文のみを保存し、復号鍵は各法域のデータ所有組織が保持することです。

メールとファイル共有：見落とされがちな主権リスク面

データ主権プログラムの多くはデータベースや構造化データに集中し、実際に機密データの大半が移動するチャネル—メール添付、ファイル共有プラットフォーム、MFTワークフロー—を見落としています。ベンダーにメールで契約書を送る、コラボレーションプラットフォームで財務レポートを共有する、デューデリジェンスファイルを海外転送する—いずれもデータベースレプリケーションと同じくGDPR、NIS 2、DORAの対象となる越境データ転送です。

GDPRは、形式を問わず個人データのあらゆる処理に適用され、メール送信も含まれます。多くの組織で主権管理がデータベースにのみ適用され、メールやファイル共有チャネルには適用されていないため、重大な外部流出リスクが残ります。移動中の非構造化データに求められる実質的な主権要件は、構造化データと同じです。すなわち、転送中および保存時の暗号化、越境転送時のアクセス制御、すべての転送イベントの監査証跡、非準拠先への送信防止のポリシー施行—これらをプラットフォームレベルで実現する必要があります。なぜなら、第三者と共有する際にはデータが完全に組織インフラ外に出るためです。

ベンダー契約に必須の要件と代替できないもの

主権データを扱うベンダー契約には、処理目的と指示の限定、暗号化規格と鍵管理アーキテクチャ（ベンダーが復号能力を持つか否かの明記）、サブプロセッサーの承認と義務の流し込み、違反通知の期限、監査権限とその範囲、終了時のデータ返却または削除、そしてDORA対象企業の場合は第30条に基づくデータローカライゼーション、鍵管理、終了条項が必要です。

同時に、契約で代替できないことも重要です。米国ベンダーにEUデータの政府アクセス防止を契約で義務付けても、CLOUD Actに基づく有効な要求への法的義務は変わりません。データレジデンシー条項は違反時の責任を生みますが、技術的にデータの越境を防ぐものではありません。契約は義務を文書化するものであり、技術的な管理策を生み出すものではありません。したがって、問うべきは契約の完全性ではなく、ベンダーがEUデータを法的要求にかかわらず開示から守るアーキテクチャを実証できるかどうかです。

顧客所有の暗号鍵：技術的基盤

顧客所有の暗号鍵は、ベンダーチェーンにおける主権リスクを根本から解消します。データ所有者がベンダーが一切保持しない鍵を管理することで、ベンダーは法的要求があっても可読なデータにアクセス・開示できません。これは、プロバイダーのインフラが復号処理やアクセス権限を持つBYOK/顧客管理型鍵スキームとは本質的に異なります。BYOKでは有効な召喚状があれば可読データが開示されますが、顧客所有鍵ではプロバイダーは復号できない暗号文しか保持しません。

ベンダーとのデータ共有に適用すれば、機密データはベンダーが一切保持しない鍵で暗号化された状態で到達します。ベンダーは保存・転送・処理はできても、内容を読むことも開示することも、政府要求に応じて可読データを提供することもできません。主権が守られるのは、ベンダーの約束によるのではなく、ベンダーが技術的に違反できないからです。これにより、各ベンダーのアクセス制御や法域、サブプロセッサーチェーンを個別に監査する必要がなくなり、データ所有者が自組織からデータを出す前の単一アーキテクチャ管理で主権を維持できます。

Kiteworksが第三者主権ギャップを解消する方法

Kiteworksのプライベートデータネットワークは、組織の機密データが外部に出るすべてのチャネル—メール、ファイル共有、MFT、ウェブフォーム、API—で第三者データ主権を実現し、統一されたポリシーフレームワークで管理します。顧客が独占的に保持し、Kiteworksが一切アクセスできない暗号鍵により、Kiteworksは顧客データにアクセスできず、召喚状があっても可読データを提供できず、いかなる政府にも復号データの提出を強制されません。

この主権保証はアーキテクチャに基づくものであり、Kiteworksにどのような法的要求があっても、どのベンダーにデータが共有されても変わりません。顧客が選択した場所でのシングルテナント導入により、データはデータ所有者の法域とインフラ管理下に置かれます。ゼロトラスト・セキュリティアーキテクチャにより、すべてのベンダーや下請け業者のアクセスを管理し、すべてのイベントをCISOダッシュボードで改ざん不可能な監査証跡として記録します。これにより、GDPR第28条の監査協力、DORAの運用文書、NIS 2のサプライチェーン証拠など、規制当局が求める要件を満たします。GDPR、NIS 2、DORA、ISO 27001に対応したコンプライアンスレポートも事前に用意されており、ベンダー契約だけでは実現できない説明責任文書をサポートします。

あらゆるチャネル・法域でKiteworksが組織の第三者データ共有をどのように保護するか、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  データ主権：ベストプラクティスか規制要件か？
• eBook
  データ主権とGDPR
• ブログ記事
  データ主権の落とし穴に注意
• ブログ記事
  データ主権のベストプラクティス
• ブログ記事
  データ主権とGDPR【データセキュリティの理解】