セキュリティ

パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順

パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順

パッチ管理は、管理しているOSやソフトウェアに出た修正プログラムを見つけ、どれから当てるかを決め、適用して、当たったことを確かめるまでの一連の作業です。この記事では、NISTの指針にある定義を確認したうえで、CISAの既知の悪用脆弱性カタログ（KEV）を自社の製品台帳と突き合わせて優先度を決めるスクリプト、UbuntuとRHEL系でセキュリティ更新だけを自動で入れる設定、AWS Systems Manager Patch Managerのベースラインの作り方をコードで示します。開発が止まったWSUSの移り先と、自動適用に任せてはいけない条件も言い切ります。数値と仕様は2026年11月4日時点のものです。

まとめ：パッチ管理は台帳・優先度・自動適用・適用確認の4つを仕組みにする作業

パッチ管理で先に作るべきは、ツールではなく台帳です。どのサーバーと端末に、どのOSのどの版が入っていて、誰が再起動を判断するのか。これが無いと、どの修正が自社に関係するかを判定できません。

優先度は、深刻度の点数より「実際に悪用されているか」で決めます。KEVに載った製品が台帳にあれば、その週のうちに当てる。Linuxはunattended-upgradesやdnf-automaticでセキュリティ更新だけを夜間に自動適用し、AWS上のサーバーはPatch Managerで承認までの待ち日数を決めて集中管理します。データベースのクラスタや業務パッケージのように再起動や互換性で業務が止まるものは、自動適用から外し、検証環境で確かめてから当てる運用です。社内に担当者を置けない場合や、適用後に穴が残っていないかを外から確かめたい場合は、脆弱性診断・セキュリティ診断を組み合わせます。

パッチ管理とは何か：NIST SP 800-40の定義と脆弱性管理との守備範囲の違い

言葉の範囲を先に固めておくと、どこまでを自動化の対象にするかが決めやすくなります。

NIST SP 800-40 Rev.4が定義するパッチ管理の5工程

米国立標準技術研究所（NIST）は2022年4月にSP 800-40 Rev.4（Guide to Enterprise Patch Management Planning）を公開しました。そこではエンタープライズパッチ管理を、組織全体でパッチ・アップデート・アップグレードを特定し、優先順位を付け、取得し、適用し、適用されたことを確かめるプロセスと定義しています。副題は「Preventive Maintenance for Technology」で、パッチ適用を技術の予防保守として扱う立場です。

この定義で見落とされやすいのは最後の「確認」です。配布ツールが「成功」と返しても、再起動待ちのまま古いカーネルで動いているサーバーは珍しくありません。後半で示すPatch Managerの確認コマンドは、この工程を機械で回すためのものです。

パッチ管理と脆弱性管理の違い：パッチで直らない設定不備やEOL機器の扱い

脆弱性管理は、パッチで直らない弱点まで含めて扱います。管理画面がインターネットに開いている設定ミスや、修正版がもう出ないサポート終了済みの機器は、パッチ管理の外側です。逆にパッチ管理は、脆弱性と関係のない不具合修正や機能更新も対象に含みます。

実務では、脆弱性管理が「何が危ないか」を決め、パッチ管理が「直せるものを期限内に直す」を受け持つと分けると混乱しません。脆弱性という言葉の範囲とCVEの読み方は脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説で整理しています。

適用の前提作り：OSと版の棚卸しと「準拠」の基準を文書で決める作業

手を動かす前に、何を管理するのかと、どの状態を合格とするのかを決めます。

管理対象の台帳：OS・版・担当者・再起動できる時間帯の4項目を載せる

台帳に最低限載せるのは、ホスト名、OSと版、担当者、再起動してよい時間帯の4項目です。このうち再起動の時間帯が抜けていると、自動適用の設定を決められません。後で示すKEVとの照合に使うため、ソフトウェアは「ベンダー名,製品名」の形でもう1枚の表にしておきます。

台帳づくりそのものの進め方や、ツールで自動収集するかどうかの判断はIT資産管理とは？目的・ツール機能と選び方・運用判断を解説を参照してください。パッチ管理の側で求めるのは、版番号が実機と合っていることだけです。

Patch Managerの「準拠」は自社が作るベースラインの承認規則で決まる仕組み

