金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」

金融庁が2024年10月4日に公表した、金融機関等のサイバーセキュリティ管理に関する監督上の着眼点を示す文書である。銀行や証券会社（金融商品取引業者）を含む幅広い金融機関等が対象であり、日本の多くの銀行・証券会社等にとって、自社の管理態勢を整備・点検する際の共通の参照資料となる。ただし、個々の金融機関による採用・利用件数を示すものではない。

原文は金融庁のサイトで一般公開されており、誰でも全文を確認できる。 金融庁の公開PDF

読み方と全体像

ガイドラインの主な流れは 「態勢の構築 → リスクの特定 → 防御 → 検知 → 対応及び復旧」 である。サードパーティリスク管理は、この全段階にまたがる横断的なテーマとして続く（第2.1～2.6節）。さらに第3章では金融庁と関係機関の情報共有・連携を扱う。

原文は項目ごとに「基本的な対応事項」と「対応が望ましい事項」を区別する。前者は金融機関等が一般的に実施する必要のある基礎的な事項、後者は大手金融機関等が参照すべき優良事例や、影響の大きい組織で望まれる取組みなどである。いずれも全社に画一的な実装を求めるものではない。 事業、規模、重要業務、脅威、許容可能なリスクに応じて評価し、優先順位をつける「リスクベース・アプローチ」を採る（第1.1節）。以下は実務向けの要約であり、原文の逐語訳や網羅的なチェックリストではない。

1. 態勢を構築する（第2.1節）

• 取締役会等が基本方針を定め、経営陣が戦略、具体的な施策・期限・担当を含む取組計画、必要な予算と人員を確保する。管理態勢を少なくとも年1回レビューし、計画も年次・重要変更時に見直す。
• CISO等の統括責任者と、業務部門、システム・セキュリティ部門、リスク管理部門、内部監査部門の役割・権限・報告経路を明確にする。担当者の退職・異動で対応が止まらないようにする。
• 脅威情報の収集・共有、SOC等による監視、CSIRT等による緊急時対応、顧客・当局への連絡、広報の体制を整える。経営陣はリスク評価、インシデント、取組計画の進捗について少なくとも年1回報告を受ける。
• 規程と業務プロセスを実装し、リスク管理部門の牽制と内部監査で有効性を検証して改善する。新商品・サービスの企画時からセキュリティ要件を組み込む。

2. リスクを特定・評価する（第2.2節）

• 資産を把握する。 情報システムと外部サービス、機器・ソフトウェアとサポート期限、顧客情報等のデータについて台帳を整備・更新し、データフロー図とネットワーク図を維持する。委託先が管理する自社資産や外部接続も見落とさない。
• 脅威と影響を評価する。 自社の事案、公的機関、情報共有機関、委託先等から脅威・脆弱性情報を集め、発生可能性と重要業務・資産への影響を評価する。内部不正や境界防御の突破も対象にする。少なくとも年1回、重大な脅威・脆弱性の判明時、新商品・サービスの提供時に評価する。
• 対処を決める。 優先順位と担当・期限を決め、回避、軽減、受容、移転から対応を選ぶ。例外と残存リスクの受容には経営陣等の承認を得て、定期的に報告する。
• 脆弱性を管理・検証する。 情報源、影響判定、パッチ等の期限、未対応の例外承認を定める。資産台帳から影響対象を特定し、深刻な脆弱性には速やかに対処する。脆弱性診断・ペネトレーションテスト、定期的な演習・訓練を行い、経営陣や業務責任者も参加して改善につなげる。

3. 攻撃を防御する（第2.3節）

