キーワードで検索

今日を知り、明日を変えるシステム運用メディア

AWS Systems Manager攻略マニュアル「PatchManager実践編 パッチベースライン、パッチグループ」

【第11回】AWS Systems Manager攻略マニュアル「PatchManager実践編 パッチベースライン、パッチグループ」

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

今回も、Patch Manager を取り上げ、「パッチベースライン」と「パッチグループ」について解説します。

パッチベースラインの種類

パッチベースラインは、適用対象とするパッチの選別に利用するドキュメントです。パッチベースラインには、次の2種類があります。

  1. 定義済みパッチベースライン
  2. カスタムパッチベースライン

定義済みパッチベースラインは、AWSが事前に用意しているパッチベースラインです。設定をカスタマイズすることはできず、定義をそのまま利用します。

一方、カスタムパッチベースラインは、定義済みパッチベースラインをコピーする形で作成するため、定義済みパッチベースラインをベースに、独自にカスタムして利用できるパッチベースラインです。

パッチベースラインが対応するOS

パッチベースラインが対応するOSは、次の通りです。

  • AlmaLinux
  • Amazon Linux 1
  • Amazon Linux 2
  • Amazon Linux 2022
  • Amazon Linux 2023
  • CentOS および CentOS Stream
  • Debian Server
  • macOS
  • Oracle Linux
  • Raspberry Pi OS
  • RHEL(Red Hat Enterprise Linux)
  • Rocky Linux
  • SLES(SUSE Linux Enterprise Server)
  • Ubuntu Server
  • Windows Server

これらのOSについて、それぞれに定義済みパッチベースラインが用意されています。

※Windows Serverには、以下3種類の定義済みパッチベースラインが用意されています。更新の対象がOSプログラムのみか、Microsoft製品のパッチも含むかの違いです。

定義済みパッチベースライン名更新対象とするパッチの種類
AWS-DefaultPatchBaselineOSプログラムのパッチを対象とする。
AWS-WindowsPredefinedPatchBaseline-OSOSプログラムのパッチを対象とする。
「AWS-DefaultPatchBaseline」と全く同じだが、「AWS-WindowsPredefinedPatchBaseline-OS-Applications」と名称で区別する目的で用意されている。
AWS-WindowsPredefinedPatchBaseline-OS-ApplicationsOSプログラムのパッチに加え、Microsoft製アプリケーションのパッチも対象とする。

カスタムパッチベースラインを作成してみよう

この章では、カスタムパッチベースラインの作成手順について解説します。また、今回はAmazon Linux 2023を対象OSとした場合を例として手順を説明しています。

カスタムパッチベースラインの作成場所

カスタムパッチベースラインの作成は、「パッチベースラインの作成」画面から行います。

まず、Patch Managerのページに移動し、「パッチベースライン」タブをクリックします。画面下ペインにパッチベースラインの一覧が表示されるので、その右上にある「パッチベースラインを作成する」をクリックします。

「パッチベースラインの作成」画面が表示されます。

パッチベースラインの設定項目と作成

「パッチベースラインの作成」画面の各設定項目を見ていきます。このセクションでは、作成するパッチベースラインの「名前」、「説明」、「オペレーションシステム」、「デフォルトのパッチベースライン」を設定します。

特筆すべきは、デフォルトのパッチベースライン設定です。これをチェック状態にすると、作成したパッチベースラインが、選択したOSに紐付くデフォルトパッチベースラインとなります。

ただし、パッチグループ(※)に関連付けていないマネージドノードで、且つ今回選択したOSで稼働するものが存在する場合、このパッチベースライン作成時点から即時に設定が適用されてしまうため注意が必要です。

※パッチグループについては後述します。

オペレーティングシステムの承認ルール

このセクションでは、パッチベースラインでパッチを自動承認するルールを定義します。

対象

