KNOWLEDGE & INSIGHTS

金融機関におけるシステム障害要因とシステム化課題との関係性

 

 

【はじめに】

近年、あらゆる分野でIT・デジタル化が進んでいる中、決済等に必要不可欠な金融機関のシステムも高度化・複雑化している。それに伴い金融機関のシステム障害も少なくない頻度で発生している。
本コラムでは金融機関のシステム障害要因と、金融機関のシステム化における課題について触れつつ、その関係性に述べていこうと思う。

【システム障害の分類と障害傾向別割合】

  • システム障害の分類

金融庁は金融機関のシステム障害に関する分析レポート(2024年6月)の中でシステム障害発生の端緒を下記のように分類している。(個別事例の事象や原因等は文末に補足資料として記載)

  1. サイバー攻撃・不正アクセス等の意図的な行為
  2. システム統合・更改プロジェクトに伴い発生
  3. システムの日常的な保守・運用の中で発生したシステム障害
  4. システムのプログラム更新等の普段とは異なる作業等から発生したシステム障害
  •  障害傾向別割合

同レポートによると、金融業界全体の障害傾向(事象別)の、約7割が「ソフトウェア障害」と「管理面・人的要因」によるものだとしている。

URL:https://www.fsa.go.jp/news/r5/sonota/20240626/01.pdf

この割合は2019年の金融機関のシステム障害に関する分析レポートから多少の変化はあるものの上から、「ソフトウェア障害」「管理面・人的要因」という形は変わっていない。

URL:https://www.fsa.go.jp/news/r1/20200630-2/system_01.pdf

 

【金融機関のシステム化における課題】

金融機関のシステム化(デジタル化)の課題として

  1. レガシーシステムへの依存
  2. IT人材不足
  3. カルチャー

3点がよく挙げられる。まずはそれぞれの理由をもう少し詳しく解説する。

  • レガシーシステムへの依存

レガシーシステムとは過去の技術や仕組みで構築されているシステムを指す用語で、独自のシステムで動いているため整備性や拡張性に難があるという特徴がある。
また、1980年代に多くの企業が導入した背景から、当時の開発・運用に関わった人たちが今後定年等で退職してしまった結果、現場にナレッジが残りにくいということも叫ばれている。
特に金融機関の場合、情報セキュリティの観点からのシステムの内製化意識・必要性が高いことや、金融機関同士の統廃合などによる無理な設計がレガシーシステムへの依存が高めているとされている。
独立行政法人情報処理推進機構のDX動向2024のアンケート結果を見ても金融機関のレガシーシステムへの依存は高いといえる。

URL:https://www.ipa.go.jp/digital/chousa/dx-trend/eid2eo0000002cs5-att/dx-trend-2024.pdf

 

  • IT人材不足

こちらについては金融機関だけではなくすべての業界に当てはまるかと思う。
ただ、金融機関においてはもともとIT技術との親和性が低いことに加え、自社内でIT人材の育成を行うのが難しいという特徴がある。
私自身が新卒から約6~7年、金融機関に勤めていたが、業務の性質上この指摘は正しいと思う。
また先と同様にDX動向2024のアンケート結果を見ても人材は不足しているといえる。

URL:https://www.ipa.go.jp/digital/chousa/dx-trend/eid2eo0000002cs5-att/dx-trend-2024.pdf

 

  • カルチャー

金融機関の企業としての特徴として規模が比較的大きく、歴史も長いという特徴もシステム化に迅速に舵を切れない理由として挙げられる。
また、企業の経営状況や個人の資産状況等の情報を扱うことから、そもそも情報がオープンになる可能性があるということ自体を嫌うという考えがあるということも要因ではないかと推察する。

 

【システム障害事例と金融機関のシステム化の課題との関係性】

先に述べたように金融機関のシステム障害事象別割合の上位2つが「ソフトウェア障害」「管理面・人的ミス」であり、その順位は5年前と変わっていない。このことと金融機関のシステム化の課題とを併せて考えてみると根底にあるものは同じであるのではないかとの印象を受ける。
つまり「ソフトウェア障害」の根底には「レガシーシステムへの依存」があり、「管理面・人的ミス」の根底には「IT人材不足」があるのではないか、そしてこの状況をなかなか変えられない根底にはカルチャーがあるのではないかということである。

 

【金融機関のシステム化への意識】

ここまでの話だと金融機関はシステム化に後ろ向きであるとの印象を受けた方もいるであろうが、その印象が正しいのかを最後に見ていきたい。ここでは独立行政法人情報処理推進機構のDX動向2024と、少し古いが令和3年度版の総務省の情報通信白書を使用して見ていこうと思う。
下が情報通信白書より抜粋した総務省が取りまとめた日本の業種別のデジタル・トランスフォーメーションの取組状況である。(なお、調査対象や定義が異なる点には注意が必要である)