• アクセスを絞る。 最小権限、職務分離、アカウントの発行・棚卸し・失効、操作記録を運用する。特権アカウントと委託先のアクセスを厳格に管理し、重要システムへのリモートアクセスには多要素認証を使う。システム間認証、物理的な入室も管理する。
• 人を備える。 経営陣を含む役職員に役割別の定期研修を行い、インシデント時の行動も教える。必要に応じて委託先担当者の教育を確認し、顧客へフィッシング等の注意を促す。
• データと復旧手段を守る。 重要度でデータを分類し、暗号化、鍵・証明書管理、アクセス制御、媒体の利用・廃棄管理を行う。重要度に応じてバックアップの頻度・保護・整合性確認・復旧テストを定める。ランサムウェアを想定し、改ざんに強い、またはネットワークから切り離した複数環境のバックアップを検討・実施する。
• システムを守る。 必要なポート・機能だけを有効にし、マルウェア対策、サポート終了製品の更改、ネットワーク分離、必要な通信だけを許すファイアウォール設定を行う。企画・設計からセキュリティを組み込み、ログの取得・監視・保存・改ざん防止を規程化する。クラウドでは責任共有モデル、設定ミス、仕様変更、終了時のデータ消去を確認する。

4. 攻撃を検知する（第2.4節）

• 監視・分析・報告の手順を決め、クラウドや委託先の監視範囲も責任分界に応じて確認する。
• 未承認の機器・ソフトウェア、不審な端末・サーバの動作、パッチ状況、不正な接続・通信量・データ転送、役職員と保守事業者の異常なアクセスを継続監視する。
• アラートを業務影響と重要度で分析し、インシデントの該当性を判断して責任者に速やかに報告する。検知ルールと閾値を定期的に見直す。サービス特性に応じた24時間365日監視やSIEMによる相関分析は、原文では「対応が望ましい事項」の例である。

5. 対応し、復旧する（第2.5節）

• DDoS、Web改ざん、マルウェア・ランサムウェア、脆弱性悪用、不正送金等を想定し、種類別のインシデント対応計画・コンティンジェンシープラン（復旧を含む）を策定する。業務の優先順位、目標復旧時間、目標復旧水準、指揮命令と連絡先を定め、訓練する。
• 初動・分析： 監視、顧客の問い合わせ、外部からの通報を受け付け、事実確認・トリアージ・経営陣等への報告を行う。ログ等の証拠を保全して攻撃経路、被害範囲、業務影響を調べ、検知から復旧までの判断と作業を記録する。
• 連絡・封じ込め： 顧客の二次被害が懸念される場合は影響と必要な行動を伝え、法令等に従い当局へ速やかに報告し、必要な公表を行う。権限者が業務への影響も踏まえて通信遮断・システム停止を判断し、被害を抑える。
• 根絶・復旧： マルウェアや侵入原因を除去し、パッチ等を適用する。バックアップ自体の改ざん・感染を確認し、再構築したシステムの正常性、再接続の安全性、重要業務の動作を確認する。原因への対応を確認したうえで権限者が再開を判断し、事後検証を計画・管理態勢へ反映する。

6. サードパーティを全段階で管理する（第2.6節）

クラウド、システム運用委託先、外部サービスなどを特定し、業務の重要度、扱う情報、システム接続を踏まえてリスクを評価する。契約前の確認から運用中の監視、終了時のデータ廃棄・アクセス遮断まで管理する。重要な委託先にはセキュリティ態勢、インシデント対応・復旧計画も確認する。

契約・SLAには重要度に応じて、責任分界、監査権、再委託、対策、重大な脆弱性やインシデントの報告、訓練、データの保管・移転・廃棄、終了条件を明記する。集中リスクや再委託先への依存、代替手段・出口戦略の検討は「対応が望ましい事項」として挙げられている。

実務に落とすときの最初の確認

領域	まず確認する成果物・運用
経営・態勢	取締役会の方針、責任者、年次レビュー、予算・計画、報告・監査記録
特定・評価	更新された資産台帳と構成図、重要業務、リスク評価、脆弱性対応期限・例外承認
防御	権限棚卸しとMFA、パッチ、ログ、暗号鍵、バックアップと復旧テスト、研修
検知	監視範囲・責任分界、アラート基準、分析・報告経路、定期的な見直し
対応・復旧	シナリオ別計画、連絡先、演習記録、証拠保全・報告・再開判断の手順
委託先	重要度別評価、契約・SLA、継続監視、終了時のデータ・アクセス管理

この表は着手の手掛かりであり、原文の全項目を置き換えない。自社に適用される監督指針、法令、サービス特性に照らして原文を確認する。

出典： 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月4日公表）。