1. はじめに
本記事では、Amazon Linux 2023（以下、AL2023）を対象に、Amazon Inspector（以下、Inspector）で脆弱性を確認し、AWS Systems Manager Patch Manager（以下、Patch Manager）でパッチを適用するまでの流れを解説します。
AL2023はパッケージリポジトリが特定のバージョンにロックされているという特徴を持っています。常に最新を見に行くAmazon Linux 2（以下、AL2）とも、マイナーバージョンを固定できるRed Hat Enterprise Linux（以下、RHEL）とも異なる方式です。この仕組みがPatch Managerの動作にどう影響するのか、実機で確認しながら深いところまで見ていきます。
この記事でわかること
- AL2023の「確定的アップグレード」の仕組み（更新の参照先が特定のリポジトリバージョンに固定される）と、AL2・RHELとの考え方の違い
- Patch Managerがパッチを選定・適用する内部の動作と、AL2023固有の挙動
- リポジトリのロック状態がPatch Managerの結果にどう影響するか
- デフォルトパッチベースラインの「7日の自動承認遅延」が、直近のセキュリティ修正を取りこぼす仕組み
この記事で扱わないこと
- VPC・EC2・IAMの基本的な構築手順
- Windows Serverや他ディストリビューションのパッチ運用
2. Amazon Linux 2023とは
まず、AL2023がどういうOSなのかを整理します。すでにご存じの方は3章まで読み飛ばしていただいて構いません。
AL2023は、AWSが管理し、AWS向けに最適化された汎用Linuxディストリビューションです。EC2の標準料金以外に追加のライセンス費用は発生しません。
特徴は大きく4つに整理できます。
| 特徴 |
内容 |
| AWSに最適化 |
EC2向けにカスタマイズされたカーネル、ECS／EKS向け最適化AMI、AWSのツール・エージェントとの統合 |
| 標準で高いセキュリティ |
SELinuxが有効、カーネルライブパッチ、隔週でのセキュリティアップデート |
| シンプルなメンテナンス |
リポジトリのバージョンロック、予測可能なライフサイクル、Patch Managerによるパッチ適用 |
| 低コスト |
追加のライセンス費用なし、AWS Gravitonへの最適化 |
参考：AWS Black Belt Online Seminar「Amazon Linux」
2.1 バージョニングの体系
AL2023のバージョンは、次のような形式で表されます。
Amazon Linux 2023.9.20251208
- 2023：メジャーバージョン
- 9：マイナーバージョン（四半期ごとにリリース。メジャーリリース時は0）
- 20251208：AMIのリリース日
セキュリティリリースは隔週で、AMIとリポジトリの両方が提供されます。つまり、同じ「2023」でも、AMIリリース日が違えば中身のパッケージ構成は異なります。この「AMIリリース日まで含めてバージョンである」という考え方が、3章で解説する確定的アップグレードの土台になります。
サポート期間は次のとおりです。
- 標準サポート（四半期ごとのマイナーバージョンが提供される）：2027年6月30日終了予定
- メンテナンスサポート（セキュリティ更新と重要なバグ修正のみ）：2029年6月30日終了予定
なお、AL2のサポートは2026年6月30日をもって終了し、以降はセキュリティ更新が提供されません。まだAL2で稼働している環境があれば、移行は急務です。
余談ですが、AL2の後継が世に出るまでには、かなりの待ち時間がありました。次期バージョンは2021年11月22日に「Amazon Linux 2022」としてパブリックプレビューが発表されたものの、そこから正式リリースの発表がないまま時間が過ぎ、「結局いつ出るのか」と気を揉んだ方も多いのではないでしょうか。最終的に名称が「Amazon Linux 2023」へと変わり、一般提供が開始されたのは2023年3月15日です。プレビュー発表から1年4か月近くが経っていました。
AL2023では標準サポートとメンテナンスサポートの終了日が公開されており、いつまで使えるかを事前に見積もれます。ただし日程は改定されることがあるため、最新の情報は公式のRelease cadenceのページで確認してください。
参考：Release cadence - Amazon Linux 2023
2.2 パッケージのサポート区分
AL2023では、パッケージによってサポートが切れる時期が異なります。
- コアリポジトリのパッケージ（glibc、OpenSSL、OpenSSH、dnfなど）：原則としてAL2023のサポート期間（2029年6月30日）まで
- ただし例外があり、アップストリームのEOLが先に来るパッケージは、そちらに従って先にサポートが終わる
注意が必要なのは2つ目です。たとえば php8.1 や nodejs20 はコアリポジトリのパッケージですが、アップストリームのEOLに合わせて、AL2023本体より早くサポートが終了しています（php8.1は2025年12月31日、nodejs20は2026年4月30日）。「コアパッケージだからAL2023の期間中は安心」とは言えません。
インストール済みパッケージのサポート状況は、次のコマンドで確認できます。プラグインが入っていない環境では、先にインストールします。
sudo dnf install dnf-plugin-support-info
dnf supportinfo --show installed
参考：Package support information - Amazon Linux 2023
また、2025年11月にリリースされたSPAL（Supplementary Packages for Amazon Linux）は、EPEL 9から派生したAL2023向けの拡張パッケージリポジトリです。AL2023本体に含まれないパッケージを利用できる一方、AWSによるCVEトラッキングの対象外であり、セキュリティパッチはアップストリームであるEPEL 9からのみ提供されます。SPAL由来のパッケージを使っている場合、脆弱性対応の考え方が本体パッケージとは変わる点に注意が必要です。
2.3 他のディストリビューションとの違い
AL2およびRHEL 9との違いを整理すると、次のようになります。
| 項目 |
Amazon Linux 2 |
Red Hat Enterprise Linux 9 |
Amazon Linux 2023 |
| パッケージ管理 |
yum |
dnf |
dnf |
| SELinux |
Disabled |
Enabled / enforcing |
Enabled / permissive |
| IMDS（AMIの既定） |
v1／v2とも利用可 |
IMDSv2のみ |
IMDSv2のみ |
| cgroups |
v1 |
v2 |
v2 |
| 定期実行 |
cron |
cron／systemd timer |
systemd timer |
| JVM |
OpenJDK |
OpenJDK |
Amazon Corretto |
| 追加パッケージ |
EPEL |
EPEL |
SPAL |
| アップグレード方式 |
常に最新バージョンへ |
既定は最新マイナーへ追従。subscription-manager release --set で固定可能 |
リポジトリを特定バージョンにロック |
| サポート期間 |
2026/6/30に終了済み |
フルサポート2027/5/31、メンテナンス2032/5/31、延長（有償アドオン）2036/5/31 |
標準2027/6/30、メンテナンス2029/6/30 |
パッケージ管理がdnfである点やSELinuxが有効である点など、AL2023はRHEL 9に近い操作感を持っています。表のとおり違いはいくつかありますが、パッチ運用の設計に直結するのは、太字にした「アップグレード方式」です。
3. AL2023の「確定的アップグレード」
3.1 何もしないと「Nothing to do」になる
AL2の感覚でAL2023にログインし、パッケージを更新しようとすると、次のような結果になることがあります。
$ sudo dnf upgrade
Last metadata expiration check: 0:00:02 ago on ...
Dependencies resolved.
Nothing to do.
Complete!
※ 新しいリリースが存在する場合は、5.3のようにWARNINGも併せて表示されます。ここでは省略しています。
新しいセキュリティアップデートがリリースされているにもかかわらず、更新対象が見つからない。これはバグではなく、AL2023の設計どおりの挙動です。
AL2023では、それぞれのAMIが特定のリポジトリバージョンにロックされています。これを「確定的アップグレード（Deterministic upgrades through versioned repositories）」と呼びます。ロックされている限り、パッケージマネージャーはロック先のバージョンのリポジトリしか参照しないため、それより新しい更新は「存在しないもの」として扱われます。
3.2 releasever の優先順位
どのリポジトリバージョンを参照するかは、dnfのreleaseverという変数で決まります。releaseverに指定できる値は、latest または 2023.9.20251208 のような日付入りのバージョンです。
この値は、次の3つの方法で決まります。上にあるものほど優先度が高く、上位の指定が下位を上書きします。
- コマンドラインフラグ（--releasever=latest など）
- オーバーライド変数ファイル（/etc/dnf/vars/releasever）
- インストール済みのsystem-releaseパッケージのバージョン
新規に起動したインスタンスには /etc/dnf/vars/releasever が存在しないため、--releasever を付けずに実行すると3が採用され、system-releaseのバージョンにロックされます。現在のロック状態は次のコマンドで確認できます。
$ rpm -q system-release
system-release-2023.12.20260817-0.amzn2023.noarch
明示的にバージョンを指定すれば、アップグレードは実行されます。
sudo dnf upgrade --releasever=2023.12.20260909
このとき、次の2つが同時に起こります。
- インストール済みのパッケージのうち、旧バージョンと新バージョンの間で変更されたものがすべて置き換わる
- system-releaseも更新されるため、システムは新しいバージョンのリポジトリにロックし直される
この方式の利点は、同じバージョンを指定すれば、どのインスタンスでもパッケージが同じリリースのバージョンにそろうことです。検証環境で 2023.12.20260909 の動作を確認しておけば、本番環境で同じバージョンを指定したときも同じ結果になります。
AL2のように常に最新を参照する方式では、更新を実行した日によってインストールされるパッケージのバージョンが変わります。同じ手順で構築したはずのインスタンスでも、構築した日が違えば中身が異なる、ということが起こります。AL2023はこれを防ぐ設計になっています。
3.3 ロックを外す方法と、そのリスク
/etc/dnf/vars/releasever に latest を書き込めば、ロックを恒久的に解除できます。
echo latest | sudo tee /etc/dnf/vars/releasever
これでAL2と同じ「常に最新を見に行く」挙動になります。運用は楽になりますが、テストしていないOS更新がそのまま本番に入るリスクを引き受けることになります。AWSのドキュメントでも、この設定については警告が明記されています。
ロックを外す代わりに推奨されているのは、次のいずれかです。
- 新しいAMIから起動したインスタンスへの置き換え（ブルー／グリーンデプロイ）
- インスタンス置き換えができない場合は、Patch Managerによるフリート全体へのパッチ適用のオーケストレーション
- EC2 Image Builderによる、パッチ適用済みの独自AMIの自動ビルド
参考：Using Deterministic upgrades through versioned repositories - Amazon Linux 2023
なお、この確定的アップグレードはAL2023だけの仕組みではありません。2026年9月時点でパブリックプレビューが公開されている後継のAmazon Linux 2027（AL2027）でも、AL2023と同じ更新モデルを採用することが公式ドキュメントに明記されています。本記事で扱うreleaseverの管理の考え方は、次のメジャーバージョンでも基本的に通用すると考えられます（AL2027はプレビューのため、仕様が変わる可能性があります）。
参考：Deterministic upgrades through versioned repositories on AL2027 - Amazon Linux 2027
先に挙げた推奨策の1つが、Patch Managerによるパッチ適用です。では、Patch Managerはこのロックをどう扱うのでしょうか。それが本記事で確認したい点です。
4. 検証シナリオと構成
4.1 前提
- VPC：各サブネットとルーティングを設定済み
- EC2：AL2023のAMIから起動し、AmazonSSMManagedInstanceCoreポリシーを付与したIAMロールをアタッチ済み
- Systems Manager：対象インスタンスがマネージドノードとして認識されている状態（AL2023の標準AMIにはSSM Agentがプリインストールされているため、個別のインストールは不要）
- Amazon Inspector：対象リージョンでEC2スキャンを有効化済み
プライベートサブネットのインスタンスを対象にする場合は、Systems Managerと通信するためのVPCエンドポイント（ssm、ssmmessages、ec2messages）が必要です。InspectorのEnhanced EC2 Scanningを使う場合は、inspector2-telemetryも追加します（一部のリージョンでは未提供）。加えてパッチ適用では、ノードに設定されたリポジトリへの接続と、AWSが管理するS3バケットへのアクセスが必要なため、NATゲートウェイを使わない構成ではS3のゲートウェイエンドポイントも用意します。
参考：Scanning Amazon EC2 instances with Amazon Inspector - Amazon Inspector
参考：Patch Manager prerequisites - AWS Systems Manager
4.2 構成
4.3 作業の流れ
本記事では、次の順に進めます。
- Inspectorで、パッチ適用前の脆弱性を確認する（5章）
- 切り戻しに備えてAMIを取得する（5章）
- OS側で、パッチ適用前のパッケージ情報を取得する（5章）
- Patch Managerでスキャンし、未適用のパッチを確認する（7章）
- パッチを適用し、何が起きたかをdnfの履歴で確認する（8章）
- Inspectorを再確認し、検出が解消されたかを確認する（10章）
- カスタムパッチベースラインを作成し、残った検出を解消する（11章）
5. 事前確認とバックアップ
5.1 Inspectorの検出結果を確認する
Inspectorは、EC2インスタンスからソフトウェアインベントリ（インストール済みパッケージの一覧）を抽出し、セキュリティアドバイザリと突き合わせて脆弱性を検出します。SSMマネージドノードであれば、SSM Agent経由のエージェントベーススキャンが継続的に実行されます。
Inspectorコンソールの[検出結果]で、対象インスタンスのリソースIDを指定して絞り込みます。今回の対象インスタンスでは、22件の脆弱性が検出されました。重大性の内訳はHighが11件、Mediumが10件、Lowが1件で、Criticalはありません。
影響を受けるパッケージごとに整理すると、次のようになります。
| パッケージ |
件数 |
内訳 |
| vim-common、vim-data ほか |
9 |
High 6 / Medium 2 / Low 1 |
| microcode_ctl |
8 |
High 2 / Medium 6 |
| dracut、dracut-config-generic |
1 |
High 1 |
| kbd、kbd-misc |
1 |
High 1 |
| kernel6.18 |
1 |
High 1 |
| python3-pip-wheel |
1 |
Medium 1 |
| openssl、openssl-fips-provider-latest ほか |
1 |
Medium 1 |
vimとmicrocode_ctlの2つで17件を占めています。またkernel6.18が1件含まれており、この1件が7章以降で話の中心になります。
検出された22件のCVEは次のとおりです。10章で「どの検出が消えたか」を突き合わせるため、この時点で控えておきます。
[High]
CVE-2026-73072 vim-common, vim-data ほか
CVE-2026-73073 vim-common, vim-data ほか
CVE-2026-73074 vim-common, vim-data ほか
CVE-2026-73076 vim-common, vim-data ほか
CVE-2026-73077 vim-common, vim-data ほか
CVE-2026-73078 vim-common, vim-data ほか
CVE-2025-35973 microcode_ctl
CVE-2026-20713 microcode_ctl
CVE-2026-15816 dracut, dracut-config-generic
CVE-2026-72693 kbd, kbd-misc
CVE-2026-74580 kernel6.18
[Medium]
CVE-2025-31936 microcode_ctl
CVE-2025-31938 microcode_ctl
CVE-2026-20707 microcode_ctl
CVE-2026-20716 microcode_ctl
CVE-2026-20901 microcode_ctl
CVE-2026-20917 microcode_ctl
CVE-2026-73070 vim-common, vim-data ほか
CVE-2026-73075 vim-common, vim-data ほか
CVE-2026-45409 python3-pip-wheel
CVE-2026-14456 openssl, openssl-fips-provider-latest ほか
[Low]
CVE-2026-73071 vim-common, vim-data ほか
ここで一点、重大性の見方について注意が必要です。Inspectorが表示する重大性（Critical / High / Medium / Low）は、CVSSのベーススコアにネットワーク到達性などの環境情報を加味した「Inspectorスコア」に基づくものです。 Amazon Linuxのパッケージでは、ベーススコアとしてAmazonが付与したCVSSが使われます。
一方、6章で扱うパッチベースラインの重要度（Critical / Important / Medium / Low / None）は、Amazon Linuxのセキュリティアドバイザリ（ALAS）がアドバイザリ単位で付与する値です。Patch ManagerはCVSSやNVDから重要度を導出しません。両者は別の指標であり、Inspectorの「High」がそのままベースラインの「Important」に対応するとは限りません。
参考：Viewing the Amazon Inspector score and understanding vulnerability intelligence details - Amazon Inspector
参考：How patch baseline rules work on Linux-based systems - AWS Systems Manager
5.2 切り戻しに備えてAMIを取得する
パッチ適用は、カーネルや共有ライブラリを含むパッケージを入れ替える作業です。アプリケーションが起動しなくなるなどの事態に備え、変更を加える前にバックアップを取得しておきます。
EC2コンソールから対象インスタンスを選択し、[アクション] → [イメージとテンプレート] → [イメージを作成] でAMIを取得します。
デフォルトでは、AMI作成時にインスタンスが一時的に再起動されます。稼働中のインスタンスを止めたくない場合は「インスタンスを再起動」のチェックを外すこともできますが、その場合はファイルシステムの整合性が保証されません。データベースなど書き込みが継続するミドルウェアが動いている場合は、事前に停止するか、再起動を伴う取得を選択してください。
ステータスが「利用可能」になれば、切り戻しに使える状態です。
ここでは挙動を段階的に追うため手動でAMIを取得しますが、バックアップの取得からパッチ適用、失敗時の切り戻しまでを1つの処理として自動化する方法もあります。9章で扱います。
5.3 OS側でパッチ適用前の状態を取得する
Inspectorの検出結果と突き合わせるため、インスタンス上でも情報を取得しておきます。
まず、現在ロックされているリポジトリバージョンを確認します。
$ rpm -q system-release
system-release-2023.12.20260817-0.amzn2023.noarch
このインスタンスは 2023.12.20260817 のリポジトリにロックされています。
次に、インストール済みパッケージの一覧を取得します。適用後との差分を取るため、ファイルに保存しておきます。
$ rpm -qa | sort > /var/tmp/rpm-before.txt
$ wc -l /var/tmp/rpm-before.txt
495 /var/tmp/rpm-before.txt
保存先を /tmp ではなく /var/tmp にしている点に注意してください。AL2023では、再起動時に /tmp の内容が削除されます。パッチ適用に伴って再起動が発生すると、/tmp に置いた適用前の情報は消えてしまいます。
最後に、ロックされた状態と、ロックを無視した状態とで更新対象がどう変わるかを見比べます。まずは現在のロック状態のままセキュリティ更新を確認します。
$ sudo dnf check-update --security
==========================================================================
WARNING:
A newer release of "Amazon Linux" is available.
Available Versions:
Version 2023.12.20260831:
Run the following command to upgrade to 2023.12.20260831:
dnf upgrade --releasever=2023.12.20260831
Release notes:
https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.12.20260831.html
Version 2023.12.20260909:
Run the following command to upgrade to 2023.12.20260909:
dnf upgrade --releasever=2023.12.20260909
Release notes:
https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.12.20260909.html
==========================================================================
更新対象のパッケージは1件も表示されません。 Inspectorが22件の脆弱性を検出しているにもかかわらず、インスタンスから見えている更新はゼロです。
代わりに表示されているのが、新しいリリース（2023.12.20260831 と 2023.12.20260909）が利用可能であるという警告です。修正が存在しないのではなく、ロックされたリポジトリの外側にあるという状態が、この出力に表れています。
次に、releaseverにlatestを指定して同じコマンドを実行します。
$ sudo dnf check-update --releasever=latest --security
Amazon Linux 2023 repository 72 MB/s | 78 MB 00:01
dracut.x86_64 102-3.amzn2023.0.4 amazonlinux
dracut-config-generic.x86_64 102-3.amzn2023.0.4 amazonlinux
kbd.x86_64 2.4.0-2.amzn2023.0.4 amazonlinux
kbd-misc.noarch 2.4.0-2.amzn2023.0.4 amazonlinux
kernel6.18.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
kernel6.18-tools.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
microcode_ctl.x86_64 2:2.1-53.amzn2023.0.16 amazonlinux
openssl.x86_64 1:3.5.7-2.amzn2023.0.2 amazonlinux
openssl-fips-provider-latest.x86_64 1:3.5.7-2.amzn2023.0.2 amazonlinux
openssl-libs.x86_64 1:3.5.7-2.amzn2023.0.2 amazonlinux
python3-pip-wheel.noarch 21.3.1-2.amzn2023.0.21 amazonlinux
vim-common.x86_64 2:9.2.920-1.amzn2023.0.1 amazonlinux
vim-data.noarch 2:9.2.920-1.amzn2023.0.1 amazonlinux
vim-enhanced.x86_64 2:9.2.920-1.amzn2023.0.1 amazonlinux
vim-filesystem.noarch 2:9.2.920-1.amzn2023.0.1 amazonlinux
vim-minimal.x86_64 2:9.2.920-1.amzn2023.0.1 amazonlinux
xxd.x86_64 2:9.2.920-1.amzn2023.0.1 amazonlinux
17個のパッケージが更新対象として表示されました。この結果は、5.1でInspectorが検出したパッケージに対応しています。
| Inspectorの表示 |
check-updateで表示されたパッケージ |
| vim-common, vim-data and 4 more |
vim-common、vim-data、vim-enhanced、vim-filesystem、vim-minimal、xxd（6個） |
| openssl, openssl-fips-provider-latest and 1 more |
openssl、openssl-fips-provider-latest、openssl-libs（3個） |
| microcode_ctl |
microcode_ctl |
| dracut, dracut-config-generic |
dracut、dracut-config-generic |
| kbd, kbd-misc |
kbd、kbd-misc |
| kernel6.18 |
kernel6.18、kernel6.18-tools |
| python3-pip-wheel |
python3-pip-wheel |
この2つの結果の差が、「本来当てるべき更新」と「今のインスタンスから見えている更新」のギャップです。ロックされたままでは、パッケージマネージャーから見て更新は存在しません。この状態でPatch Managerを動かすとどうなるかを、7章以降で確認します。
6. Patch Managerの仕組み
Patch Managerが何をどう選んでパッチを適用しているのかを整理します。
6.1 3つの構成要素
| 要素 |
役割 |
| パッチベースライン |
どのパッチを「承認済み」とみなすかのルール。重要度・分類・自動承認までの日数などを定義 |
| パッチグループ |
パッチベースラインを適用する対象インスタンスのグループ。PatchGroup（またはPatch Group）タグで指定 |
| コンプライアンス |
ベースラインに照らして、各インスタンスが準拠（Compliant）か非準拠（Non-Compliant）かを示す状態。個々のパッチはInstalled／Missingなどの状態を持つ |
6.2 デフォルトのパッチベースラインの中身
AL2023には AWS-AmazonLinux2023DefaultPatchBaseline というAWS提供のベースラインが用意されています。その実体は次のとおりです。
- ルール1：分類 Security、重要度 Critical・Important、自動承認の遅延 7日
- ルール2：分類 Bugfix、重要度の指定なし、自動承認の遅延 7日
- どちらも「セキュリティ以外の更新を含める」はオフ
承認ルールは2行あり、どちらも「承認するまで7日間待機する」となっています。
見落としやすいのが、この「7日」です。SecurityかつCritical／Importantのパッチも、Bugfixのパッチも、7日経過してはじめて自動承認されます。リリース直後のパッチは、スキャンしても未適用として計上されません。
さらにAL2023では、この7日は通常、updateinfo.xmlのRelease DateではなくUpdated Dateから計算されます。Updated Dateはアドバイザリの最終更新日で、説明文の修正だけでも更新されます。パッケージが実際にリポジトリで利用可能になった日と一致するとは限りません。
なお、Patch Managerの別のページでは起算点を「issued（発行日）」とする記載もあり、ドキュメント間で表現が揃っていません。本記事の7.3と11.8の実機結果は、Updated Dateを起算点とした場合と一致しています。
参考：How package release dates and update dates are calculated - AWS Systems Manager
このベースラインでPatch Managerが実行する処理は、次のdnfコマンドと等価であるとドキュメントに明記されています。
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
ここでの「等価」は重要度と分類の条件についての話で、7日の待機は含まれません。また6.4で見るとおり、AL2023ではPatch Managerが最新のリポジトリを参照するため、ロック中のインスタンスでこのコマンドを手で実行しても同じ結果にはなりません。
一方、重要度と分類がデフォルトと同じカスタムベースラインで「セキュリティ以外の更新を含める」をオンにした場合は、次と等価になります。
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
デフォルトベースラインでは、分類がSecurityのアドバイザリのうち、ALASの重要度がMedium以下のものは対象外です（Bugfixは重要度に関係なく対象）。
ここで言う重要度はALASが付与する値であり、5.1で触れたInspectorの重大性（Inspectorスコア）とは別の指標です。Inspectorで「Medium」と表示されている脆弱性でも、ALASの重要度がImportantならデフォルトベースラインで解消されます。実際、5.1でInspectorがMediumと表示していたopensslやmicrocode_ctlの検出も、7.1でImportantとして計上され、デフォルトベースラインで解消されています。
参考：How patches are installed - AWS Systems Manager
6.3 AL2023固有の挙動
ドキュメントには、AL2023について次の補足が記載されています。
重要度 None を指定できる
AL2023では、dnfが認識する重要度 None もベースラインに指定できます。
MediumとModerateは同じ重要度を指す
重要度の呼び方はリポジトリによって異なり、Patch Managerが「Medium」と呼ぶ重要度を「Moderate」と表記するリポジトリもあります。AL2023ではこの2つを同じ重要度として扱います。
そのため、ベースラインにMediumを指定すると、Moderateと表記されたパッチもあわせて適用されます。DescribeInstancePatches APIでコンプライアンスを確認する際も、Mediumで絞り込むとModerateのパッチが一緒に返ります。
推移的依存関係のバージョンが一致しないことがある
あるパッケージを更新すると、そのパッケージが依存する別のパッケージも一緒に更新されます。さらにその依存先が依存しているパッケージ（依存関係の依存関係）を、推移的依存関係と呼びます。
この推移的依存関係について、dnf upgrade-minimal --security をコマンドラインで実行した場合は、セキュリティ問題の解決に必要な最小限のバージョンで止まります。一方Patch Managerは、同じ推移的依存関係を利用可能な最新のバージョンまで更新します。
つまり、6.2で示した「等価コマンド」を手元で実行して確認した結果と、Patch Manager経由で適用した結果とで、インストールされるバージョンが食い違う場合があります。
廃止パッケージの置き換えは行われない
あるパッケージが廃止され、別のパッケージに置き換えられた場合、Patch Managerはその新しいパッケージをインストールしません。dnfコマンドを手で実行すればインストールされますが、Patch Manager経由では入らない、という差があります。
ただし例外が2つあります。新しいパッケージが「更新対象となる別のパッケージの依存関係」である場合と、新旧のパッケージ名が同じ場合は、Patch Manager経由でもインストールされます。
6.4 ここが本記事の確認ポイント
Patch Managerのドキュメントには、次の記述があります。
Patch Manager uses the operating system built-in package manager to install updates on managed nodes. For example, it uses the Windows Update API on Windows Server and DNF on Amazon Linux 2023. Patch Manager respects existing package manager and repository configurations on the nodes, including settings such as repository status, mirror URLs, GPG verification, and options like skip_if_unavailable.
※引用：AWS公式ドキュメント『How patches are installed』（2026年9月29日アクセス）
How patches are installed - AWS Systems Manager
「ノード上の既存のパッケージマネージャーおよびリポジトリの設定を尊重する」と書かれています。これだけを読むと、AL2023のreleaseverによるバージョンロックも「リポジトリの設定」として尊重されるように読めます。
もし尊重されるなら、ロックされたままのインスタンスにPatch Managerでパッチを適用しても、ロック先のリポジトリに存在する更新しか当たりません。実行自体は成功として記録され、コンプライアンスも準拠と表示される一方で、Inspectorの検出は残り続けることになります。
しかし、Patch Managerの別のページには、AL2023について次の注記があります。
Amazon Linux 2023 (AL2023) uses versioned repositories that can be locked to a specific version through one or more system settings. For all patching operations on AL2023 EC2 instances, Patch Manager uses the latest repository versions, independent of the system configuration.
※引用：AWS公式ドキュメント『How patch baseline rules work on Linux-based systems』（2026年9月29日アクセス）
How patch baseline rules work on Linux-based systems - AWS Systems Manager
公式には、AL2023ではシステムの設定に関係なく、すべてのパッチ適用操作で最新のリポジトリバージョンが使われるとされています。つまり、ロックは尊重されません。
ただし、この注記からは「具体的にどうやってロックを越えているのか」「そのときコンプライアンスやInspectorの表示がどうなるのか」までは分かりません。以降は、これを実機で確認していきます。
7. Patch Managerでスキャンする
パッチを当てずにスキャンだけを実行し、Patch Managerから見た現在の状態を確認します。
Systems Managerコンソールの[Patch Manager]から[今すぐパッチ適用]を選択します。この機能を使うと、メンテナンスウィンドウやパッチポリシーのスケジュールを設定しなくても、対象を指定して即時にパッチ適用操作を実行できます。
- パッチ適用オペレーション：スキャン
- ターゲット：対象インスタンス
[今すぐパッチ適用]には、パッチベースラインを選ぶ項目はありません。インスタンスにパッチグループのタグがない場合は、そのOSのデフォルトとして設定されているベースラインが自動で使われます。今回はAWS提供の AWS-AmazonLinux2023DefaultPatchBaseline です。
実行すると[関連付けの実行の概要]が開き、進行状況を確認できます（[今すぐパッチ適用]はState Managerの関連付けとして実行されます）。
参考：Patching managed nodes on demand - AWS Systems Manager
実行後、Patch Managerのコンプライアンス画面で結果を確認します。
結果は次のとおりでした。
| 項目 |
値 |
| コンプライアンス状況 |
非準拠 |
| 重要な非準拠の数 |
0 |
| セキュリティの非準拠の数 |
14 |
| その他の数 |
0 |
「重要な非準拠の数」が0なのは、Criticalのパッチがないからではありません。AWS提供の定義済みベースラインは、適用するすべてのパッチにコンプライアンスレベル Unspecified を割り当てるため、この値は常に0になります。コンプライアンスレベルで重み付けしたい場合は、定義済みベースラインをコピーしてカスタムベースラインを作る必要があります。
ロックされた状態にもかかわらず、14件が未適用として計上されました。 5.3で確認したとおり、インスタンス上で dnf check-update --security を実行しても更新候補は1件も表示されない状態です。それにもかかわらず、Patch Managerのスキャンは未適用のセキュリティパッチを検出しています。
この時点で、Patch Managerのスキャンは、インスタンスがロックしているリポジトリバージョンだけを見ているわけではないことが分かります。6.4で引用した注記のとおりで、注記の「all patching operations」には、インストールだけでなくスキャンも含まれることが確認できます。
7.1 検出された14件の内訳
「セキュリティの非準拠の数」のリンクから、対象のパッケージを確認できます。
dracut.x86_64 Missing Security Important
dracut-config-generic.x86_64 Missing Security Important
kbd.x86_64 Missing Security Important
kbd-misc.noarch Missing Security Important
microcode_ctl.x86_64 Missing Security Important
openssl.x86_64 Missing Security Important
openssl-fips-provider-latest.x86_64 Missing Security Important
openssl-libs.x86_64 Missing Security Important
vim-common.x86_64 Missing Security Important
vim-data.noarch Missing Security Important
vim-enhanced.x86_64 Missing Security Important
vim-filesystem.noarch Missing Security Important
vim-minimal.x86_64 Missing Security Important
xxd.x86_64 Missing Security Important
14件はすべて、分類がSecurity、重要度がImportantです。デフォルトのパッチベースラインが対象とする条件と一致しています。
7.2 5.3の結果との差分
5.3でreleasever=latestを指定したときに表示された更新対象は17パッケージでした。ここでの14件と比べると、次の3つが含まれていません。
- kernel6.18
- kernel6.18-tools
- python3-pip-wheel
python3-pip-wheelについては説明がつきます。該当するCVE-2026-45409をALASで確認すると、重要度はMedium（CVSS 5.3）です。デフォルトのパッチベースラインはCriticalとImportantのみを対象とするため、対象外になります。
参考：CVE-2026-45409
一方、カーネルは事情が異なります。5.1でInspectorが検出していたCVE-2026-74580をALASで確認すると、重要度はImportant（CVSS 7.8）で、AL2023のkernel6.18に対する修正もリリース済みです。
参考：CVE-2026-74580
つまり、ベースラインの条件（Security・Important）を満たしているにもかかわらず、カーネルのパッチはこの14件に含まれていません。 重要度のフィルタでは説明がつきません。
7.3 カーネルはどう扱われているのか
パッチの概要でフィルタを解除し、kernelで検索すると、次のように表示されます。
kernel-livepatch-repo-s3.noarch InstalledOther - -
kernel-srpm-macros.noarch InstalledOther - -
kernel6.18-tools.x86_64 InstalledOther - -
kernel6.18.x86_64 InstalledOther - -
カーネルの状態は Missing ではなく InstalledOther でした。この状態の定義は次のとおりです。
The patch isn't in the baseline, but it is installed on the managed node.
※引用：AWS公式ドキュメント『Patch compliance state values』（2026年9月29日アクセス）
Patch compliance state values - AWS Systems Manager
つまりPatch Managerは、インストール済みのカーネルを「ベースラインに含まれないパッチ」として扱っています。InstalledOtherのコンプライアンス値はCompliantであり、非準拠としては計上されません。
分類と重要度が「-」になっているのも仕様です。同じドキュメントの注記に、InstalledOtherとNotApplicableの状態ではClassificationとSeverityの値が省略されると記載されています。
では、なぜカーネルが「ベースラインに含まれないパッチ」になるのでしょうか。原因は6.2で触れた自動承認の遅延です。
該当するアドバイザリをALASで確認します。
| 項目 |
値 |
| アドバイザリ |
ALAS2023-2026-2106（kernel6.18） |
| Advisory Released Date |
2026-08-31 |
| Advisory Updated Date |
2026-09-09 |
| Severity |
Important |
参考：ALAS2023-2026-2106
今回のスキャンと適用を実施したのは9月11日です。リリース日の8月31日から数えれば11日が経過しており、7日の待機は通過しているように見えます。
しかし6.2で確認したとおり、AL2023の待機期間は、通常はRelease DateではなくUpdated Dateから計算されます。Updated Dateは9月9日なので、経過はわずか2日。7日に届いていません。
この時点でカーネルのパッチはまだ自動承認されていませんでした。承認されていないパッチはベースラインに含まれないため、インストール済みの旧バージョンがInstalledOther＝準拠と表示されていたと考えられます。この解釈は、11.8の再スキャンで裏付けています。
Updated Dateはアドバイザリが更新されるたびに後ろへ動きます。説明文の修正のような小さな更新でも動くため、「リリースから十分に日数が経っているから当たっているはず」という感覚は当てになりません。
ここから読み取れるのは、カーネルの更新状況は、Patch Managerのコンプライアンス表示だけでは判断できないということです。ALASでImportantのセキュリティ修正が公開されていても、待機期間中であればコンプライアンス上は準拠と表示されます。Inspectorが同じカーネルの脆弱性を検出していたのとは対照的な結果です。
パッチ適用の結果を追う場合は、Patch Managerのコンプライアンスだけに頼らず、InspectorやALASを併用する必要があります。
7.4 スキャン結果のまとめ
ノードのパッチ適用の詳細画面では、集計値も確認できます。
| 項目 |
値 |
| Updates installed |
52 |
| Updates with errors |
0 |
| Updates needed |
14 |
ここまでで「スキャンでは14件が見えている」ことが分かりました。次に確認すべきは、この状態でインストールを実行したときに、実際にパッケージが更新されるのかです。8章で確認します。
8. パッチを適用する
ここからが本記事の中心です。ロックされた状態のまま、Patch Managerでパッチを適用するとどうなるかを確認します。
8.1 適用結果
7章と同じく[今すぐパッチ適用]から実行し、オペレーションだけを変更します。
- パッチ適用オペレーション：スキャンとインストール
- ターゲット：対象インスタンス
- 再起動オプション：必要に応じて再起動（既定）
実行後、コンプライアンスレポートを確認すると、7章で「非準拠」だったコンプライアンス状況が「準拠」に変わっています。
ノードのパッチ適用の詳細では、集計値も変化しています。
| 項目 |
スキャン時（7.4） |
適用後 |
| Updates installed |
52 |
66 |
| Updates with errors |
0 |
0 |
| Updates needed |
14 |
0 |
未適用が14件から0件になり、インストール済みが52件から66件に増えています。差はちょうど14件で、7章でMissingとして検出されたパッケージがすべて適用されたことになります。
次に、OS側の状態を確認します。
$ rpm -q system-release
system-release-2023.12.20260909-0.amzn2023.noarch
$ uname -r
6.18.41-94.142.amzn2023.x86_64
ここで注目すべきは system-release です。適用前は 2023.12.20260817 でしたが、2023.12.20260909 に変わっています。
5.3で確認したとおり、このインスタンスには 2023.12.20260831 と 2023.12.20260909 という2つの新しいリリースが提示されていました。Patch Managerは、そのうち最新の 2023.12.20260909 までシステムを引き上げています。
つまり、次のことが確認できました。
Patch Managerは、AL2023のreleaseverによるロックを尊重しません。 ロックされたバージョンの範囲でパッチを探すのではなく、最新のリリースを参照して適用し、system-release自体も更新します。結果として、適用後のインスタンスは新しいリリースバージョンにロックし直された状態になります。
6.4で引用した『How patches are installed』で「尊重する」設定として例示されていたのは、リポジトリの有効・無効、ミラーURL、GPG検証、skip_if_unavailableでした。releaseverによるバージョンロックはこの「尊重」の対象ではなく、6.4の注記どおりの動作が、system-releaseの更新まで含めて実機で確認できました。
これは運用設計に直接影響します。確定的アップグレードは「テスト済みのバージョンにフリートを揃える」ための仕組みですが、Patch Managerでパッチを適用すると、その固定が外れて最新リリースまで進みます。 検証環境で特定バージョンを確認してから本番へ、という運用を組んでいる場合、Patch Managerの適用がその前提を崩すことになります。
8.2 何が実行されたのかをdnfの履歴で確認する
なぜこうなったのかは、インスタンス上のdnfのトランザクション履歴から追えます。
$ sudo dnf history
ID | Command line | Date and time | Action(s) | Altered
---+-------------------------------------------------------------------------------+------------------+-----------+--------
17 | install -y xxd-2:9.2.920-1.amzn2023.0.1.x86_64 --releasever=2023.12.20260909 | 2026-09-11 14:20 | Upgrade | 1
16 | install -y vim-filesystem-2:9.2.920-1.amzn2023.0.1.noarch --releasever=... | 2026-09-11 14:20 | Upgrade | 1
15 | install -y vim-common-2:9.2.920-1.amzn2023.0.1.x86_64 --releasever=... | 2026-09-11 14:20 | Upgrade | 4
14 | install -y openssl-1:3.5.7-2.amzn2023.0.2.x86_64 --releasever=... | 2026-09-11 14:20 | Upgrade | 3
13 | install -y microcode_ctl-2:2.1-53.amzn2023.0.16.x86_64 --releasever=... | 2026-09-11 14:20 | Upgrade | 1
12 | install -y kbd-0:2.4.0-2.amzn2023.0.4.x86_64 --releasever=... | 2026-09-11 14:20 | Upgrade | 2
11 | install -y dracut-0:102-3.amzn2023.0.4.x86_64 --releasever=... | 2026-09-11 14:20 | Upgrade | 2
10 | update system-release -y --releasever=2023.12.20260909 | 2026-09-11 14:19 | Upgrade | 1
※ 長いコマンドラインは --releasever=... と省略しています。時刻はUTCです。
Patch Managerの内部動作がそのまま残っています。読み取れることは2つあります。
1つ目は、すべてのコマンドに --releasever=2023.12.20260909 が明示的に付いていることです。インスタンスがロックしていた 2023.12.20260817 ではなく、利用可能な最新のリリースバージョンが指定されています。8.1で観測した挙動は、この指定によるものです。
2つ目は、最初に実行されているのが system-release の更新（トランザクション10）だという点です。パッケージのパッチを当てる前に、システムのリリースバージョンそのものを引き上げています。その後、承認されたパッケージを1つずつ install しています（トランザクション11〜17）。
トランザクション11〜17のAltered列を合計すると、1 + 1 + 4 + 3 + 1 + 2 + 2 = 14 となり、7章でMissingと判定された14件と一致します。
個々のトランザクションの中身も確認できます。
$ sudo dnf history info 17
Transaction ID : 17
Begin time : Fri Sep 11 14:20:49 2026
User : System <unset>
Return-Code : Success
Releasever : 2023.12.20260909
Command Line : install -y xxd-2:9.2.920-1.amzn2023.0.1.x86_64 --releasever=2023.12.20260909
Packages Altered:
Upgrade xxd-2:9.2.920-1.amzn2023.0.1.x86_64 @amazonlinux
Upgraded xxd-2:9.2.780-1.amzn2023.0.1.x86_64 @@System
Releasever の欄にも 2023.12.20260909 が記録されています。Patch Managerはロックを暗黙に読み飛ばしているのではなく、releaseverの優先順位が最も高いコマンドラインの --releasever（3.2）で最新バージョンを明示し、ロックを上書きしていることが分かります。
8.3 カーネルは更新されたのか
8.1で確認したとおり、適用後の uname -r は 6.18.41-94.142.amzn2023.x86_64 でした。5.3で更新候補として表示されていたのは 6.18.44-99.149.amzn2023 です。
8.2のdnf履歴を見ても、kernel6.18 を対象とするトランザクションはありません。インストール済みのカーネルを確認します。
$ rpm -q kernel6.18
kernel6.18-6.18.41-94.142.amzn2023.x86_64
表示されたのは古いバージョンだけです。カーネルは新しいバージョンが既存のものと並存する形でインストールされるため、更新されていれば、新しいバージョンの行が追加されます（今回なら2行）。1行しか出ていないことから、新しいカーネルはインストールすらされていないと分かります。
7.3で確認したとおり、この時点のカーネルのパッチは自動承認の待機期間中で、ベースライン外として扱われていました。その結果がここに現れています。
整理すると、次の状態になっています。
- ALASはカーネルのセキュリティ修正をImportantとして公開している（Release Dateは適用日の11日前）
- Inspectorはそのカーネルの脆弱性をHighとして検出している
- Patch Managerは自動承認の待機期間中として適用対象とせず、Updates needed は 0 と表示している
「Updates needed 0」は、未適用のセキュリティ修正が存在しないことを意味しません。 ベースラインが対象としているパッチの範囲で未適用がない、という意味です。
なお、再起動オプションを「必要に応じて再起動」にしている場合、更新がインストールされるとノードは再起動されます。カーネルの更新は再起動しなければ有効にならないため、本来はこのオプションが効いてくる場面ですが、今回はそもそもカーネルが承認されていなかったため、再起動しても稼働中のカーネルは変わっていません。
8.4 バージョンを固定したまま運用したい場合
ここまでの結果から、Patch Managerを使う限り、適用先のリリースバージョンは選べないことが分かります。6.4の注記には「one or more system settings」「independent of the system configuration」とあり、/etc/dnf/vars/releasever による固定もこの「システムの設定」に含まれると読めます。releaseverの優先順位（3.2）からも、コマンドラインの --releasever が優先されると考えられます（本記事では実機未検証）。
「検証環境で特定バージョンを確認し、本番にも同じバージョンを適用する」という運用を守りたい場合は、次のような手段が候補になります。
- Run Commandでdnfを直接実行する：AWS-RunShellScript で
sudo dnf upgrade --releasever=（テスト済みバージョン） -y を実行します。AWSはリリースの更新をすべて適用することを推奨しています（3.3で参照したページに記載）。--security などで対象を絞ると system-release が更新されず、ロックが旧バージョンのまま残る場合があるため、実行後に rpm -q system-release で確認します。Patch Managerのコンプライアンス管理は使えません
- カスタムベースラインで代替パッチソースリポジトリを指定する：AWSは、重要なパッチの適用時期を制御したい場合にこの方法を推奨しています。ただし本記事で確認した「Patch Managerが --releasever を明示する」挙動と両立するかは未検証です
- EC2 Image Builderで更新済みAMIを作り、インスタンスを置き換える：3.3で紹介した、AWSが推奨している方法です。適用先バージョンを固定したうえで、テスト済みのイメージをフリートに展開できます
逆に言えば、バージョンの固定より「最新のリリースに追従すること」を優先する運用であれば、Patch Managerの挙動はむしろ都合がよいとも言えます（ただし、自動承認の待機期間中の修正は適用されません）。どちらを取るかは、そのシステムがOS更新に対してどれだけ敏感かによります。
いずれの方法を取るにせよ、新しいリリースが出たことを検知する手段は必要です。AWSからリリース通知を受け取る仕組みが提供されています。
参考：Receive notifications on new updates - Amazon Linux 2023
インスタンス上から直接確認することもできます。
sudo dnf check-release-update
なお、5.3で見たとおり、dnfの実行時には新しいリリースが利用可能である旨が警告として表示されます。日常的にdnfを操作していれば、この警告でも気づけます。
9. 切り戻しまで含めて自動化する：AWS-PatchInstanceWithRollback
5章から8章では、バックアップ・スキャン・適用を手動で分けて実行しました。これらをまとめて1回の処理として実行できるのが、Systems Manager Automationの AWS-PatchInstanceWithRollback ランブックです。
9.1 ランブックの構成
このランブックは12のステップで構成されています。
| # |
ステップ |
アクション |
| 1 |
createDocumentStack |
aws:createStack |
| 2 |
IdentifyRootVolume |
aws:invokeLambdaFunction |
| 3 |
PrePatchSnapshot |
aws:executeAutomation（AWS-CreateSnapshot） |
| 4 |
installMissingUpdates |
aws:runCommand（AWS-RunPatchBaseline、Operation=Install） |
| 5 |
SleepThruInstallation |
aws:invokeLambdaFunction |
| 6 |
WaitForInventoryPropagation |
aws:sleep（10分） |
| 7 |
CheckCompliance |
aws:invokeLambdaFunction |
| 8 |
SaveComplianceReportToS3 |
aws:invokeLambdaFunction |
| 9 |
ReportSuccessOrFailure |
aws:invokeLambdaFunction |
| 10 |
RestoreFromSnapshot |
aws:invokeLambdaFunction |
| 11 |
DeleteSnapshot |
aws:invokeLambdaFunction |
| 12 |
deleteCloudFormationTemplate |
aws:deleteStack |
参考：AWS-PatchInstanceWithRollback - AWS Systems Manager Automation Runbook Reference
公式リファレンスのステップ一覧は11ステップですが、実際のランブックの定義（Systems Managerコンソールの[ドキュメント]→ AWS-PatchInstanceWithRollback →[コンテンツ]、2026年9月時点）では、インベントリの反映を10分待つステップ6が加わっています。上の表は実際の定義に合わせています。
ステップ1と12は、処理に必要なLambda関数などをCloudFormationスタックとして一時的に作成し、最後に削除するものです。
実質的な処理は2から11です。ルートボリュームの特定（2）→ スナップショット取得（3）→ パッチ適用（4）→ インスタンスが稼働状態に戻るまで待機（5）→ インベントリの反映待ち（6）→ コンプライアンス確認（7）→ レポートのS3保存（8）→ 成否の判定（9）→ 失敗時のみスナップショットからの復元（10）→ スナップショットの削除（11）という流れです。
ここで注目すべきは、ステップ4のinstallMissingUpdatesです。定義を見ると、AWS-RunPatchBaseline を Operation=Install で実行しています。つまり、8章の「スキャンとインストール」と同じ処理です。ランブックが追加しているのは、その前後のスナップショット取得と復元です。
9.2 パラメータ
| パラメータ |
必須 |
内容 |
| InstanceId |
必須 |
パッチベースラインを適用する対象のEC2インスタンスID |
| AutomationAssumeRole |
任意 |
Automationが処理を実行するIAMロールのARN。未指定の場合は実行ユーザーの権限が使われる |
| LambdaAssumeRole |
任意 |
Automationが作成するLambda関数が使用するIAMロールのARN。未指定の場合は一時的なロールが作成される |
| ReportS3Bucket |
任意 |
処理中に生成されるコンプライアンスレポートの保存先S3バケット |
事前準備として、AutomationAssumeRole用のIAMロールを用意します（コンプライアンスレポートをS3に保存する場合は、保存先のバケットも用意します）。ランブックは、Lambda関数を含むCloudFormationスタックの作成・削除、Lambda関数の実行、Run Command（AWS-RunPatchBaseline）の実行、子のAutomation（AWS-CreateSnapshot）の実行を行います。ロールにはこれらの権限と、Lambda関数にロールを渡すための iam:PassRole を付与しておきます。LambdaAssumeRoleを省略した場合はスタック内でIAMロールが作成されるため、IAMロールの作成・削除の権限も必要です。実行はSystems Managerコンソールの[Automation]から行います。
9.3 適用されるパッチの範囲は変わらない
9.1で確認したとおり、このランブックが追加しているのはスナップショットの取得と復元であり、パッチの選定と適用そのものは8章とまったく同じです。ステップ4で実行されるのがAWS-RunPatchBaselineだからです。
したがって、次の点は変わりません。
- releaseverのロックは尊重されず、最新のリリースバージョンまで引き上げられる（8.2）
- 自動承認の待機期間を通過していないパッチは適用されない（7.3・8.3）
バックアップと切り戻しは自動化されますが、適用されるパッチの範囲までは変わりません。 むしろ処理が1つにまとまるぶん、手動で分けて実行するより途中経過が見えにくくなる面があります。
9.4 使用前に押さえておく制約
- 保護されるのはルートボリュームのみ：追加でアタッチしたEBSボリュームはスナップショットの対象外です。データボリュームを持つインスタンスでは、別途バックアップが必要です
- 切り戻しの判定基準はパッチコンプライアンスだけ：ステップ7で、パッチコンプライアンスに非準拠の項目が1件でもあれば失敗と判定し、ステップ10で復元します。アプリケーションの正常性やInspectorの検出は判定に使われません。ステップ4のパッチ適用自体が失敗しても処理は止まらず、判定はこのコンプライアンスで行われます。7.3のとおり、待機期間中のパッチはInstalledOther＝準拠と扱われるため、それだけでは切り戻しは起きません
- 切り戻しはボリュームの差し替えで行われる：スナップショットから新しいボリュームを作成し、インスタンスを停止して元のルートボリュームを取り外し、新しいボリュームを取り付けて起動します。パッチ適用中に書き込まれたデータ（ログなど）は新しいボリュームには含まれませんが、取り外された元のボリュームは削除されずに残ります。必要なデータを回収したら、手動で削除してください。停止と起動を伴うため、ダウンタイムも発生します
- スナップショットは処理の最後に削除される：ステップ11のスナップショット削除は、成功時にも復元後にも実行されます。このランブックで取得されるスナップショットは処理中の切り戻し用なので、パッチ適用後も残しておきたい場合は、5.2のようにAMIを別途取得しておきます。一方、途中のステップが失敗して処理が中断した場合は、スナップショットやCloudFormationスタックが残ることがあります。実行履歴を確認し、不要なリソースは手動で削除します
- 一時的にCloudFormationスタックとLambda関数（LambdaAssumeRole省略時はIAMロールも）が作成される：組織のSCPやCloudFormationに関するガードレールによっては、実行できない場合があります
- 対象は単一インスタンス：InstanceIdは1つしか指定できません。フリート全体に適用する場合は、Automationのターゲット指定とレート制御を組み合わせる必要があります
個別のインスタンスに、バックアップと切り戻しを担保しながらパッチを適用したい場面に適したランブックです。
10. 事後確認：Inspectorの結果はどう変わるか
10.1 再スキャンのタイミング
エージェントベースのスキャンでは、インスタンスに新しいソフトウェアがインストールされたタイミングで再スキャンが開始されます。パッチ適用はこの契機に該当します。
ただし、結果が反映されるまでには時間差があります。「最終スキャン日」が更新されるのは、InspectorがSSMインベントリを評価したとき（デフォルトでは30分ごと）です。パッチ適用直後にInspectorの画面を開いても、まだ古い結果が表示されている可能性があります。
10.2 解消された検出と残った検出
しばらく時間を置いてから、対象インスタンスの検出結果を再度確認します。
High CVE-2026-74580 - kernel6.18 Package Vulnerability Active
Medium CVE-2026-45409 - python3-pip-wheel Package Vulnerability Active
22件あった検出が2件になりました。 解消されたのは20件で、7.1でMissingとして計上され、8章で適用された14パッケージ（vim系、microcode_ctl、dracut、kbd、openssl系）に対応するものがすべて消えています。
残った2件は、それぞれ理由が異なります。
| 残った検出 |
Inspectorの重大性 |
残った理由 |
| CVE-2026-74580（kernel6.18） |
High |
アドバイザリのUpdated Dateから7日が経過しておらず、自動承認されていなかった。未承認のためInstalledOther＝準拠と表示されていた（7.3・8.3） |
| CVE-2026-45409（python3-pip-wheel） |
Medium |
ALASの重要度がMediumで、デフォルトベースラインの対象（Critical・Important）から外れる（7.2） |
注目すべきは、カーネルの検出はInspectorでHigh、ALASでもImportantでありながら、Patch Managerでは適用対象にすらならなかったという点です。重要度が低いから見送られたのではなく、タイミングによって漏れています。
なお、今回は該当しませんでしたが、検出が残る理由は他にもあります。
- カーネル更新後に再起動していない：新しいカーネルがインストールされていても、再起動するまで稼働中のカーネルは古いままです
- 廃止パッケージの置き換え：名前が変わる置き換えパッケージは、依存関係として引き込まれる場合を除き、Patch Manager経由ではインストールされません（6.3）
- 修正版がまだリリースされていない：ALASでアドバイザリが発行されているかを確認します
参考：Amazon Linux 2023 Security Advisories
SPAL由来のパッケージはAWSのCVEトラッキング対象外のため、そもそもInspectorの検出やPatch Managerの重要度判定に頼れません。EPEL側の情報を別途確認する必要があります。
10.3 「コンプライアンス準拠」と「脆弱性ゼロ」は同じではない
同じインスタンスの、同じ時点の状態について、2つのサービスが次のように判定しています。
| |
判定 |
| Patch Manager |
準拠（Updates needed 0） |
| Amazon Inspector |
脆弱性2件が残存（うち1件はHigh） |
両者の判定基準が異なるためです。
- Patch Managerのコンプライアンスは、適用中のパッチベースラインのルールに照らして準拠しているかを示すものです
- Inspectorの検出は、インストール済みパッケージに既知のCVEが該当するかを示すものです
パッチベースラインがCritical／Importantのみを対象としていれば、それ以外の脆弱性が残っていてもコンプライアンスは準拠と表示されます。さらに今回のカーネルのように、重要度と分類の条件を満たしていても、自動承認の待機期間中であれば適用対象から外れます。ベースラインの設定だけを見ると対象に入っているように見えるぶん、こちらのほうが気づきにくい漏れ方です。
コンプライアンスが準拠であることを、脆弱性が解消されている根拠として扱わない。 これが、AL2023でパッチ運用を設計するうえでの実務的な結論です。パッチ適用の結果は、Patch Managerのコンプライアンスとは別の指標で確認する必要があります。
11. カスタムパッチベースラインで残り2件を解消する
10章で残った2件は、いずれもデフォルトのパッチベースラインの設計に起因するものでした。ここでは、カスタムベースラインを作成して解消できるかを確認します。
11.1 残っているのはどのパッケージか
OS側で更新候補を確認します。
$ rpm -q system-release
system-release-2023.12.20260909-0.amzn2023.noarch
$ rpm -q kernel6.18
kernel6.18-6.18.41-94.142.amzn2023.x86_64
$ uname -r
6.18.41-94.142.amzn2023.x86_64
$ sudo dnf check-update --releasever=latest --security
kernel6.18.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
kernel6.18-tools.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
python3-pip-wheel.noarch 21.3.1-2.amzn2023.0.21 amazonlinux
残っているのは3パッケージです。7.2で「releasever=latestでは17パッケージ、Patch Managerのスキャンでは14パッケージ」と差分が3パッケージあることを確認しましたが、それがそのまま残っています。
次に、releaseverを指定せずに同じコマンドを実行します。
$ sudo dnf check-update --security
kernel6.18.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
kernel6.18-tools.x86_64 1:6.18.44-99.149.amzn2023 amazonlinux
python3-pip-wheel.noarch 21.3.1-2.amzn2023.0.21 amazonlinux
結果は同じ3パッケージです。 5.3では、releaseverを指定しない場合は更新候補が1件も表示されず、代わりに新しいリリースが利用可能である旨の警告が出ていました。今回はその警告も出ていません。8章のパッチ適用によってsystem-releaseが最新（2023.12.20260909）に更新されたためです。
つまりこの3パッケージは、いまのインスタンスがロックしているリポジトリから見えています。5.3で確認した「ロックされていて見えない」状態とは異なり、ここでは見えているのに適用されなかったことになります。原因はリポジトリのバージョンではなく、パッチベースラインの設定にあります。
11.2 カスタムパッチベースラインを作成する
Patch Managerの[パッチベースライン]タブから新規作成します。デフォルトベースラインとの主な違いは次の3点です。
- 自動承認の遅延を0日に変更：7.3で確認した待機期間による取りこぼしを解消するため
- 重要度にMediumを追加：python3-pip-wheel（ALAS重要度Medium）を対象に含めるため
- 承認済みパッチにカーネルを明示指定：承認済みパッチは承認ルールを迂回するため、保険として指定
なお、このカスタムベースラインは1つのルールに「分類：Security・Bugfix × 重要度：Critical・Important・Medium」をまとめています。そのため、重要度がLowやNoneのBugfixアドバイザリは承認されません（デフォルトのBugfixルールは重要度を指定していません）。Bugfixをデフォルトと同じ範囲にしたい場合は、「分類：Bugfix、重要度：指定なし」のルールを別に追加します。
承認済みパッチリストに指定できる主な形式は、次のとおりです。
- パッケージ名（kernel6.18、kernel6.18.x86_64 など）
- アドバイザリID（ALAS2023-2026-2106 など）
- CVE ID（CVE-2026-74580 など）
- パッケージ名にワイルドカードを1つ含めた形式（kernel6.18* など）
参考：Package name formats for approved and rejected patch lists - AWS Systems Manager
承認済みパッチに指定したものは、承認ルールの条件を満たさない場合でも承認されます。今回はカーネルを確実に対象へ入れるための保険として指定しました。
ただし、バージョンを付けずに kernel6.18 と指定すると、今後の kernel6.18 の更新もすべて待機期間なしで承認されます。あとで遅延を7日に戻しても、カーネルだけは即時に適用されます。本番環境では、アドバイザリID（ALAS2023-…）やCVE ID単位で指定するほうが安全です。
11.3 ベースラインをインスタンスに適用する
カスタムベースラインを作っただけでは、インスタンスには適用されません。2か所の設定が必要です。
1. ベースライン側でパッチグループを登録する
作成したベースラインを選択し、[アクション] → [パッチグループの変更] から、パッチグループ名を追加します。これは「このベースラインはこのグループを担当する」という宣言にあたります。
なお、コンソールでのパッチグループの操作は、パッチポリシーがリリースされた2022年12月22日より前からパッチグループを使っていたアカウント・リージョンでのみ利用できます。メニューが表示されない場合は、AWS CLIの aws ssm register-patch-baseline-for-patch-group を使うか、パッチポリシーを利用します。
参考：Patch groups - AWS Systems Manager
2. EC2インスタンスにタグを付与する
インスタンス側にも、そのグループに属していることを示すタグが必要です。
| 項目 |
値 |
| キー |
PatchGroup（スペースなし）または Patch Group（スペースあり） |
| 値 |
ベースラインに登録したパッチグループ名 |
キーは大文字・小文字を区別します。また、インスタンスで「インスタンスメタデータ内のタグを許可」を有効にしている場合、タグキーにスペースを含められないため、スペースなしの PatchGroup を使う必要があります。どちらの表記を使うかは、環境内で統一しておくことが推奨されています。
参考：Creating and managing patch groups - AWS Systems Manager
このタグがないと、そのOSのデフォルトとして設定されているベースラインが使われます。 タグの値を打ち間違えた場合も、エラーにはならずデフォルトが使われます。7章・8章はまさにその状態で、AWS提供の AWS-AmazonLinux2023DefaultPatchBaseline が適用されていました。ベースラインを作り、パッチグループを登録しただけでは切り替わらない点に注意が必要です。
カスタムベースラインが適用されているかどうかは、スキャン後にノードのパッチ適用の詳細でPatch baseline IDを確認するのが確実です。カスタムベースラインのIDになっていれば、タグが効いています。
11.4 スキャン結果
カスタムベースラインを適用した状態で、[今すぐパッチ適用]から「スキャン」を実行します。
ノードのパッチ適用の詳細で Patch baseline ID がカスタムベースラインのものに変わっていれば、11.3のタグが効いています。
集計値は次のようになりました。
| 項目 |
デフォルトベースライン（8.1） |
カスタムベースライン |
| Updates installed |
66 |
125 |
| Updates with errors |
0 |
0 |
| Updates needed |
0 |
3 |
未適用が0件から3件に増えています。内訳は次のとおりです。
kernel6.18-tools.x86_64 Missing Security Important
kernel6.18.x86_64 Missing Security Important
python3-pip-wheel.noarch Missing Security Medium
カーネルの状態が InstalledOther から Missing に変わりました。 7.3で確認したとおり、デフォルトベースラインでは自動承認の待機期間中で「ベースラインに含まれないパッチ」として扱われ、コンプライアンス上は準拠とみなされていました。
分類と重要度が表示されるようになった点も、7.3の説明と符合します。InstalledOther では ClassificationとSeverity が省略される仕様のため「-」でしたが、Missing になったことで Security・Important という値が現れました。分類・重要度の情報自体は、InstalledOtherと表示されていた時点でもPatch Managerが保持していたことになります。
ここで、変更した3点のうち何が効いたのかを切り分けられる手がかりがあります。承認済みパッチに指定したのは kernel6.18 だけですが、kernel6.18-tools も Missing として計上されている点です。
kernel6.18-tools は承認済みパッチに入れていません。重要度はImportantなので、Mediumを追加した効果でもありません。残る違いは自動承認の遅延を0日にしたことだけです。つまりカーネルは、承認済みパッチへの明示指定がなくても、待機期間さえ通過すれば承認ルールだけで承認されます。
python3-pip-wheel は重要度が Medium と表示されており、こちらは承認ルールに Medium を追加したことが効いています。
Updates installed が 66 から 125 に増えているのは、ベースラインの条件を広げたことで、すでにインストール済みのパッケージのうち「ベースラインの対象」と判定されるものが増えたためと考えられます。スキャンのみのため、実際にインストールされたパッケージは増えていません。
11.5 適用結果
[今すぐパッチ適用]から「スキャンとインストール」を実行し、再起動オプションは「必要に応じて再起動」としました。
$ uname -r
6.18.44-99.149.amzn2023.x86_64
$ rpm -q kernel6.18
kernel6.18-6.18.41-94.142.amzn2023.x86_64
kernel6.18-6.18.44-99.149.amzn2023.x86_64
稼働中のカーネルが 6.18.44-99.149 に変わりました。 8.3では 6.18.41-94.142 のままだったものが、再起動まで含めて反映されています。
rpm -q の結果が2行になっている点にも注目してください。8.3で触れたとおり、カーネルは新しいバージョンが既存のものと並存する形でインストールされます。適用前は1行でしたが、新バージョンが加わって2行になりました。
dnfの履歴を確認します。
$ sudo dnf history
ID | Command line | Date and time | Action(s) | Altered
---+-----------------------------------------------------------------------+------------------+-----------+--------
20 | install -y python3-pip-wheel-0:21.3.1-2.amzn2023.0.21.noarch | 2026-09-12 05:21 | I, U | 2
19 | install -y kernel6.18-tools-1:6.18.44-99.149.amzn2023.x86_64 | 2026-09-12 05:21 | Upgrade | 1
18 | install -y kernel6.18-1:6.18.44-99.149.amzn2023.x86_64 | 2026-09-12 05:21 | Install | 1
※ 時刻はUTCです（日本時間では14:21）。
8.2の履歴と比べると、2つの違いがあります。
1つ目は、カーネルのアクションが Install である点です。kernel6.18-tools が Upgrade（既存バージョンの置き換え）であるのに対し、kernel6.18 は Install（新規追加）として記録されています。
これはカーネルがdnfの installonly パッケージ（複数バージョンを並存させるパッケージ）だからです。古いカーネルを残したまま新しいカーネルを追加し、起動に失敗したときに前のカーネルへ戻せるようにするための仕組みです。rpm -q の結果が2行になるのと同じ理由であり、7.3のInstalledOtherとは別の話です。
2つ目は、--releasever が付いていない点です。8.2では全トランザクションに --releasever=2023.12.20260909 が指定され、その前に system-release の更新が実行されていました。今回はどちらもありません。8章の適用によってsystem-releaseがすでに最新になっているためです。引き上げるべき新しいリリースがある場合にのみ、Patch Managerはreleaseverを明示していると考えられます（ドキュメントに記載はなく、今回の観測結果からの推論です）。
実際、dnf history info でトランザクションの詳細を見ると、コマンドラインに --releasever がないにもかかわらず Releasever の欄には 2023.12.20260909 と記録されています。システムがロックしているバージョンがそのまま使われたことが分かります。
11.6 Inspectorの再確認
10.1で触れたとおり、Inspectorへの反映には時間差があります。しばらく置いてから、対象インスタンスのリソースIDで絞り込んで確認します。
検出結果は0件になりました。
ここで、0件の意味を確認しておきます。検出結果が0件になる原因には「脆弱性が解消された」以外に「スキャン対象から外れた」という可能性もあるためです。[設定]の[リソースカバレッジ]で、対象インスタンスのスキャン状況を確認します。
ステータスは「アクティブにモニタリング中」で、最終スキャン日もパッチ適用より後になっています。スキャン対象から外れたのではなく、スキャンされたうえで検出ゼロであることが確認できました。
11.7 検出件数の推移
ここまでの結果をまとめます。
| 時点 |
Inspectorの検出 |
Patch Managerの判定 |
| パッチ適用前（5章・7章） |
22件 |
非準拠（14件） |
| デフォルトベースラインで適用後（10章） |
2件 |
準拠（0件） |
| カスタムベースラインで適用後（11章） |
0件 |
準拠（0件） |
デフォルトベースラインのままでは、Patch Managerが「準拠」と表示する状態でも脆弱性が2件残っていました。ベースラインを変更することで、その2件も解消できています。
- 自動承認の遅延を0日にする：カーネル（ALAS重要度Important）を対象に含めるため
- 承認ルールの重要度に Medium を追加する：python3-pip-wheel（ALAS重要度Medium）を対象に含めるため
（11.2で指定した承認済みパッチは、11.4のとおり解消に必須ではありませんでした）
AL2023でPatch Managerを使う場合、デフォルトのパッチベースラインには7日の自動承認遅延があり、その起算点は通常、アドバイザリのUpdated Dateです。直近に更新されたアドバイザリの修正は適用されず、それでもコンプライアンスは「準拠」と表示されます。 これが本記事でもっとも実務に効く結論です。
今回はそれがたまたまカーネルでしたが、対象はカーネルに限りません。どのタイミングで適用しても、直近7日以内にUpdated Dateが更新されたアドバイザリは、その回の適用から外れて次回以降に持ち越されます。
遅延を0日にすればこの持ち越しはなくなりますが、リリース直後のパッチが検証なしで入ることになります。遅延を外すかどうかは、直近の修正をすぐに適用できる利点と、リリース直後のパッチを検証なしで受け入れるリスクとを比べて判断することになります。
遅延を外さない場合は、実行間隔をむしろ短めに取り、待機期間を過ぎた修正を早く拾えるようにします。待機期間中の修正はInspectorで把握し、急ぐものはALAS IDやCVE IDでカスタムベースラインの承認済みパッチに追加します。
11.8 補足：待機期間の経過後に、デフォルトベースラインで再スキャンする
ここまでの説明を実機で裏づけておきます。
アドバイザリのUpdated Date（2026年9月9日）から15日が経過した時点で、インスタンスのPatchGroupタグを外してデフォルトのパッチベースラインに戻し、「スキャン」を実行しました。
kernel6.18-tools.x86_64 Installed Security Important
kernel6.18.x86_64 Installed Security Important
状態が InstalledOther から Installed に変わりました。 7.3では「-」だった分類と重要度も、Security・Important として表示されています。
ベースラインの設定は6.2とまったく同じです。11.5で新しいカーネルをインストール済みという違いはありますが、Installedは「ベースラインで承認済み、かつインストール済み」を表す状態です。待機期間を過ぎたALAS2023-2026-2106が、デフォルトベースラインで承認されたと分かります。
カーネルは恒久的にベースラインの対象外だったのではなく、待機期間中のため一時的に承認されていなかった。これが、7.3から追ってきた挙動の答えです。
※ このスキャンは検証から2週間後に実施しているため、Updates installed / needed の値は8.1の時点とは一致しません。その後に公開されたアドバイザリが加わっています。
12. まとめ
本記事では、AL2023を対象に、Inspectorでの脆弱性確認からPatch Managerでのパッチ適用、再確認までの流れを追いました。
- AL2023はAMIごとにリポジトリバージョンがロックされており、何もしなければ、ロック先より新しいリリースの更新はdnfから見えません。参照先はreleasever（コマンドラインフラグ、/etc/dnf/vars/releasever、system-releaseの順に優先）で決まります
- Patch Managerはこのロックを尊重しません。 これはSystems Managerのドキュメントに明記されている仕様で、実機のdnf履歴でも、system-releaseの更新を含むすべてのコマンドに --releasever で最新バージョンを明示していることを確認できました。適用後のインスタンスは、最新のリリースバージョンにロックし直された状態になります
- バージョンを固定したまま運用したい場合は、Run Commandでdnfを直接実行するか、EC2 Image Builderで更新済みAMIを作ってインスタンスを置き換える方法を選ぶことになります
- デフォルトのパッチベースラインには7日の自動承認遅延があり、その起算点は通常、アドバイザリのUpdated Dateです。 今回はカーネルの修正がリリースから11日経っていたにもかかわらず、Updated Dateからは2日しか経っておらず未承認でした。未承認の間、インストール済みのカーネルはInstalledOther（ベースラインに含まれないパッチ）として扱われ、ALASでImportant、InspectorでHighと判定されていてもコンプライアンスは準拠と表示されます
- カスタムベースラインで自動承認の遅延を0日にすれば適用されます。 あわせて承認ルールの重要度にMediumを追加すると、ALAS重要度Mediumの更新も対象に入ります。遅延を外すかどうかは、直近の修正をすぐに適用できる利点と、リリース直後のパッチを検証なしで受け入れるリスクとのトレードオフです
- カスタムベースラインは、作成しただけでは切り替わりません。ベースライン側でパッチグループを登録し、EC2インスタンスにもPatchGroupタグを付与する必要があります。このほか、カスタムベースラインをOSのデフォルトに設定する方法や、Quick Setupのパッチポリシーで指定する方法（AWS推奨）もあります
- パッチ適用はカーネルや共有ライブラリを入れ替える作業です。事前のAMI取得や、AWS-PatchInstanceWithRollbackランブックによる切り戻し手段を組み込んでおきます
- パッチコンプライアンスが準拠であることと、脆弱性が解消されていることは同義ではありません
今回の検証では、Inspectorの検出が22件 → 2件 → 0件と推移しました。デフォルト設定のままでは2件が残り、しかもPatch Managerは「準拠」と表示していました。ベースラインを設計し直して、はじめて0件に到達しています。
7.3でカーネルがInstalledOtherと表示されたときは「カーネルはPatch Managerの対象外なのではないか」とも考えましたが、実際の原因は自動承認のタイミングでした。コンプライアンスの「準拠」は、ベースラインのルールを満たしているという意味でしかありません。まだ承認されていないためにベースラインの対象に入っていないパッチがあっても、「準拠」と表示されます。
AL2からの移行を控えている環境では、OSの移行そのものだけでなく、パッチ運用も設計し直す必要があるという点を、あらためて確認できました。