AWSのPatch Managerのドキュメントは、パッチ準拠（compliance）の基準はAWSやOSベンダーではなく、利用者がパッチベースラインで定義すると明記しています。準拠しているとは、ベースラインで承認したパッチが入っているという意味であり、安全であることまでは示しません。

同じページには、AWSはパッチを提供前に検証しないこと、Linuxの深刻度はソフトウェア発行元の値を使いCVSSから導かないこと、事前定義のベースラインは例であって推奨設定ではないことも書かれています。つまり、何日待ってから当てるか、どの分類まで含めるかは自社で決めて文書に残す必要があります。

優先度の決め方：CVSSより先にKEVとEPSSで今週当てるパッチを選ぶ手順

月に数百件出る修正を全部同じ速さで当てることはできません。並べ替えの基準を、点数ではなく悪用の事実に置きます。

CISA KEVのJSONを取得して自社の製品台帳と突き合わせるPythonスクリプト

米国CISAのKnown Exploited Vulnerabilities Catalogは、実際に悪用が確認された脆弱性の一覧です。11月3日公開の版（catalogVersion 2026.11.03）には1,767件が載り、そのうちベンダーがMicrosoftのものが390件、ランサムウェアでの利用が既知（Known）とされたものが361件ありました。JSON版は誰でも取得でき、各要素にcveID、vendorProject、product、dateAdded、dueDate、knownRansomwareCampaignUseが入っています。

# kev_match.py：KEVに直近30日で追加された脆弱性のうち、自社台帳の製品に当たるものを出す
import csv
import json
import urllib.request
from datetime import date, timedelta

KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"

with urllib.request.urlopen(KEV_URL, timeout=60) as r:
    kev = json.load(r)

# 自社の製品台帳（vendor,product の2列。KEVの表記に合わせ、小文字にして比べる）
with open("inventory.csv", encoding="utf-8") as f:
    owned = {(row["vendor"].lower(), row["product"].lower()) for row in csv.DictReader(f)}

since = (date.today() - timedelta(days=30)).isoformat()
print("catalogVersion", kev["catalogVersion"], "count", kev["count"])
for v in kev["vulnerabilities"]:
    key = (v["vendorProject"].lower(), v["product"].lower())
    if key in owned and v["dateAdded"] >= since:
        print(v["cveID"], v["product"], v["dateAdded"], v["dueDate"],
              v["knownRansomwareCampaignUse"], sep="\t")

inventory.csvは1行目を「vendor,product」とし、「Microsoft,Windows」「WordPress,WordPress Core」のようにKEVと同じ表記で書きます。表記がずれると一致しないので、最初はKEVのJSONをproductで検索して、自社製品がどう書かれているかを確かめてから台帳に写してください。出てきた行は、その週のうちに当てる候補です。

EPSSのAPIで悪用確率を引き、KEVに載る前のCVEの順番を決める方法

KEVは悪用が確認された後の一覧なので、まだ載っていない脆弱性の順番は決められません。そこを補うのがFIRSTのEPSS（Exploit Prediction Scoring System）で、今後30日以内に悪用が観測される確率を0から1の値で出しています。APIは登録なしで呼べます。

# 複数のCVEをカンマ区切りで渡し、確率（epss）と全CVE中の順位（percentile）を表にする
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2026-119977" \
  | jq -r '.data[] | [.cve, .epss, .percentile, .date] | @tsv'

応答のepssとpercentileは数値ではなく文字列で返るため、プログラムで比べるときは数値に変換します。社内の線引きは、たとえば「percentileが0.95以上なら次の定期適用を待たずに当てる」のように、件数を見ながら決めます。CVSSは被害の大きさの目安として残し、順番の決め手にはしません。点数の読み方はCVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説にまとめています。

適用期限の置き方：KEVのdueDateは件ごとに違い、短いものは3日で来る

KEVの各行にあるdueDateは、米国の連邦機関に課された対応期限です。民間企業に義務はありませんが、期限の長さが緊急度の目安になります。11月4日に取得したデータでは、WordPress Coreの脆弱性（CVE-2026-119977）は11月3日に追加され、期限は11月6日でした。9月8日に追加されたWindowsの2件は期限が9月22日で、14日の幅がありました。

