【情報処理安全確保支援士試験対策】脆弱性を放置しない！パッチ管理と資産管理の徹底攻略

サイバー攻撃のニュースを見るたびに、「なぜ防げなかったのか」と疑問に思うことはないでしょうか。高度な未知の攻撃（ゼロデイ攻撃）が原因であるケースもありますが、既知の脆弱性が放置されたことを突かれた被害も数多く報告されています。米国CISAは、実際に悪用が確認された既知の脆弱性を「KEVカタログ」として公開し続けており、その掲載件数は2026年10月時点で1,700件を超えています。

攻撃者は、常にインターネット上のシステムをスキャンし、鍵が開いたままの窓（脆弱性）を探しています。この窓を確実に閉じる作業こそが「パッチ管理」であり、そもそも家のどこに窓があるのかを把握する作業が「資産管理」です。これらは地味で泥臭い運用タスクに見えますが、セキュリティ対策における「一丁目一番地」であり、情報処理安全確保支援士試験（SC試験）の科目B（旧午後）の記述式問題でも、運用フェーズの要として題材になるテーマです。

本記事では、単なる用語の暗記ではなく、実務における運用の流れや、試験で問われる「なぜその対策が必要なのか」という本質的な理由を深掘りします。システムを守るための土台となる、資産管理とパッチ管理の連携について完全に理解し、得点源に変えていきましょう。

すべてのセキュリティ対策の前提となる「資産管理」

セキュリティ対策を議論する際、多くの人がファイアウォールやアンチウイルスソフトといった防御ツールに目を向けがちです。しかし、防御対象が何であるかを知らずして、適切な防御は不可能です。「守るべきものを知らない」状態では、リスクアセスメントも脆弱性対策も機能しません。

管理外資産が生む致命的なリスク

組織内のIT環境は日々変化しています。新規サーバーの構築、PCの入れ替え、クラウドサービスの利用開始など、資産は増減し続けます。もし、管理台帳に載っていない「野良サーバー」が存在したらどうなるでしょうか。

管理者が存在を知らないサーバーには、セキュリティパッチが適用されません。ウイルス対策ソフトも導入されていないかもしれません。攻撃者は、堅牢に守られた正面玄関ではなく、このような管理外の裏口を狙います。一度侵入を許せば、そこを踏み台にして組織内部のネットワーク深くへと侵攻されてしまいます。

情報処理安全確保支援士試験の科目B（旧午後）では、次のようなシナリオが題材になることがあります。

• 管理外の端末が接続されていたことによるインシデント
• 退職者のIDが削除されずに残っていた問題
• 部門が独自導入したクラウドサービスからの情報漏洩

これらはすべて、広義の資産管理（ハードウェア、ソフトウェア、アカウント）の不備に帰結します。「どこに何があるか」を正確に把握することが、セキュリティの出発点なのです。

ハードウェア資産管理の実務

ハードウェア管理では、PC、サーバー、ネットワーク機器、モバイルデバイス（スマートフォン、タブレット）などの物理的な筐体を管理します。

管理すべき主要項目

• 機器のシリアルナンバー、資産タグ
• IPアドレス、MACアドレス
• 設置場所、管理部門
• 管理者、利用者
• 用途、重要度分類
• 購入日、保守契約期間

特に近年では、テレワークの普及により社外に持ち出されるデバイスの管理（MDM：Mobile Device Management）の重要性が増しています。リモート環境下では、物理的な所在確認ができないため、ネットワーク経由での資産把握とセキュリティポリシーの強制適用が不可欠です。

また、個人所有デバイスの業務利用（BYOD：Bring Your Own Device）を許可している組織では、私物端末と業務データを分離管理する技術（コンテナ化、仮想デスクトップなど）と併せて、BYOD端末も資産台帳に記録する運用が求められます。

ソフトウェア資産管理とライセンスコンプライアンス

ソフトウェア管理では、各ハードウェアに「どのOSの、どのバージョンの、どのようなアプリケーションが」インストールされているかを管理します。ここで重要なのが、ハードウェアとソフトウェアの紐づけです。

管理の粒度例

ハードウェアID: PC-ACC-001
利用者: 経理部 Aさん
OS: Windows 11 Pro 25H2
インストールソフトウェア:
  - 会計ソフト Ver.5.0（ライセンスNo: ACC-LIC-001）
  - Microsoft 365 Apps（ライセンスNo: OFF-LIC-045）
  - Adobe Acrobat DC
最終パッチ適用日: 2026-01-15

このレベルの詳細な管理により、特定のソフトウェアに脆弱性が発見された際、影響範囲を即座に特定できます。「会計ソフトVer.5.0に脆弱性が発見された→台帳を検索→経理部の5台のPCが該当→優先的にパッチ適用」という迅速な対応が可能になります。

また、ソフトウェアにはライセンス（使用許諾）の問題も絡みます。ライセンス違反（不正コピーなど）はコンプライアンス上の重大なリスクとなるため、インストール数と保有ライセンス数の突合も資産管理の重要な役割です。ライセンス監査で違反が発覚すると、多額の賠償金や企業イメージの毀損につながります。

シャドーITとの戦い

資産管理における最大の敵が「シャドーIT」です。シャドーITとは、情報システム部門や管理者の許可を得ずに、部門や個人が独自に導入したIT機器やクラウドサービスのことです。

典型的なシャドーITの例

• 業務効率化のために社員が勝手にインストールしたフリーソフト
• 私物のスマートフォンを社内Wi-Fiに無断接続
• 無料のファイル転送サービスで顧客データを送信
• 部門独自で契約したクラウドストレージサービス

これらは悪意がなくとも、セキュリティポリシーが適用されないため、情報漏洩やマルウェア感染の温床となります。特にクラウドサービスのシャドーIT利用は、通常のHTTPS通信として組織のファイアウォールを通過するため、従来の境界防御だけでは検知・制御が困難です。

対策の両輪アプローチ

1. ルールの策定と教育
   • 私物利用の禁止明文化
   • ソフトウェア導入時の申請フローの確立
   • 違反時のペナルティ規定
   • 定期的なセキュリティ教育の実施
