パッチ管理 - OS パッチ管理

OS やミドルウェアの既知の脆弱性を修正するセキュリティパッチを計画的に適用・管理するプロセス。パッチ適用の遅延は攻撃者に悪用される時間を与えるため、自動化と運用プロセスの整備が不可欠。

実例

Ubuntu / Debian で unattended-upgrades を設定し、セキュリティパッチを自動適用する

bash

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

# 有効化
sudo dpkg-reconfigure -plow unattended-upgrades

# 手動テスト
sudo unattended-upgrades --dry-run --debug

RHEL / CentOS で yum-cron を使いセキュリティ更新を自動化する

bash

# /etc/yum/yum-cron.conf
[commands]
update_cmd = security
apply_updates = yes

# サービス有効化
sudo systemctl enable --now yum-cron

AWS Systems Manager Patch Manager でパッチベースラインとメンテナンスウィンドウを作成する

bash

aws ssm create-patch-baseline \
  --name "ProductionBaseline" \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules \
    'PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=SEVERITY,Values=[Critical,Important]}]},ApproveAfterDays=3}]'

aws ssm create-maintenance-window \
  --name "PatchWindow" \
  --schedule "cron(0 3 ? * SUN *)" \
  --duration 4 --cutoff 1 --allow-unassociated-targets

パッチ管理の重要性と課題

セキュリティパッチの適用は最も基本的かつ効果の高い防御策ですが、実際の運用では多くの課題があります。

パッチ適用の遅延が招くリスク:

リスク	説明
既知の脆弱性の悪用	CVE が公開されてからエクスプロイトコードが出回るまでの期間は年々短縮しており、数日以内に攻撃が始まるケースも多い
ゼロデイ攻撃後の対応遅延	ベンダーがパッチをリリースしても適用に時間がかかると、攻撃にさらされ続ける
コンプライアンス違反	PCI DSS や ISMS ではパッチ適用の期限が定められており、未適用はセキュリティ監査の指摘事項になる
ラテラルムーブメントの起点	1 台の未パッチサーバーが侵害されると、内部ネットワーク全体への横展開の足がかりとなる

過去の重大インシデント:

WannaCry（2017年）: Microsoft が 2017 年 3 月に公開した MS17-010（EternalBlue）パッチを適用していなかったシステムが世界中で被害を受け、150 か国以上・約 30 万台が感染。NHS（英国国民保健サービス）では手術のキャンセルや患者の転送が発生した
Equifax 情報漏洩（2017年）: Apache Struts の既知の脆弱性（CVE-2017-5638）にパッチを適用せず、約 1 億 4,700 万人の個人情報が流出。パッチは攻撃の 2 か月前にリリース済みだった
Log4Shell（2021年）: Apache Log4j の CVE-2021-44228 は公開直後から大規模な悪用が始まり、パッチ適用のスピードが組織の命運を分けた

これらの事例が示すように、パッチの存在を知りながら適用しないことは、鍵をかけずにドアを開け放つことと同義です。

パッチ管理の自動化手法

手動でのパッチ適用は漏れやすく、スケーラビリティに欠けるため、自動化が不可欠です。

環境に応じた主要なツールと手法を紹介します。

Linux 環境:

ツール	対象 OS	特徴
unattended-upgrades	Debian / Ubuntu	セキュリティリポジトリからの自動更新に特化。再起動タイミングの制御、メール通知に対応
yum-cron / dnf-automatic	RHEL / CentOS / Fedora	yum / dnf ベースの自動更新。`security` フィルタでセキュリティパッチのみ適用可能
Canonical Livepatch	Ubuntu	カーネルパッチを再起動なしで適用。稼働率が要求されるサーバー向け

Windows 環境:

ツール	特徴
WSUS（Windows Server Update Services）	オンプレ環境でパッチの承認・配信を一元管理。無償
SCCM / MECM（Microsoft Endpoint Configuration Manager）	大規模環境向け。パッチだけでなくソフトウェア配布・インベントリも統合管理
Windows Update for Business	Azure AD / Intune と連携したクラウドベースの更新管理。更新リングによる段階展開が可能

クラウド環境:

サービス	プロバイダー	特徴
AWS Systems Manager Patch Manager	AWS	パッチベースライン定義、メンテナンスウィンドウによるスケジュール管理、コンプライアンスレポート
Azure Update Management	Azure	Azure VM とオンプレの両方に対応。Log Analytics と連携した更新評価
Google OS Config	GCP	OS ポリシーによるパッチジョブの定義と実行。Compute Engine VM が対象

パッチ適用のベストプラクティス

パッチの適用は「当てれば終わり」ではなく、テスト・展開・監視のサイクルを確立することが重要です。

段階的な適用プロセス:

脆弱性情報の収集 — CVE データベース、ベンダーアドバイザリ、US-CERT/JPCERT 等の情報源を定期的に確認する
影響評価とトリアージ — CVSS スコア、自社環境での影響範囲、エクスプロイトの有無に基づいて優先度を決定する
テスト環境での検証 — 本番と同等の構成で動作確認を行う。アプリケーションの互換性、パフォーマンスへの影響を確認する
段階展開 — 開発環境 → ステージング → 本番（カナリア）→ 本番（全台）の順で展開する
ロールバック計画 — パッチ適用前のスナップショット取得、切り戻し手順の事前準備を徹底する
適用確認と監査 — パッチが正しく適用されたことを検証し、コンプライアンスレポートを生成する

定期スケジュールの設計:

種別	推奨頻度	備考
Critical / High（CVSS 7.0以上）	72 時間以内	攻撃が確認されている場合は即日
Medium（CVSS 4.0-6.9）	2 週間以内	月次パッチサイクルに含める
Low（CVSS 4.0 未満）	次回の定期メンテナンス	四半期ごとのメンテナンスウィンドウ等

EOL（End of Life）OS の扱い:

サポート終了した OS はセキュリティパッチが提供されないため、以下の対策が必要です。

移行計画の策定 — EOL 前に後継バージョンへの移行スケジュールを立てる
仮想パッチ — WAF や IPS のルールで脆弱性を仮想的に塞ぐ（暫定対策）
ネットワーク分離 — EOL システムを隔離されたネットワークセグメントに配置する
延長サポートの検討 — RHEL の Extended Life Cycle Support や Ubuntu の ESM（Extended Security Maintenance）等の有償延長サポートを利用する
棚卸しの定期実施 — EOL を迎えた OS やミドルウェアの一覧を四半期ごとに更新し、経営層へ報告する

実例

パッチ管理の重要性と課題

パッチ管理の自動化手法

パッチ適用のベストプラクティス

関連トピック