.png)
要約
DORA（デジタルオペレーショナルレジリエンス法）は、金融セクターのデジタルレジリエンスを対象としています。銀行、保険会社、フィンテック企業、またはそれらにサービスを提供するテクノロジーベンダーである場合、これは影響を及ぼします。
ICTリスク管理、必須の脅威テスト（TLPTなど）、サードパーティリスクの監視、および厳格なインシデント報告をカバーします。
2025年1月17日より施行 — 不意を突かれた場合には厳しい罰則が科せられます。
DORAスコアカード概要:
- 開発者の労力: 中程度から高い（セキュアで回復力のあるコーディングプラクティスの実装、堅牢なICTリスク管理のサポート、詳細なインシデントログ/レポートの有効化、高度な回復力テストへの参加が必要です）。
- ツールコスト: 高い（ICTリスク管理ツール、高度なセキュリティテストツール（ペンテスト、TLPT）、堅牢な監視/SIEM、サードパーティリスク管理プラットフォーム、事業継続/災害復旧ソリューションへの投資が必要）。
- 市場への影響: 非常に重要（事実上すべてのEU金融機関およびその重要なICTプロバイダーに義務付けられています。運用レジリエンスの高い基準を設定します）。
- 柔軟性: 中程度（規制は主要な柱にわたる要件を規定していますが、規模、リスクプロファイル、サービスの性質/複雑性に基づいて比例的な対応を許可しています）。
- 監査の厳格度: 高（国内の管轄当局および欧州監督当局 (ESAs) によるコンプライアンス監督。堅牢なフレームワーク、テスト結果、インシデント管理能力の実証が含まれます）。
DORAとは何ですか？
EUのデジタルオペレーショナルレジリエンス法（Digital Operational Resilience Act、規則 (EU) 2022/2554）、またはDORAは、金融機関のビジネスプロセスをサポートするネットワークおよび情報システムのセキュリティに関する統一要件を確立する重要な法案です。これは、EU金融セクターのITセキュリティと運用レジリエンスを強化するために特別に設計された、拘束力のある包括的なフレームワークを構築します。
広範に適用されるNIS2とは異なり、DORAは金融機関（銀行、保険会社、投資会社、決済機関、暗号資産プロバイダーなど）およびそれらにサービスを提供する重要なICTサードパーティプロバイダー（クラウドプラットフォーム、ソフトウェアベンダー、データ分析プロバイダーなど）に特化しています。
DORAは5つの主要な柱に基づいています。
- ICTリスク管理: 事業体に対し、ICTリスクを特定し、保護し、検出し、対応し、回復するための戦略、ポリシー、手順、プロトコル、ツールを含む、包括的で十分に文書化されたICTリスク管理フレームワークを持つことを要求します。経営陣が最終的な責任を負います。
- ICT関連インシデント管理と報告: 主要なICT関連インシデントを検出、管理、ログ記録、分類し、標準化されたテンプレートとタイムラインを使用して管轄当局に報告するためのプロセスを義務付けます。
- デジタルオペレーショナルレジリエンス試験： 事業体に対し、脆弱性評価、ネットワークセキュリティ評価、シナリオベースのテスト、そして重要な事業体に対しては、少なくとも3年ごとに高度な脅威主導型ペネトレーションテスト（TLPT）を含む、比例的かつリスクベースのデジタルオペレーショナルレジリエンス試験プログラムを確立することを要求します。
- ICTサードパーティリスク管理: ICTサードパーティサービスプロバイダーへの依存に関連するリスクを管理するための厳格な規則を課します。これには、契約前のデューデリジェンス、特定の契約条項（アクセス、監査、セキュリティ、終了戦略をカバー）、集中リスク評価、および継続的な監視が含まれます。
- 情報共有: 金融機関間でサイバー脅威情報とインテリジェンスの自発的な共有を奨励し、集団的な認識とレジリエンスを高めます。
DORAは、ICT問題やサイバー攻撃に起因する深刻な運用中断が発生した場合でも、金融システムがレジリエンスを維持できるようにすることを目的としています。2023年1月に発効し、金融機関は2025年1月17日までに遵守する必要があります。
なぜそれが重要なのか
DORAは、EUの金融セクターとそのエコシステムにとって極めて重要です。
- Harmonization: 断片化された各国のアプローチに代わり、すべてのEU加盟国においてデジタル運用レジリエンスに関する単一で一貫した規則を確立します。
- 金融の安定性: ICTインシデントが個々の金融機関または広範な金融システムを不安定化させることを防ぐことを目指します。
- システミックリスクへの対応: ICTへの依存度の高まりと、特に重要なサードパーティプロバイダーに関連する障害によってもたらされる潜在的なシステミックリスクを認識しています。
- 重要プロバイダーの直接監督: 欧州監督機関（EBA、ESMA、EIOPAなどのESA）に、指定された重要なICTサードパーティプロバイダー（CTPP）に対する直接監督権限を独自に付与します。
- 遵守の義務化: 一部のフレームワークとは異なり、DORAは規制であり、対象となるすべての事業体に直接適用され、法的拘束力があります。
- レジリエンス要件の強化: 基本的なサイバーセキュリティを超え、堅牢なテスト（TLPTを含む）、詳細なインシデント管理、および厳格なサードパーティリスク管理を要求します。
- 経営陣の責任: NIS2と同様に、ICTリスクの監督に対する明確な責任を経営陣に課しています。
金融機関およびその主要なテクノロジーサプライヤーにとって、DORAへの準拠は、EUでの規制承認、市場アクセス、および運用安定性の維持に不可欠です。
何を、どのように実装するか (技術的側面とポリシー側面)
DORAの導入には、その5つの柱全体にわたる多大な努力が必要であり、技術的およびポリシーによる対策が含まれます。
- ICTリスク管理フレームワーク（第5条～16条）：
- ポリシー/戦略: 経営陣によって承認された、健全で包括的なICTリスク管理フレームワークを開発し、維持します。
- 技術的制御: リスク評価に基づいたセキュリティ対策を実施します – 識別、保護（セキュアな構成、パッチ適用、ネットワークセキュリティ、物理セキュリティ）、検出（システム監視、異常検出）、対応、回復（バックアップ、災害復旧計画）が含まれます。これには、ファイアウォール、SIEM、EDR、脆弱性管理、IAMなどのツールが関与します。
- 文書化: フレームワーク、リスク評価、管理策の実装、および有効性テストに関する広範な文書を維持します。
- インシデント管理および報告 (第17条～23条):
- プロセス: 主要なICTインシデントの監視、検出、分類（Regulatory Technical Standards - RTSで定義された基準に基づく）、管理、ログ記録、報告のためのプロセスを確立します。
- 技術サポート: インシデントを検出し、報告に必要なデータを収集できるログおよび監視ツール（SIEM）を実装します。報告ワークフローを開発します。
- デジタルオペレーショナルレジリエンス テスト (Art. 24-27):
- テストプログラム: 脆弱性評価、オープンソース分析、ネットワークセキュリティ評価、物理セキュリティレビュー、シナリオベースのテスト、互換性テストを含むリスクベースのプログラムを確立します。
- ツール: 脆弱性スキャナー、構成スキャナー、DAST、SAST、SCAツールを活用します。
- 脅威ベースのペネトレーションテスト (TLPT): 重要なエンティティに対して、特定のRTSに基づいた高度なTLPT（TIBER-EUなど）を実施します。これには、実際の攻撃者をシミュレートする外部の認定テスターが関与します。効果的であるためには、成熟した検知および対応能力が必要です。
- ICTサードパーティリスク管理（第28条～44条）：
- 戦略とポリシー: ICTサードパーティプロバイダーに関連するリスクを管理するための戦略とポリシーを策定します。
- 情報登録簿: すべてのICTサードパーティサービス契約の詳細な登録簿を維持します。
- デューデリジェンス: ICTプロバイダーと契約する前に、厳格なセキュリティおよびレジリエンス評価を実施します。
- 契約上の要件（第30条）: 契約に、セキュリティ基準、監査権、インシデント報告協力、明確なサービス説明、データ処理の場所、および終了戦略をカバーする必須条項が含まれていることを確認します。
- 重要プロバイダー（CTPP）の監視: 指定されたCTPPの直接監視活動中にESAと協力します。
- 集中リスク: 単一または少数のプロバイダーに過度に依存することに関連するリスクを評価し、管理します。
- 情報共有（第45条）：
- GDPRコンプライアンスを確保しつつ、サイバー脅威インテリジェンスおよび情報の共有に関する取り決めに（自主的に）参加します。
導入には、強固なガバナンス、専用のリソース、部門横断的な連携 (IT、セキュリティ、リスク、法務、調達)、および多くの場合、テクノロジーと専門知識への多大な投資が必要です。
避けるべきよくある間違い
DORAを実装するエンティティは、これらの一般的なエラーを回避すべきです。
- 実装の遅延: 2025年1月の期限までに、ギャップ分析、フレームワーク開発、テスト実装、およびサードパーティ契約の是正に必要な広範な作業を開始するのが遅すぎる場合。
- 範囲/労力の過小評価: DORAの要件が5つの柱すべてにわたる広範なものであることを把握できず、コンプライアンスへの取り組みに対するリソースが不足していること。
- 単なるIT/セキュリティとして扱うこと: リスク、法務、調達、および上級管理職を十分に巻き込まないこと。特にICTリスクフレームワークとサードパーティリスク管理に関して、その傾向が見られます。
- 不十分なサードパーティリスク管理：適切なデューデリジェンスの実施、必須条項を含む契約の更新、またはICTプロバイダーに関連する集中リスクの管理ができていないこと。
- 不十分なレジリエンステスト: DORAによって義務付けられている包括的でリスクベースのテスト（必要に応じてTLPTを含む）ではなく、基本的な脆弱性スキャンのみを実施していること。
- インシデント報告体制の不備: 重大なインシデントを正確に、かつ必要な期間内に分類し報告するための技術的な監視や内部プロセスが不足しています。
- 他のフレームワークで十分であると仮定する: 既存のISO 27001やその他のコンプライアンスのみに依拠し、特にサードパーティリスクとレジリエンステストに関するDORAの詳細な要件に対する具体的なギャップ分析を実施しないこと。
監査人/規制当局が尋ねる可能性のあること (開発者向け)
DORAコンプライアンスをチェックする監督当局は、広範な権限を有します。開発チームに影響を与える質問は、レジリエンス、セキュリティバイデザイン、テスト、およびインシデントサポートに焦点を当てる可能性があります。
- (ICTリスク管理) 「セキュリティとレジリエンスの要件は、ソフトウェア開発ライフサイクルにどのように組み込まれていますか？」
- (ICTリスク管理) 「開発におけるセキュアコーディングプラクティスと脆弱性管理の証拠を提示してください。」
- (インシデント管理) 「アプリケーションのロギングは、ICT関連インシデントの検知、分析、報告をどのように促進しますか？」
- (Resilience Testing) 「アプリケーションに対してどのようなセキュリティテスト（静的、動的、コンポーネント）が実施されていますか？最新の結果を提示してください。」
- (Resilience Testing) 「アプリケーションは、障害や高負荷（例：冗長性、スケーラビリティ、フェイルオーバーメカニズム）に耐えるようにどのように設計されていますか？」
- (Resilience Testing) 「バックアップからアプリケーションとそのデータを復元するプロセスを実演できますか？」
- (Third-Party Risk) 「アプリケーションに統合されたサードパーティのソフトウェアコンポーネントまたはAPIに関連するセキュリティリスクをどのように管理していますか？」
規制当局は、文書化されたフレームワーク、ポリシー、手順、テスト結果、インシデントログ、およびレジリエンスがシステムとプロセスに組み込まれている証拠を期待します。
開発チームのためのクイックウィン
DORAコンプライアンスの完全な達成は複雑ですが、開発チームは基本的なプラクティスを通じて貢献できます。
- アプリケーションロギングの改善: インシデント分析に役立つセキュリティ関連のイベントやエラーを捕捉するために、アプリケーションログを強化します。ログが一元化されていることを確認します。
- SAST/SCAの統合: CI/CDパイプラインの早期段階で、コードと依存関係の自動セキュリティスキャンを組み込みます。
- レジリエンスパターンへの注力: レジリエンスを向上させるコーディングプラクティス（例：適切なエラー処理、タイムアウト、リトライ、可能な限りステートレス化）を重視します。
- Document Dependencies: アプリケーションの正確なSBOM（Software Bill of Materials）を維持します。
- 障害シナリオのテスト: 障害条件下（例：依存関係が利用不可、高負荷）でのアプリケーションの動作に関するテストを含めます。
- セキュアな設定: アプリケーションがセキュアなデフォルト設定を持ち、設定を適切に外部化していることを確認します。
これを無視すると...（非準拠の結果）
DORAは、管轄当局に重要な監督権限と執行権限を付与します。不遵守の場合、以下の結果が生じる可能性があります。
- 行政罰／罰金: DORA自体は一律の罰金額を定めていませんが（一部の実施は加盟国に委ねられています）、DORAが強化する基礎となる指令／規制への不遵守、または管轄当局の命令に従わない場合、多額の罰金（世界売上高の最大1〜2%または1,000万ユーロのような特定の金額。国内の実施状況および特定の違反によって異なる）につながる可能性があります。訂正: 一部の情報源では、欧州監督機関（ESAs）が直接監督する重要なサードパーティプロバイダーに対し、平均日次世界売上高の最大1%の定期的な違約金が課される可能性があると述べています。金融機関自体の国内罰則は異なりますが、重大なものになると予想されます。
- 是正措置：当局は事業体に対し、行為の停止、特定の是正措置の実施、または特定の情報の提供を命じることができます。
- 公開通知: 当局は、非準拠のエンティティと侵害の性質を特定する公開通知を発行することができます。
- 認可の取り消し: 重大なケースでは、金融機関の認可が取り消される可能性があります。
- 経営陣への制裁: 違反の責任を負う経営陣のメンバーに対し、行政罰または一時的な職務停止が課される可能性があります。
- 評判の損害: コンプライアンス違反やそれに起因するインシデントの公表は、金融業界における信頼に深刻な損害を与えます。
- 運用制限: コンプライアンスが回復するまで、当局は運用に制限を課す可能性があります。
よくあるご質問
DORAに準拠する必要があるのは誰ですか？
DORAは、銀行、信用機関、決済機関、投資会社、保険・再保険会社、暗号資産サービスプロバイダー、クラウドファンディングプラットフォーム、中央清算機関（CCP）、取引情報蓄積機関、オルタナティブ投資ファンド運用会社（AIFM）、UCITS運用会社、および欧州監督当局によって指定された重要なICT第三者サービスプロバイダーを含む、幅広いEUの金融機関に適用されます。
DORAコンプライアンスの期限はいつですか？
金融機関は、DORAに2025年1月17日までに完全に準拠する必要があります。
DORAはNIS2とどのように関連しますか？
DORAは金融セクターにおける特別法（lex specialis）を構成します。これは、DORAとNIS2の両方に該当する金融機関が、ICTリスク管理、インシデント報告、レジリエンス試験、および第三者リスクに関して、DORAのより具体的な要件に主として従うことを意味します。DORAでカバーされていない側面については、NIS2が引き続き適用されます。
DORAにおける脅威ベースのペネトレーションテスト（TLPT）とは何ですか？
TLPTは、DORA（第26条）の下で重要な金融機関に義務付けられている、高度なレジリエンス試験の一種です。これは、組織の重要な機能と基盤システムを標的とする現実世界の脅威アクターの戦術、技術、手順（TTPs）をシミュレートするものです。TIBER-EUのようなフレームワークに基づいており、認定された外部テスターが必要です。
DORAはクラウドプロバイダーに適用されますか？
はい、大幅に影響します。クラウドサービスプロバイダーは、DORAの下でICTサードパーティサービスプロバイダーとみなされます。クラウドサービスを利用する金融機関は、厳格なサードパーティリスク管理要件（第28条～30条）を適用する必要があります。さらに、欧州監督当局によって「重要」とみなされるクラウドプロバイダーは、直接的な監督と潜在的な罰則（第31条～44条）の対象となります。
DORAの主要な柱は何ですか？
5つの主要な柱は以下の通りです。
- ICTリスク管理
- ICT関連インシデント管理および報告
- デジタルオペレーショナルレジリエンス テスト
- ICTサードパーティリスク管理
- 情報共有の取り決め
DORAの認証はありますか？
いいえ、DORA自体は認証制度を確立していません。コンプライアンスは、各国の管轄当局および欧州監督当局（重要なICT第三者プロバイダー向け）によって監督および執行されます。事業体は、導入されたフレームワーク、ポリシー、テスト結果、インシデントレポート、および監督当局との協力によってコンプライアンスを実証します。
