【脆弱性対応】AWS Systems Manager Patch Manager を使ったパッチ戦略の例

SSMパッチマネージャーの活用方法を考えてみます
2021.04.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Systems Manager(SSM) Patch Manager を使ってパッチ適用を自動化できます。

本ブログでは Patch Manager で実現できるパッチ戦略の例をいくつか紹介します。 Patch Manager でできることをざっくりと理解してもらえると幸いです。

※そもそも Patch Manager って何?深堀りしたい方は以下ブログを是非御覧ください。

<<2021/06/24追記>> 実際の実装例を以下ブログにまとめています。

想定環境

以下想定するAWS環境です。

  • 対象インスタンス群は Amazon Linux 2。すべて SSM管理下にある
  • 検証環境、本番環境が存在する

例1. ほぼほぼデフォルト

img

参考として AWSが提供しているデフォルトベースライン AWS-AmazonLinux2DefaultPatchBaseline と、 それを使った(ほぼ)デフォルト設定のメンテナンスウィンドウを活用したパターンを紹介します。

  • #対象
    • Patch Group=AL2 タグが付いたインスタンスが対象です
  • #実行タイミング
    • 12:00 から 12時間毎にパッチ適用を行います
  • #パッチ内容
    • Security 系のパッチ(重要度 Critical, Important)で、リリース後 7日以上経っているものをインストールします
    • Bugfix 系のパッチで、リリース後 7日以上経っているものをインストールします

とりあえず始められるメリットがあります。

しかし、パッチの例外登録などカスタマイズはできません。本番環境には安易に適用するべきではないです。

例2. 「パッチリリース後 N日」活用

img

#対象/実行タイミング

検証環境 本番環境
対象 Patch Group=AL2-STG Patch Group=AL2-PRD
実行タイミング 毎日 AM 2:00 -- AM 3:00 毎日 AM 2:00 -- AM 3:00

#パッチ内容(承認ルール)

分類 重要度 自動承認(検証環境) 自動承認(本番環境)
Security Critical, Important パッチリリース後 1日 パッチリリース後 31日
Bugfix - パッチリリース後 1日 パッチリリース後 31日

#パッチ内容(パッチの例外)

検証環境 本番環境
承認済みパッチ 無し 無し
拒否されたパッチ 無し 検証環境パッチで問題が出たもの

パッチグループごとに異なるベースラインを指定します。

検証環境と本番環境でパッチインストールのタイミングをずらすことによって、 パッチインストールの影響を事前に検証環境で把握できます。

継続的なパッチ当ての自動化を実現できますが、 検証環境で問題が出たときのフォローはしっかりとする必要があります。

例えば「 "検証環境パッチで問題が出たもの" は 一旦は本番環境の パッチの例外 に入れておく」フローを定めておきます。

例3. 「パッチ日付 YYYY-MM-DD」活用

img

#対象/実行タイミング

検証環境 本番環境
対象 Patch Group=AL2-STG Patch Group=AL2-PRD
実行タイミング 毎日 AM 2:00 -- AM 3:00 毎日 AM 2:00 -- AM 3:00

#パッチ内容(承認ルール)

▼ Step1 (3月1日〜)

分類 重要度 自動承認(検証環境) 自動承認(本番環境)
Security Critical, Important 20XX/03/01までのパッチ 20XX/02/01までのパッチ
Bugfix - 20XX/03/01までのパッチ 20XX/02/01までのパッチ

▼ Step2 (4月1日〜)

分類 重要度 自動承認(検証環境) 自動承認(本番環境)
Security Critical, Important 20XX/04/01までのパッチ 20XX/03/01までのパッチ
Bugfix - 20XX/04/01までのパッチ 20XX/03/01までのパッチ

例2. 「パッチリリース後 N日」活用 と同じく、 パッチインストールの影響を事前に検証環境で把握できます。

パッチ適用状況の足並みを揃えたい場合に活用できる設定です。

ほぼパッチ当てを自動化できます。 この例では月が変わるたび(Step1→Step2) に自動承認設定を変える必要がありますが、 そこまで負荷ではありません。Lambda など活用して自動化も可能だと思います。

※図には書いていませんが、 もちろん 例2と同じく「 "検証環境パッチで問題が出たもの" は 本番環境の パッチの例外 に入れておく」フローは必要です。

例4. 「承認済みパッチ」活用

img

#対象/実行タイミング

検証環境 本番環境
対象 Patch Group=AL2-STG Patch Group=AL2-PRD
実行タイミング 毎日 AM 2:00 -- AM 3:00 毎日 AM 2:00 -- AM 3:00

#パッチ内容(パッチの例外)

▼ Step1

検証環境 本番環境
承認済みパッチ CVE-20XX-YYYYY 無し
拒否されたパッチ 無し 検証環境パッチで問題が出たもの

▼ Step2

検証環境 本番環境
承認済みパッチ 無し CVE-20XX-YYYYY
拒否されたパッチ 無し 検証環境パッチで問題が出たもの

この例では「承認ルール」は使っていません。 自動的にパッチをまとめてインストールすることはありません。

まず、 検証環境で 承認済みパッチ に入れたパッチがインストールされます(Step1)。 問題なければ 本番環境の 承認済みパッチ に同じものを入れてパッチを当てます(Step2)。

自動化のメリットは損なわれますが、脆弱性情報を1つづつ確認、慎重に対応を行いたい場合に有用です。

また、特定のパッチをとりあえず当てたいときにも使えます。(参考: Systems Manager Patch Manager で特定パッチを適用する | DevelopersIO)

おわりに

ざっくりと Patch Manager でできること把握できたでしょうか。 紹介した例をチューニング/組み合わせて、最適なベースラインへカスタマイズすると良いと思います。

今回は説明を省きましたが、ベースラインを定義するにあたって、他いくつかパラメータが あります。

  • 再起動するかどうか
  • セキュリティ以外の更新を含むかどうか
  • など

実際に設定する際はこれらも考慮してカスタマイズしていきましょう。

参考