BfDI要件の下でドイツ企業が米国政府による個人データアクセスからデータを保護する方法
ドイツ連邦データ保護・情報自由委員（BfDI）は、ドイツの個人データを処理するために米国のクラウドプロバイダーを利用する組織への監視を強化しています。米国クラウド法（US CLOUD Act）は、米国の法執行機関が物理的なデータの所在地に関係なく、米国企業に対してデータへのアクセスを強制できる権限を与えており、これは米国の監視法とGDPRに基づくドイツのデータプライバシー要件との間に根本的な対立を生じさせています。
ドイツの組織は重要な課題に直面しています：BfDIに対して、個人データが外国政府からのアクセスから確実に保護されていることを証明できますか？BfDIは、単なる契約上の約束ではなく、不正アクセスを技術的に不可能にするアーキテクチャ上の制御などの技術的対策を要求しています。
本ガイドでは、ドイツの組織がデータ主権を通じてBfDI要件を満たす方法を解説します。顧客管理の暗号鍵、シングルテナントの欧州内展開、ポリシーによるデータレジデンシーの強制がその柱です。
エグゼクティブサマリー
主なポイント：ドイツの組織は、データ主権コンプライアンス—顧客管理の暗号鍵とシングルテナントの欧州内展開—を実装し、CLOUD Act下での米国政府によるアクセスから個人データを保護する必要があります。標準契約条項などの契約上の措置では、法的強制による外国当局への開示を防ぐことはできません。
なぜ重要か：BfDIは、外国政府によるアクセスを不可能にすることを証明できる技術的制御を要求しており、契約上の約束だけでは不十分です。技術的主権を証明できない組織は、規制執行、グローバル売上高の最大4%に及ぶGDPR違反金、顧客契約違反、市場要件としてのデータ主権に伴う競争上の不利に直面します。
主なポイント
1. CLOUD Actはデータの所在地に関係なく米国企業に適用されます。Clarifying Lawful Overseas Use of Data Actは、米国企業に対して世界中のどこにデータが保存されていても米国政府への提供を義務付けており、フランクフルトやアムステルダムのデータセンターも対象です。物理的な所在地は法的管轄権を決定しません。
2. 契約上の保護では法的強制に打ち勝てません。標準契約条項やEU・米国間データプライバシーフレームワークは法的な移転メカニズムですが、米国の法執行要請への対応をプロバイダーが拒否することはできません。米国法が開示を強制する場合、プロバイダーは顧客との契約義務に関係なく従う必要があります。
3. 顧客管理の暗号鍵はプロバイダーによる外国要請への対応を防ぎます。顧客が自ら暗号鍵を生成し、ハードウェアセキュリティモジュールに保管する場合、プロバイダーは法的強制があってもデータを復号できません。復号の技術的な不可能性は、契約では得られない保護を実現します。
4. BfDIは契約上の主張ではなく技術的証拠を要求します。ドイツのデータ保護当局は、データがドイツの管轄を離れないこと、暗号鍵が顧客管理下にあること、プロバイダーが復号済みの個人データにアクセスできないことを証明するアーキテクチャ文書を期待しています。コンプライアンスには証明可能な技術的対策が必要です。
5. シングルテナント欧州展開はマルチテナントによる管轄の複雑性を排除します。指定されたドイツのデータセンターでの専用インフラは、明確な管轄、他組織からの完全な分離、BfDIの移転影響評価や監査要件を満たすレジデンシーの証明を提供します。
ドイツ組織におけるCLOUD Act問題の理解
Clarifying Lawful Overseas Use of Data Act（米国クラウド法）は、2018年に米国議会で可決されて以来、国際的なデータ保護のあり方を根本的に変えました。ドイツの組織は、この法律が自社のデータ処理体制にどのような影響を及ぼすかを理解する必要があります。
GDPRコンプライアンスの完全チェックリスト
Read Now
CLOUD Actがドイツのデータに与える意味
CLOUD Actは、米国企業に対してデータの物理的な保存場所に関係なく、米国法執行機関へのデータ提供を義務付けています。この法律は、米国で事業を行う企業、米国の従業員、米国の投資家を持つ企業—すべての主要クラウドプロバイダー—に適用されます。
米国当局がフランクフルトのデータセンターにあるデータについてMicrosoft、Google、Amazonに法的要請を出した場合、これらの企業は従う義務があります。データがドイツ国内に物理的に存在していても、米国の法的管轄からは守られません。
主な影響：
- 米国プロバイダーによるドイツのデータセンター内のデータも米国政府がアクセス可能
- 米国の法執行はドイツの裁判所の監督を必要としない
- プロバイダーは政府要請について顧客に通知できない場合が多い
- ドイツのデータガバナンス法ではプロバイダーの法的対応を阻止できない
ドイツのデータセンター所在地だけでは不十分な理由
物理的な所在地はデータが地理的にどこにあるかを決めますが、法的管轄はどの国の法律がデータアクセスを規定するかを決めます。米国企業がドイツのデータセンターを運営する場合、サーバーの所在地に関係なく米国法が義務を規定します。
BfDIの立場：ドイツ国内のデータセンター所在地は必要条件ですが十分条件ではありません。組織は、法的強制があってもプロバイダーがデータにアクセスできないようにする技術的制御を実装する必要があります。
標準契約条項（SCCs）の限界
標準契約条項は、欧州委員会が承認したデータ移転用の契約条項です。しかし、SCCsは契約上の仕組みであり、技術的な保護ではありません。
SCCsでできないこと：
- データ開示を義務付ける米国法に打ち勝つこと
- プロバイダーが法的強制に従うのを防ぐこと
- プロバイダーの法的対応を不可能にすること
- 米国法と契約が衝突した場合にデータを守ること
法的な優先順位：米国連邦法がプロバイダー契約に優先し、プロバイダー契約が標準契約条項に優先します。米国法が開示を強制する場合、契約上の義務では対応を防げません。
BfDIによるデータ主権要件
ドイツのデータ保護当局は、特に外国政府による監視からの保護について、GDPR要件を厳格に解釈しています。
ドイツのデータ主権に関する重要なGDPR条項
BfDIのデータ主権要件の基礎となるGDPR条項は3つあります。
| GDPR条項 | 要件 | BfDIの解釈 |
|---|---|---|
| 第25条 | 設計およびデフォルトによるデータ保護 | 第三者プロバイダー利用時は機微な個人データに顧客管理の暗号化が必須 |
| 第32条 | 処理のセキュリティ（暗号化を含む） | プロバイダーが鍵を保有する暗号化は不十分—顧客による鍵管理が必要 |
| 第44～49条 | 国際移転および移転影響評価 | 契約では法的強制アクセスを防げないためアーキテクチャ上の対策が必須 |
証明可能な技術的制御とは
BfDIは、不正アクセスを技術的に不可能にする制御を要求しており、契約上の禁止だけでは不十分です。
| 不十分な対策 | 証明可能な技術的制御 |
|---|---|
| プロバイダーがデータにアクセスしないと約束 | 顧客がハードウェアセキュリティモジュールで暗号鍵を管理 |
| 標準契約条項のみ | 顧客の鍵がなければプロバイダーはデータを復号できない |
| プロバイダーが鍵を保有する暗号化 | 指定ドイツ拠点でのシングルテナント展開 |
| 米国企業が運営するドイツのデータセンター | データがドイツ国外へ出るのを防ぐジオフェンシングポリシー |
| アクセスと所在地を記録する包括的な監査ログ |
移転影響評価（TIA）要件
BfDIは、移転影響評価（TIA）がリスクを正直に評価し、効果的な技術的緩和策を証明することを期待しています。
必要なTIA要素：
リスク評価の正直な回答：
- 米国クラウド法が適用されるか？（米国企業なら「はい」）
- プロバイダーは米国要請に抵抗できるか？（「いいえ」）
- 契約で法的対応を防げるか？（「いいえ」）
- 補完的な対策は機能するか？（技術的に証明が必要）
技術的対策の文書化：
- データフローを示すアーキテクチャ図
- 暗号化と鍵管理の詳細
- アクセス制御の実施状況
- 地理的制限とその運用
有効性の証拠：
- なぜ対策が外国アクセスを防ぐのか
- 顧客による鍵管理が復号を不可能にする仕組み
- 法的要請時の対応
- BfDIへの証明方法
組織は包括的な文書を事前に準備しておくべきです。BfDIからの問い合わせには4週間以内の回答が求められます。BfDIは「データはどこに保存されているか（”クラウド”ではなく正確な場所）」「暗号鍵は誰が管理しているか（”暗号化”ではなく顧客のHSM）」「プロバイダーは外国要請に応じられるか（鍵を持たないため”いいえ”）」など具体的な質問をします。
ドイツ労働評議会（ワークスカウンシル）への配慮
ドイツの労働評議会（Betriebsräte）は従業員データ処理に関する共同決定権を持っています。組織は、評議会の審査用に体制を文書化し、技術的主権対策を分かりやすい言葉で説明し、従業員データ処理システムの変更前に評議会の同意を得る必要があります。
BfDI準拠データ主権のためのアーキテクチャ的ソリューション
技術アーキテクチャは、BfDI要件を満たすデータ主権の基盤となります。3つのアーキテクチャ的柱が連携し、証明可能な技術的制御を実現します。
顧客管理の暗号鍵アプローチ
顧客管理の暗号鍵は、法的強制があってもプロバイダーアクセスを防ぐ暗号的主権を実現します。
顧客による鍵管理の仕組み
顧客は自らの安全な環境で暗号鍵を生成し、ハードウェアセキュリティモジュールや鍵管理システムに保管します。鍵は顧客管理下や地理的管轄を離れません。
プロバイダーは、認可された操作のためにのみ安全なKey Access Service経由で鍵にアクセスします。このサービスは、顧客ポリシーに照らして各リクエストを検証し、一時的なアクセスを許可します。プロバイダーは顧客の認可なしにデータを復号できません。
これがBfDI要件を満たす理由
米国当局がCLOUD Act要請を出しても、プロバイダーは暗号化されたデータしか保有しておらず、復号鍵は持っていません。プロバイダーは「復号鍵を管理していないため、復号済みデータを提供できません。鍵は顧客がドイツのHSMで管理しています」と回答できます。
法的要請は、保有していないものの提出を強制できません。顧客による鍵管理により、プロバイダーは復号能力を持たず、法的要請の履行が不可能となります。
この仕組みはGDPR第32条の暗号化要件、第25条の設計によるデータ保護を満たし、プロバイダーアクセスを防ぐ適切な技術的対策の証明となります。
鍵管理の技術アーキテクチャ
ドイツ国内の顧客ハードウェアセキュリティモジュールに、顧客管理者がAES-256暗号鍵を保管します。これらのHSMは、安全なKey Access Serviceを介してプロバイダーシステムと接続し、リクエストを検証します。
鍵管理ワークフロー：
- 顧客がHSMで鍵を生成
- 鍵は顧客管理者の管理下に留まる
- システムが操作のため一時的な鍵アクセスをリクエスト
- Key Access Serviceがポリシーに基づきリクエストを検証
- 認可されれば一時的なアクセスを付与
- システムが顧客鍵でデータを暗号化
- 暗号化データを保存、鍵はHSMに戻す
- 復号も同様の検証プロセスを経る
プロバイダーが法的要請を受けても、暗号化データしか保有せず復号鍵は持たないため、要請には応じられません。
シングルテナント欧州展開
シングルテナント展開とは、1顧客専用のインフラを利用し、リソースを他と共有しないことを意味します。
シングルテナントアーキテクチャが重要な理由
マルチテナントプラットフォームでは、複数の顧客が物理サーバーやストレージ、ネットワークインフラを共有し、クロステナントリスクや管轄の複雑性が生じます。
シングルテナント展開ではこれを排除できます。組織は、選択したドイツのデータセンターで専用インフラを利用し、完全な分離を実現します。データの混在は発生しません。
ドイツ組織向け展開オプション
| 展開オプション | インフラ制御 | 期間 | 最適な用途 |
|---|---|---|---|
| 顧客データセンター | 完全 | 3～6か月 | 大企業、高度なセキュリティ要件 |
| ドイツのクラウドプロバイダー | 高い | 1～3か月 | 柔軟性を求める中堅組織 |
| プロバイダー運用の専用環境 | SLAで定義 | 4～8週間 | スピード重視の組織 |
分離による明確な管轄
シングルテナント展開は、管轄を明確にします。ドイツ国内に物理的に配置されたインフラは、希望に応じてドイツ人管理者が運用し、ドイツ法の下で稼働します。
組織は「EUリージョン」ではなく、正確なドイツのデータセンター所在地を指定します。インフラの完全分離により管轄の曖昧さが排除され、BfDIへの文書化も容易です。
ポリシー強制によるデータレジデンシー制御
技術的なポリシー強制により、ユーザー操作に関係なくデータが指定地域外に出ることを防ぎます。
ジオフェンシングと強制メカニズム
組織は「ドイツのみ」「EU/EEAのみ」などの境界を定義します。ポリシーエンジンが、保存・処理・転送・バックアップなど全てのデータ操作にこれらの境界を強制します。
保存場所制御は、データが明示的な許可なしにドイツのデータセンター以外に複製されないようにします。アクセス場所制御は、必要に応じてドイツ国外からのリモートアクセスを制限し、管理者アクセスにはドイツIPアドレスを要求し、不正アクセスをブロックします。
転送防止は、すべてのデータ移動に適用されます：メール添付ファイルはポリシーチェックを受け、ファイル共有は地理的制限を強制し、APIアクセスもジオフェンシングを適用し、同期クライアントは地理的に同期を制限します。
包括的な監査証跡
すべての操作は、ユーザーID、実施アクション、アクセスしたデータ、データおよびアクセスの地理的位置、ポリシー評価結果、暗号署名付きタイムスタンプとともに記録されます。
BfDIからの問い合わせに対し、これらの監査証跡は、データがどこに保存され、誰がアクセスし、ドイツ管轄を離れていないことを証明する完全な証拠となります。
ドイツ組織の導入アプローチ
アーキテクチャ的なデータ主権の導入には、技術・運用・コンプライアンスの各側面で体系的な計画が必要です。
現状評価と移行計画
組織は現行体制を文書化し、ギャップを特定すべきです。プロバイダーインベントリでは、どの米国プロバイダーがドイツ個人データを保有し、どのカテゴリを処理し、データセンターの所在地、暗号鍵の管理者を特定します。移転影響評価（TIA）レビューでは、現行TIAがCLOUD Actリスクを正直に評価し、効果的な対策を文書化しているかを確認します。BfDI対応準備評価では、4週間以内に問い合わせに回答できる体制かを判断します。
データ分類と優先順位付け
優先度1データは即時対応が必要：従業員個人データ、厳格な契約下の顧客データ、GDPR第9条の特別カテゴリ、公的機関顧客データ、BfDI問い合わせ対象データ。
優先度2データは計画的な移行が必要：競合他社が主権を提供する顧客データ、パートナー機密データ、規制対象の金融データ、GDPR特別カテゴリ以外の健康関連データ。
優先度3データは時間をかけて評価可能：社内コラボレーションデータ、非個人データ、低感度データ。
技術導入タイムライン
導入期間は展開方法によって異なります。プロバイダー運用の専用環境は通常12～16週間、ドイツクラウド展開はさらに2～4週間、顧客データセンター展開はさらに4～12週間を要します。
1～4週目：基盤構築—HSMセットアップ、鍵生成、Key Access Service構築、データセンター選定、インスタンス設定、ネットワーク接続、ジオフェンシング実装。
5～8週目：統合—SSO統合、アクセス制御、ドイツ人管理者設定、SIEM接続、監査設定、セキュリティ手順策定。
9～12週目：移行—優先度1データでパイロット、暗号化と鍵管理のテスト、ジオフェンシング検証、セキュリティテスト、本番移行、レジデンシー検証。
13～16週目：検証—コンプライアンス検証、鍵管理確認、ジオフェンシングテスト、TIA更新、BfDI回答パッケージ準備、ワークスカウンシル文書化。
リソース要件は、プロジェクトマネージャー（4か月のうち50%）、セキュリティアーキテクト（2か月フルタイム）、インフラエンジニア（1か月フルタイム）、IAMスペシャリスト（パートタイム）、データ保護責任者（パートタイム）が一般的です。
コンプライアンス文書と証拠収集
データ保護責任者は、導入中にBfDI問い合わせ対応パッケージを作成すべきです：アーキテクチャ図、暗号化文書、アクセス制御マトリクス、ジオフェンシング設定、監査証跡、更新済みTIA、GDPR第30条記録、ワークスカウンシル文書など。
BfDIへのコンプライアンス証明
BfDIは、アーキテクチャ的証拠に基づくコンプライアンス証明を期待しています。
データ保護当局向け証拠要件
データ所在地の証拠：正確なデータセンター住所と運営者、データがドイツを離れないことを示すネットワークアーキテクチャ、ドイツ/EU内のバックアップ・DR拠点、指定地域外への転送がないことを示すログ。
鍵管理の証拠：顧客所有を示すHSM文書、顧客による鍵生成手順、鍵アクセスログ、プロバイダーが認可なしに鍵へアクセスできない証拠。
アクセス制御の証拠：ユーザーアクセス制御と認証、地理的制限付き管理者制御、すべてのアクセス試行の監査ログ、不正な場所からの失敗試行。
ポリシー強制の証拠：ジオフェンシング設定、ブロック転送を含む強制ログ、不正移動防止例、監査証跡付きの例外手順。
BfDIの問い合わせプロセス
最初の連絡は公式書簡やメールで行われ、通常4週間の回答期限が設けられます。BfDIは、データ処理業務の説明、個人データのカテゴリ、保存・処理場所、保護対策、移転影響評価、証拠資料の提出を求めます。
組織は体系的に対応すべきです：1週目に受領確認と既存文書の収集、2～3週目にアーキテクチャ図の作成、コンプライアンスレポート生成、TIA更新、回答文書作成、4週目に法務・ワークスカウンシル審査、経営承認、証拠一式を添えて提出します。
積極的な規制当局との関与
一部の組織は、問い合わせが発生する前にBfDIと積極的に関与し、誠実なコンプライアンス姿勢を示し、非公式なガイダンスを得て、規制当局との関係を構築し、データ保護へのコミットメントを示しています。これは、新たな大規模処理の導入、米国プロバイダーからの移行、顧客からの質問対応、厳格な規制業界での運用時に有効です。
アーキテクチャ的データ主権でBfDIコンプライアンスを実現
ドイツの組織は、CLOUD Act下での米国政府アクセスから個人データを守るため、BfDIの明確な要件に直面しています。契約上の措置では法的強制を覆せず—BfDIは外国政府アクセスを技術的に不可能にする証明可能な技術的制御を要求しています。
KiteworksによるBfDI準拠データ主権の実現方法
Kiteworksは、個人データが欧州管轄下に留まることを保証しなければならない組織向けに設計されたアーキテクチャ的データ主権を提供します。CLOUD Actの対象となる米国本社のクラウドプロバイダーとは異なり—契約上の約束では法的強制を覆せない—Kiteworksは、3つの中核機能で真の欧州データ主権を実現します。
シングルテナント欧州展開：Kiteworksインスタンスは、選択したドイツのデータセンター—自社施設、欧州クラウドプロバイダー、またはKiteworks運用のEU拠点—で専用インフラとして稼働します。マルチテナント共有が一切ない完全分離により、明確なドイツ管轄が確保されます。
顧客管理の暗号化：お客様がハードウェアセキュリティモジュールで暗号鍵を生成・保管・管理します。Kiteworksは、当社が一切保有しない鍵でデータを暗号化します。当社は法的強制があってもデータを復号・提供できません。契約上の約束ではなく、技術的不可能性が担保されます。
ポリシー強制によるデータレジデンシー：ジオフェンシング制御により、データがドイツ境界を越えることを技術的に防止します。包括的な監査証跡が、すべてのアクセス試行とポリシー強制の履歴を記録し、BfDIが求める証拠を提供します。
Kiteworksを導入したドイツ組織は、契約上の保証ではなくアーキテクチャ的証拠で主権を規制当局に示します。データ保護当局にはドイツ管轄の文書証拠を提出できます。法務部門は、Kiteworksが鍵を保有しないため外国政府要請に応じられないことを確認できます。BfDIの執行強化や主権が競争要件となる中、早期導入は規制コンプライアンスと市場優位の両方をもたらします。
BfDIおよびデータ主権要件を満たしながら機密コンテンツを保護する方法について詳しくは、カスタムデモを今すぐご予約ください。
よくある質問
よくある質問
更新後の移転影響評価（TIA）では、米国への移転が発生しないため、標準契約条項やEU・米国間データプライバシーフレームワークに依拠しないことを明記してください。データが指定ドイツデータセンターにのみ存在し、顧客がドイツのハードウェアセキュリティモジュールで暗号鍵を管理し、プロバイダーはCLOUD Act要請に応じられず、技術アーキテクチャにより米国政府アクセスが不可能であることを具体的に記述します。これらの主張を裏付けるアーキテクチャ図、鍵管理文書、監査ログ証拠も添付してください。TIAの結論として、データが顧客管理の技術的保護下でドイツ管轄に留まるため、十分性認定や移転メカニズムは不要であると記載します。
顧客管理の鍵管理は、KMIP（Key Management Interoperability Protocol）やベンダー固有APIを通じてエンタープライズHSMと統合されます。HSMが暗号鍵を生成・保管し、鍵は決して顧客管理下を離れません。Key Access ServiceがシステムとHSM間の安全な仲介役となり、ポリシーエンジンが各鍵アクセスリクエストを定義済みポリシーに照らして検証します。一時的な鍵アクセスは特定の認可済み操作にのみ付与され、すべての鍵アクセスリクエストと結果は監査証跡として記録されます。対応HSMにはThales、Utimaco、VPC内に展開したAWS CloudHSM、その他エンタープライズ鍵管理システムが含まれます。セキュリティチームが鍵ライフサイクル管理を完全にコントロールし、組織外に鍵エスクローは存在しません。このアプローチにより、顧客主権によるAES-256暗号化が実現します。
アーキテクチャ的主権により、GDPRにおける移転分析は大きく変わります。データがドイツまたはEUを一切離れず、顧客管理の暗号化下にある場合、GDPR第44条における「第三国への移転」には該当せず、十分性認定、標準契約条項、例外規定は不要となる可能性が高いです。ただし、GDPR第28条に基づくデータ処理契約はプロバイダーと締結し、第32条のセキュリティ対策を実装し、なぜ移転が発生しないかの法的分析を文書化する必要があります。GDPR第30条記録には「国際移転なし」と明記してください。法務部門は、ドイツでの顧客管理鍵によるデータ保存が移転に該当しない理由、法的移転メカニズムではなくアーキテクチャ的対策に依拠する根拠、証拠を文書化すべきです。このアプローチはプライバシー・バイ・デザインの原則に合致します。
導入タイムラインは選択する方式によって異なります。プロバイダー運用の専用環境は、計画から本番まで通常12～16週間で、要件定義、インスタンス準備、HSMセットアップ、セキュリティ統合、パイロットテスト、本番展開を含みます。ドイツクラウドプロバイダー展開はインフラ準備に2～4週間追加され、合計14～20週間です。顧客データセンター展開はインフラ調達・セットアップに4～12週間追加され、合計16～28週間となります。導入コストにはソフトウェアライセンス、プロバイダー管理の場合のドイツホスティング、必要に応じたHSM調達、導入サービス、社内リソース工数が含まれます。プロジェクト管理、セキュリティアーキテクチャ、インフラエンジニアリング、ID・アクセス管理統合、データ保護責任者の工数も予算化してください。運用コストには年次ライセンス、ホスティングまたはインフラ保守、セキュリティ監視、コンプライアンス活動が含まれます。
顧客管理鍵による災害復旧には慎重な計画が必要ですが、堅牢な事業継続性が確保できます。一般的には、ドイツ国内の2都市に本番・DRインスタンスを配置したアクティブ-パッシブ構成の二重データセンターアーキテクチャを採用します。HSM間で鍵を複製することで、障害時も鍵が利用可能です。他の方法としては、顧客管理鍵で暗号化したバックアップをドイツまたはEUストレージに保存・復元する、顧客データセンター本番＋ドイツクラウドDRのクラウド型DRなどがあります。DRシナリオでの鍵管理は、HSMクラスタリングや鍵複製によりDR拠点から鍵にアクセスできるようにし、定期的なDR鍵アクセス試験、DR鍵手順の文書化が必要です。RTO目標は重要度に応じて4～24時間、RPO目標は15分～1時間が一般的です。四半期ごとにDR手順をテストし、DRアーキテクチャをBfDIコンプライアンス証拠に文書化してください。このアプローチで安全な展開のレジリエンスが確保されます。
追加リソース
- ブログ記事
データ主権：ベストプラクティスか規制要件か？ - eBook
データ主権とGDPR - ブログ記事
データ主権の落とし穴に注意 - ブログ記事
データ主権のベストプラクティス - ブログ記事
データ主権とGDPR【データセキュリティの理解】