自社の期限を「KEV掲載から一律14日」と決めてしまうと、3日で来る件に間に合いません。dueDateの長さがどう決まるかはBOD 26-04とは？KEVの是正期限を4変数で決める仕組みと自社運用への移し方で解説しました。外部に公開している機器ほど期限は短くなるので、VPN装置のように外から届く機器はVPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断の手順で別枠に管理します。

Linuxサーバーの自動適用：apt・dnfでセキュリティ更新だけを夜間に入れる設定例

Linuxでは、OS標準のしくみでセキュリティ更新だけを自動で入れられます。機能追加を含む全更新を自動にすると、ライブラリの挙動が変わって業務アプリが止まる危険が増えるため、範囲をセキュリティに絞ります。

Ubuntuのunattended-upgrades：更新範囲と再起動時刻の設定

Ubuntu Serverのドキュメントによると、unattended-upgradesは既定で導入されており、設定は/etc/apt/apt.conf.d/50unattended-upgradesに書きます。許可する配布元（Allowed-Origins）を-security系だけにしておくと、通常の更新は自動では入りません。

// /etc/apt/apt.conf.d/50unattended-upgrades（抜粋）
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};

// 互換性の確認が要るパッケージは自動適用から外す
Unattended-Upgrade::Package-Blacklist {
    "libc6$";
};

// カーネル更新などで再起動が要るときは、決めた時刻に再起動する
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

更新範囲や再起動の時刻の設定を変えたら、sudo unattended-upgrade -v --dry-runで何が入る予定かを確かめます。実行の記録は/var/log/unattended-upgrades配下に残るので、ログ収集の対象に加えておくと、後で「いつ何が入ったか」を追えます。

RHEL系のdnf-automatic：セキュリティ更新と再起動条件の設定

RHEL系ではDNF Automaticを使います。セキュリティ更新に絞る指定はupgrade_type=securityです。設定ファイルは/etc/dnf/automatic.confで、既定では更新を確認するだけで、ダウンロードも適用もしません（download_updatesとapply_updatesの既定がFalse）。

# /etc/dnf/automatic.conf（抜粋）
[commands]
# security にするとセキュリティ勧告の付いた更新だけが対象になる
upgrade_type = security
download_updates = yes
apply_updates = yes
# never（既定）／when-changed／when-needed
reboot = when-needed

# タイマーを有効にする
sudo systemctl enable --now dnf-automatic.timer

reboot = when-neededは、カーネルやsystemdの更新のように再起動が要る場合だけ再起動します。古い版のdnf-automaticにはこの項目が無い場合があるため、man dnf-automaticで項目があるかを確かめてから書いてください。dnf5を採用したディストリビューションでは設定ファイルの場所も変わります。

AWS環境の集中管理：Patch Managerのベースラインと承認までの日数の設定例

台数が増えると、1台ずつの設定では版の差が管理できなくなります。AWS上のサーバーで承認の規則と適用の結果を1か所に集めるのが、Systems ManagerのPatch Managerです。Systems Manager全体の機能と料金はAWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使い方で扱っています。

create-patch-baseline：7日後に自動承認するJSON設定

create-patch-baselineのリファレンスでは、承認規則（PatchRules）を最大10個まで並べられ、ApproveAfterDaysは0から360の整数で、パッチの公開から何日後に承認するかを指定します。日付はUTCで計算されます。Amazon Linux 2023向けに、セキュリティ分類（Security）の重大なものだけを7日後に承認するベースラインの例です。

# 先に、このOSで使える SEVERITY の値を確かめる
aws ssm describe-patch-properties --operating-system AMAZON_LINUX_2023 --property SEVERITY

# al2023-baseline.json
{
  "Name": "al2023-security-7days",
  "OperatingSystem": "AMAZON_LINUX_2023",
  "ApprovalRules": {
    "PatchRules": [
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            { "Key": "CLASSIFICATION", "Values": ["Security"] },
            { "Key": "SEVERITY", "Values": ["Critical", "Important"] }
          ]
        },
        "ApproveAfterDays": 7,
        "ComplianceLevel": "CRITICAL"
      }
    ]
  }
}

