【第10回】AWS Systems Manager攻略マニュアル「PatchManager実践編パッチスキャン、パッチ適用」

Ops Todayでは「面倒なAWSシステム運用を効率化しよう！」をテーマに、AWSリソースを含むシステムの運用をする際に便利なサービス「AWS Systems Manager」に関する記事を複数回にわたってご紹介しています。（記事一覧はこちら）

Patch Managerのメイン機能である「パッチスキャン」と「パッチ適用」について取り上げます。Patch Managerの概要や動作イメージ、実際の開始方法については「PatchManager基本編」で紹介しておりますので、そちらをご覧ください。

パッチスキャンとは

パッチスキャンは、マネージドノードに適用されているパッチを読み取り、OSやアプリケーションが公開するパッチ情報と照合する機能です。

パッチスキャンを実行した結果、未適用かつ適用が必要なパッチを検出することができ、検出後に自動インストールを行うことも可能です。

Patch Managerでパッチスキャン機能を利用するメリット

Patch Managerのパッチスキャンを利用することで、次のメリットがあります。

パッチの欠落や適用失敗といったパッチコンプライアンス状況をすぐに把握できる
パッチコンプライアンス状況をレポートとして出力できる
スケジュールによってスキャンを実行するタイミングを制御できる
スキャン処理のログを残すことができる

複雑なプログラムを組む必要なく、スキャンやレポート出力をスケジュールによる自動実行できるのが利点だと感じます。これらの自動実行はGUIで簡単に設定できます。

また、スキャン処理は Systems Manager Run Commandによって実行され、処理の詳細なログが Run Commandに記録されます。何か問題があった場合など、スキャン処理の出力内容を確認したい場合に便利です。

パッチスキャンの設定項目

別記事「PatchManager基本編」では、Patch Managerの利用を始める際にセットアップ作業としてパッチポリシーの作成が必要でしたが、その設定項目の中でスキャンに関する設定がありました。

パッチポリシーではスキャン対象を選択できましたが、パッチポリシーのターゲットノードとなったマネージドノードでは、パッチポリシーが有効となった瞬間よりスキャン処理がスケジュールで実行されます。

前回は触れなかった、パッチポリシー作成画面のパッチスキャン設定をより詳細に見てみましょう。

パッチスキャンに関する設定は、「スキャンとインストール」欄で行います。

パッチオペレーション

「スキャン」と「スキャンとインストール」の選択肢があります。スキャンのみ行う場合は「スキャン」、スキャン後にパッチの自動インストールまで行う場合は「スキャンとインストール」を選択します。

「スキャンとインストール」を選択すると、「インストールスケジュール」項目が表示され、インストールのスケジューリング設定やインストール後の再起動に関して設定が可能となります。

スキャンのスケジュール

パッチポリシーによるスキャンは、スケジュールで実行されます。ここでは、スケジュールをPatch Managerの推奨設定とするか、独自にカスタマイズするか選択できます。

「推奨される既定値を使用」を選択すると、毎日午前１時（UTC）（日本時間では午前１０時）にマネージドノードに対するスキャンが行われることになります。
「カスタムスキャンスケジュール」を選択すると、「スキャンの頻度」項目が表示され、スケジュールの指定方法について、「日単位」か「カスタムCRON式」のいずれかを選択できます。

スキャンの頻度

「日単位」を選択する場合、毎日何時何分に実行するか hh:mm の形式で指定します。

「カスタムCRON式」を選択する場合、CRON式でスケジュールを指定できます。

cronはUnix系OSに標準搭載されているジョブ管理ツールですが、ここでいう”CRON式”とはメンテナンスウィンドウのCRON式を意味しています。
したがって、メンテナンスウィンドウのCRON式に従って設定しましょう。

例えば、次のスケジュールでスキャンを実行したいとします。

毎週土曜日の23時30分

この場合、CRON式は以下のようになります。

cron(30 23 ? * SAT *)

cron()と記述し、カッコの中にスケジュールを指定するのが特徴です。スペース区切りで各フィールドの値を指定します。

以下に示す表は、各フィールドと使用可能な値およびワイルドカードの一覧です。フィールドの順序は、 cron()のカッコ内で左端から指定する順序と一致します。

フィールド	値	ワイルドカード
分（Minutes）	0～59	, – * /
時間（Hours）	0～23	, – * /
日（Day-of-month）	1～31	, – * ? / L W
月（Month）	1～12 または JAN～DEC	, – * /
曜日（Day-of-week）	1～7 または SUN～SAT	, – * ? / L #
年（Year）	1970～2199	, – * /

