三菱UFJ・静岡銀はなぜ「止める決断」？ PHP欠陥が突きつけた銀行の“思わぬ弱点”(2/2)

パッチだけでは足りない…金融庁要請「9項目」は機能したか

　金融当局は、今回のPHP問題より前から緊急対応のあり方を示していた。金融庁と日本銀行は5月22日、先端AIによって脆弱性の発見や悪用が加速するリスクを踏まえ、金融機関に9項目の短期的な対応を要請。7月公表の「金融分野におけるITレジリエンスに関する分析レポート」にも、その内容が整理された。

　9項目は、（1）AI対応の経営課題化、（2）優先サービスの特定、（3）技術負債の解消、（4）パッチ適用の人員確保、（5）保守契約の確認、（6）リスクに応じたパッチ適用、（7）パッチ以外の防御強化、（8）サービス停止への備え、（9）外部との連携だ。

　特にPHP問題と重なるのが、パッチを当てるIT資産の即時把握、作業人員の確保、維持保守契約の確認である。さらに金融庁は、ベンダーとの契約について「夜間・休日等も含めて適時に対応可能」か確認するよう求めた。修正版があっても作業できる担当者がいなければ、危険な状態が長引くからだ。

　とりわけ重要なのが8番目の「優先サービス／ITシステムの停止に備える」である。攻撃で止まる場合に加え、金融機関が自らサービスを止めざるを得ない場合も想定し、事業継続計画（BCP）、顧客対応、停止の判断基準を点検するよう促している。単なるパッチ管理を超えた経営課題というわけだ。

　金融庁は10月9日にも、顧客情報の漏えいが相次いでいる状況を踏まえ、委託先などのサードパーティリスク管理と、インシデント対応態勢の点検を要請している。非対面の本人確認についても、画像の不自然な点を確認するとともに、2027年4月1日の制度変更を待たずにICチップ情報の読み取りへ可能な限り早く移行するよう求めた。

　これは金融機関の管理対象が自社システムだけにとどまらないことを示している。

止めなかった実績より重要？ 銀行セキュリティの新しい評価軸

　今回のPHP問題には、さらに重い教訓がある。米アマゾン・ウェブ・サービス（AWS）は、10月17日に自社のおとりサーバで「PHP2shell」の悪用の試みを観測していたと公表していた。修正版公開の4日前である。

　これは金融機関への侵入成功を示すものではない。ただ、脆弱性の公表前から攻撃の試みがあった以上、パッチの適用だけでなく、それ以前に侵入されていないかを確認する必要もある。AWSは、少なくとも10月17日までさかのぼって調査するよう推奨している。


　ここで金融機関に問われるのが、経営陣の意思決定能力だ。脆弱性の深刻度が高いからといって、すべてのサービスを一律に停止するわけにはいかない。

　セキュリティ部門が悪用の可能性と影響範囲を評価し、業務部門が停止に伴う顧客への影響を整理した上で、経営陣が両者のリスクを比較して判断する必要があるだろう。こうした判断の手順や責任者が曖昧なままでは、必要以上のサービス停止を招く恐れもある。

　さらに重要なのは、緊急対応の実効性を客観的に評価できるかどうかだ。

　脆弱性の把握から影響範囲の特定までに何時間かかったのか。委託先との連携は円滑だったのか。再開の判断には十分な根拠があったのか。こうした対応を検証し、次の訓練やシステム設計に反映できなければ、同じ混乱を繰り返しかねない。

　今後、金融機関のセキュリティを評価する上では、システムを止めなかった実績だけでなく、有事の判断を検証し、改善につなげる能力が重要な指標になりそうだ。