2. 技術的な検知と遮断
   • 資産管理ツールの導入: エージェントソフトを各PCに導入し、インストールされているソフトウェア一覧を自動収集。許可されていないソフトが検出された場合、管理者にアラートを飛ばしたり、起動をブロック
   • ネットワークアクセス制御（NAC：Network Access Control）: 未登録のMACアドレスを持つ機器がネットワークに接続された際、検疫ネットワークに隔離するか、接続を遮断
   • CASB（Cloud Access Security Broker）: クラウドサービスへのアクセスを監視・制御し、未承認のサービス利用を検知

SBOM（ソフトウェア部品表）による細粒度管理

近年、資産管理の文脈で急速に注目されているのが「SBOM（Software Bill of Materials）」です。これは、あるソフトウェアがどのようなコンポーネント（ライブラリやミドルウェア）で構成されているかをリスト化した「ソフトウェアの部品表」です。

SBOMが重要視される背景

近年のソフトウェア開発では、オープンソースソフトウェア（OSS）の利用が当たり前になっています。しかし、利用しているOSSに脆弱性が見つかった場合、そのOSSを組み込んでいる自社システムも影響を受ける可能性があります（脆弱なコードを実際に使っているか、外部から到達できるか、設定はどうかによっては影響しないこともあります）。

従来の資産管理では「Webサーバー用アプリ Ver 1.0」という単位でしか管理しておらず、「その中にLog4jというライブラリが含まれているか」までは把握しきれないケースが多発しました。2021年12月に公表されたLog4Shell脆弱性（CVE-2021-44228）では、世界中の企業が影響調査に苦慮しました。

SBOMの導入効果

アプリケーション: 社内業務システム Ver 2.0
├─ フレームワーク: Spring Boot 2.5.6
├─ ログ出力ライブラリ: Apache Log4j（log4j-core）2.14.1 ← 脆弱性あり！（CVE-2021-44228）
├─ データベース接続: PostgreSQL JDBC 42.2.23
└─ 認証ライブラリ: OAuth2 Client 5.5.2

SBOMを導入・管理することで、特定のライブラリに脆弱性が発見された際、自社のどのシステムが影響を受ける可能性があるかを即座に洗い出せるようになります。洗い出した候補について、実際に影響があるかどうかは、ベンダーの公表情報や、製品が脆弱性の影響を受けるかどうかを示すVEX（Vulnerability Exploitability eXchange）などで確認します。情報処理安全確保支援士試験においても、令和7年度春期の午後問1（旧午後試験。サプライチェーンセキュリティ）で、脆弱性管理におけるSBOM利用の利点が問われています。

米国では大統領令14028（2021年）を受けて、OMB覚書M-22-18（2022年）が政府調達ソフトウェアに安全な開発手法の自己証明（アテステーション）を求め、SBOMについては各省庁がソフトウェアの重要度などに応じて求められるとしました。2026年1月のOMB覚書M-26-05は、このM-22-18と関連覚書M-23-16を撤回し、各省庁がリスクに応じて独自の要件を定める方針に改めました。SBOMについては、各省庁が契約条件として、求めに応じた最新SBOMの提出を求められると明記されています。日本では経済産業省が「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公表しており（2024年8月にVer2.0へ改訂）、脆弱性管理の具体的な手法が示されています。

脆弱性を塞ぐ「パッチ管理」の実践プロセス

資産管理によって「守るべき対象」が明確になったら、次はその対象を「最新かつ安全な状態」に保つ必要があります。これがパッチ管理です。パッチ（修正プログラム）の適用は、脆弱性対策の基本中の基本ですが、実務では「ただ適用すれば良い」という単純なものではありません。

ステップ1：脆弱性情報の収集と影響範囲の特定

パッチ管理の第一歩は、情報の収集です。世の中には日々膨大な数の脆弱性が報告されており、その全てに即座に対応することは不可能です。自社の環境に関係のある情報を効率よく収集し、対応の優先順位を決める必要があります。

主要な情報源

• JVN (Japan Vulnerability Notes): JPCERT/CCとIPAが共同で運営する日本の脆弱性対策情報ポータルサイト。日本語で情報が得られるため、まずはここを確認するのが基本
• ベンダーの公式サイト: Microsoft、Adobe、Cisco、Oracleなど、利用している製品のベンダーが発信するセキュリティアドバイザリ
• NVD (National Vulnerability Database): 米国NISTが運営する脆弱性データベース。CVE（共通脆弱性識別子）ベースで網羅的な情報が得られる
• CISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）: 旧US-CERTの情報発信を引き継いだ米国の政府機関（US-CERTのブランドは2023年2月に廃止）。実際に悪用が確認された脆弱性の一覧「KEV（Known Exploited Vulnerabilities）カタログ」も公開
• セキュリティベンダーのブログ: トレンドマイクロ、シマンテック、カスペルスキーなどが発信する脅威分析

影響範囲の特定プロセス

これらの情報源から得た情報と資産管理台帳を突き合わせ、自社で影響を受ける資産を洗い出します（資産台帳との照合による影響範囲の特定）。以下は、実在の脆弱性CVE-2021-42013（Apache HTTP Server 2.4.49と2.4.50のみが対象のパストラバーサル）を例にした照合イメージです。

【脆弱性情報】
CVE-2021-42013: Apache HTTP Server 2.4.49 / 2.4.50 にパストラバーサルの脆弱性

【資産台帳との照合】
→ サーバーA: Apache 2.4.50 → 影響あり（要対応）
→ サーバーB: IIS 10.0 → 影響なし
→ サーバーC: Apache 2.4.51 → 影響なし（修正済みバージョン）

なお「影響あり」と判定した資産も、該当するモジュールや設定を使っているかによって実際の危険度が変わるため、ベンダーの公表情報で条件を確認します。

このスクリーニング作業により、対応が必要な資産を正確に特定できます。ここで資産管理台帳の精度が低いと、影響有無の判断に時間がかかり、脆弱性が攻撃にさらされたままの期間が長引いてしまいます。

ステップ2：CVSS による深刻度評価と優先順位付け

適用すべきパッチが特定できたら、次はその緊急度を判断します。すべてのパッチを「今すぐ」適用できれば理想的ですが、稼働中のシステムを止める調整や検証作業のリソースは有限です。

CVSS（Common Vulnerability Scoring System）の活用

