金融機関における脆弱性管理・システム構成管理の課題と対策【前編】

はじめに

サイバー攻撃の巧妙化・多様化が進む中、不正アクセスや侵入拡大の糸口としての「システム脆弱性の悪用」は、今も昔も変わらず攻撃者にとっての正攻法の一つとなっています。

金融機関においても脆弱性に起因するセキュリティインシデントが後を絶たず、脆弱性への適切な管理は全社的に取り組むべき優先課題だと言えます。2024年10月に金融庁が公表した「金融分野におけるサイバーセキュリティに関するガイドライン¹」においても、脆弱性管理およびそのための土台として必要となるシステム構成管理（ハードウェア・ソフトウェア・アプリケーションといったシステム資産の管理）に関連する項目が「サイバーセキュリティリスクの特定」のための対応事項の大半を占めており、その重要性が示されています（図表１）。

金融機関を取り巻く以下のような環境を考慮すると、脆弱性管理・システム構成管理の必要性はより一層高まるものと考えています。

まず、金融分野は経済安全保障推進法における基幹インフラ事業の一つとして位置付けられています。2025年5月に公布された「サイバー対処能力強化法²」では、基幹インフラ事業者を対象に、特定重要電子計算機を導入した際の製品名などの事業所管大臣への届け出が必要となりました。そのため、正確かつタイムリーなシステム構成情報提供の仕組みや、管理体制の整備が必要になることが想定されます。

また、量子攻撃に対して耐性があるとされる新しい暗号技術、いわゆる耐量子計算機暗号（Post-Quantum Cryptography：PQC）への対応においても注意が必要です。金融庁が公表した「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書」では、PQCへの移行に向けた推奨事項として、移行対象システムの選定・優先順位付けやクリプト・インベントリの構築・更新に言及しています。これらを進めるにあたっては、最新のシステム構成情報を容易に参照可能な状態にしておくことが有効と言えます。

多くの金融機関では、脆弱性管理・システム構成管理については何らかのポリシーや管理手続きを定めて運用を行っています。一方で効率性や実効性の観点で現状に不満を持っている、あるいは上記のような新たな要求・ニーズに対応していく上での課題を感じているのではないでしょうか。

そこで本稿では実務・実装面での課題を整理するとともに、対応の方向性について提言していきます。

金融機関における脆弱性管理・システム構成管理の課題

金融機関や一般企業が脆弱性管理を効果的に実施する上では、さまざまな組織的・技術的な課題が存在します。特に金融機関では、監督官庁によるセキュリティ面での高い要求水準や法規制の遵守を求められることに加えて、複雑化・多様化するIT環境とともに攻撃手法も高度化しており、脆弱性管理における実務の負荷と難易度が増している状況です。

また、金融業界固有の運用制約やリスク許容度の違い、組織内部の情報共有体制の問題なども相まって、理想的な脆弱性管理の遂行に対してさまざまな障壁が生じています。これらの課題を正しく理解し、適切に対処することが、安全性の確保と競争力維持において重要なポイントとなります。

以下に、金融機関および一般企業に共通する主な脆弱性管理の課題を整理します。

1 資産・構成情報の把握の難しさ

脆弱性対応を行うためには、まず、企業内にどのようなIT資産があるのかを把握する必要があります。しかし、システム規模や複雑性の増大、システム部門以外で構築されるEUC（End User Computing）の増加の他、昔から問題視されているシャドーIT、さらに近年ではDXやフィンテックの推進によるITシステムの拡大などにより、全てのIT資産を把握することが困難になっています。特に金融機関では、多種多様なレガシーシステムと最新技術で構築されたシステムが混在し、異なる手法、異なるフォーマットで資産・構成情報が管理されていることから、一元的な管理がますます難しい状況です。

なお、IT資産を一元的に管理できている企業であっても、表計算ソフトなどで台帳管理しているケースはまだまだ多く、その場合は記載事項の正確性やメンテナンスの手間、情報の鮮度が問題になります。

また、2021年に発見されたApache Log4jの脆弱性をきっかけとして、各ソフトウェアが内包しているオープンソースソフトウェア（OSS）などのコンポーネントをソフトウェア部品表（Software bill of materials：SBOM）として管理しようという動きがあるものの、現状ではソフトウェア開発者（ベンダー）にSBOM提供を求めるルールが策定されはじめたところであり、ソフトウェア利用者としては、SBOMのフォーマットが標準化されていないことや、ソフトウェア開発者によってSBOMの提供方法がまちまちであることなどから、SBOM導入のハードルは高いと言わざるを得ない状況です。

2 脆弱性評価・優先順位付けの課題

