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

サイバー攻撃のニュースを見るたびに、「なぜ防げなかったのか」と疑問に思うことはないでしょうか。高度な未知の攻撃（ゼロデイ攻撃）が原因であるケースもありますが、実は多くのセキュリティインシデントは、既知の脆弱性が放置されたことに起因しています。

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

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

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

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

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

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

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

情報処理安全確保支援士試験では、以下のようなシナリオが頻繁に出題されます。

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

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

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

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

管理すべき主要項目

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

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

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

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

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

管理の粒度例

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

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

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

ハードウェア、ソフトウェア、ネットワーク機器、ライセンス情報が統合された資産管理台帳の構造図

シャドーITとの戦い

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

典型的なシャドーITの例

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

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

対策の両輪アプローチ

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

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

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

SBOMが重要視される背景

近年のソフトウェア開発では、オープンソースソフトウェア（OSS）の利用が当たり前になっています。しかし、利用しているOSSに脆弱性が見つかった場合、そのOSSを組み込んでいる自社システムも影響を受けます。

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

SBOMの導入効果

アプリケーション: 社内業務システム Ver 2.0
├─ フレームワーク: Spring Boot 2.5.6
│  └─ 含まれるライブラリ: Log4j 2.14.1 ← 脆弱性あり！
├─ データベース接続: PostgreSQL JDBC 42.2.23
└─ 認証ライブラリ: OAuth2 Client 5.5.2

SBOMを導入・管理することで、特定のライブラリに脆弱性が発見された際、自社のどのシステムが影響を受けるかを即座に特定できるようになります。情報処理安全確保支援士試験においても、サプライチェーンセキュリティや開発セキュリティの分野で、このSBOMの概念が問われる可能性が高まっています。

米国では、政府調達ソフトウェアに対してSBOMの提出を義務化する動きがあり、日本でもこの流れが加速すると予想されます。

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

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

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

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

主要な情報源

JVN (Japan Vulnerability Notes): JPCERT/CCとIPAが共同で運営する日本の脆弱性対策情報ポータルサイト。日本語で情報が得られるため、まずはここを確認するのが基本
ベンダーの公式サイト: Microsoft、Adobe、Cisco、Oracleなど、利用している製品のベンダーが発信するセキュリティアドバイザリ
NVD (National Vulnerability Database): 米国NISTが運営する脆弱性データベース。CVE（共通脆弱性識別子）ベースで網羅的な情報が得られる
US-CERT: 米国のコンピュータ緊急対応チームが発信する情報
セキュリティベンダーのブログ: トレンドマイクロ、シマンテック、カスペルスキーなどが発信する脅威分析

影響範囲の特定プロセス

これらの情報源から得た情報と、資産管理台帳を突き合わせます。

【脆弱性情報】
CVE-2024-XXXX: Apache HTTP Server 2.4.50以前に深刻な脆弱性

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

このスクリーニング作業により、対応が必要な資産を正確に特定できます。ここで資産管理台帳の精度が低いと、影響有無の判断に時間がかかり、攻撃を受けるリスク期間（Time to Exploit）が長引いてしまいます。

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

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

CVSS（Common Vulnerability Scoring System）の活用

CVSSは脆弱性の深刻度を0.0から10.0のスコアで定量的に評価する仕組みです。特に以下の3つの基準で評価されます。

1. 基本評価基準（Base Metrics）

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

攻撃元区分（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）の成熟度: 理論的（U）、概念実証（P）、機能的（F）、高度（H）
対応策のレベル: 公式パッチあり（O）、暫定対応（T）、回避策（W）、未対応（U）
報告の信頼性: 未確認（U）、確認済み（C）

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

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

実務での優先順位付け

【最優先（Critical）】
- CVSSスコア 9.0以上
- 攻撃コードが既に公開されている
- インターネットに直接公開されているシステム

【高優先（High）】
- CVSSスコア 7.0～8.9
- 重要な業務データを扱うシステム
- 内部ネットワークからアクセス可能

【中優先（Medium）】
- CVSSスコア 4.0～6.9
- 限定的な影響範囲
- 攻撃には特殊な条件が必要

【低優先（Low）】
- CVSSスコア 0.1～3.9
- 物理アクセスが必要
- 理論上の脆弱性のみ

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

情報収集、優先順位付け、検証、適用、確認へと続く脆弱性管理サイクルのフローチャート

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

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

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

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

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

情報処理安全確保支援士試験頻出の失敗パターン

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

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

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

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

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

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

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

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

ローリングアップデート
- 二重化したサーバーの片方ずつに適用
- ロードバランサーで切り替えながら無停止で更新
ブルー/グリーンデプロイメント
- 新環境（グリーン）を構築し、パッチ適用後に切り替え
- 問題があれば旧環境（ブルー）に即座に戻せる
カナリアリリース
- 一部のユーザーにのみ新バージョンを提供
- 問題がなければ段階的に拡大