CVSSは脆弱性の深刻度を0.0から10.0のスコアで定量的に評価する仕組みです。現在広く使われているCVSS v3.1では、以下の3つの基準で評価されます（2023年11月公開のCVSS v4.0では、現状評価基準が「脅威評価基準（Threat Metrics）」に再編され、補足評価基準（Supplemental Metrics）が追加されています）。

1. 基本評価基準（Base Metrics）（以下はCVSS v3.1の評価項目）

脆弱性そのものの特性を評価。時間の経過や環境によって変化しない普遍的な値です。

• 攻撃元区分（Attack Vector）: ネットワーク経由（N）、隣接ネットワーク（A）、ローカル（L）、物理アクセス（P）
• 攻撃条件の複雑さ（Attack Complexity）: 低（L）、高（H）
• 必要な特権レベル（Privileges Required）: 不要（N）、低（L）、高（H）
• ユーザ関与レベル（User Interaction）: 不要（N）、要（R）
• スコープ（Scope）: 変更なし（U）、変更あり（C）
• 機密性への影響（Confidentiality Impact）: なし（N）、低（L）、高（H）
• 完全性への影響（Integrity Impact）: なし（N）、低（L）、高（H）
• 可用性への影響（Availability Impact）: なし（N）、低（L）、高（H）

2. 現状評価基準（Temporal Metrics）

時間の経過とともに変化する基準です。

• 攻撃される可能性（Exploit Code Maturity）: 未実証（U）、実証可能（P）、攻撃可能（F）、容易に攻撃可能（H）
• 利用可能な対策のレベル（Remediation Level）: 正式（O）、暫定（T）、非公式（W）、なし（U）
• 脆弱性情報の信頼性（Report Confidence）: 未確認（U）、未確証（R）、確認済（C）

※いずれも「未評価（X）」も選択できます。

3. 環境評価基準（Environmental Metrics）

利用者の環境に依存する基準です。そのサーバーがインターネットに公開されているか、重要な個人情報を扱っているかなど、組織ごとの事情を加味します。

実務での優先順位付け

ここで注意したいのは、CVSSが表すのは脆弱性の「深刻度」であって、自社にとっての「リスク」そのものではないという点です。同じCVSS 9.8の脆弱性でも、インターネットに公開されたサーバーと閉域網の検証機とでは、取るべき対応の速さが違います。そこで実務では、CVSSに加えて次の情報を組み合わせて優先順位を決めます。

• KEVカタログ掲載の有無：CISAが「実際に悪用が確認された」と判断した脆弱性です。掲載されていれば、自社に該当する製品・バージョンがあり、攻撃者が到達できる状態かを確認したうえで、強い優先要因として扱います
• EPSS（Exploit Prediction Scoring System）：FIRSTが公開している指標で、公開済みのCVEが今後30日以内に悪用される確率を推定した値（0〜1）です。CVSSの現状評価基準のように攻撃コードの公開状況を自分で調べなくても、毎日更新される値をそのまま参照できます（CVSSとは別の指標で、併用して判断します）
• 資産の重要度と露出度：インターネット公開の有無、扱うデータの重要度など（CVSSの環境評価基準に相当）

以下は優先度区分の一例です。前提として、資産台帳との照合で自社に該当する資産があることを確認済みの脆弱性に適用します。まず例外を確認し、次に「脆弱な機能へどこから到達できるか」で分け、悪用実績（KEV）や深刻度・悪用予測（CVSS・EPSS）で上下を決めます。重要な業務データを扱うシステムや停止の影響が大きいシステムは1段階引き上げる、といった調整を加え、具体的な閾値は組織のリスク基準に合わせて決めます。

【先に確認する例外】
- 自社環境で悪用を確認した、または侵害済みの端末から悪用できる
  KEV掲載の脆弱性（ローカル権限昇格など）は、
  到達経路がローカルでも高優先以上を検討する

【最優先（Critical）】の例：インターネットから脆弱な機能へ到達できる
- KEV掲載（悪用確認済み）
- KEV未掲載だが、CVSS 9.0以上かつEPSS値が高い

【高優先（High）】の例
- インターネットから到達できるが、最優先の条件には当たらない
- KEV掲載だが、到達経路は社内ネットワークに限られる

【中優先（Medium）】の例
- KEV未掲載で、到達経路は社内ネットワークに限られる
- 端末上でのコード実行などが必要だが、例外にも低優先の条件にも当たらない

【低優先（Low）】の例：次のすべてに当てはまる
- 悪用の実績がなく、影響も限定的
- 物理アクセスや端末上でのコード実行などが必要で、
  そのアクセス自体が十分に制限されている（緩和策で経路を断った場合を含む）

隣接ネットワーク（BluetoothやWi-Fiなど同じネットワーク内の攻撃者）からの攻撃や、利用者が悪意のある文書を開くことで成立する攻撃は、この表に当てはめず、利用状況や悪用実績を踏まえて個別に評価します。この表の条件に当てはまらない場合も、到達可能性・悪用実績・影響を踏まえて個別に評価します。

情報処理安全確保支援士試験では、この優先順位付けの根拠を説明できることが重要です。「なぜこのパッチを先に適用するのか」を、CVSSの各指標、悪用実績（KEV）と悪用可能性の予測（EPSS）、システムの重要度から論理的に導き出せるようにしましょう。

ステップ3：検証環境でのテストと互換性確認

「緊急の脆弱性だから」といって、検証なしで本番環境のサーバーにいきなりパッチを適用するのは大きなリスクを伴います。パッチによっては、業務アプリケーションとの相性が悪く、動作しなくなったり、システム全体のパフォーマンスが低下したりする「副作用（リグレッション）」が発生することがあります。

そのため原則は検証を経てから適用します。ただし、すでに悪用が確認されている脆弱性のように一刻を争う場合は、検証範囲を主要機能に絞って短時間で済ませる、パッチ適用までの間は後述の緩和策を先に講じるなど、「攻撃されるリスク」と「副作用で業務が止まるリスク」を比較して判断します。

検証環境（ステージング環境）でのテスト項目

本番環境と同一（または極めて近い）構成の検証環境で、以下のテストを実施します。

1. インストールの成功確認
   • パッチが正常に適用できるか
   • エラーログが出力されていないか
   • 適用時間の測定（本番適用時の参考）
