金融庁が2019年以降公表してきた「金融機関のシステム障害に関する分析レポート」を、サイバー・地政学リスクの高まりを踏まえて再構成し、2025年6月に公表した分析レポート。2024年度に報告された約1,800件の障害分析に、サイバーセキュリティ(ガイドライン・TLPT)、クラウド、オペレーショナル・レジリエンスのモニタリング結果を束ね、「対策を講じても障害は起こり得る」という前提に立った重要業務の継続・早期復旧、すなわちITレジリエンスの強化と、それを牽引する経営層の主導を金融機関に求めています。
概要
本レポートは大きく4つの柱で構成されます。第一に2024年度(2024年4月~2025年3月)に報告された約1,800件のシステム障害の傾向と主な事案の分析、第二に2024年10月に策定した「金融分野におけるサイバーセキュリティに関するガイドライン」の要諦とTLPT(脅威ベースのペネトレーションテスト)から得られた示唆、第三に拡大するクラウドサービス利用の固有リスク、第四にオペレーショナル・レジリエンス(以下「オペレジ」)のモニタリング結果です。通底する問題意識は、金融業界におけるITの複雑化と外部依存の増大によってリスクが顕著に高まり、一金融機関の障害が金融システム全体を揺るがしかねないという危機感にあります。金融庁は、未然防止策をどれだけ尽くしてもインシデントは発生し得るという前提に立ち、発生時の影響最小化と重要業務の早期復旧を担う態勢整備こそが要だと繰り返し強調します。そして、その実現はIT・サイバーリスクを「トップリスク」として捉える経営層のガバナンス・投資・人材育成にかかっていると位置づけています。
ITレジリエンスとは何か・背景にある問題意識
本レポートでいう「ITレジリエンス」とは、障害の未然防止に止まらず、障害発生時の重要業務の継続・顧客影響の軽減・業務の早期復旧までを含む組織の回復力を指します。従来の「障害を起こさない」という発想から、「障害は必ず起こり得る前提で、起きても重要なサービスを止めない・早く戻す」という発想への転換が核心です。レポートは、これをassume breach(侵入・障害は起こるとの前提)の考え方として、防御一辺倒の設計からの脱却を促しています。
背景には、サイバー攻撃の高度化と地政学リスクの高まり、クラウドや外部委託(サードパーティ)への依存と特定事業者への集中、システム間の相互接続の深化があります。2024年度の主なインシデントとしては、北朝鮮を背景とする攻撃グループが標的型ソーシャルエンジニアリングで従業員になりすまし取引を改ざんした顧客暗号資産(ビットコイン)の不正流出、委託先である電子帳票等の発送業者からの顧客情報漏えい、金融機関へのDDoS攻撃、セキュリティソフトのアップデート不具合による業務端末の停止(保険料支払の遅延)、証券口座への不正アクセスによる不正売買などが挙げられています。いずれも、防御が破られても顧客影響をいかに抑え、いかに早く立て直すかという課題を共通して突きつけています。
2024年度の障害傾向(数値・分類)
障害事象別では「ソフトウェア障害」と「管理面・人的要因」が全体の約7割を占めました。具体例として、設計時の影響調査やテスト工程の検証観点を有識者がレビューする体制を欠いたことでATMが利用不可となった事案、設計書の判読性の低さから本番に影響しないと誤認して稼働中システムへ保守作業を行い、複数行が利用するインターネットバンキング(IB)が長時間停止した事案などが報告されています。金融庁は障害の端緒を、①サイバー攻撃・不正アクセス等の意図的な行為、②システム統合・更改プロジェクト、③日常的な保守・運用、④プログラム更新等の普段と異なる特殊作業、の4つに整理し、それぞれ特徴的な事案と課題を分析しています。
| 項目 | 内容 |
|---|---|
| 集計対象期間 | 2024年度(2024年4月~2025年3月) |
| 報告されたシステム障害件数 | 約1,800件(2025年3月時点で調査中の約100件は集計対象外) |
| 障害事象別の最多 | 「ソフトウェア障害」+「管理面・人的要因」で全体の約7割 |
| 障害の端緒(4分類) | ①意図的な攻撃 ②システム統合・更改 ③日常の運用・保守 ④プログラム更新等の特殊作業 |
| クラウドサービス利用 | 8割超の金融機関が利用。勘定系(基幹系)への採用・検討も進展 |
重要業務の特定と「障害前提」の設計
レポートは、オペレジの確保を4つの基本動作として整理しています。出発点は「重要な業務」の特定です。重要な業務とは「その中断が金融システムの安定や利用者の日常生活に著しい悪影響を生じさせるおそれのある金融サービス」を指し、先行する金融機関はBIA(ビジネスインパクト分析)を行い、資産損失・対外関係の損失・社会的影響に加え、「代替可能性」「市場シェア・利用者数」などをより重く評価して、利用者目線で選定しています。一方で「評価対象業務の網羅性確保の難度が高い」ことが共通の課題とされています。
次の「耐性度(Tolerance for disruption)」の設定こそ、障害前提の設計の核です。これはリスク選好度を定めたうえで、業務中断は必ず生じることを前提に、最低限維持すべき水準を決めるものです。多くの金融機関は既存BCPのRTO(目標復旧時間)を起点としつつ、「完全復旧」と「暫定復旧」の2段階化や、RTOに加えてRLO(目標復旧レベル=復旧時点で平時のどの程度の業務量を戻すか)の併用、事務処理時限(カットオフ)の活用などへ発展させています。考慮すべき条件が多岐にわたり、設定する業務範囲と粒度次第で負担が大きくなる点が課題です。
| ステップ | 考え方 | 主な指標・取組と課題 |
|---|---|---|
| ①重要な業務の特定 | 中断が金融システムや利用者生活に著しい悪影響を及ぼす金融サービスを特定 | BIA、公共的使命・金融市場・自社健全性、代替可能性/網羅性確保が難しい |
| ②耐性度の設定 | 中断は必ず起こる前提で最低限維持すべき水準を設定 | RTO・RLO、完全/暫定の2段階、カットオフ/条件設定と業務負担が課題 |
| ③相互連関性のマッピング・経営資源確保 | ヒト・モノ・カネをend to endで特定し相互依存を可視化 | 業務フロー図、概要/詳細シート、TPRM/外部委託先の全量調査が課題 |
| ④適切性の検証・追加対応 | 極端だが起こり得るシナリオで定期・組織横断に検証し見直し | 机上ストレステスト、複数ストレスケース/複合・同時多発シナリオが課題 |
復旧・テスト・演習
第3の基本動作が相互連関性のマッピングと経営資源の確保です。重要業務を顧客接点から終了まで(end to end)の業務フロー図に落とし、各工程で必要なヒト・施設・システム・サードパーティ・再委託先を特定して相互依存を可視化します。経営層が俯瞰できる「概要シート」と現場用の「詳細シート」を分け、両者が同じ情報で対話できるよう工夫する事例が見られます。課題は、マッピング手法が未確定であったり、外部委託先をサンプリング調査に留めて全量把握ができていない点です。
第4の基本動作が適切性の検証・追加対応です。経営陣のコミットメントの下、「極端だが起こり得るシナリオ」を想定した分析・訓練を通じ、設定が妥当かを定期的・組織横断的に検証します。先行事例では、複数のストレスケースで「耐性度までに復旧できるか」を机上ストレステストにより定量検証し、復旧できない場合は補強ポイントと優先順位を明確化しています。ただし、大規模震災のみを想定し他シナリオが不足する、複数リソースが同時に毀損する複合シナリオを描けていない、といった課題が残ります。実際の障害でも、副系への切替が機能せず、システム全面停止を想定した復旧手順が未整備で迅速に復旧できなかった「不芳事案」が報告されており、シナリオ別の復旧手順と代替手段の整備が繰り返し求められています。
TLPT(脅威ベースのペネトレーションテスト)の良好・課題事例
TLPTは、現実の攻撃に対して自組織の対策がどの程度有効かを第三者視点で検証し、リスクを可視化する手段で、大手金融機関や金融市場インフラ等で実施が望ましいとされます。良好事例は、攻撃が不成立だった確認に留めず「侵入された前提」で多層防御の有効性まで踏み込む、ブルーチーム(SOC)に非通知でリアルタイムの検知・対応能力を測る、製品だけでなく「人」「プロセス」も評価する、といったものです。課題事例は、侵入不成立の報告で終える、脅威情報分析を省き既定シナリオのみで実施する、ブルーチームに事前開示してしまう、EDR等の製品有効性評価に留める、ホワイトチームの役割が不明確、などです。業界横断では金融庁が2016年から毎年「Delta Wall」演習(直近は2024年10月のDelta Wall IX)を実施しています。
クラウド/サードパーティ依存と集中リスク
我が国金融分野では8割超の金融機関がクラウドを利用し、メインフレーム事業からの撤退表明やAI利活用を背景に、勘定系システムをクラウドへ移行する動きも出ています。レポートは、対話を通じて抽出した留意点を示します。第一に、クラウド利用は業法上の「委託」に該当し(二段階以上の再委託を含む)、外部委託として管理する必要があること。第二に、障害発生時にオンプレミスと同程度に迅速かつ十分な情報を取得できるかを事前確認すること(事業者がインターネット上に独自のタイミング・内容で公表する情報に留まり、誤った復旧や復旧遅延を招くリスクがある)。第三に、想定以上に深刻で起こり得るシナリオを設定した机上演習を金融機関とクラウド事業者がともに行い、同一クラウドを使う複数金融機関で共同実施することも有効であること。第四に、その結果を踏まえてインシデント対応計画・コンティンジェンシープランを整備・更新することです。
サードパーティリスク管理については、チェックリストによる形式的確認に陥らず実効性を高めることが要点です。リスクを一元管理する統括部署の設置、契約前のデューデリジェンスから期中モニタリング、出口戦略までのライフサイクル管理、再委託先(フォースパーティ)やクラウド事業者への依存状況の把握(TPRMの活用)が挙げられます。サービス提供型で情報開示に制約がある場合は、契約書や第三者保証報告書を活用するほか、サードパーティ側にも金融機関の管理に必要な情報提供などの支援が求められるとしています。複数行が利用するサービスや共同センターの障害は影響が広範に及ぶため、代替手段の確保と不断の情報連携が重ねて強調されています。
経営層の役割と良好・課題事例
レポートが最も強く打ち出すのは、経営層の主導です。サイバーリスクは経営に重大な影響を及ぼすトップリスクの一つであり、形式的な体制整備ではなく「現実にどの程度有効に機能するか」という実質本位の対応が求められます。サイバーセキュリティはIT部門だけでなく企画・広報・コンプライアンス・リスク管理・監査などの部門連携が不可欠で、技術的対策に加えて組織的対策を推進できるかは経営者の認識とイニシアチブ次第だと指摘します。経営陣が特定の部署・職員に任せきりにせず、自らリーダーシップを発揮して組織風土を醸成し、ガバナンスを確立することが明記されています。ひっ迫するセキュリティ人材についても、短期の配置転換を繰り返さず中長期視点で確保・育成する人事政策を、経営陣が率先して関与して進めるよう求めています。
モニタリングで把握された良好事例は、設定(リスク選好度・重要業務・耐性度・経営資源)を経営陣のコミットメントの下で定期検証する、サマリーシートで経営層が業務全体を俯瞰する、TPRMシステムで依存度の高い先を特定する、などです。課題事例は、マッピング手法が未定、外部委託先の全量調査ができていない、シナリオが特定の自然災害に偏る、検証負荷が大きい、といった「これから整備する」段階の論点が中心でした。金融庁はこれらを優劣の認定ではなく、各社が規模・特性に応じてベストプラクティスを探求する際の参考と位置づけています。
- 重要業務の特定と耐性度の制度化。BIAで重要業務を洗い出し、RTO(目標復旧時間)に加えRLO(復旧時にどの程度の業務量を戻すか)まで含む「耐性度」を業務ごとに設定する。年次BIAでの見直しを枠組み化し、副系切替や全面停止を想定した復旧手順まで具体化しておく。
- クラウド・サードパーティを「委託」として実効管理。クラウド利用は法令上の委託であり、障害時に必要情報をオンプレ同等に取得できるか、再委託・フォースパーティ依存も含めて事前確認する。統括部署による一元管理とライフサイクル管理(評価・モニタリング・出口戦略)を整え、特定事業者への集中リスクを可視化する。
- 「極端だが起こり得るシナリオ」で検証する文化。大規模震災に偏らず、複数リソースの同時毀損や複合シナリオを設定した机上ストレステストを定期実施し、耐性度までに復旧できるかを定量検証する。クラウド事業者や同一クラウドを使う同業他社との共同演習も有効である。
- TLPTで「侵入された前提」の備えを検証。攻撃不成立の確認に留めず、侵入された前提で多層防御の有効性まで踏み込み、ブルーチームには非通知でリアルタイムの検知・対応能力を測る。製品の有効性だけでなく「人」「プロセス」も評価対象に含める。
- 経営主導のガバナンスへ。ITレジリエンスを形式でなく実質的に機能する態勢とするため、検証結果・残存リスク・追加投資の要否を経営会議へ定期報告する。ひっ迫するセキュリティ人材は中長期計画で確保・育成し、現場任せにしないリーダーシップを示す。