アスタリスク（*）は全指定を意味します。例えば、毎日30分ごとにスキャンを実行したい場合は、次のように「分（Minutes）」を 30 とし、それ以外のフィールドにアスタリスクを指定することで実現可能です。

cron(30 * * * ? *）

クエスチョンマーク（?）は、併用できないフィールドを指定する際に使用するワイルドカードです。「日（Day-of-month）」と「曜日（Day-of-week）」は同時に指定できず、どちらか一方を指定する場合は、もう一方にクエスチョンマークを指定する必要があります。

詳しくは、AWS公式ドキュメントのCRON式に関するページを参照してください。

「最初のCRON間隔までターゲットのスキャンを待ちます」というチェックボックスは、マネージドノード検出後に即時実行されるスキャンを無効化させたい際に使用します。

Patch Managerはマネージドノードを検出すると、即時パッチスキャンを実行します。パッチポリシー作成のタイミングで、パッチスキャンよりも優先的に実施したい作業がある場合などに使用するといいでしょう。

インストールスケジュール

パッチスキャンによって要適用（非準拠）判定となったパッチについて、インストールするスケジュールを設定します。パッチスキャン同様、スケジュールをPatch Managerの推奨設定とするか、カスタマイズ設定とするか選択できます。

「推奨される既定値を使用」を選択すると、毎週日曜の午前２時（UTC）（日本時間では午前１１時）にパッチインストールが行われることになります。

インストールの頻度

インストールスケジュールで「カスタムインストールスケジュール」を選択した際に指定可能で、パッチスキャンと同様に「日単位」か「カスタムCRON式」のどちらかを指定できます。

パッチスキャンと異なるのは、「必要に応じて再起動」の項目です。パッチによっては、適用後にノードの再起動が必要なものがあります。この項目をチェックすると、再起動が必要なものを判断し、インストール後の再起動まで自動で実施してくれます。

勝手に再起動されると困る場合は、チェックを外しておきましょう。

パッチスキャン設定の確認

パッチポリシー設定の確認は、「Quick Setup（高速セットアップ）」から行います。使い勝手が悪いことに、Patch Manager のダッシュボードからは確認できません（2025年2月時点）。

ポイント！
パッチポリシーの設定確認は Quick Setup からしか確認できない！

Quick Setupへの移動は、Systems Managerの「変更管理ツール」から行います。

Quick Setupを開いたら、「設定マネージャー」タブをクリックします。設定マネージャーの一覧に設定済みのパッチポリシーが表示されます。「設定タイプ」列に “Patch Manager” と表示されるものがパッチポリシーです。

ラジオボタンをクリックしてパッチポリシーを選択し、画面上部の「詳細を表示」をクリックします。

パッチポリシーの設定詳細画面が表示されます。

この画面からパッチポリシー設定の確認や編集、削除といった基本操作が可能で、ポリシーのターゲットとなっているマネージドノードのステータスも確認できます。

パッチスキャンの実行結果確認

パッチポリシーによるパッチスキャンの実行結果を確認するには、Systems Manager の Run Command を利用します。
スキャン実行の実態は、Run Commandによる SSMドキュメントの実行です。

ポイント！
スキャンやインストールの実行結果は、Run Commandから確認しよう！

Systems Manager の「ノードツール」より、「Run Command」へ移動しましょう。

Run Command の画面が表示されたら、「コマンド履歴」タブをクリックします。
実行された Run Commandの履歴が一覧で表示されるので、「リクエストされた日付」列と「ドキュメント名」列より、内容を確認したいスキャンの履歴に見当をつけます。

パッチスキャンは、「ドキュメント名」列に “AWS-RunPatchBaseline” か “AWS-RunPatchBaselineAssociation” で表示されます。

対象の履歴に見当が付いたら、コマンドIDのリンクをクリックしましょう。

履歴の詳細画面では、コマンドの説明やパラメータ、実行ターゲットなどの情報を確認できます。
パッチスキャンの履歴では、「コマンドのパラメータ」セクションの「Operation」欄に “Scan” と表示されます（スキャンとインストールの場合は “Install” と表示されます）。

この画面で、様々なステータスが表示されますが、それぞれ「成功」と表示されていれば、スキャン処理は問題なく行われたと判断していいでしょう。
より詳細なコマンドの出力を確認したい場合は、「ターゲットと出力」セクションの「インスタンスID」リンクをクリックします。

インスタンスIDのリンクをクリックすると、次のページが表示されます。

コマンドの実行結果はステップ単位で整理され、各ステップの「Output」や「Error」に表示されたコマンドの出力結果から詳細を読み取ることができます。
コマンドがエラーとなった場合は、エラー原因の分析に役立つでしょう。

ただし、この画面では24,000字以上の出力はできないため、出力結果が多くなることに備えて、S3ストレージにログを出力する設定を有効化しておくことを推奨します（前回記事で触れています）。

パッチ適用を実行

続いて、パッチ適用について解説します。

パッチコンプライアンス非準拠のノードにパッチを適用する

パッチスキャンは、必要なパッチが無いノードをパッチコンプライアンス非準拠であるとして検出します。パッチコンプライアンス非準拠のノードに対してパッチ適用操作を実行することで、準拠した状態にすることができます。

パッチコンプライアンス非準拠のノード数は、Patch Managerのダッシュボードに表示されます。
「コンプライアンス違反数」に “パッチが欠落しているノード”、”パッチが失敗したノード”、”再起動を保留中のノード”のいずれかがカウントされている場合、カウント数のリンクをクリックして詳細を確認できます。

今回は、「パッチが欠落しているノード」のリンクをクリックしました。
コンプライアンス違反ノードについて、パッチが欠落しているノードが一覧表示されます。
さらに「セキュリティの非準拠の数」列のリンクをクリックすることで、さらに詳細を確認できます。

次の画面で、欠落しているパッチが一覧表示され、パッチの「名前」や「分類」、「重要度」、「コンプライアンスレベル」などの情報を確認できます。

なお、パッチごとにラジオボタンが用意されているため、あたかもパッチ単位で個々にインストールができるように見えますが、個別にパッチを選択してインストールすることはできません。
パッチ適用は、このページで表示されるすべてのパッチを対象に実施することになります。

※パッチを選択状態にすると、対応する CVE-ID やパッチの概要を分割パネル（画面右側ペイン）上で確認できるという意義はあります。

「今すぐパッチ適用」をクリックすると、「今すぐインスタンスにパッチを適用する」画面が表示されます。

設定項目の内容を見ると、パッチポリシー設定で指定した設定項目と同じような内容であることが確認できます。

このインタフェースは、ユーザーの誤解を招くと感じました。１つ前の画面で「今すぐパッチ適用」というボタンをクリックすることで当該画面に移ったわけですが、それにもかかわらず、「スキャン」か「スキャンとインストール」を選択させるのは変に感じます。
そして、「スキャン」を選択した状態で操作を進めた場合、最終的にパッチ適用、すなわちパッチのインストールは行われません。

したがって、パッチ適用、すなわちパッチのインストールまで実施したい場合は、「パッチ適用操作」の欄で必ず「スキャンとインストール」を選択するようにしてください。

ポイント！
「今すぐパッチ適用」で「スキャン」を選択すると、パッチは適用されないので注意！

「再起動オプション」項目では、必要に応じて再起動を行うか指定できますが、パッチポリシー設定の時とは異なり、再起動の実施タイミングをスケジューリングできます。
再起動の実施タイミングをスケジューリングする場合は、「再起動時間をスケジュール」を選択してください。例えば、日中にパッチ適用を行い、システムに影響の無い夜間に再起動を実施するといった制御が可能です。
※タイムゾーンの指定に気を付けてください。

「パッチを適用するインスタンス」項目では、パッチ適用の対象インスタンスを個別に指定するか、あるいは指定しない（全インスタンスを対象とする）か選択できます。

個別に指定する場合は、「パッチを適用するインスタンス」欄にて、「指定したターゲットインスタンスにのみパッチを適用する」を選択します。
対象インスタンスは、タグ指定、手動指定、リソースグループ指定といった３通りの方法で指定することが可能です。

「ログストレージのパッチ適用中」項目では、パッチ適用操作のログをS3バケットに保存するか否か、保存する場合は保存先S3バケットの指定を行います。

S3バケットにログを保存しない場合は、「ログを保存しません」を選択します。
S3バケットに保存する場合、プルダウンリストに既存のS3バケットが表示されます。

この画面からS3バケットの作成操作はできないので、新規でS3バケットを用意したい場合は、あらかじめS3サービスでバケットを作成しておきましょう。

最後に、「詳細オプション」として、ライフサイクルフックの設定が可能です。

ライフサイクルフックを利用することで、パッチ適用に付随する処理を実行できます。

例えば、パッチを適用する前にアプリケーションをシャットダウンする、パッチ適用後や再起動後にアプリケーションのヘルスチェックをするなどの処理をライフサイクルフックで実現できます。
※ライフサイクルフックを利用するには、Systems Manager の Documents でSSMドキュメントを用意する必要があります。いずれ、Documents を取り上げる際に、解説するかもしれません。

特に付随処理を実行しない場合は、「AWS-Noop」を指定します（既定値）。
※「AWS-Noop」は、何も処理を行わないことを意味する設定値です。

すべての項目について設定を終えたら、画面右下にある「今すぐパッチ適用」をクリックすることでパッチ適用処理が開始します。
※確認画面は表示されず、クリック直後、即時に処理が開始するので注意してください。

パッチ適用処理の開始後、「関連付けの実行の概要」画面が表示されます。
処理中は「ステータス：Pending」で、以下のように表示されます。

パッチ適用処理が完了すると、以下のように「ステータス：Success」に変わります。

Run Command履歴からパッチ適用状況を確認する

実際にパッチが適用されているか確認してみます。

パッチ適用の際に実行された Run Command のログから、パッチ適用処理の結果を確認できます。
Patch Managerの「ダッシュボード」画面下側にある「パッチポリシーに基づかないオペレーション」欄に、オンデマンドによるパッチ適用操作のリンクが表示されます。

パッチ適用操作の詳細を確認するには、「Install」リンクをクリックしてください。
対象ログは、「終了時刻」列や「ターゲット」列などの情報から判断してください。

コマンドの詳細情報が表示されるので、「Output」に出力されている内容を参照することで、適用したパッチを確認することができます。
Outputから確認できる “適用に成功したパッチ” と、パッチ適用実行前に確認した “欠落しているパッチ”、あるいは “失敗したパッチ” が一致していれば、必要なパッチが漏れなく適用されたと判断できます。

適用作業前に確認した対象パッチは、「KB5050187」と「KB5051979」でした。
Outputの内容とも一致していたので、漏れなく適用できたようですね。

マネージドノードでパッチ適用状況を確認する

次に、マネージドノードのOS側でも適用状況を確認してみます。
今回は Windows Server 2022 をOSとするノードにパッチを適用しました。

フリートマネージャーより、対象ノードに接続して確かめます。
Windows の場合、コマンドプロンプトにて次のコマンドを実行することで、適用済みのプログラムを表示することができます。

wmic qfe

出力結果の「Install Date」で、今回のパッチ適用でインストールされたプログラムを判断します。

上の図の出力結果だと、Patch Managerから適用されたのは「KB5049617」、「KB5051979」、「KB5050117」の３つと判断できます。
「KB5051979」は想定通りで Run Command の Output とも一致しますが、他の２つは一致していません。

「KB5049617」の不一致は、累積プログラムであることが関係していると考えます。
累積プログラムとは、過去のプログラムを累積したもので、最新のパッチを適用すると、それ以前にリリースされた修正も含めて一括で適用してくれます。
こちらで独自に調査した結果、「KB5049617」は「KB5050187」を包含する累積プログラムだったので問題ないと判断します。

今回の対象ノードはインターネットへ接続可能であり、必要なパッチの問い合わせは Windows Updateサービスを通じて行われました。
Windows Updateサービスは、OS構成に応じて必要なパッチを自動判定してくれますが、今回の処理過程では「KB5049617」が対象パッチであると判断された様です。

一方、「KB5050117」は SSU（Servicing Stack Updates）と呼ばれるもので、ざっくりいうとWindows Updateによるプログラム更新を補助するプログラムです。
Patch Managerによる適用の対象とはなっていませんでしたが、今回の更新でWindows Updateサービスにより適用されたと解釈します。
したがって、これも問題ないと判断します。

このように、Patch Managerからパッチを適用する場合、必ずしもOSの内容と一致するとは限りません。Patch Managerからのパッチ適用の結果は、Patch Managerコンソールからだけでなく、実際の環境上でも確認しておくことが大事でしょう。

ちなみに、Linux環境では、rpmやdnf、Zypper等のパッケージ管理ツールを利用することで、同様にパッチの適用状況を確認することになります。

ポイント！
実際にどのパッチが適用されたのか、実態を確認するようにしよう！