2. システムの再起動確認
   • OSやミドルウェアが正常に再起動するか
   • 自動起動サービスがすべて起動しているか
   • 起動時間が異常に長くなっていないか
3. 業務アプリケーションの動作確認
   • 主要機能が正しく動作するか
   • データの読み書きに問題がないか
   • 帳票出力などのバッチ処理が正常に完了するか
   • ユーザーインターフェースの表示崩れがないか
4. 性能テスト
   • レスポンスタイムの悪化がないか
   • CPU・メモリ使用率に異常な上昇がないか
5. 連携システムへの影響確認
   • 他システムとのAPI連携が正常に動作するか
   • ファイル転送などの定期バッチが正常に動作するか

記述式で押さえたい失敗パターン

試験の記述式問題では、「パッチ適用後にシステム障害が発生した」というトラブル事例が出題されることがあります。この場合に解答の軸となるアクションや予防策は以下の通りです。

• 適用前に検証環境で動作確認を行うこと
• バックアップを取得し、すぐに切り戻し（ロールバック）ができる手順を確立しておくこと
• 適用作業手順書を作成し、作業者間でレビューすること
• 本番適用時は、問題発生時に即座に対応できる体制（待機要員の確保）を整えること

ステップ4：適用計画の策定と実施

検証が完了したら、本番環境への適用計画を立てます。

適用タイミングの考慮事項

• 業務への影響最小化: 深夜や休日など、システム利用が少ない時間帯を選択
• メンテナンス窓の確保: 関係部門と調整し、システム停止時間を事前通知
• 季節要因: 決算期や繁忙期を避ける
• 段階的適用: すべてのサーバーに一斉適用せず、段階的に展開

高可用性システムの適用戦略

24時間365日稼働が求められるシステムでは、以下の手法を用います。

1. ローリングアップデート
   • 二重化したサーバーの片方ずつに適用
   • ロードバランサーで切り替えながら無停止で更新
2. ブルー/グリーンデプロイメント
   • 新環境（グリーン）を構築し、パッチ適用後に切り替え
   • データの整合性と後方互換性（データベースのスキーマ変更など）を確保しておけば、問題時に旧環境（ブルー）へ迅速に切り戻せる
3. カナリアリリース
   • 一部のユーザーにのみ新バージョンを提供
   • 問題がなければ段階的に拡大

ステップ5：適用後の確認と継続監視

パッチ適用後も油断は禁物です。以下の確認作業を実施します。

即時確認

• システムログの確認（エラーの有無）
• 監視ツールのアラート確認
• 主要機能の疎通確認
• パッチバージョンの確認（正しく適用されているか）

継続監視

• 翌営業日の業務開始後の動作確認
• ユーザーからの問い合わせ状況の監視
• 性能メトリクスの継続観測（CPU、メモリ、ディスクI/O）

資産台帳の更新

パッチ適用が完了したら、必ず資産管理台帳を更新します。

サーバーA
OS: Windows Server 2022
最新パッチレベル: 2024-02セキュリティ更新プログラム
最終適用日: 2024-02-15
次回適用予定: 2024-03月度パッチ（2024-03-12予定）

この記録により、次回のパッチ適用時に「どのサーバーが未適用か」を即座に把握できます。

パッチ適用不可時の「緩和策」という選択肢

現実の運用現場では、様々な事情でパッチを即座に適用できないケースがあります。

パッチ適用が困難な典型的ケース

• 業務アプリが古く、最新のOSパッチを適用すると動かなくなる
• 24時間365日稼働が求められるシステムで、再起動のメンテナンス窓が取れない
• メーカーのサポートが終了した（EOS: End of Support）レガシーシステムを使わざるを得ない
• 医療機器や制御システムなど、ベンダー認証が必要で独自にパッチ適用できない

このような場合、「パッチを適用しない」という選択肢を取るのではなく、回避策（Workaround）や緩和策（Mitigation）を講じることでリスクを低減する必要があります。情報処理安全確保支援士試験では、この代替案を提示できるかどうかが問われます。

緩和策1：ネットワークレベルでの防御

パッチが適用できないサーバーを守る代表的な方法は、ネットワーク的な隔離やフィルタリングです。

WAF（Web Application Firewall）による仮想パッチ

Webアプリケーションに脆弱性がある場合、WAFで攻撃パターン（SQLインジェクションやXSSのシグネチャ）を検知・遮断することで、アプリ自体を修正できなくても攻撃を防ぐことができます。これは「仮想パッチ（Virtual Patching）」とも呼ばれます。

【通常のパッチ適用】
脆弱なアプリ → パッチ適用 → 脆弱性解消

【仮想パッチ】
脆弱なアプリ → そのまま
          ↓
       WAFで防御 → 攻撃遮断

IPS（Intrusion Prevention System）の設置

ネットワーク経由のエクスプロイト攻撃をIPSでブロックします。特定の脆弱性を狙った攻撃パターンをシグネチャとして登録し、該当する通信を自動的に遮断します。

ネットワークセグメントの分離

脆弱なシステムをインターネットから直接アクセスできない内部ネットワークの深い場所に配置し、アクセスできる端末を厳しく制限します。

【分離前】
インターネット → 脆弱なサーバー（直接攻撃される）

【分離後】
インターネット ✕（到達不可）→ 脆弱なサーバー

特定の管理端末 → 内部FW → 限定セグメント → 脆弱なサーバー
（内部FWで送信元を限定し、許可した端末だけが到達できる）

ファイアウォールルールの厳格化

不要なポートを閉じ、必要最小限の通信のみを許可します。

• 送信元IPアドレスの制限（ホワイトリスト方式）
• アクセス可能な時間帯の制限
• 許可するプロトコルの限定

緩和策2：機能の無効化による攻撃面の削減

脆弱性が特定の機能やポートに依存している場合、その機能を無効化することでリスクを回避できることがあります。

具体例：WannaCry対策

2017年に世界中で猛威を振るったランサムウェア「WannaCry」は、WindowsのSMBv1の脆弱性（CVE-2017-0144 等、MS17-010 で修正）を悪用しました。この際、パッチ適用までの間、暫定的にSMBv1自体を無効化するという対策が有効でした。

# SMBv1の無効化（クライアント版Windowsの例。管理者権限のPowerShellで実行し、再起動が必要）
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

