はじめに
日々の脆弱性対策のために、パッチ適用を手助けするAWS Patch Manager（以下Patch Manager）を皆さん活用していますか。
脆弱性検知してから手動でパッチアップデート対応を行うのもやり方としてはありますが、ある程度自動化できるPatch Managerは積極的に活用したほうが便利かと思います。
ただ、複数環境（検証、本番）が存在している場合、気にしなければいけないのは、パッチバージョンの環境差分です。
パッチアップデートしたことによる動作確認が必要なサービスであれば、予め動作確認を実施して、問題なければ動作確認をしたパッチバージョンを本番環境に適用する必要があります。
Patch Managerは定期実行でパッチのアップデートを行うことが可能ですが、アプリ影響を考える必要がある環境下では安易な自動アップデートはできません。
今回はPatch Managerのパッチアップデートは都度手動による実行での運用を想定します。
その中でWindows Server(EC2)は考慮しなければならない内容があるので、本稿で取り扱いながら運用について考えていきます。
Patch Managerの手動実行運用
まずは、Windows Serverの考慮はせずに、検証環境と本番環境があるサービスでパッチバージョンの環境差分を出させない運用を考えます。
これは非常にシンプルで、カスタムパッチベースラインの「自動承認」項目にある”特定の日付までにリリースされたパッチを承認する”の設定を行うことで差分を無くせます。
- [Approve patches released up to a specific date] (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。
※引用：カスタムパッチベースラインの作成 (Windows)
このカスタムパッチベースラインの設定を本番環境側で、検証環境でインストールした日付を指定することで、インストールされるパッチバージョンは同一のものが適用されます。
例えば月初日にパッケージの脆弱性が発見されたことを仮定して、
2環境(検証、本番)に対し、パッチ適用の運用する場合、以下のようなイメージで自動承認日を設定します。
Windows Serverでの考慮事項
Patch ManagerではMicrosoft Updateで公開している更新プログラム(パッチ)のリストを取得して、その内容をアップデートしています。
そうした際にAWSドキュメント以下のように説明書きがあります。
Microsoft Windows オペレーティングシステムの場合、Patch Manager は Microsoft が Microsoft Update に公開して Windows Server Update Services (WSUS) で自動的に利用可能になる更新プログラムのリストを取得します。
Patch Manager は各 AWS リージョン で新しい更新を継続的にモニタリングします。利用可能な更新プログラムのリストは、各リージョンで 1 日 1 回以上更新されます。Microsoft からのパッチ情報が処理されると、Patch Manager は最新の更新プログラムで置き換えられた前の更新プログラムをパッチのリストから削除します。したがって、最新の更新のみが表示され、インストール可能になります。例えば、
KB3135456がKB4012214に置き換えられると、Patch ManagerではKB4012214のみが利用可能になります。同様に、Patch Manager がインストールできるのは、パッチ適用オペレーション中にマネージドノードで利用可能になっているパッチのみです。デフォルトで、Windows Server 2019 および Windows Server 2022 は後続の更新に置き換えられた更新を削除します。その結果、Windows Server パッチベースラインで
ApproveUntilDateパラメータを使用しても、ApproveUntilDateパラメータで選択された日付が最新パッチの日付よりも前になっている場合は、以下のシナリオが発生します。
- 置き換えられたパッチはノードから削除されるため、Patch Manager を使用してインストールすることができない。
- 最新の代替パッチがノードに存在するが、
ApproveUntilDateパラメータで指定された日付に従ったインストールにはまだ承認されていない。
内容を簡単にまとめると、「パッチ更新対象のプログラムは最新のバージョンにしかアップデートできない」「ApproveUntilDate（自動承認日）の指定が最新パッチ日付よりも前になっている場合、パッチがアップデートされない」ということです。
Patch Managerの仕様上、更新対象とするプログラムは常に最新バージョンのものでしか取得していないため、運用において非常に注意しなければなりません。
自動承認日の指定を検証環境で実行した日付を指定すれば良いかというと、本番環境の適用までにMicrosoft Update上で更に新しい更新プログラム（パッチ）が出ていた場合、本番環境上では検証環境と同様のパッチバージョンがインストールできないということになります。
また、補足としてWindowsの更新プログラム(パッチ)は緊急時の更新を除き、更新タイミングが定期的に決められています。
セキュリティ更新プログラムは、 米国太平洋標準時間の毎月第 2 火曜日 に公開しています。日本では、時差の関係上、毎月第 2 火曜日の翌日 (第 2 水曜または第 3 水曜) の公開となります。なお、未修正の脆弱性の悪用が広がっているため迅速にセキュリティ更新プログラムを公開する必要性がある場合など、定期的なスケジュール以外の日程でセキュリティ更新プログラムを公開する場合もあります。
※参考：セキュリティ更新プログラム リリース スケジュール (2024 年)
Patch ManagerとEC2（Windows Server）のパッチ運用を考える
今までの内容をまとめると以下となります。
- パッチバージョンによる環境差分を無くすために、カスタムパッチベースラインの自動承認日を設定する
- Patch ManangerのWindows更新プログラム(パッチ)はMicrosoft Updateカタログから最新パッチのみを取得している
- 旧バージョンは指定できない
- Windows更新プログラム(パッチ)が更新されるタイミングは日本時間で第2水曜または第3水曜
このことから検証環境でのパッチインストールは、セキュリティ更新プログラムリリーススケジュールを確認して、実施する必要があります。
一例としては、以下のようなスケジュールであれば、Windows Serverでのパッチバージョンの環境差分は起こらないと考えています。
| 第4月曜 | 検証環境 | パッチインストール |
| 第4火曜〜第1金曜 | 検証環境 | アプリテスト期間 |
| 第2月曜 | 本番環境 | パッチインストール+テスト |
最後に
パッチ運用はサービスを継続して運用していく上では避けては通れない運用です。
PatchManagerは、パッチインストール作業の負担を減らしてもらえる便利なサービスですが、運用設計を注意しないと意外な落とし穴もあります。
サービスや企業体制によっては、更に環境が分かれたり、本番環境へのリリース作業準備が必要だったり運用スケジュールを考えることが多いかと思います。
この記事が少しでも役立てれば幸いです。
以上となります。