多くの脆弱性が日々公表される中、金融機関および一般企業においても、公的機関や業界団体からの注意喚起、ハードウェア・ソフトウェアベンダーによる脆弱性情報の公開、NVD³などの脆弱性データベースからの情報入手、脆弱性スキャンツールによる診断やペネトレーションテストによる脆弱性の発見など、何らかの手段で脆弱性情報を入手していますが、入手した脆弱性情報の中からリスクの高い脆弱性を適切に選別し、迅速に対応策を講じることが重要です。日本の多くの企業では、共通脆弱性評価システム（Common Vulnerability Scoring System：CVSS）スコアを用いた脆弱性評価・優先順位付けを行っていますが、例えば「CVSSスコアが9.0以上の場合は即時対応」のような基準を設けた場合、CVSSスコアが9.0以上となる脆弱性はNVDの公表によると2024年は5,000件弱、2025年は9月下旬の時点ですでに3,500件以上とされており、その全てを評価するのは困難です。

また、CVSSは主に脆弱性を攻撃された場合の影響を評価しており、CVSSだけで評価してしまうと本当に攻撃の可能性の高い脆弱性の対応優先度が低く設定されるなど、対応が後手に回ってしまう懸念があります。

なお、金融システムではサービス停止のリスクや規制対応が絡むため、脆弱性パッチの適用タイミングを調整せざるを得ないケースもあり、多くの脆弱性に対応することはより困難な状況です。

3 組織内の連携不足

脆弱性管理はIT部門だけでなく、業務部門、リスク管理部門、経営層、さらにはハードウェアやソフトウェアの製品ベンダーとの連携が不可欠ですが、部門間の情報共有や役割分担が不明確なことが多く、脆弱性の見落としや対応の遅れの原因となっています。

組織内の連携不足に起因する脆弱性管理・システム構成管理の課題としては、以下のようなものが挙げられます。

1. 情報共有の不足
   • 構成情報や脆弱性情報が適時・正確に共有されず、最新のシステム状態やリスクが全体として把握できない。結果として、脆弱性の検知が遅れたり、対応の漏れが発生したりする。
   • 構成情報の変更管理が部門間で連携されていないと、変更が他部門に影響を及ぼしながらも把握されず、不整合や新たな脆弱性発生の原因となる。
2. 責任範囲のあいまいさ
   • 各部門の役割や責任範囲が明確でないため、誰が脆弱性の対応や構成変更を管理・実施すべきか不明瞭になる。それにより、対応漏れや対応の遅れなどが起きやすくなる。
3. 優先順位や対応基準の不統一
   • 脆弱性のリスク評価や対応の優先順位付けが部門ごとに異なり、統一的な対応方針がないことで対応が遅延したり、対応漏れが発生したりする。
4. 対応状況の可視化・進捗管理不足
   • 複数部門が関与する対応状況を一元的に把握できていない。進捗管理が甘く、対応遅延や抜け漏れが発生しやすい。
5. 教育・意識差による連携障害
   • セキュリティ意識や専門知識の差異により、脆弱性管理の重要性の認識や取り組み姿勢にズレが生じ、協力体制が整わない。

4 委託先・業務提携先における脆弱性管理状況の把握

近年の金融システムは、多くの外部ベンダーや委託先にシステム運用・開発や機密情報を用いた業務委託を行っています。そのため、委託先の社内システムにおける脆弱性や、委託先が製造・提供する製品やサービスに存在する脆弱性によって、金融機関のITシステムや業務が影響を受ける可能性があります。実際に、委託先のインシデントによって被害が拡大する事例は国内外で発生しており、情報漏えいや事業停止などのリスクにつながり得るため注意が必要です。

そのためセキュリティインシデントが起こらないよう、委託先の脆弱性管理の状況を適切に把握・評価することが必要ですが、実際には委託契約におけるセキュリティ要件の不備や情報共有不足が原因で、委託先経由の脆弱性が見逃されるケースが存在します。

これまでに述べてきた金融機関および一般企業が直面する脆弱性管理の課題に対しては、多面的かつ組織横断的な対応策が必要です。

後編では、これらの主要な課題ごとに具体的な対応策の例を示します。

¹ 金融庁，2024.「金融分野におけるサイバーセキュリティに関するガイドライン」（2025年10月29日閲覧）https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf

² 内閣官房国家サイバー統括室, 2025.「サイバー対処能⼒強化法及び同整備法について」https://www.cas.go.jp/jp/seisaku/cyber_anzen_hosyo_torikumi/pdf/setsumei.pdf（2025年10月29日閲覧）

³ 「National Vulnerability Database」の略で、ソフトウェアやハードウェアの脆弱性に関する情報を集めたデータベース。米国国立標準技術研究所（NIST）が運営