対象とするOS製品名を指定します。
前セクションの「オペレーションシステム」で選択したOSによって、プルダウンリストに表示される選択項目が変わります。Amazon Linux 2023 の場合の選択肢は “AmazonLinux2023” のみですが、他OSだとバージョンごとに選択肢が設けられます。

以下の画像は、オペレーティングシステムに「Ubuntu」を選択した場合のプルダウンリスト表示です。

分類(セクション)

対象とするパッチの種類を指定します。この項目も、前セクションの「オペレーションシステム」で選択したOSによって、プルダウンリストに表示される選択項目が変わります。
※SUSEやUbuntuを選ぶと「分類」から「セクション」に表記が変わります。

Amazon Linux 2023を選択した場合に表示される選択肢は次の通りです。

分類名称説明
All全種類のパッチを対象とします
Securityセキュリティ修正パッチを対象とします
Bugfixバグ修正パッチを対象とします
Enhancement拡張パッチを対象とします
Recommended推奨機能パッチを対象とします
NewPackagenewpackage関連パッチを対象とします

Amazon Linux 2023 はRHELをベースにしており、dnf によるパッケージ管理を行います。これらの選択肢は、dnfコマンドのオプションと関連付いている様です。

RHEL系のLinux OSでは、この選択肢と一致します。一方、同じLinux OSでもSUSEやUbuntuなど系統が変わると、プルダウンリストの内容も異なります。

また、Windowsを選択した場合も、プルダウンリストの内容は大きく異なります。Windowsの場合における、各分類の詳細はMicrosoft公式ページを参照してください。

重要度(優先度)

対象とするパッチの重要度レベルを指定します。「分類」同様、前セクションの「オペレーションシステム」で選択したOSによって、プルダウンリストに表示される選択項目が変わります。
※SUSEやUbuntuを選ぶと「重要度」から「優先度」に表記が変わります。

Amazon Linux 2023を選択した場合は、次の選択肢が表示されます。

重要度レベル名称説明
All全重要度レベルのパッチを対象とします
Critical重要度レベル=Critical のパッチを対象とします
Important重要度レベル=Important のパッチを対象とします
Medium重要度レベル=Medium のパッチを対象とします
Low重要度レベル=Low のパッチを対象とします
None重要度レベル=None のパッチを対象とします

これら重要度レベルの値は、パッチ発行元の報告に基づいたもので、AWS側でAPIを実行して都度取得しています。

※オペレーティングシステムで MacOS を選択した場合、重要度は設定できません。MacOSの場合、重要度に関係なくすべてのパッチを対象とするためです。

自動承認

自動承認の対象とするパッチの選定方法を指定します。

自動承認の選択肢説明
指定した日数後にパッチを承認するパッチリリースあるいは更新からの経過日数を元に自動承認の対象を選定します。
0-360までの整数を指定可能です。
特定の日付までにリリースされたパッチを承認する特定日付以前にリリースされたパッチを自動承認対象とします。

※オペレーティングシステムで「Debian」、「Raspberry Pi OS」、「Ubuntu」のいずれかを選択した場合、自動承認の設定はできません。これらのOSは、更新パッケージのリリース日を確実に特定できないことが理由です。

コンプライアンスレポート

この自動承認ルールの対象となったパッチについて、重大度レベルを割り当てます。割り当て可能な重大度レベルは6段階あります。

  • 未指定
  • 重大
  • 情報

承認されたパッチのステータスがMissing(※)になった際、パッチベースラインで報告されるコンプライアンス全体の重要度は、この項目で指定した重要度レベルになります。
※ステータス “Missing” は、パッチベースラインで承認されたパッチがインストールされていない状態です。

なお、定義済みパッチベースラインでは、”未指定” が設定値となっています。

セキュリティ以外の更新を含める

セキュリティに関連しないOSのパッチをインストールしたい場合にチェック状態にします。

※オペレーティングシステムで「MacOS」、「SUSE」、「Windows」のいずれかを選択した場合、この設定はできません。