<DX動向2024

URL:https://www.ipa.go.jp/digital/chousa/dx-trend/eid2eo0000002cs5-att/dx-trend-2024.pdf

<情報通信白書>

URL:https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/pdf/n1200000.pdf

どちらの調査結果をからもわかるように、むしろ金融機関は他の業界と比べてもシステム化には積極的に取り組んでいると見受けられる。

また、一般社団法人 日本情報システム・ユーザー協会の企業IT動向調査報告書2024によるとCIO(最高情報責任者)の設置状況を見ても、全体の設置状況5.7%に対して19.1%と積極的な姿勢が見て取れることから、金融機関のシステム化に対する意識はむしろ高いともいえる。

URL:https://juas.or.jp/cms/media/2024/04/JUAS_IT2024.pdf

 

【おわりに】

今回、金融機関のシステム障害とシステム化の課題との関係性について推察を述べさせていただいた。
金融インフラは水道や電気、道路といったライフラインのインフラと同様に、国や企業、個人にとって重要なものであるため強固なインフラを築いていく必要性がある。
一説によると近年のアフリカの発展はネットバンキング等の金融インフラの浸透が一助していると聞く。
これまでアフリカでは店舗や従業員を確保することが難しかったため銀行が少なく、その地域の住民は銀行口座を持つことも難しかった。銀行口座がなければ融資を受けることや貯蓄が難しいだけでなく、ライフラインや税金の支払いも難しい。その結果としてのライフラインインフラを用意する資金も用意できずインフラが整備されないという負のスパイラルがあった。
そんな中、ネットやスマホの普及によって、電波と電気と電気さえあれば、ネットバンキング等の金融インフラが利用できるようになった。これにより負から正へスパイラルの転換が起きている。
日本においては金融インフラについては早くから整備されており、今日までの経済を循環させる大きな原動力となってきた。しかしながら新たな技術や仕組みの台頭により優位性がよって失われつつある。
今度は日本が取り残されないためにも金融業界には現状のシステム化課題を乗り越え、強固な金融インフラを整備することで引き続き日本経済の原動力となっていって欲しい。

 

【補足資料:分類毎の個別事例】

  1. サイバー攻撃・不正アクセス等の意図的な行為によって発生したシステム障害
  • ランサムウェア感染に伴う情報漏えい

<業態>

  • 信用金庫・信用組合等

<事象>

  • ファイアウォールの脆弱性を悪用した外部からの不正アクセスにより、ファイルサーバーがランサムウェアに感染し、データが暗号化されて身代金を要求されるとともに、情報漏えいが発生した。

<原因>

  • ファイルサーバーへの接続元を制限する設定としていなかった。
  • サポート期限切れの古いサーバーを利用していた。

<対策>

  • 認証強化(二要素認証)、ネットワーク機器の接続先IPアドレス等制御の実施
  • サポート期限切れのサーバーの利用中止

 

  • DDoS攻撃による決済不可

<業態>

  • 資金移動業者等

<事象>

  • DDoS攻撃により、サーバーへの負荷が急増し、リクエストを処理できず、決済に影響が生じた。

<原因>

  • 複数あるインターネット上の入り口(ドメイン)の一部に対し、特定IPアドレスより通常時の3,000倍以上のアクセスが発生したため、サーバーへの負荷が増加し、リクエストを処理できなかった。

<対策>

  • 異常なリクエストを自動で制御するためのドメインレベルでの主要経路に対するレートリミット14の導入
  • ブロック対応の高度化(IPブラックリストの適用、HTTPヘッダーを用いたブロックルールの適用)

 

  1. システム統合・更新プロジェクトに伴って発生したシステム障害
  • 大規模プロジェクトに係る知見、経験等の不足によるATM停止及び残高情報の誤更新

<業態>

  • 主要行等

<事象>

  • ATM取引不能及び勘定不整合が発生した。

<原因>

  • 勘定系システムとATMの間で発生したネットワーク障害(障害に対する考慮不足によりネットワークのログを保存していなかったため詳細不明)により勘定系システムからの応答(下り電文)がATMへ届かなかったため、取引が不能となった。
  • ネットワーク障害が発生し応答が正常にできていないことを検知していたにもかかわらず、勘定系システム内ではATMから続々と要求され続ける取引(上り電文)の処理を続けたため、取引が完結していないにもかかわらず勘定系システム内の残高情報が更新された。

<対策>

  • 重要システムでの障害発生時に原因を正確に特定するため、ログの保存を開始
  • ネットワーク障害を検知した場合には即時に取引を停止し再起動するよう勘定系システムを改修

 

  • リリース作業誤りによる仕向振込・被仕向入金一部不可

<業態>

  • 主要行等

