米国クラウドプロバイダーへの依存なしでDORA準拠の運用レジリエンスを実現する方法
デジタル・オペレーショナル・レジリエンス法（DORA、規則EU 2022/2554）は2025年1月17日から施行され、欧州金融セクター全体でICTセキュリティの統一要件を確立しました。DORAは、ICTリスク管理、インシデント管理と報告、デジタルオペレーショナルレジリエンステスト、第三者ICTリスク管理、サイバー脅威情報共有の5つの柱に要件を構築しています。各柱は、金融機関が自らのICTインフラとその処理データを真にコントロールしていることを前提としています。
この前提は、米国本社のクラウドプロバイダーに依存する欧州金融機関にとって根本的な問題を生み出します。銀行の重要なデータ交換プラットフォームがCLOUD法やFISA第702条の対象となるプロバイダーによって運用されている場合、機関のオペレーショナルレジリエンスは自ら制御できない外国の法制度に依存することになります。米国政府によるデータアクセス要求が発生しても、銀行のインシデント対応プロセスは発動されません。完全に迂回され、プロバイダーは銀行に通知することなく要求に応じ、銀行はDORAのレジリエンスフレームワークが暗黙的に求めるデータ主権を証明できなくなります。
本ガイドでは、DORAの各柱を米国クラウドプロバイダー依存の観点から検証し、欧州金融機関が外国アクセスリスクを「管理」するのではなく「排除」する主権アーキテクチャによって、真のオペレーショナルレジリエンスをどのように実現できるかを解説します。
エグゼクティブサマリー
主なポイント：DORAの5つの柱は、欧州金融機関に対し、ICTリスク管理、インシデント対応、レジリエンステスト、第三者管理、情報共有の各領域でオペレーショナルレジリエンスを証明することを求めています。重要なデータプラットフォームが外国政府アクセス法の対象となるプロバイダーによって運用される場合、各柱は根本から損なわれます。DORA準拠のレジリエンスを実現するには、顧客管理型暗号化、単一テナントの欧州展開、米国プロバイダーインフラからの運用的独立性といった主権アーキテクチャが不可欠です。
なぜ重要か：DORA違反時の罰則は、金融機関で年間売上高の最大10%、重要なICTプロバイダーで最大500万ユーロに達します。2025年11月、欧州監督当局はAWS、Microsoft Azure、Google Cloudなど19社を重要ICTサービスプロバイダーに指定し、直接的なEU監督下に置きました。BaFinは2025年末までに初回のDORAコンプライアンス報告を求めています。自ら完全に監督できないプロバイダーに依存する機関は、規制上の罰則とDORAが防止を目的とする運用リスクの両方に直面します。
5つの重要なポイント
- DORAのICTリスク管理の柱は、米国プロバイダーに委任できないコントロールを要求します。金融機関はICTリスクの特定、保護、検知、対応、復旧を行わなければなりません。プロバイダーが暗号鍵を保持し、外国アクセス法の対象である場合、機関は契約措置だけでは緩和できない残余リスクを抱えることになります。
- インシデント報告義務は、データアクセスイベントへの完全な可視性を前提としています。DORAは重大なICTインシデントの分類と厳格な期限内での報告を要求します。米国プロバイダーが政府のデータ要求に銀行へ通知せず応じた場合、銀行は見えない事象を報告できません。
- レジリエンステストは、外国政府アクセスシナリオもカバーしなければなりません。DORAは脆弱性評価、ペネトレーションテスト、シナリオベースのテストを義務付けています。米国プロバイダーが運用する重要プラットフォームでは、CLOUD法によるデータ要求をテストシナリオに含めるべきです。
- 第三者リスク管理は、セキュリティ認証だけでなくプロバイダーの法域評価を要求します。DORAはICTサードパーティの監督を明示的に求めており、プロバイダーが外国政府の要求にさらされる法的リスクも評価対象です。
- 主権アーキテクチャは依存を「管理」するのではなく「排除」します。顧客管理型暗号鍵、単一テナントの欧州展開、ポリシーによるデータレジデンシーは、アーキテクチャレベルで外国アクセスリスクを排除し、DORAの5つの柱すべてを同時に満たします。
DORAの5つの柱と米国プロバイダー依存問題
柱1：ICTリスク管理
DORA第6条は、金融機関に対し、特定・保護・検知・対応・復旧を網羅した包括的なICTリスク管理フレームワークの構築を義務付けています。このフレームワークは、サードパーティを含む内部・外部リスクに対応し、ガバナンス監督は取締役会レベルまで及びます。
ドイツの銀行では、BaFinのBAITフレームワーク（移行期間中は2026年12月まで適用）が長年ITリスク管理を要求してきました。DORA第6条4項は、既存のBAIT情報セキュリティ責任者に類似しつつも同一ではない、独立性要件を明確にしたICTリスク管理機能を導入しています。
根本的な課題は、「クラウドプロバイダー経由の米国政府データアクセス」をリスクとして特定しつつ、標準契約条項やEU・米国間データプライバシーフレームワークに依存して許容する場合、法的に不確実な基盤の上にレジリエンスを築いていることです。SCCやDPFは法的な移転手段であり、技術的な保護策ではありません。CLOUD法による要求を防ぐことはできません。DORAは、金融機関に対し、ICTリスクを真に管理する措置の実装を求めており、単なる文書化では不十分です。リスクがアーキテクチャに起因する場合、対応もアーキテクチャでなければなりません。
柱2：インシデント管理と報告
DORAは、重大なICTインシデントの検知・分類・報告のための体系的なプロセスを義務付けています。EBAの報告タイムラインは、分類から4時間以内の初期通知、72時間以内の中間報告、1か月以内の最終報告を要求しています。重大インシデントは各国の主管当局へ報告しなければなりません。
この柱は、機関のデータに影響を与えるイベントへの完全な可視性を前提としています。米国プロバイダーが国家安全保障書簡やFISA裁判所命令を受けてデータ提出を強制された場合、顧客への通知が法的に禁止されることがあります。金融機関はアクセスイベントを把握できず、分類も報告もできません。この構造的なギャップは、プロセス改善では埋められず、プロバイダーとの関係自体に組み込まれています。
主権アーキテクチャは、法的要求があってもプロバイダーが復号データにアクセスできないようにすることで、この問題を解決します。機関が自らのHSMで暗号鍵を管理すれば、プロバイダーへの政府要求は暗号化データしか生みません。機関の監査ログはすべての正当なアクセスイベントを記録し、DORAのインシデント報告要件に必要な完全な可視性を提供します。
柱3：デジタルオペレーショナルレジリエンステスト
DORAは、脆弱性評価、ペネトレーションテスト、シナリオベース演習など、オペレーショナルレジリエンスの定期的なテストを義務付けています。重要な機関には、TIBER-EUフレームワークに準拠した高度な脅威主導型ペネトレーションテスト（TLPT）が求められる場合もあります。
外国政府によるデータアクセスシナリオを除外したレジリエンステストは、米国運用のクラウドサービスを利用する機関にとって不完全な評価となります。包括的なテストプログラムでは、重要なデータプラットフォームプロバイダーが顧客データの提出を強制された場合を想定し、アーキテクチャがデータ漏洩を防げるか、監視システムが試行を検知できるか、インシデント対応手順が正しく発動するかを評価すべきです。
顧客管理型暗号化を導入すれば、このテストの結果は明確です。プロバイダーは可読データを提出できません。このシナリオは、緩和不能なリスクの露呈ではなく、アーキテクチャコントロールの有効性検証となります。
柱4：第三者ICTリスク管理
DORAの第三者リスク管理要件は、最も影響力の大きい規定の一つです。金融機関はICTプロバイダーからのリスクを評価・継続監視し、契約にはセキュリティ条項、監査権、終了権、出口戦略、インシデント通知手順を盛り込む必要があります。欧州監督当局は2025年11月に19社を重要ICT第三者プロバイダー（CTPP）に指定し、AWS、Microsoft Azure、Google Cloudなどを直接的なEU監督下に置きました。
DORA第28条3項は、金融機関にICT第三者プロバイダーとのすべての契約関係を記録したRegister of Informationの維持を義務付けています。BaFinはドイツの機関に2025年4月11日までに初回登録の提出を求めました。この登録簿には、関係の有無だけでなく、サービスの内容、データの所在、リスク分類も記載しなければなりません。
機密データ交換に米国運用プラットフォームを利用する機関は、第三者リスク評価でプロバイダーの法的リスクを正直に評価する必要があります。EBAは、ISO 27001などの認証だけに依拠するリスク評価は不十分と明言しています。評価では、プロバイダーが外国法の下で顧客データの提出を強制される可能性や、その際に機関のアーキテクチャが可読データの漏洩を防げるかを検証しなければなりません。
DORAはまた、実効性のある出口戦略も要求しています。金融機関は、どのICTプロバイダーからも運用を中断せずに移行できることを証明しなければなりません。この要件は、少数の米国ハイパースケールプロバイダーに重要機能を集中させることで生じるベンダー依存リスクに直接対応しています。現行アーキテクチャが移行をサポートしているか、欧州法域下で同等機能を提供できる代替プロバイダーが存在するかを評価すべきです。
柱5：サイバー脅威情報共有
DORAは金融機関に脅威インテリジェンス共有への参加を推奨しています。参加は義務ではありませんが、機関は情報共有活動について規制当局に報告しなければなりません。効果的な共有には、自らの脅威状況を把握していることが前提です。クラウドプロバイダー経由の政府強制アクセスの可視性がない機関は、脅威モデルが不完全です。主権アーキテクチャは外国アクセスの曖昧さを排除し、機関が本来の外部サイバー脅威に集中して情報共有できる環境を整えます。
DORAにおける主権アーキテクチャの要件
米国クラウドプロバイダー依存なしでDORA準拠のオペレーショナルレジリエンスを実現するには、「データ主権は契約条項ではなく技術アーキテクチャである」というGTM原則に沿った3つのアーキテクチャ機能が必要です。
顧客管理型暗号鍵
機関は自らのハードウェアセキュリティモジュール（HSM）で暗号鍵を生成・保管し、オンプレミスまたは機関管理の欧州データセンターに設置します。クラウドプラットフォームは暗号化データを処理しますが、復号鍵を一切保持しません。これは、プロバイダーが鍵素材にアクセス可能なBYOK（Bring Your Own Key）方式とは根本的に異なります。テストは単純です。プロバイダーが法的要求を受けた場合、復号データを提出できるか？「はい」であれば、その暗号化モデルはDORAの重要機能に対するリスク管理要件を満たしません。
単一テナントの欧州展開
マルチテナントプラットフォームは、グローバル最適化された共用インフラで数千の顧客にサービスを提供します。単一テナントの専用欧州インフラ展開は、欧州法の下でアクセス制御が管理された分離システムから1顧客にサービスを提供します。顧客管理型暗号化と組み合わせることで、プロバイダー依存を生む論理的アクセス経路（暗号鍵）と物理的アクセス経路（共用インフラ）の両方を排除します。
運用的独立性と出口能力
DORAは、重要機能を支えるすべてのICT第三者契約に対して実効性のある出口戦略を要求しています。つまり、金融機関はデータポータビリティと運用的独立性をサポートする標準プロトコルに基づくプラットフォームを必要とします。アーキテクチャは、オンプレミス、欧州プライベートクラウド、プロバイダー運用の欧州インフラのいずれでも展開でき、データ損失や運用中断なく柔軟に移行できる必要があります。これはDORAの集中リスク懸念や、アウトソース機能のリパトリエーション（再内製化）に対するBaFinの期待に対応します。
DORA柱別：米国プロバイダー依存 vs. 主権アーキテクチャ
| DORAの柱 | 米国プロバイダー依存時のリスク | 主権アーキテクチャの対応 |
|---|---|---|
| ICTリスク管理 | 外国アクセスリスクは契約措置だけでは緩和不可 | アーキテクチャレベルでリスク排除、プロバイダーはデータにアクセス不可 |
| インシデント管理 | 政府要求が機関の可視性・報告を迂回する可能性 | 完全な監査証跡、すべてのアクセスイベントが機関に可視 |
| レジリエンステスト | 外国アクセスシナリオで緩和不能なリスクが露呈 | 外国アクセスシナリオでアーキテクチャコントロールを検証 |
| 第三者リスク | プロバイダーの法域が構造的依存を生む | 顧客管理型鍵と単一テナント展開で依存排除 |
| 情報共有 | プロバイダーレベルのアクセス曖昧性により脅威モデルが不完全 | 脅威状況が明確化、本来の外部脅威に集中可能 |
実装：DORA準拠主権アーキテクチャへの移行
フェーズ1：重要ICT依存関係のマッピング
DORA Register of Informationを出発点とし、重要または重要度の高い機能を支えるすべてのICT第三者契約を特定します。各プロバイダーの法域、暗号化モデル、鍵管理アーキテクチャを評価します。米国運用サービスごとに、法的強制を含め、プロバイダーが復号済み顧客データにアクセスできるかどうかを文書化します。この評価はICTリスク管理フレームワークに直結し、BaFinの「正直なリスク評価」要件を満たします。
フェーズ2：規制リスクの高い順に優先順位付け
すべてのICTサービスが同じDORAリスクを持つわけではありません。最も機密性の高いデータを扱うサービス（顧客金融記録、規制提出用マネージドファイル転送、内部監査コミュニケーション、国境を越えた取引記録、取締役会レベルのやり取り）を優先します。これらは、外国政府によるデータアクセスイベントが最大の規制・評判・運用リスクを生む機能です。
フェーズ3：主権アーキテクチャの導入
優先機能を、顧客管理型暗号化、単一テナントの欧州展開、ジオフェンシングによるデータレジデンシー強制を備えたプラットフォームへ移行します。プロバイダーが復号データにアクセスできないことを独立したテストで検証します。包括的な監査ログを構成し、DORAのインシデント報告タイムラインや継続的監視義務をサポートします。新アーキテクチャの能力に合わせたインシデント対応手順を整備します。
フェーズ4：証拠によるコンプライアンス実証
DORAコンプライアンスは主張ではなく証拠で示します。機関のHSMでの暗号鍵生成、単一テナント展開設定、ジオフェンシング強制、完全な監査証跡を示す文書を維持します。これらの証拠パッケージをBaFinの検査、ECB監督レビュー、DORAが求める定期的なレジリエンステストに備えて準備します。「証明できる主権」こそが、機関を守る主権です。
オペレーショナルレジリエンスにはオペレーショナル主権が不可欠
DORAの5つの柱は、オペレーショナルレジリエンスのあるべき姿を示しています。しかし、コントロールがなければレジリエンスは成立しません。金融機関の重要なデータプラットフォームが外国政府アクセス法の対象となるプロバイダーによって運用されている場合、機関のレジリエンスフレームワークには、契約条項や認証、プロセス改善では埋められない構造的なギャップが生じます。
顧客管理型暗号化、単一テナントの欧州展開、真の運用的独立性に基づく主権アーキテクチャは、そのギャップを「管理」ではなく「排除」によって解消します。このアーキテクチャを実装する欧州金融機関は、単にDORAに準拠するだけでなく、欧州金融規制当局が描くゼロトラスト・レジリエンス基盤を構築することになります。
Kiteworksは欧州金融機関のDORA準拠オペレーショナルレジリエンスを支援
Kiteworksプライベートデータネットワークは、DORAの5本柱フレームワークに特化した主権アーキテクチャを提供します。Kiteworksは、機関が自らのHSMで暗号鍵を生成・保持する顧客管理型暗号化モデルを採用しています。Kiteworksは復号済みコンテンツにアクセスできず、鍵を保持しないため、外国政府の可読データ提出要求にも応じられません。
Kiteworksは、専用欧州インフラ上の単一テナントインスタンスとして展開され、オンプレミス、プライベートクラウド、強化された仮想アプライアンスなど柔軟な展開と出口能力を提供し、DORA要件を満たします。プラットフォームレベルでのジオフェンシングによりデータレジデンシーを強制します。包括的な監査ログはDORAのインシデント報告タイムラインをサポートし、規制当局が期待する継続的監視の証拠を提供します。Kiteworksは、機密コンテンツのICTリスク管理を統合的に実現し、5本柱すべてでDORAコンプライアンスを支援します。
本プラットフォームは、セキュアなファイル共有、メール保護、マネージドファイル転送、ウェブフォームを単一のガバナンスフレームワークで統合し、金融機関がすべてのデータ交換チャネルにおけるDORAの第三者リスク要件に、1つのアーキテクチャ、1つのコントロールセット、1つの監督証拠パッケージで対応できるようにします。
米国クラウドプロバイダー依存なしでDORA準拠のオペレーショナルレジリエンスを実現する方法について、ぜひカスタムデモをご予約ください。
よくある質問
いいえ。DORAは米国本社のICTプロバイダーの利用を禁止していませんが、これらの関係が生むリスクを管理することを機関に求めています。規則は、すべてのICT第三者契約に対して包括的なリスク評価、出口戦略を含む契約管理、継続的なモニタリングを義務付けています。重要機能を支える米国運用サービスについては、CLOUD法やFISA 702のリスク評価が必須です。プロバイダーが復号データにアクセスできないよう、顧客管理型暗号鍵などのアーキテクチャコントロールを実装すれば、技術的レベルで外国アクセスリスクを無効化しつつ米国プロバイダーの利用継続も可能です。
金融機関は重大な違反で年間売上高の最大10%または1,000万ユーロの罰金、個人の上級管理職は最大100万ユーロの罰金が科されます。DORAの罰則は2025年1月17日の施行日から適用され、猶予期間はありません。主管当局は検査、違反行為の停止命令、公表による違反機関の特定も可能です。金銭的罰則に加え、評判リスクや顧客信頼の喪失も懸念されます。BaFinは2025年にアウトソーシング監督を強化し、年末までに最初のコンプライアンス報告を求めているため、主権アーキテクチャの早期導入が優先事項となります。
ESAによる19社の重要プロバイダー指定（2025年11月）は、これらプロバイダーを直接的なEU監督下に置きますが、銀行自身のコンプライアンス義務が軽減されるわけではありません。銀行は引き続き独立したリスク評価、契約管理、出口戦略の実装が求められます。指定により、規制当局は銀行のリスク管理とプロバイダーの運用の両方を審査しています。銀行は、これをプロバイダーへの規制上の「お墨付き」ではなく、第三者リスク管理への監督強化と捉えるべきです。顧客管理型暗号化や単一テナント展開を実装することで、指定プロバイダー特有のリスクに対応していることを示せます。
ドイツの銀行は、DORA Register of Informationの作成、ICT契約の契約上のコンプライアンス確保、アーキテクチャリスク緩和策の文書化の3点を優先すべきです。BaFinは2025年4月11日までに初回登録の提出を求め、第三者ICT契約の契約調整を最優先事項としています。BaFinは進捗を示すリスクベースのタイムラインを期待しています。銀行は、暗号鍵管理アーキテクチャ、データレジデンシー管理、データガバナンスフレームワークを、真のリスク管理の証拠として文書化すべきです。BAITからDORAへの移行機関は、BaFinのギャップ分析文書を活用し、既存要件と新要件の実務的な比較を行いましょう。
主権クラウドは一部の依存リスクを緩和しますが、多くの場合、米国ハイパースケールプロバイダーとの提携を含み、基盤インフラに米国技術依存が残る可能性があります。DORAはサプライチェーン全体（サブアウトソーシングも含む）の評価を要求します。Microsoft Azure技術を用いた主権クラウドでも、米国コード依存や運用上の接点が残る場合があります。主権クラウドが真の独立性、顧客管理型暗号鍵、完全な運用コントロールを提供するか、あるいは機能制限や高価格を伴うかを評価すべきです。最も重要なのは、どのチェーン上の主体も、外国法の強制下で復号データにアクセスできないかどうかです。サービスのブランドに関わらず、すべてのプロバイダーと同じゼロトラストデータ交換基準で主権クラウドを評価しましょう。
追加リソース
- ブログ記事
データ主権：ベストプラクティスか規制要件か？ - eBook
データ主権とGDPR - ブログ記事
データ主権で陥りがちな落とし穴 - ブログ記事
データ主権のベストプラクティス - ブログ記事
データ主権とGDPR【データセキュリティの理解】