パッチの例外

このセクションでは、明示的に承認するパッチ、あるいは明示的に拒否するパッチを指定できます。
ここで指定したパッチは、前セクションで設定した承認ルールに一致するか否かに関わらず、例外的な承認や拒否の対象となります。

明示的に承認するパッチは「承認済みパッチ」、明示的に拒否するパッチは「拒否されたパッチ」です。どちらもカンマ区切りで指定します。
承認済みパッチに関しては、コンプライアンスレポートやセキュリティ以外の更新を含むかの設定が可能です(設定の内容は、前セクションで解説した通りなので説明は割愛します)。

※承認済みパッチにセキュリティ以外の更新を含めるかについて、「MacOS」、「SUSE」、「Windows」のいずれかをOSとして選択した場合に設定できない点も、前セクションの説明と共通です。

拒否されたパッチに関しては、拒否後のアクションとして次のどちらかを指定します。

依存関係として許可別のパッケージと依存関係にあれば、拒否さ
れたパッチでもインストールする
ブロックいかなる場合もインストールを許可しない

タグの管理

このセクションでは、パッチベースラインにタグを関連付けることができます。

設定項目は以上です。設定内容を確認し、画面の一番下にある「パッチベースラインの作成」をクリックします。

クリック直後、パッチベースラインの一覧画面に戻りますが、作成に成功すると次のメッセージが画面上部に表示されます。

デフォルトパッチベースラインの設定変更

作成したカスタムパッチベースラインを、デフォルトパッチベースラインに設定する手順を解説します。

デフォルトパッチベースラインの設定は、Patch Managerの「パッチベースライン」画面より行います。
現時点でデフォルトパッチベースラインであるか否かは、「デフォルトのパッチベースライン」列を確認します。

「デフォルトのパッチベースライン」列に表示される値は、次の意味があります。

説明
はいデフォルパッチベースラインに設定されている
いいえデフォルパッチベースラインに設定されていない

デフォルトパッチベースラインにするパッチベースラインのラジオボタンをクリックします。そのうえで、リスト右上の「アクション」をクリックし、表示されたメニューより「デフォルトパッチベースラインの設定」をクリックします。

次のメッセージポップアップが表示されます。「デフォルトの設定」をクリックすることで、このパッチベースラインをデフォルトパッチベースラインに設定できます。

改めてパッチベースライン一覧の「デフォルトのベースライン」列を確認すると、新しくデフォルトパッチベースラインに設定したパッチベースラインに “はい” が表示されています。
また、これまでデフォルトパッチベースラインであった方は “いいえ” に変更されています。

これでデフォルトパッチベースラインの設定変更は完了です。

パッチグループによる管理

複数のマネージドノードを対象にPatch Managerでパッチ管理を行う場合、パッチグループを利用すると便利です。
パッチグループを利用することで、パッチベースラインを適用するマネージドノードをグループ化することができます。パッチベースラインの設定変更やデフォルトパッチベースラインの切り替えといった操作もパッチグループ単位で実施でき、パッチ管理の運用効率が向上するでしょう。

パッチグループの利点

パッチグループを利用することで、次のような利点があります。

予期しないパッチの自動適用を回避することができる

パッチグループに属さないマネージドノードは、パッチポリシーによるパッチ管理の対象となります。
パッチポリシーのパッチベースライン設定を推奨設定にしている場合、適用されるパッチベースラインはデフォルトパッチベースラインであり、パッチベースラインの作成や変更を行う際、予期しない変更やパッチ適用の対象となる恐れがあります。

パッチグループを活用することで、上記のようなアクシデントを回避できるでしょう。

環境を分けて段階的にパッチを適用できる

例えば、「開発環境」、「本番環境」といったパッチグループを作成できます。これにより、開発環境でパッチ適用の影響を検証してから、本番環境への適用を検討するような運用を実現できます。

パッチグループ単位で異なるパッチベースラインを関連付けられる