アタックサーフェスの削減

不要なサービスを停止することは、攻撃面（アタックサーフェス）を減らす基本動作です。

• 使用していないネットワークサービスの停止
• デフォルトで有効になっている管理機能の無効化
• 不要なアカウントの削除
• デフォルトパスワードの変更

緩和策3：アクセス制御の強化

脆弱性が存在しても、そこにたどり着けなければ攻撃は成立しません。

多要素認証（MFA）の導入

多要素認証を追加すると、パスワードが漏洩しても、それだけでは不正ログインされにくくなります（認証処理そのものをバイパスされる脆弱性には効果がない点に注意）。

最小権限の原則（Principle of Least Privilege）

脆弱性を悪用されても、権限が限定されていれば被害を最小化できます。

• 管理者権限での常時作業を避ける
• サービスアカウントに必要最小限の権限のみ付与
• ファイルやディレクトリのアクセス権限を厳格に設定

緩和策4：監視と早期検知の強化

攻撃を防げなくても、早期に検知して対応すれば被害を限定できます。

ログ監視の強化

• 脆弱性を狙った攻撃の兆候（異常なアクセスパターン、エラーログの急増）を監視
• SIEM（Security Information and Event Management）による相関分析
• 異常検知時の自動アラート

定期的な脆弱性スキャン

• パッチ未適用の状態が継続していることを定期確認
• 新たな攻撃手法の出現を監視

効率化を実現する管理ツールとベストプラクティス

管理対象の台数や構成の変更頻度が増えるほど、手動でのパッチ管理や資産管理は難しくなります。既存の基盤が備える管理機能や、専用の管理ツール・自動化ツールを活用して、収集・配布・確認の手間を減らすことが重要です。

資産管理ツール（ITAM・SAMを支えるツール）

ITAM（IT Asset Management：IT資産管理）やSAM（Software Asset Management：ソフトウェア資産管理）は、資産を把握し続ける管理活動そのものの名称です。資産管理台帳はその活動で維持する記録であり、資産管理ツールは台帳の情報収集・更新を自動化する道具という関係です。

代表的な製品

• SKYSEA Client View
• LANSCOPE
• JP1/IT Desktop Management
• Microsoft Intune（旧Microsoft Endpoint Manager。2022年に名称をIntuneへ統一）
• Jamf（Mac環境）

主要機能

1. 自動資産情報収集
   • エージェント型: 各端末にソフトウェアを導入し、情報を自動収集
   • エージェントレス型: ネットワークスキャンやActive Directory連携で情報取得
2. ソフトウェア配布
   • 承認済みソフトウェアの一斉配布
   • アンインストールの強制実行
3. セキュリティポリシーの強制適用
   • USBメモリの使用制限
   • スクリーンロックの強制
   • パスワードポリシーの適用
4. 操作ログの取得と分析
   • ファイル操作履歴
   • Webアクセス履歴
   • アプリケーション使用履歴
5. 禁止ソフトウェアの制御
   • ブラックリスト方式: 禁止アプリの起動ブロック
   • ホワイトリスト方式: 許可されたアプリのみ起動可能

パッチ管理ツール

WSUS（Windows Server Update Services）

Windows環境が多い組織で標準的に利用されてきたのがWSUSです。これは、Microsoft Updateのサーバーを社内に構築するようなものです。なお、Microsoftは2024年9月にWSUSを非推奨（新機能の追加を終了）と発表しました。既存機能は引き続きサポートされますが、クライアントはWindows Autopatch／Microsoft Intune、サーバーはAzure Update Managerといったクラウド型の管理への移行が推奨されています。

WSUSの利点

1. 段階的な展開制御
   • 公開された更新プログラムの中から、自社で検証済みのものだけを承認
   • グループ分けして段階的に配信（検証グループ → 一般グループ）
2. ネットワーク負荷の軽減
   • 各PCが一斉にインターネットへパッチを取りに行くと回線がパンク
   • WSUSがあれば社内LAN経由で配信できるため、帯域を節約
3. 適用状況の可視化
   • どの端末にどのパッチが適用されているかを一元管理
   • 未適用端末の洗い出しが容易
4. 自動承認ルールの設定
   • 定義ファイル更新など、安全性が高いものは自動承認
   • セキュリティ更新プログラムは手動レビュー後に承認

Linux/Unix環境のパッチ管理

• yum/dnf（Red Hat系）: リポジトリからの自動更新設定
• apt/apt-get（Debian系）: unattended-upgradesによる自動更新
• Ansible/Chef/Puppet: 構成管理ツールによる一元管理

脆弱性スキャナーの活用

パッチ適用の漏れや設定ミスを検出するため、定期的な脆弱性スキャンが重要です。

主要なスキャナー

• Nessus
• OpenVAS
• Qualys
• Rapid7 Nexpose

スキャン項目

• パッチ未適用の脆弱性
• 設定不備（デフォルトパスワード、不要なサービスの起動）
• 証明書の有効期限切れ
• エンドオブライフ（EOL）に達したソフトウェアの使用

情報処理安全確保支援士試験必須知識：用語と概念の完全整理

情報処理安全確保支援士試験合格に向けて、パッチ管理と資産管理に関連する重要用語と概念を整理します。これらのキーワードが出たら、即座に意味と関連技術が思い浮かぶようにしておきましょう。

CVE・CPE・CVSSの三位一体

この3つの英字略語はセットで覚える必要があります。

CVE (Common Vulnerabilities and Exposures)

「共通脆弱性識別子」。脆弱性そのものに付けられたユニークなIDです。

• 形式: CVE-[年]-[連番]
• 例: CVE-2023-12345
• 世界中で同じIDが使われるため、情報共有と特定に不可欠
• CVEプログラムは米MITREが運営（米CISAが支援）し、IDの採番はMITREや、JPCERT/CC・主要ベンダーなどのCNA（CVE採番機関）が行う

CPE (Common Platform Enumeration)

「共通プラットフォーム一覧」。ハードウェア、OS、アプリケーションなどのIT資産を識別するための統一された名称記述ルールです。

• 形式: cpe:2.3:a:ベンダー名:製品名:バージョン:...
• 例: cpe:2.3:a:microsoft:internet_explorer:11.0:::::::*
• 資産管理ツールがCPE形式で資産情報を持ち、脆弱性データベースのCPE情報と突合することで、自動的なマッチングが可能