ステップ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でブロックします。特定の脆弱性を狙った攻撃パターンをシグネチャとして登録し、該当する通信を自動的に遮断します。

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

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

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

【分離後】
インターネット → DMZ → 内部FW → 限定セグメント → 脆弱なサーバー
                              ↑
                        特定の端末のみアクセス可

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

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

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

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

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

具体例：WannaCry対策

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

# SMBv1の無効化（Windows）
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

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

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

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

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

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

多要素認証（MFA）の導入

認証の脆弱性に対しては、多要素認証を追加することで、パスワード漏洩があっても不正アクセスを防げます。

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

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

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

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

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

ログ監視の強化

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

定期的な脆弱性スキャン

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

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

手動でのパッチ管理や資産管理は、台数が数十台を超えたあたりから限界を迎えます。数百、数千台の端末を管理する企業では、専用の統合管理ツールの導入が必須です。

資産管理ツール（ITAM/SAMツール）

代表的な製品

SKYSEA Client View
Lanscope
JP1/IT Desktop Management
Microsoft Endpoint Manager（旧Intune）
Jamf（Mac環境）

主要機能

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

パッチ管理ツール

WSUS（Windows Server Update Services）

Windows環境が多い組織で標準的に利用されるのがWSUSです。これは、Microsoft Updateのサーバーを社内に構築するようなものです。

WSUSの利点

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

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が使われるため、情報共有と特定に不可欠
MITRE社が採番を管理

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 v3.1（v4.0も策定済み）
基本評価基準、現状評価基準、環境評価基準の3層構造
0.0～10.0のスコア（深刻度レベル: None, Low, Medium, High, Critical）

試験での出題例

「JVN MyJVNバージョンチェッカ」のようなツールが題材になることがあります。これはPC内のソフトウェア情報を収集し、JVNのデータベースと照らし合わせてバージョンが古いものを警告するツールですが、その裏側ではCPEによる資産識別とCVEによる脆弱性情報の紐づけが行われています。

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

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

構成管理の範囲

何があるか（資産の網羅）
各資産がどのように関係しているか（依存関係）
現在の設定状態がどうなっているか（ベースライン）

構成ベースライン

「あるべき正しい設定状態」を定義したものです。

【Webサーバーのベースライン例】
- OS: Rocky Linux 9.1
- Apache: 2.4.54
- 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日後）に行われる攻撃です。パッチが存在するにも関わらず、未適用のシステムを狙います。

現実には、この N-day攻撃による被害が大多数
対策: 迅速なパッチ適用プロセスの確立

パッチの種類と優先度

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

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

累積パッチ（Cumulative Update）

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

機能パッチ（Feature Update）

新機能の追加や大規模な変更を含む更新。Windows 10/11の大型アップデート（年2回）など。セキュリティパッチに比べて慎重な検証が必要です。

ホットフィックス（Hotfix）

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

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

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

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

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

製品のサポートが終了した状態です。サポート終了後は、脆弱性が発見されてもパッチが提供されません。

典型的な問題

Windows Server 2008（2020年サポート終了）を使い続けている
Internet Explorer 11（2022年サポート終了）を社内アプリで使用している
古いJavaランタイムに依存したシステム

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

移行計画の策定: サポート終了前に新バージョンへの移行を計画
延長サポートの購入: Microsoftの場合、有償で延長セキュリティ更新プログラム（ESU）を提供
緩和策の実施: 前述のネットワーク分離、仮想パッチなど
リスクの可視化: 経営層に報告し、予算確保と意思決定を促す

実務運用と情報処理安全確保支援士試験の橋渡し：典型的な出題パターン

情報処理安全確保支援士試験の午後問題（記述式）では、架空の企業を舞台に、セキュリティインシデントや改善提案を問う問題が出題されます。パッチ管理・資産管理に関する典型的な出題パターンを押さえておきましょう。

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

シナリオ例

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

問われる内容

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

模範解答の要素

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

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

シナリオ例

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

問われる内容

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

模範解答の要素

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

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

シナリオ例

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

問われる内容

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

模範解答の要素

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

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

シナリオ例

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

問われる内容

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

模範解答の要素

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

午後問題の得点源にする！「脆弱性対策プロセス」徹底演習

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

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

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

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

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

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

資産管理の本質

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

パッチ管理の原則

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

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

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

継続的改善のサイクル

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

Plan（計画）

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

Do（実行）

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

Check（確認）

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

Act（改善）

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

このサイクルを組織に定着させることで、セキュリティレベルは確実に向上します。

最後に

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

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

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

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