パッチベースラインは、パッチグループに対して紐付けることができます。同じOSを対象としたパッチベースラインでも、グループごとに異なる承認ルールやパッチの例外設定を行うことができます。

パッチグループの設定手順

マネージドノードに対して “Patch Group” (“PatchGroup”でも可)というタグキーを設定することで、特定のマネージドノードをパッチグループに所属させることができます。

設定手順は、大きく2つのステップに分けることができます。

  1. パッチグループにマネージドノードを追加する
  2. パッチベースラインにパッチグループを追加する

パッチグループにマネージドノードを追加する

Systems Managerのフリートマネージャーへ移動し、マネージドノードの一覧より、パッチグループに所属させたいマネージドノードの「ノードID」リンクをクリックします。

マネージドノードの詳細ページにて、画面左ペインの「全般」メニューにある「タグ」をクリックすることで、タグの詳細画面が表示されます。タグの詳細画面で、画面右上の「管理」をクリックします。

「タグの管理」ポップアップが表示されるので、「新しいタグを追加」をクリックします。

“Patch Group” (“PatchGroup”でも可)というタグキー名でパッチグループ用タグを追加します。値は任意です。

※以下の画像のように、”PatchGroup”の方で設定することを推奨します。対象マネージドノードがEC2インスタンスである場合、EC2側で「インスタンスメタデータ内のタグを許可する」設定を有効化していると、タグキーに半角スペースを入れられないためです。

タグキーの追加に成功すると、画面上部に次のメッセージが表示されます。

以上、パッチグループにマネージドノードを追加する手順です。

なお、EC2インスタンスに関しては、EC2コンソールからもタグの設定が可能ですが、今回解説した手順はEC2インスタンス以外のデバイス(オンプレミスやエッジデバイス)にも対応した手順なのでお勧めです。

パッチベースラインにパッチグループを追加する

Patch Managerの「パッチベースライン」タブ画面に移動します。
パッチベースラインの一覧より、パッチグループと紐付けたいパッチベースラインを選択します。リスト右上の「アクション」をクリックして表示されるメニューより、「パッチグループの変更」をクリックします。

「パッチグループの変更」ポップアップが表示されます。「パッチグループ」欄に、ステップ①でマネージドノードに追加したパッチグループ用タグキーの「値」を入力し、入力欄の右にある「追加」をクリックします。
※タグの「キー」ではなく、「値」を入力することに注意してください。

パッチグループの追加に成功すると、画面上部に次のメッセージが表示されます。

パッチグループとパッチベースラインの紐付け設定をコンソール上で確認するには、Patch Managerの「パッチグループ」タブをクリックします。

以下画像のように、「パッチベースラインの関連付け」一覧に、これまでの手順で紐付けたパッチグループの情報が表示されていれば、紐付けは正常に完了していると判断できます。

さいごに

今回は「AWS Systems Managerフル攻略マニュアル」の第11回ということで、Patch Managerにおけるパッチベースライン、パッチグループについて解説しました。

どちらもPatch Managerを使いこなすうえで欠かせない機能ですので、この記事を参考に実際に設定してみて、色々試していただけると幸いです。

Patch Managerの解説は次回まで行います。是非とも次回の記事も合わせて参考にしてください。

サーバエンジニア歴7年、ネットワークエンジニア歴4年。 長らくSI業界のインフラ部隊に勤め、基本設計から導入まで一通りの経験あり。

この記事を含む特集

AWS Systems Manager攻略マニュアル

面倒なAWSシステム運用を効率化!AWS Systems Manager攻略マニュアル

最新情報をお届けします!

最新のITトレンドやセキュリティ対策の情報を、メルマガでいち早く受け取りませんか?ぜひご登録ください

メルマガ登録

最新情報をお届けします!

最新のITトレンドやセキュリティ対策の情報を、メルマガでいち早く受け取りませんか?ぜひご登録ください

メルマガ登録