CVSS (Common Vulnerability Scoring System)

前述の通り、脆弱性の「深刻度」をスコアリングする仕組みです。

• 最新版はCVSS v4.0（2023年11月公開）。ただし脆弱性データベースや製品ベンダーの公表では、現在もCVSS v3.1のスコアが広く併用されている
• CVSS v3.1は基本評価基準、現状評価基準、環境評価基準の3層構造（v4.0は基本・脅威・環境・補足の4種類）
• 0.0～10.0のスコア（深刻度レベル: None, Low, Medium, High, Critical）

押さえておきたい関連知識

IPAが提供する「MyJVNバージョンチェッカ」は、PCにインストールされたソフトウェアが最新バージョンかどうかを確認するツールです。MyJVNでは製品の識別子にCPE名を使うことで、製品とJVN iPediaの脆弱性対策情報（CVE等）との紐づけを可能にしています。資産（CPE）と脆弱性（CVE）を共通の識別子でつなぐ、という考え方を押さえておきましょう。

構成管理（Configuration Management）とベースライン

ITIL（ITサービスマネジメントのベストプラクティス集）の文脈では、資産管理は「構成管理」の一部、あるいは密接に関連するものとして扱われます。

構成管理の範囲

• 何があるか（資産の網羅）
• 各資産がどのように関係しているか（依存関係）
• 現在の設定状態が、承認された基準（ベースライン）と一致しているか

構成ベースライン

特定の時点で正式にレビュー・承認された構成の基準点です。以後の変更は変更管理の手続を通して行い、承認されれば新しいベースラインになります。運用中は、現在の設定値をこのベースラインと比較して逸脱がないかを確認します。

【Webサーバーのベースライン例】
- OS: Rocky Linux 9系（サポート中の最新マイナーリリース）
- Apache: 配布元のセキュリティ更新を適用済みのhttpdパッケージ（パッケージ版数を記録）
- SSL/TLS: TLS 1.2以上のみ許可
- 不要なモジュール: mod_status, mod_info を無効化
- ファイアウォール: 80, 443番ポートのみ開放
- SELinux: Enforcing モード

構成ドリフト（Configuration Drift）

ベースラインからの逸脱のことです。意図しない設定変更は、以下の可能性があります。

• 内部不正による改ざん
• マルウェアによる設定変更
• 操作ミス
• 管理者の無断作業

これを早期に発見し、正常な状態に戻すプロセスも、広義のパッチ管理・資産管理に含まれます。

試験での重要性

「設定ファイルの改ざんを検知するための仕組み」を問われたら、以下を軸に考えましょう。

• ファイル整合性監視（FIM: File Integrity Monitoring）
• 定期的なベースラインとの差分確認
• 構成管理データベース（CMDB）の活用

ゼロデイ攻撃とN-day攻撃

ゼロデイ攻撃（Zero-Day Attack）

修正プログラム（パッチ）が提供される前に、その脆弱性を悪用する攻撃です。開発者が対策に使える日数が「0日」であることに由来します。

• 対策: パッチがないため、緩和策（前述のネットワーク分離、WAFなど）で対応
• 検知: 異常な通信パターンの監視、振る舞い検知

N-day攻撃（N-Day Attack）

パッチが公開されてから数日後（N日後）に行われる攻撃です。パッチが存在するにも関わらず、未適用のシステムを狙います。

• 現実のインシデントでも、パッチが提供済みなのに未適用だった既知の脆弱性を突かれるケースが数多く報告されている
• 対策: 迅速なパッチ適用プロセスの確立

パッチの種類と優先度

セキュリティパッチ（Security Update）

脆弱性を修正するための更新プログラム。最優先で適用すべきものです。

累積パッチ（Cumulative Update）

過去の複数のパッチをまとめたもの。Windowsでは月例の「品質更新プログラム」がこれに該当します。

機能更新プログラム（Feature Update）

新機能の追加や大規模な変更を含む更新。Windowsの大型アップデート（Windows 11では年1回。Windows 10も当初の年2回から2021年以降は年1回に変更。なお、Windows 10の通常チャネル（22H2など）は2025年10月14日にサポートが終了。LTSC版は別のライフサイクルで管理される）など。セキュリティパッチに比べて慎重な検証が必要です。

ホットフィックス（Hotfix）

緊急性の高い個別の修正プログラム。通常の更新サイクルを待たずに提供されます。

ファームウェアアップデート

ハードウェアの制御ソフトウェア（ファームウェア）の更新。ルーター、スイッチ、ストレージ機器などが対象です。

EOL（End of Life）とサポートライフサイクル

EOL（End of Life）/ EOS（End of Support）

製品のサポートが終了した状態です。サポート終了後は、ESU（拡張セキュリティ更新プログラム）などの対象を除き、脆弱性が発見されても通常は修正プログラムが提供されません。

典型的な問題

• Windows 10の通常チャネル（2025年10月14日サポート終了）を、ESU（拡張セキュリティ更新プログラム）を利用しないまま使い続けている（LTSC版は製品ごとに終了日が異なる）
• Windows Server 2008（2020年サポート終了）を使い続けている
• Windows 10の通常チャネル上のInternet Explorer 11デスクトップアプリ（2022年6月15日サポート終了）に依存した社内アプリを使い続けている
• 古いJavaランタイムに依存したシステム

情報処理安全確保支援士試験での対応策

1. 移行計画の策定: サポート終了前に新バージョンへの移行を計画
2. 拡張セキュリティ更新の利用: Microsoftの場合、対象製品では拡張セキュリティ更新プログラム（ESU）を利用できる。ESUはセキュリティ更新の提供を延長するもので、技術サポート全般の延長ではない。費用や条件は製品や利用形態によって異なる
3. 緩和策の実施: 前述のネットワーク分離、仮想パッチなど
4. リスクの可視化: 経営層に報告し、予算確保と意思決定を促す

SC試験での出題パターンと対策

パッチ管理・資産管理の分野は、科目A-2（旧午前II）ではCVSSやSBOMの用語の理解として、科目B（旧午後）では脆弱性管理の手順や優先度判断を記述させる事例問題として問われます。ここでは、IPAの公開問題で確認できる過去問を整理します。

