副題：「止めない・広げない・戻す」を経営の言葉で設計する
想定読者：経営層、CISO、CRO、BCM/BCP担当、IT企画
金融庁が2025年6月に公表した「金融分野におけるITレジリエンスに関する分析レポート」によると、2024年度に金融機関から報告されたシステム障害は約1,800件にのぼります。
サイバー攻撃だけではありません。ソフトウェアの不具合、人為的なミス、委託先の障害。原因はさまざまですが、結果は同じです。業務が止まり、顧客に影響が出ます。
防御への投資は今後も必要です。しかし、どれだけ投資しても止まるときは止まる。だとすれば、経営が問うべきは「防げたか」ではなく「止まったときに何が起きるか」です。本稿では、この問いの立て方 ― サイバーレジリエンス ― を整理します。
1. 「防げなかった」は、もはや例外ではない
同レポートは、2024年度に実際に起きた事象として次のような例を挙げています。
- 委託先でのランサムウェア：外部委託先で運用されていたサーバが不正アクセスを受け、個人情報を含むファイルが暗号化・窃取され、のちにダークウェブ上で公開された
- セキュリティソフトの更新不具合：アップデートの不具合で端末が再起動を繰り返し、一部金融機関の支払業務に支障が出た
- なりすましによる不正送金：標的型のソーシャルエンジニアリングで従業員になりすまされ、正規取引の依頼が改ざんされて顧客の暗号資産が流出した
3つに共通するのは、自社の防御の内側だけでは止められなかったことです。1つ目は委託先、2つ目は守るために導入したはずの製品、3つ目は正規の業務手続きそのものが起点になっています。2つ目にいたっては攻撃ですらありません。
侵入を防ぐ努力が足りなかった、と片付けることはできません。防御が完全であることを前提にした設計そのものが、現実と合わなくなっているのです。
2. サイバーセキュリティとサイバーレジリエンスは何が違うのか
両者は対立する概念ではありません。問いの置き方が違います。
サイバーセキュリティ | サイバーレジリエンス | |
|---|---|---|
中心となる問い | 侵入・障害を防げるか | 侵入・障害が起きても、重要な業務を提供し続けられるか |
前提 | 脅威は防御で止められる | 防御を尽くしても事象は起きる |
成功の定義 | インシデントが起きないこと | 顧客・市場への影響が許容できる範囲に収まること |
主な指標 | 脆弱性の件数、検知率、パッチ適用率 | 重要業務の停止時間、影響を受けた顧客数、復旧までの時間 |
主な担い手 | セキュリティ部門、IT部門 | 経営、業務部門、リスク管理、IT・セキュリティ部門の全体 |
最も大きな違いは最後の行です。サイバーセキュリティは技術部門が中心でも回ります。しかしレジリエンスは、どの業務を止めてはいけないか、どこまでなら止まってよいかという判断を含むため、技術部門だけでは決められません。
3. レジリエンスを構成する4つの能力
米国NISTは、サイバーレジリエンスに関するエンジニアリング指針（SP 800-160 Vol.2 Rev.1、2021年12月）で、システムが備えるべき能力を「予期する（anticipate）」「耐える（withstand）」「回復する（recover）」「適応する（adapt）」の4つで整理しています。
図1 レジリエンス曲線 ― 4つの能力と耐性度（© ProSol）
能力 | 意味 | 金融機関での具体例 |
|---|---|---|
予期する | 起こりうる事象に備え、兆候を捉える | 重要業務と依存先の把握、脅威情報の活用、対応計画と訓練 |
耐える | 事象が起きても重要な機能を維持する | 縮退運用、代替手段への切り替え、被害範囲の封じ込め |
回復する | 機能を元の水準に戻す | 改ざんされていないバックアップからの復元、復旧手順の実行 |
適応する | 経験をもとに、次の事象に強い形へ変える | 事後レビュー、構成・プロセスの見直し、耐性度の再設定 |
従来のサイバーセキュリティ投資の多くは、図の左側 ― 事象を起こさないための「予期」の一部 ― に集中してきました。レジリエンスの観点で見ると、曲線がどこまで落ち込み、どれだけ早く戻るかを決める「耐える」「回復する」への備えが、相対的に薄いことが分かります。
4. 金融庁が求めているもの ― 重要な業務を、耐性度の範囲で
金融庁は2023年4月、ディスカッション・ペーパー「オペレーショナル・レジリエンス確保に向けた基本的な考え方」を公表しました。ここでオペレーショナル・レジリエンスは次のように定義されています。
システム障害、テロやサイバー攻撃、感染症、自然災害等の事象が発生しても、金融機関が重要な業務を、最低限維持すべき水準（耐性度）において、提供し続ける能力
この定義には、サイバーレジリエンスを考えるうえで重要な3つの要素が含まれています。
- 原因を問わない：サイバー攻撃は想定事象の一つにすぎず、システム障害も自然災害も同じ枠組みで扱う
- すべての業務ではなく「重要な業務」：中断が金融システムの安定や利用者の日常生活に著しい悪影響を及ぼすおそれのあるサービスに絞る
- 「止めない」ではなく「耐性度の範囲で提供し続ける」：中断は起こりうる前提で、許容できる限界を先に決める
同ペーパーは、取組みの基本動作を①重要な業務の特定、②耐性度の設定、③業務プロセスの相互関係のマッピングと経営資源の確保、④訓練・テストによる検証と継続的な見直しの4点に整理しています。あわせて、サイバーセキュリティはオペレーショナル・レジリエンスと「不可分一体」であり、未然防止に加えて早期復旧と影響範囲の軽減を担保するサイバー・レジリエンスが課題であると指摘しています。
国際的には、バーゼル銀行監督委員会が2021年3月に「オペレーショナル・レジリエンスのための諸原則」を公表しており、欧州のDORAや英国の規制も同じ方向を向いています。防御の水準を問う規制から、止まったときの影響を問う規制へ。この流れは今後も強まると見るべきです。
5. 経営が決めなければならない3つのこと
レジリエンスの設計には、技術部門では決められない判断が含まれています。経営が決めるべきことは、突き詰めると次の3つです。
① どの業務を止めてはならないか
すべての業務を同じ水準で守ることはできません。「この業務が止まると、顧客と市場に何が起きるか」から、守る優先順位を経営として決めます。ここが曖昧なままでは、IT部門は全システムを等しく守ろうとし、結果としてどれも十分に守れない状態になります。
② どこまでなら止まってよいか
重要な業務ごとに、「これを超えたら受容できない」という限界 ― 耐性度 ― を決めます。これは技術的な目標値ではなく、顧客と市場に対する経営の約束です。復旧目標（RTO）との違いを含め、決め方の手順は第2回で扱います。
③ 本当に戻せることを、どう確かめるか
計画書があることと、実際に戻せることは別物です。バックアップはあっても、それ自体が暗号化されていた。手順書はあっても、担当者が不在だった。依存先の委託先が同時に止まっていた。こうした「想定外」は、検証して初めて見つかります。演習の設計は第3回で扱います。
まとめ ― このシリーズで扱うこと
サイバーレジリエンスは、サイバーセキュリティを置き換えるものではありません。防御の投資判断に「止まったときの影響」という物差しを加えるものです。そしてその物差しを決めるのは、技術部門ではなく経営です。
- 第1回（本稿）：「侵入を防ぐ」だけでは足りない ― サイバーレジリエンスとは何か
- 第2回：重要業務から逆算する復旧設計 ― RTO・RPOだけでは足りない
- 第3回：サイバー演習で「本当に復旧できるか」を検証する
次回は、重要な業務の特定と耐性度の設定を起点に、依存先と復旧順序を含めた復旧設計の組み立て方を解説します。
主要出典
- 金融庁「オペレーショナル・レジリエンス確保に向けた基本的な考え方」（ディスカッション・ペーパー、2023年4月）
- 金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2025年6月）
- NIST SP 800-160 Vol.2 Rev.1「Developing Cyber-Resilient Systems: A Systems Security Engineering Approach」（2021年12月）
- 金融庁・日本銀行「バーゼル銀行監督委員会による『オペレーショナル・レジリエンスのための諸原則』の公表について」（2021年5月／原文公表 2021年3月）
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月、2025年7月一部改正）
本記事は公開情報に基づく一般的な解説です。事例は上記出典の記載に基づくもので、特定の機関を指すものではありません。制度の動向に応じて定期的に見直します。