<事象>

  • プログラムのリリース作業誤りにより、全銀システム関連機能が意図せず二重起動したことに起因し、当該機能がダウンと再起動を繰り返し、全銀システムとの通信が不安定な状態となった。これにより、仕向振込及び被仕向入金が一部不可等となった。また、復旧方法を誤り、仕向振込の二重送信等が発生した。

<原因>

  • 本番環境に準じたテスト環境を構築した上でのリリース作業手順確認を実施していなかった。
  • 外部委託先からリリース作業が遅延しているという報告を受けていたものの、リリース時間が全銀システムに与える影響を認識しないままリリースを承認してしまった。
  • 全銀システムとの接続復旧後に電文を送信する際に電文ごとに不整合の発生有無を確認していなかった。

<対策>

  • 本番環境に準じたテスト環境の構築とリリース作業手順確認の実施
  • リリースプロセス見直しの実施

 

  1. システムの日常的な保守・運用の中で発生したシステム障害
  • ハードウェアの障害による終日株式売買の停止

<業態>

  • 証券取引所

<事象>

  • 共有ディスク装置のメモリに故障が発生した際、冗長構成になっていたにもかかわらず、もう一つの装置に切り替わらず一部業務に異常が発生し、売買を停止せざるを得ない状況となった。
  • 日中にシステムを再起動した場合の市場の混乱を懸念し、終日売買停止することとなった。

<原因>

  • 故障した製品のマニュアルに不備があり、自動切替えがされない設定になっていた。また、当該設定に係る実際の稼働テストが不十分であった。
  • システム障害による売買停止後の再開に向けたルールが整備されていなかった。

<対策>

  • 冗長構成が正常に動作することの確認
  • システム障害発生時の業務再開に向けた手順やルールの整備

 

  • レビュー観点不足に起因したプログラム誤りによる誤入出金

<業態>

主要行等

<事象>

  • ATMにおいて、QRコードを用いた入出金を行った際、別ATMで同時刻に同様の操作を行った別顧客の口座に入出金される事象が発生した。

<原因>

  • QRコードの生成において、全ての取引の取引キーが重複しないよう一意となる必要があるが、要件定義の内容が後続の設計書やプログラムまで反映されているかという観点でのレビューが不足していた。
  • プログラム設計・担当者が要件を正しく理解できる記載となっているかという観点でのレビューが不足していた。

<対策>

  • 設計書やプログラムのレビュー時の要件定義反映に係るレビュー観点の追加
  • プログラム設計・担当者が要件を正しく理解できる記載となっているかという観点での有識者による確認実施と第三者(品質保証部門担当者等)による客観的な確認の実施

 

  1. システムのプログラム更新等の普段とは異なる作業等から発生したシステム障害

<設定ミス・操作ミス等の管理面・人的要因>

  • 送信元の設定誤りによるIB等利用不可

<業態>

  • 主要行等

<事象>

  • クラウド環境へ移行する際、本来許可すべき送信元のIPアドレスのセグメント設定を誤り、接続エラーとなったことに起因し、一部の顧客が個人用IBやホームページを利用できない事象が発生した。また、顧客からの問い合わせがあるまで当該障害を発見できなかった。

<原因>

  • 担当者の作業確認漏れにより、許可すべきIPアドレスのセグメントが本番環境に反映されていなかった。
  • 接続エラーが発生した際にアラートを検知する機能を実装していなかった。

<対策>

  • レビュー体制の整備
  • 接続エラーのアラート検知機能の構築

 

<ソフトウェアの不具合>

  • 想定を超えた注文数により時間優先での原則が適用されず約定が行われたシステム障害

<業態>

  • 暗号資産交換業者

<事象>

  • 同一価格で一定件数を超える指値買いの新規注文が蓄積した際、約定対象の買い注文に時間優先の原則が適用されず、後から注文した指値の買い注文から約定した。

<原因>

  • 当社取引所システムの板寄せ処理は、指値の買い注文を一定件数ずつ取得し売り注文とのマッチングを行っているが、一定件数を超える同一価格での指値の買い新規注文が発生した場合、直近の一定件数が優先される仕様となっていたため、先に注文した買い注文が後回しにされた。

<対策>

  • 想定以上の注文を受けた際に時間優先の原則が適用されているかというテスト確認の徹底

 

【参考】

金融庁 金融機関のシステム障害に関する分析レポート 20246

金融庁 金融機関のシステム障害に関する分析レポート 令和26

独立行政法人情報処理推進機構 DX動向2024

総務省 情報通信白書 令和3年版

一般社団法人 日本情報システム・ユーザー協会 企業IT動向調査報告書2024

Cotra 【事例で解説】金融業界でDX化が進められている3つの理由とは?

 

大島 敬吾

アーツアンドクラフツConsulting & Solution事業部/アナリスト