科目A-2（旧午前II）の過去問で確認する

過去問で確認：CVSS v3の基本評価基準

平成30年度春期 情報処理安全確保支援士試験 午前II 問1は、CVSS v3の基本評価基準の説明を選ぶ問題で、正解は（ア）です。正解の選択肢は、機密性への影響、攻撃元区分、必要な特権レベルなど「脆弱性そのものの特性を評価する」という内容でした。誤答の（イ）は「攻撃される可能性，利用可能な対策のレベル，脆弱性情報の信頼性」を評価するという内容で、本文で説明した現状評価基準にあたります。各基準にどの評価項目が属するかを覚えておくと、こうした入れ替えに引っかかりません。

過去問で確認：3つの基準で評価する仕組み

令和元年度秋期 午前II 問9は、基本評価基準・現状評価基準・環境評価基準の三つの基準で情報システムの脆弱性の深刻度を評価するものを選ぶ問題で、正解は（ア）のCVSSです（他の選択肢はISMS、PCI DSS、PMS）。3つの基準名を見てCVSSと結びつけられれば即答できる基礎問題です。あわせて、本文で整理したCVE（脆弱性のID）、CPE（製品の識別名）、CVSS（深刻度のスコア）の違いも押さえておきましょう。

過去問で確認：SBOMの説明

令和6年度春期 午前II 問17は、SBOMの説明を選ぶ問題で、正解は（ウ）「ソフトウェアを構成するコンポーネント，互いの依存関係などのリスト」です。誤答の（ア）はCVSS、（エ）はCWE（共通脆弱性タイプ一覧）の説明にあたります。本文で紹介した「ソフトウェアの部品表」というイメージを持っていれば迷わず選べます。

科目B（旧午後）の過去問で確認する

令和7年度春期 午後 問1：SBOM利用の利点

サプライチェーンセキュリティを題材にした問題で、設問4では脆弱性管理におけるSBOM利用の利点が問われました。IPAの解答例の趣旨は「利用しているソフトウェアやそのバージョンが明確になり、脆弱性の影響有無を容易に把握できる」というものです。採点講評では「SBOMの定義を記載しただけの解答が散見された」と指摘されています。SBOMとは何かではなく、SBOMを使うと脆弱性対応の何が楽になるのか（影響範囲の特定）まで書くことが求められています。

令和7年度春期 午後 問2：深刻度と対応優先度

脆弱性管理を題材に、脆弱性の深刻度レベルと対応優先度が問われました。設問4(1)ではCVSSv3の評価指標のうちAC（Attack Complexity：攻撃条件の複雑さ）が問われ、採点講評では機密性への影響（C）と取り違えた解答が多かったと指摘されています。設問5(1)では、CVSSv3の現状値とEPSS値を比較し、運用上の手間の違いを説明させる設問が出ています。現状値は攻撃コードの公開状況などを自分で調べて判断する必要があるのに対し、EPSS値は公開されている値を参照できる、という違いを押さえておきましょう。

記述式で得点するための考え方

• 「何か」を聞かれたら定義、「何に役立つか」を聞かれたら運用上の効果を書く（SBOMの設問の教訓）
• 優先度の根拠は、CVSSの指標名と、悪用実績（KEV）・悪用可能性の予測（EPSS）・資産の重要度を組み合わせて説明する
• パッチを当てられない状況なら、緩和策（遮断・無効化・アクセス制限・監視）と中長期の移行計画をセットで書く

記述式で問われやすいシナリオ例

情報処理安全確保支援士試験の科目B（旧午後）の記述式問題では、架空の企業を舞台に、セキュリティインシデントや改善提案を問う問題が出題されます。パッチ管理・資産管理を題材にした典型的なシナリオを、過去問ではなく練習用の例として整理しておきます。

パターン1：管理外資産による侵入

シナリオ例

「社内ネットワークに何者かが不正にサーバーを設置し、それが踏み台となって情報漏洩が発生した。このサーバーは資産台帳に記録されておらず、セキュリティパッチも未適用であった。」

問われる内容

• なぜこのような事態が発生したか（原因分析）
• 今後同様の事態を防ぐための対策（予防策）
• 不正なサーバーを検知する仕組み（技術的対策）

模範解答の要素

• 原因: 資産管理プロセスの不備、ネットワーク接続時の認証不在
• 予防策: 資産台帳への登録ルールの徹底、定期的な資産棚卸の実施
• 技術的対策: NAC（Network Access Control）による未登録機器の検疫、ネットワークスキャンによる定期的な資産検出

パターン2：パッチ適用遅延による被害

シナリオ例

「社内のWebサーバーがランサムウェアに感染し、業務が停止した。調査の結果、3ヶ月前に公開されていたセキュリティパッチが未適用であったことが判明した。」

問われる内容

• パッチ適用が遅れた原因
• 適切なパッチ管理プロセス
• 緊急時の対応手順

模範解答の要素

• 原因: パッチ情報の収集体制の不備、適用優先順位の判断基準がない、検証プロセスが整備されていない
• 適切なプロセス: 脆弱性情報の定期収集、CVSS評価による優先順位付け、検証環境でのテスト、計画的な本番適用
• 緊急時対応: インシデント対応手順書の整備、バックアップからの復旧手順、代替システムの準備

パターン3：パッチ適用による業務停止

シナリオ例

「セキュリティパッチを本番環境に適用したところ、業務アプリケーションが起動しなくなり、業務が停止した。」

問われる内容

• 事前に実施すべきだった対策
• 障害発生時の対応手順
• 今後の改善策

模範解答の要素

• 事前対策: 検証環境での互換性テスト、バックアップの取得、切り戻し手順の準備、適用作業手順書の作成
• 障害対応: 速やかなロールバック、影響範囲の特定、ユーザーへの通知
• 改善策: 検証プロセスの徹底、段階的適用（一部サーバーで先行適用）、メンテナンス時間の適切な設定

パターン4：レガシーシステムの脆弱性

シナリオ例

「製造ラインを制御する20年前のシステムに脆弱性が発見されたが、メーカーのサポートは既に終了しており、パッチも提供されない。システムを停止すると生産が止まるため、簡単には更新できない。」

問われる内容

• パッチ適用以外の緩和策
• リスクの評価方法
• 中長期的な対応策

