運用の回復力 · ICTリスク管理 · 金融サービス
デジタル運用レジリエンス法（DORA）、規則（EU）2022/2554は、2025年1月17日以降、欧州連合の金融機関に適用されています。その中心的な目的の一つは、企業がICT（情報通信技術）インシデントを迅速に検知し、重要または重要な機能を支えるサービスの可用性を維持することを求めるものです。
この目的を達成するには、顧客向けサービスの実際の可用性を反映した監視が必要であり、システム内部の健全性だけでなく外部からの視点も含みます。内部の可観測性ツールは企業ネットワーク内からインフラを報告しますが、サービスが外部ユーザーの位置から到達可能で機能しているかは確認できません。外部合成監視はこれを補うもので、ネットワークの外部の場所から定義されたスケジュールで本番サービスに対してスクリプト化されたトランザクションを実行します。
本記事では、継続的な監視と検知に関わる具体的なDORAの義務を特定し、外部合成監視、特にDotcom-Monitorプラットフォームがこれらをどのように満たすかを示します。
DORAの検知と可用性に関する義務
DORAはツールについて規定的ではなく、成果ベースです。特定の監視製品やチェック頻度を義務付けていません。検知、可用性、監督の義務を定め、監視はそれらの義務を満たすための運用コントロールです。特に重要な条項は4つあります。
第9条（保護と予防）は、金融機関にICTシステムおよびツールのセキュリティと機能を継続的に監視し制御することを求めています。この義務は継続的であり、定期的または手動のチェックだけでは十分なコントロールとはみなされません。
第10条（検知）は、ICTネットワークのパフォーマンス問題およびICT関連インシデントを含む異常活動を迅速に検知し、重大な単一障害点の可能性を特定する機構を求めます。第10条2項はさらに、検知機構が多層のコントロールを可能にし、警告閾値を定義し、インシデント対応担当者に自動で警告を送ることを要件としています。
「金融機関はICTネットワークのパフォーマンス問題およびICT関連インシデントを含む異常活動を迅速に検知する機構を整備しなければならない。」
DORA, 第10条（検知）
第17条および第19条（インシデント管理と報告）は、ICT関連インシデントを管理する文書化されたプロセスを要求し、重大インシデントの場合は規制当局に対し、日単位ではなく時間単位で定められた期限内に通知することを求めています。この通知の速さは検知の速さに直接依存します。
第28条（ICT第三者リスク）は、ICT第三者サービスプロバイダーから生じるリスクを管理し監視することを要求しています。プロバイダーが重要な機能を支えている場合、その可用性は当該機関の監視責任に含まれます。
これらの規定から、継続的監視、迅速なインシデント検知、可用性検証、第三者ICT監督、サービス劣化の早期警告という5つの監視機能が必要とされます。以下の節でそれぞれに対応します。
外部検証の役割
アプリケーション・パフォーマンス・マネジメント（APM）、サーバーメトリクス、ログ分析を含む内部ツールは、ネットワーク内からシステムを観察します。これらはインフラの状態を正確に報告しますが、ユーザーとサーバー間に発生する障害の一部カテゴリーは検知しません。これには以下が含まれます：
- 特定の地域またはネットワークで誤った解決をするDNS変更。
- クライアントが拒否する期限切れまたは誤設定のTLS証明書。
- データセンターへの経路上のCDNまたはISPのルーティング障害。
- ページ完了を妨げる第三者スクリプトまたはAPIの停止。
- ヘルスチェックには有効な応答を返すが、完全なユーザートランザクションに失敗するロードバランサー。
これらの条件のいずれにおいても、内部監視は正常な動作を報告しながら、サービスはユーザーにとって利用不能です。外部合成監視はネットワークの外からユーザートランザクションを実行するため、ユーザーに影響が生じる地点で障害を記録します。
外部検証はまた、コンプライアンスの証拠価値も持ちます。可用性の記録は、測定が被測定システム外で行われる場合、検査官にとってより信頼性が高いものです。独立したタイムスタンプ付きの可用性データは、DORAの検知要件に伴う監査および報告義務を支えます。
DORA要件とDotcom-Monitorの機能対応
以下の小節では各要件とそれに対応する機能を示します。Dotcom-Monitorはネットワークの外部からチェックを行う合成監視プラットフォームであり、上記の検知および可用性義務に合致しています。
継続的監視（第9条）
要件. 顧客向けサービスを支えるICTシステムの機能を継続的に監視・制御すること。
対応方法. 定義された間隔（最短1分）でスケジュールされた合成チェックを実行し、監視対象サービスを途切れなくカバーします。ウェブアプリケーション監視は実ブラウザでサービスを読み込み、レンダリング結果を測定し、単にサーバーが応答するかを確認するだけにはとどまりません。これにより、ユーザーが体験するサービスの機能性の継続記録が得られます。
異常活動の迅速な検知（第10条）
要件. ICTネットワークパフォーマンス問題やインシデントを含む異常活動を迅速に検知し、重大な単一障害点を特定すること。
対応方法. チェックサイクル中に失敗したり定義された応答時間の閾値を超えたりした合成トランザクションが独立して異常を検知します。EveryStepレコーダーによる完全なユーザージャーニーのスクリプト化は、ページ可用性を超えて認証、支払い、口座開設等の複数ステップ処理の検知を可能にし、単一ステップの失敗をインシデントとみなします。
警告閾値と自動警告（第10条2項）
要件. 警告閾値を定義し、インシデント対応担当者に自動で警告を送ること。
対応方法. 応答時間の閾値超過、エラー応答、失敗したトランザクションステップなどの定義条件で有効となる構成可能なアラートがあります。アラートは自動的にメール、SMS、統合インシデント管理ツールにルーティングされ、共有キューではなく指定された担当者に通知されます。完全な停止だけでなく劣化に基づく閾値警告は第10条2項が要求する多層コントロールを支援します。
可用性検証と監査証拠
要件. 重要または重要な機能を支えるサービスが稼働し続けたことを示し、監査や事後レビューに適した記録を残すこと。
対応方法. 稼働時間およびSLAレポートは監視される各サービスのタイムスタンプ付き可用性履歴を提供します。測定がネットワーク外で行われるため、この記録は独立した可用性の証拠および中断の時期と期間の証拠となり、内部レビューや検査官の要求を支えます。関連する可用性目標はプラットフォームの稼働時間監視リソースでも解説されています。
ICT第三者監督（第28条）
要件. 重要または重要な機能を支えるICT第三者プロバイダーの可用性とパフォーマンスを監視すること。
対応方法. API監視により、アプリケーションが依存するREST、SOAP、GraphQLのエンドポイントを監視し、第三者運営のものも含みます。運用で使用されるホスト型アプリケーションはSaaS監視でプロバイダーの可用性を直接追跡し、機関はプロバイダーのステータス報告に依存せず独立した可視性を得られます。
早期警告とインシデント報告（第10、17、19条）
要件. サービス劣化の早期警告を提供し、重大インシデントを報告期限に間に合わせて検知すること。
対応方法. チェックが継続的にネットワーク外で行われるため、劣化や停止は発生点に近いところで検知され、インシデント発生から検知までの時間を短縮します。この時間は17条および19条に重要で、重大インシデントの通知期限が時間単位であるため、早期検知は分類、対応、報告の時間を増加させます。この機能は早期停止検知も支え、金融サービスにおける合成監視の文脈でさらに検討されています。
内部システムのカバレッジ
要件. 公共サービスに加え、重要または重要な機能を支える内部アプリケーションも監視すること。
対応方法. 公共サービスはグローバル監視ネットワークからチェックされます。ファイアウォールの内側の内部アプリケーションは、機関環境内に展開されたプライベートエージェントによって同じチェックで監視され、内部システムと外部システムが単一プラットフォームからカバーされます。
要件と機能のまとめ
以下の表は上記の対応関係をまとめたものです。
| DORA規定 | 要件 | Dotcom-Monitorの機能 |
|---|---|---|
| 第9条 | ICTシステムの継続的監視 | 最短1分間隔のスケジュールされたリアルブラウザチェック |
| 第10条(1) | 異常活動の迅速な検知 | サイクルごとの障害や閾値超過を示す合成トランザクション |
| 第10条(2) | 警告閾値と自動アラート | エラーや劣化時に指定担当者へ送信される設定可能なアラート |
| 第17条、第19条 | 報告のための迅速なインシデント検知 | 発生地点近くでの連続的外部検知により認知までの時間を短縮 |
| 第28条 | ICT第三者監督 | 外部依存のAPIおよびSaaS監視 |
| 監査およびレビュー | 可用性の証拠 | ネットワーク外からのタイムスタンプ付き稼働時間およびSLAレポート |
検知ギャップの例示
2つの障害条件が外部検証がなぜ必要かを示します。いずれも内部監視だけでは検知不能です。
地域的なDNS誤設定. DNS変更が特定ISPで誤解決します。サーバー側メトリクスは正常で、影響を受けたリクエストはインフラに達しません。影響地域から実行される外部チェックは次のサイクルで障害を記録し、影響地域の通知とともにアラートを発します。
第三者認証レイテンシー. 外部IDプロバイダーは可用ですが応答が遅く、認証に数秒の遅延が生じます。内部エラーは発生しません。完全なログイン処理を行う合成トランザクションが応答時間上昇を測定し、設定閾値を超過し、依存先として特定します。これは第三者プロバイダーの可視性として第28条が求めるものです。
推奨監視構成
以下の構成は上記の検知および可用性義務に沿った監視の基準線を確立し、包括的なカバレッジよりも重要なパスを優先します。
ステップ1: 重要または重要な機能を特定する。 認証、支払い、送金、口座開設、明細アクセスなど、障害時にインシデント報告が必要となる顧客向けサービスを列挙します。これらが監視の優先順位を定めます。
ステップ2: 完全なユーザージャーニーをスクリプト化する。 各機能でEveryStepレコーダーを用いて全ユーザーフローを記録し、完了またはサービスの機能確認となるステップで終了します。ホームページのみのチェックは後続ステップ失敗を検知できません。
ステップ3: 関連する場所から監視する。 世界中の監視ネットワークから、機関の顧客地理に対応する監視場所を選定し、地域障害を検知します。
ステップ4: 第三者依存を監視する。 重要機能が依存する第三者APIやホスト型アプリケーションについて個別のチェックを構成し、障害の要因を機関かプロバイダーかに特定可能にします。
ステップ5: 閾値とアラートルーティングを定義する。 応答時間やエラー状態の警告閾値を設定し、アラートは指定担当者およびインシデント管理システムに送信されるようルーティングします。完全停止だけでなく劣化に対するアラートも設定します。
ステップ6: 可用性記録を保持する。 最初から稼働時間およびSLAレポートを有効化し、可用性履歴が自動的に蓄積され監査および事後レビューに利用可能とします。
ステップ7: 内部システムへのカバレッジを拡張する。 重要機能を支える内部アプリケーションにはプライベートエージェントを展開し、これらシステムにも同等の継続的チェックを提供します。
範囲と制限
外部合成監視はDORAプログラムの一つのコントロールであり、それだけで規制全体を満たすものではありません。可用性検証と迅速な検知を提供しますが、ICTリスクガバナンス、インシデント分類と報告手順、脅威主導のペネトレーションテスト、バックアップとリカバリー、第三者プロバイダーとの契約上の取り決めなど、他の義務は機関のレジリエンスプログラム内の他のコントロールで満たされます。
合成監視はスクリプト化されたトランザクションのみ検証します。設定されていないユーザージャーニーは監視されないため、サービスの変化に応じて監視カバレッジを維持する必要があります。この定義された範囲内で、外部合成監視は他のコントロールではほとんど提供しない検知および可用性証拠を提供します。
結論
DORAは金融機関にICTインシデントを迅速に検知し、重要または重要な機能を支えるサービスの可用性を維持し証明することを求めます。内部監視はインフラ状態を報告し、ユーザーとサーバー間で発生する障害を検知しません。外部合成監視はネットワーク外および関連地域から、第三者依存を含む完全なユーザートランザクションを継続的に検証し、その結果のタイムスタンプ付き記録を保持します。
これら機能は、第9条の継続的監視義務、第10条の検知および警告義務、第17および19条の迅速性義務、第28条の第三者監督義務に直接対応します。外部合成監視自体がDORA遵守を構成するわけではありませんが、規制が定める検知および可用性要件を満たす直接的かつ証拠に基づく手段です。
