• 2026/11/11 06:30 掲載

PHP脆弱性で金融サービス停止…経営が問われる“再開判断”と6つの備え(3/4)

大野博堂の金融最前線連載第102回

会員(無料)になると、いいね!でマイページに保存できます。

銀行が“止める判断”を下せた理由

 筆者らのチームは先般、ある大手金融グループの経営トップを対象に「サイバー攻撃時の経営意思決定演習」を実施したばかりだった。高度なサイバー攻撃の予兆を検知した際に、重要システムを停止すべきか否かを問いかけることを、演習の主要題材としたものだ。

 そこで浮き彫りになるのは、脆弱性対応とはいえ、顧客接点にかかわる重要システムやサイトを緊急に停止するという決定を、現場判断で行うハードルは極めて高いという実態である。

 その意味で、今回は総理自らがXで能動的な停止措置を含む対応を呼びかけたことの意義が極めて大きい。経営層にも、本件対応の重要性と「停止措置の必然性」が短時間で浸透したからだ。

 実際、筆者が大手銀行のサイバー対処担当者に対面でヒアリングしたところ、「総理の告知を受け、速やかにサイト閉鎖と脆弱性対応の初期的対応をすべきという判断がトップから下達され、深夜にかけて一気に対応を進めることができた。現場判断ではなくトップダウンによる効果は大きいと感じた」との声を直接得ている。

 ただし、今後も政府が都度、今回のような丁寧な呼びかけを継続してくれるとは限らない。今回の教訓は、システム停止の判断を、自社として組織的かつ速やかに下せるための手続きや手順を整備しておく必要がある、という点に尽きる。

 すなわち、サイバー攻撃時の対応マニュアルや、実際に攻撃を受けた際に発動されるBCP(事業継続計画)の有効な初動対応手順の実装が欠かせないことは明白だ。

 思い起こせば、2026年5月22日に金融庁・日銀が下達した9項目の緊急点検でも、「防御しきれず優先サービスが停止した場合に備えること」が掲げられていた。

 また、7月30日に金融庁が公表したITレジリエンスに関する分析レポートが指摘するとおり、脆弱性の公表から悪用までの時間が大幅に短縮されるなか、緊急時の権限委譲を含め、緊急時の判断のよりどころとなる基準や根拠を経営レベルで早急に見直す必要もあるだろう。

 今回の事案は、こうしたBCPの高度化要請が現実の場面で経営層にも現場レベルにも問われた稀に見る事案であったと言えよう。

金融機関が見直すべき“6つの備え”

 今回得られた教訓なども踏まえ、改めて金融機関の当面の対応および課題として、以下の6つの視点を挙げておきたい。

(1)管理対象外のサイトを洗い出す
 今回停止の対象となったのは優先度の高い一部のシステムだったが、現実には、セミナーの申込やアンケートを目的とした登録フォームを備え、短期間だけ運営されるテンポラリーなサイトも攻撃対象となり得る。

 外部のサイト構築ツールやWebサイト制作会社を使い、現場管理にとどまることもありシステム部門の所管外とされがちだが、顧客情報を収集する点では組織的に管理されたサイトと何ら変わりはない。こうした管理対象外の領域を洗い出す必要がある。

(2)“再開の判断”を先に決める
 「サービス停止」はあくまで初動対応措置の一部であり、次に問われるのは、いつ、どのような条件で「再開」するかだ。修正プログラムの適用に加え、停止までの間にすでに悪用されていなかったか、不正なファイルの設置やアクセスログ上の痕跡がないかを確認しなければ、安全な再開とは言えない。

 顧客利便を損なうリスクと拙速な再開のリスクを比較検証せねばならないし、最終的な責任を負うのは善管注意義務を負う経営層である点を改めて認識しておく必要がある。再開の判断基準と判断権者を、あらかじめ定めておくことが求められる。

(3)PHPの利用箇所とバージョンを把握する
 多くの金融機関が直面したのは、自社のどのシステムやサイトにPHPが組み込まれ、どのバージョンが稼働しているかを短時間で特定する難しさだったのではないか。パッケージ製品や委託先が構築したサイトの内部で使われているケースもあり、IT資産台帳やソフトウェア部品表(SBOM:Software Bill of Materials)が平時から整備されているか否かが、初動のスピードを左右する。

 また、留意せねばならないのは、サポートが終了した古いバージョンを対象とした修正パッチは原則として提供されないため、将来にわたって脆弱性が残置される懸念も否めないという点だ。

(4)委託先・グループ会社まで点検する
 金融機関のシステムの多くは、外部ベンダーや共同センター、クラウド事業者に依存している。とりわけ地域金融機関では、自前での技術的な確認が難しく、ベンダーからの回答待ちとなる場面も少なくないだろう。委託先に対応状況の報告を求め、その結果を経営として把握する仕組みの構築に加え、グループ会社や業務委託先が運営するサイトまで含めた総点検が欠かせない。

(5)顧客への説明と便乗詐欺への備え
 サイトやアプリの停止は顧客に不便を強いるため、停止の理由、再開の見通し、代替となる取引チャネルを迅速かつ平易に発信することが信頼の維持につながる。実際、千葉興業銀行においては、「iDeCoは店頭窓口で申込可能」と案内するなど、公表情報において代替手段を明確に通知する例が確認されており、有意な対応といえる。

 同時に、こうした混乱に乗じて「脆弱性対応のため再ログインが必要」などと称するフィッシングメールやSMSが出回ることも想定される。金融機関側から、メールなどでパスワードや暗証番号の入力を求めることはない旨を、改めて注意喚起すべきである。

(6)当局・業界と情報を共有する
 金融庁への報告はもとより、金融ISACなど業界の情報共有の枠組みを通じて、攻撃の兆候や有効な対処策を相互に共有することが重要だ。単独で割けるリソースが限られる中小の金融機関にとっては、とりわけ有効だろう。万一、顧客情報の漏えいが疑われる場合には、個人情報保護委員会への報告も視野に入れた対応が求められる。 【次ページ】PHP対応の次はBrotli、何を守る?
関連タグ タグをフォローすると最新情報が表示されます
あなたの投稿

    PR

    PR

    PR

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報が
本メディアサイトに公開されます

基本情報公開時のサンプル画像
報告が完了しました

「」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報が
お相手に公開されます

基本情報公開時のサンプル画像