模範解答の要素

• 緩和策: ネットワークの物理的分離、ファイアウォールによるアクセス制限、IPSの導入（Webインタフェースを持つ場合はWAFも）、監視の強化
• リスク評価: 脆弱性の深刻度（CVSS）、攻撃の容易性、業務への影響度、攻撃を受けた場合の損失額
• 中長期対策: システム更新計画の策定と予算確保、代替製品の調査、段階的な移行計画

【演習】脆弱性対応・資産管理 理解度チェック（全10問）

「既知の脆弱性」への対応遅れは、実際の被害事例で繰り返し報告されていると同時に、情報処理安全確保支援士試験でも繰り返し題材になるポイントです。CVEやCVSS、SBOMといったキーワードを理解しているつもりでも、いざ問題として問われると迷ってしまうことはありませんか？ 以下の練習問題は、記事で学んだ「資産の把握」から「パッチ適用」「緩和策の検討」までの流れを再確認するために作成しました。解説を読み込み、記述式試験で迷わず回答できる「運用力」を養いましょう。

まとめ：地道な運用こそがセキュリティの要

パッチ管理と資産管理は、派手なハッキング対策技術に比べると、事務的で退屈な作業に思えるかもしれません。しかし、実際のセキュリティインシデントの現場では、「管理されていないサーバーが踏み台にされた」「1年前に公開されたパッチが当たっていなかった」という初歩的なミスが原因となるケースが少なくありません。

セキュリティの世界には「銀の弾丸（Silver Bullet）」は存在しません。どんなに高度なAI脅威検知システムを導入しても、基本的な資産管理とパッチ管理がおろそかでは、城壁に大きな穴が開いた状態です。

情報処理安全確保支援士試験合格のための重要ポイント再確認

資産管理の本質

• 資産を把握していないと適切に守れない（資産管理の網羅性が全ての前提）
• ハードウェアとソフトウェアの紐づけによる影響範囲の即座の特定
• シャドーITの排除と検出（技術的対策と組織的対策の両輪）
• SBOMによる細粒度管理（サプライチェーンセキュリティの要）

パッチ管理の原則

• 脆弱性情報は選別と優先順位付けが命（リスクベースアプローチ）
• CVSS評価による客観的な深刻度判断
• パッチ適用はテストとセット（可用性の確保）
• パッチがダメなら緩和策（多層防御の思想）

記述式試験での回答のコツ

1. プロセスの流れを意識する: 「情報収集 → 評価 → 検証 → 適用 → 確認」という一連の流れを説明できるように
2. 根拠を明確にする: 「なぜその対策が必要か」を、リスクやCVSSスコアなどの客観的指標で説明
3. 実務的な制約を考慮する: 理想論だけでなく、「業務を止められない場合の代替案」など現実的な解を提示
4. 多層防御の視点: 単一の対策だけでなく、複数の対策を組み合わせる発想

継続的改善のサイクル

パッチ管理と資産管理は、一度整備したら終わりではありません。以下のPDCAサイクルを回し続けることが重要です。

Plan（計画）

• 資産管理台帳のメンテナンス計画
• パッチ適用スケジュールの策定
• リスク評価基準の見直し

Do（実行）

• 定期的な資産棚卸
• パッチの検証と適用
• 脆弱性スキャンの実施

Check（確認）

• 適用状況の確認
• 未適用資産の洗い出し
• インシデント分析

Act（改善）

• プロセスの見直し
• ツールの導入・更新
• 教育訓練の実施

対策の有効性を測定し、その結果を次の改善に反映し続けることで、継続的なリスク低減を目指せます。

最後に

情報処理安全確保支援士として求められるのは、最新の攻撃手法や防御技術の知識だけではありません。地道な運用をいかに論理的に、システマチックに行えるかという実務能力こそが真価です。

情報処理安全確保支援士試験の科目B（旧午後）では、この「泥臭い運用」を題材にした問題が出題されています。本記事で解説した以下の原則を心に刻み、記述式試験で「どのような手順で対応すべきか」を問われた際に、具体的なプロセスを回答できるように準備しておいてください。

• 守るべき資産を正確に把握する
• 脆弱性情報を効率的に収集し、優先順位をつける
• 検証を経て計画的にパッチを適用する
• パッチが適用できない場合は緩和策で対応する
• すべてのプロセスを記録し、継続的に改善する

この基礎体力こそが、セキュリティスペシャリストとしての真の実力となります。着実に理解を深め、情報処理安全確保支援士試験合格、そしてその先の実務での活躍を目指してください。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA「共通脆弱性評価システムCVSS v3概説」
• FIRST「CVSS v4.0 Specification Document」
• FIRST「Exploit Prediction Scoring System (EPSS)」
• CISA「Known Exploited Vulnerabilities Catalog」
• JVN（Japan Vulnerability Notes）
• JVN iPedia（脆弱性対策情報データベース）
• MyJVN（JVN iPedia）
• NIST「National Vulnerability Database」
• 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0」改訂の公表
• OMB「M-26-05 Adopting a Risk-based Approach to Software and Hardware Security」（2026年1月23日）
• OMB「M-22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices」（2022年9月）
• CISA「Vulnerability Exploitability eXchange (VEX) – Status Justifications」
• Apache HTTP Server 2.4 vulnerabilities
• Microsoft Learn「Internet Explorer 11 desktop app support ended for certain versions of Windows 10」
• NIST「configuration baseline」（CSRC Glossary）
• Mayer Brown「OMB Rescinds Biden-Era Software Security Memoranda」（2026年2月・解説）
• Microsoft「Windows Server Update Services (WSUS) deprecation」
• Microsoft Learn「Extended Security Updates (ESU) program for Windows 10」
• Microsoft Learn「Windows 10 Home and Pro」ライフサイクル
• Microsoft Learn「WindowsでSMBv1、SMBv2、SMBv3を検出、有効化、無効化する方法」
• IPA 平成30年度春期 情報処理安全確保支援士試験 午前II 問題・解答例
• IPA 令和元年度秋期 情報処理安全確保支援士試験 午前II 問題・解答例
• IPA 令和6年度春期 情報処理安全確保支援士試験 午前II 問題・解答例
• IPA 令和7年度春期 情報処理安全確保支援士試験 午後 問題・解答例・採点講評