こんにちは、ロジカル・アーツの井川です。
AWS Systems Manager パッチマネージャーを使用して、マネージドノードに対してパッチを自動的に適用できます。今回は EC2 インスタンスをターゲットにパッチを適用してみます。
はじめに
この記事では開発環境にパッチを適用し、問題がないことを確認したうえで本番環境に適用する運用フローを想定した設定を行います。また、開発環境にパッチを適用した際に本番環境には適用したくないパッチが出てきたとします。
開発・本番環境については同一の Windows Server 2022 AMI から作成された EC2 インスタンスを 1 台ずつ用意し、それぞれ以下のタグを付けることとします。
開発環境
キー | 値 |
---|---|
Name | dev-server |
PatchTarget | demo-dev |
本番環境
キー | 値 |
---|---|
Name | prod-server |
PatchTarget | demo-prod |
さらに、各インスタンスには SSM Agent(2.0.834.0 以降)がインストールされているとします。そのほかのパッチマネージャーの前提条件は以下のリンクを参照してください。
それではパッチ適用の準備をしていきます。なお、インスタンスの作成手順は省略します。
手順
おおよそ以下の作業を行います。
- パッチベースラインの作成
- パッチポリシーの作成
- パッチの除外とパッチ適用結果の確認
パッチベースラインの作成
パッチベースラインではパッチの自動承認ルールや、承認または拒否するパッチリストを定義します。事前定義されたものもありますが、細かく設定したい場合は作成する必要があります。
今回は開発環境用と本番環境用のベースラインをそれぞれ作成します。
まず、開発環境用のベースラインを作成します。
Systems Manager のコンソール画面の左ペインの「パッチマネージャー」をクリックし、「パッチベースライン」タブ、「パッチベースラインを作成する」の順でクリックします。
「名前」に「Demo-DevBaseline」と入力し、「オペレーティングシステム」は「Windows」を選択します。
「オペレーティングシステムの承認ルール」では、下記の項目については表のとおりに設定し、そのほかについてはデフォルトのままにします。
項目 | 値 |
---|---|
分類 | SecurityUpdates |
重要度 | Critical,Important |
以降も特に設定は変更せず、画面右下にある「パッチベースラインを作成する」をクリックします。
本番環境用のベースラインも「名前」を「Demo-ProdBaseline」にする以外は開発環境用と同じ設定で作成します。
パッチポリシーの作成
パッチポリシーではパッチのスキャンやインストールのスケジュール、対象インスタンスなどを定義します。パッチベースラインもこのポリシーに含まれます。
こちらも開発環境用と本番環境用のものを作成します。
パッチマネージャーの画面で右上の「パッチポリシーを作成」をクリックします。
まず、「設定名」に demo-dev-patch-policy
と入力します。
「スキャンのインストール」では以下の表のように設定します。
項目 | 値 | 備考 |
---|---|---|
パッチオペレーション | スキャンとインストール | |
スキャンのスケジュール | カスタムスキャンスケジュール | |
スキャンの頻度 | 日単位 | |
-- | 04:00 | UTC |
最初の CRON 間隔までターゲットのスキャンを待ちます | チェック | |
インストールスケジュール | カスタムインストールスケジュール | |
インストールのスケジュール | カスタムインストールスケジュール | |
インストールの頻度 | 日単位 | |
-- | 05:00 | UTC |
最初の CRON 間隔までターゲットのスキャンを待ちます | チェック | |
必要に応じて再起動 | チェック |
「パッチベースライン」では、「カスタムパッチベースライン」を選択し、Windows Server のベースラインを先ほど作成した Demo-DevBaseline
に変更します。
「ログストレージにパッチ適用」の「S3 バケットに出力を書き込む」のチェックはこの記事では外しておきますが、必要であればつけてください。
「ターゲット」では「ノードタグを指定」を選択し、タグを以下のように指定します。
項目 | 値 |
---|---|
PatchTarget | demo-dev |
「インスタンスプロファイルオプション」は必要であればチェックを入れて下さい。
最後に「作成」をクリックします。
本番環境用も基本的に同様の手順で作成します。開発環境用と異なる点は以下の通りです。
「設定名」に demo-dev-patch-policy
と入力します。
「スキャンのインストール」では以下のように設定します。
項目 | 値 | 備考 |
---|---|---|
スキャンの頻度 | 06:00 | UTC |
インストールの頻度 | 07:00 | UTC |
必要に応じて再起動 | チェックしない |
「パッチベースライン」では、「カスタムパッチベースライン」を選択し、Windows Server のベースラインを Demo-ProdBaseline
に変更します。
「ターゲット」では「ノードタグを指定」を選択し、タグを以下のように指定します。
項目 | 値 |
---|---|
PatchTarget | demo-prod |
結果の確認(開発環境)
パッチマネージャーの画面で、少し下にスクロールしたあたりにある「コンプライアンスレポート」タブをクリックすると、サーバごとにコンプライアンス状況(準拠/非準拠)が確認できます。また、コンプライアンス状況が非準拠の場合は「セキュリティの非準拠の数」列のリンクから非準拠のセキュリティパッチ一覧が確認できます。
以下の画像は開発環境サーバのスキャンが終わった時点のものです。
パッチの除外
今回は KB5032336 を本番環境のパッチから除外してみます。
※この対応は本番環境のパッチインストール前に済ませておきます。
パッチマネージャーの画面で「パッチベースライン」タブをクリックし、本番環境用のパッチベースライン(Demo-ProdBaseline)を選択して「編集」をクリックします。
下にスクロールして「拒否されたパッチ」に「KB5032336」を入力し、「拒否されたパッチのアクション」で「ブロック」を選択して「パッチベースラインの編集」をクリックします。
結果の確認(本番環境)
本番環境サーバにパッチインストール後、コンプライアンス状況を確認すると本番環境サーバが非準拠となっていたので「セキュリティの非準拠の数」列のリンクをクリックして詳細を確認してみます。
KB5033118 の状態が「InstalledPendingReboot」となっていますが、この場合インスタンスの再起動と再スキャンが必要です*1。翌日の再スキャンを待ってもいいのですが、「今すぐパッチ適用」を使用して即時にスキャンできるのでそちらを試してみます。なお、インスタンスの再起動の手順は省略します。
今すぐパッチ適用を使用した再スキャン
「今すぐパッチ適用」ではデフォルトとして設定されたパッチベースラインが使用される*2ため、本番環境用のパッチベースライン(Demo-ProdBaseline)をデフォルトに設定しておく必要があります。
パッチマネージャー画面の「パッチベースライン」タブをクリックし、Demo-ProdBaseline を選択して「アクション」、「デフォルトパッチベースラインの設定」の順にクリックします。最後にモーダルウィンドウが表示されるので「デフォルトの設定」をクリックします。
以下の画像のように「デフォルトのベースライン」が「はい」になっていれば設定できています。
インスタンスの再起動が完了したら、パッチマネージャーの画面から「今すぐパッチ適用」をクリックします。
以下の表のように設定し、「今すぐパッチ適用」をクリックします。
項目 | 値 | 備考 |
---|---|---|
パッチ適用操作 | スキャン | |
パッチを適用するインスタンス | 指定したターゲットインスタンスにのみパッチを適用する | |
ターゲットの選択 | インスタンスタグを指定 | |
インスタンスタグを指定 | PatchTarget(キー):demo-prod(値) | |
ログストレージのパッチ適用中 | ログを保存しません | 必要に応じて S3 バケットを選択してください |
スキャンが正常に完了したら結果を確認してみましょう。本番環境サーバの「コンプライアンス状況」が準拠になっていると思います。
おわりに
今回は EC2 インスタンスを対象としましたが、冒頭にマネージドノードと書いたように、対象サーバに Systems Manager の設定をしていればオンプレミスサーバであっても同様のことが行えます。また、複数のサーバに対して同一のパッチポリシーでパッチを適用できたり、特定のパッチを除外できたり、オンデマンドのパッチ適用ができたりと柔軟に対応できて便利だと思います。