# ベースラインを作り、AL2023の既定にする
BASELINE_ID=$(aws ssm create-patch-baseline --cli-input-json file://al2023-baseline.json --query BaselineId --output text)
aws ssm register-default-patch-baseline --baseline-id "$BASELINE_ID"

7日待つのは、AWSが提供前にパッチを検証しないためです。この待機期間は、検証用のサーバーへ先に当てて動作を確かめるための時間です。KEVに載った件のように待てないものは、ベースラインの承認済みリスト（approved patches）に個別に足して即日当てます。リファレンスには、Windows Serverで待ち日数を長く取りすぎると、後継の更新に置き換えられた重要なパッチが当たらなくなる場合があるという注意も載っています。

AWS-RunPatchBaseline：未適用と再起動待ちの件数確認

適用はAWS-RunPatchBaselineというSSMドキュメントで行います。Operationは必須で、Scanは未適用を数えるだけ、Installは適用まで行う指定です。RebootOptionの既定はRebootIfNeededで、パッチを1つでも入れると、そのパッチが再起動を要するかどうかに関係なく再起動します。

# 検証環境のサーバーで、まず未適用を数える（再起動しない）
aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets "Key=tag:Env,Values=stg" \
  --parameters "Operation=Scan"

# 結果を一覧にする：未適用・失敗・再起動待ちの件数
aws ssm describe-instance-patch-states \
  --instance-ids i-0123456789abcdef0 \
  --query "InstancePatchStates[].[InstanceId,MissingCount,FailedCount,InstalledPendingRebootCount,OperationEndTime]" \
  --output table

業務時間中に再起動できないサーバーでRebootOption=NoRebootを使うと、パッチは入ってもInstalledPendingRebootの状態で止まり、ノードは準拠していない（Non-Compliant）扱いになります。再起動してScanをもう一度回すまで準拠に戻りません。InstalledPendingRebootCountが0でない台数を毎週数え、再起動の予定を入れるところまでを運用の手順に含めてください。Systems Managerのエージェントの版確認はSSM Agentとは？役割・インストール・バージョン確認と自動更新の手順にあります。

Windows端末とサーバー：開発が止まったWSUSから移る先を種類別に選ぶ判断

Windowsの更新は毎月第2火曜日（日本時間では翌水曜日）にまとめて公開されます。日程とゼロデイ発生時の対応順はPatch Tuesday（パッチチューズデー）とは？日本時間と2026・2027年の日程、Microsoftゼロデイへの対応順で扱っているので、ここでは配る仕組みの選び方に絞ります。

WSUSは新機能の開発が止まった扱い：既存の機能は残るが追加は無い状態

Microsoft LearnのWindows Serverで削除または開発終了となった機能の一覧では、WSUSは「no longer actively developed」とされ、既存の機能と配信内容は引き続き使えると書かれています。同じページは、WSUSなどが使うWindows Internal Database（WID）も将来のリリースで削除予定としています。

今動いているWSUSをすぐ止める必要はありません。ただし、新しく作る仕組みの土台には選ばない、というのが妥当な線です。WIDで動かしているWSUSは、WIDが外れた時点でSQL Serverへ載せ替える作業が発生します。

Windows端末とサーバーの移行先：管理する対象と置き場所で選ぶ判断

端末はWindows Autopatchが候補です。Windows、Microsoft 365 Apps、Edge、Teamsの更新を段階的なリングで配り、Business Premium、A3以上、E3以上、F3のライセンスで使えます。Intuneで端末を管理していることが前提になります。

サーバーの管理方法を分ける判断軸は、サーバーの置き場所です。オンプレミスや他クラウドを含めて1か所で見るなら、Azure Arcでつないだサーバーも対象にできるAzure Update Managerが合います。24時間ごとの定期評価と、保守時間帯を決めた適用ができる仕組みです。サーバーの大半がAWSにあるなら、前章のPatch ManagerでWindows Serverもまとめて扱う方が、管理画面が1つで済みます。

判断：自動適用に任せる範囲と、人が検証してから当てるパッチを分ける条件

自動適用は速さを取る代わりに、互換性の確認を省きます。どこまで省いてよいかを、条件で切り分けます。

自動適用で足りる条件：冗長構成で再起動しても業務が止まらないサーバー

次の条件をすべて満たすサーバーは、セキュリティ更新を夜間の自動適用に任せて構いません。人が毎回検証する方がかえって遅れ、KEVの短い期限に間に合わなくなります。

  • ロードバランサーの下に2台以上あり、1台ずつ再起動しても応答が止まらない
  • OS標準のパッケージだけで動き、独自にビルドしたライブラリを持たない
  • 検証環境に同じ構成があり、本番より数日早く同じパッチが当たる

Webサーバーやバッチの実行サーバーの多くはこの条件に入ります。自動適用の結果は、前章のInstalledPendingRebootCountやunattended-upgradesのログで毎週数え、止まった台数だけを人が見ます。

自動適用から外す場面：DBクラスタ・業務パッケージ・サポート終了間近のOS

データベースのクラスタは自動適用から外します。片側だけが再起動して切り替わると、接続の張り直しで業務アプリがエラーを出すことがあるためです。AWSのドキュメントも、Amazon EMRのクラスタにはPatch Managerを使わないよう、特にRebootIfNeededを選ばないよう求めています。ベンダーが動作保証するOSの版を決めている業務パッケージも、ベンダーの確認を待ってから当てます。

サポート終了が近いOSは、パッチの自動化に手間をかけるより移行を先に決めるべきです。修正が出なくなった時点で、パッチ管理では守れなくなります。Amazon Linux 2の例はAmazon Linux 2のサポート終了後の移行手順にまとめました。こうした判断と、適用の後に穴が残っていないかの検査を含めて外部に任せたい場合は、脆弱性診断・セキュリティ診断で相談を受け付けています。

パッチ管理の運用でよくある質問：頻度・戻し方・費用・委託の範囲への回答

パッチ管理を始めるときに出やすい疑問に、11月4日時点の一次情報の範囲で答えます。

パッチはどのくらいの頻度で当てればよいですか？

定期の適用は月1回を基本にし、Windowsは第2火曜日の公開に合わせます。これとは別に、KEVに自社製品が載った件とEPSSが高い件は、定期を待たずに当てる臨時の枠の対象です。KEVの照合は毎日か少なくとも週1回回し、照合結果に出た件だけを臨時枠に回すと、作業量が読みやすくなります。

パッチを当てて不具合が出たらどう戻しますか？

RHEL系はdnfのdnf history undoで直前のトランザクションを取り消せますが、カーネルや依存関係の多い更新では戻り切らない場合があります。確実なのは、適用前にディスクのスナップショットやマシンイメージを取っておく方法です。Patch Managerの操作はScanとInstallで、適用の取り消しは含まれないため、AWSではEBSスナップショットを適用前の手順に入れておきます。

無料のツールだけでパッチ管理はできますか？

Linuxの自動適用はunattended-upgradesとdnf-automaticで、優先度付けはKEVのJSONとEPSSのAPIで、いずれも費用をかけずに始められます。不足するのは、台数が増えたときの結果の集約と、端末の管理です。数十台を超えたらPatch ManagerやAzure Update Managerのような集中管理の仕組みを検討します。

サポートが終わったOSにはどう対応すればよいですか？

修正が出ないので、パッチ管理の対象からは外れます。移行が終わるまでは、外部からの通信を絞る、ほかのサーバーから切り離す、といった被害を広げない対策で時間を稼ぎます。延長サポートを買える製品なら、移行の完了日まで買うのも選択肢です。移行の期限は、延長サポートの終了日から逆算して決めます。

パッチ管理を外部に委託するときは何を任せられますか？

任せやすいのは、月次の適用作業、適用結果の報告、KEV照合の結果を受けた臨時適用です。業務パッケージを自動適用から外すかどうかや、再起動の時間帯の決定は、業務を知る社内の担当者が持つべき判断です。AWS上のサーバーで委託の範囲と費用を決めるときの観点は、AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準で整理しています。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.03　テックブログ ノジマ不正アクセスで約700万件漏えい：対象確認・窓口と乗っ取り注文を止める実装
  2. 2026.10.29　テックブログ ソニー生命の情報漏洩38.5万件｜ログインできない理由、再開状況と窓口の電話番号
  3. 2026.11.03　テックブログ クラブツーリズム不正アクセス：約432万件の対象確認と偽メールの見分け方・流出検知の設計
  4. 2026.11.02　テックブログ アララの不正アクセス：メール約7,700万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告
  5. 2026.11.04　テックブログ CVE-2026-119977：WordPress更新中のRCEと安全な更新手順

RELATED POSTS 関連記事

一覧へ戻る

目次