はじめに

こんにちは！そしてこんばんは

クラウドインテグレーション事業部の大嵩です。
今回はAWS Systems Manager Patch ManagerとBacklogを組み合わせて管理表を作ってみました！
弊社とお客様における運用効率化が目的です。

手動でWikiを更新していくのはかなりの手間ですよね。
そこで自動更新の仕組みも検証します！
前後編にてぜひご覧ください！

AWS Systems Manager Patch Manager とは

EC2インスタンス内のパッチをベースラインという独自の基準でバージョン管理できる機能です。
料金はなんと無料で利用可能です！

今回のレポートエクスポート機能は有料です。
ただしほんの僅かなのでコスト面で心配は不要です。
そんな便利機能を検証していきます！

今回の構成

以下のようなシンプルな構成で進めます！

S3のイベント通知で直にLambdaをトリガーできます。
しかし将来の機能追加を見込んでEventBridgeにて対応する形にしています。

まずはインスタンスを作成

今回はAmazon Linux 2023(AL2023)とWindows Server 2025(Win2025)で検証します！
片方のインスタンスは別の検証記事で作成したものを流用しています。

Amazon Linux 2023 のパッチベースラインを作成

ここからは実際にPatch Managerの構築に入ります！
最初にパッチベースラインを作成します。
今回は重要なパッチ管理が目的なのでCriticalとImportantのみを選択します。

OSたくさん選択できる！

Amazon Linux だけ？と思いきやたくさんのOSを選択できます！
よく見るとRaspberry Pi OSもありますね！

作成完了！

パッチベースラインの作成ボタンを押下すると作成が完了します！

パッチポリシーを作成する

パッチベースラインができたら次はパッチポリシーを作成します！
スキャンを行うための設定です。
今回は業務での導入も考えてスキャンのみとして進めていきます。

まずは名前と作成したAL2023のパッチベースラインを選択しておきます。

次にスキャンターゲットを指定します！
タグやリソースグループまたは全てのSystems Manager管理ノードを対象にできます。
ここでは手動で対象インスタンスを選択します。
実際には、タグを付与したうえでリソースグループを作成し、指定するのが適切だと思います！

レートの制御により複数台ある場合に段階的な実行も可能です！

Patch Managerの裏ではSystems Manager AutomationやRun Commandを使用しています。
そのためEC2インスタンスには適切なIAMロールが必要です。
下記でQuick Setupが可能だったので自動で付与してもらいます。

アタッチされたIAMロールの内容はスクリーンショットの通りでした！
すべてマネージドポリシーで構成されています。

  • AmazonSSMManagedInstanceCore
  • AmazonSSMPatchAssociation
  • AWSQuickSetupPatchPolicyBaselineAccess

実際に作成してみる

進んでいくと下記のように作成中のシークバーが出てきます。
待ちましょう。

作成完了！

割とまっさらなインスタンスなので大体5分ぐらいで終わりました！
失敗しているものもありますが作成は正常終了しているようです。

スケジューリングも可能！

先程の画面で気になった方もいらっしゃるかと思います。
スケジュールでの実行も可能でcron指定により定期スキャンができます！
サービスに影響のない深夜帯などに実行するといった運用も可能ですね！

取得したインベントリ情報を見てみる

ポリシーによって作成されたインベントリ情報を見てみましょう！
フリートマネージャーのマネージドノードに追加されています！

いつもコマンドで探していたApacheやphpがマネジメントコンソール上から確認できます！
バージョン情報まで表示されるのは便利ですね！

kernelに関しては少々古かったようです。
CVE情報も出しつつ状態はMissingとして警告してくれています。

スキャンのやり方

パッチポリシー作成後にインベントリが取得できました。
手動でもスキャンを行うことが可能です！

「今すぐインスタンスにパッチを適用する」からスキャンを選択します。
ターゲットを指定して実行しましょう。

Windows Server 2025 のパッチベースラインを作成

AL2023ができたので次はWindows Server 2025もやってみましょう！
同じように作成します！

パッチポリシーを修正

私も検証時に困惑しました。
「パッチポリシー」というページは存在していません！
Systems Manager > 高速セットアップ > 設定マネージャー の場所にあります！

それでは編集します！
まずはWindows Server部分を先程作成したパッチベースラインに変更しましょう。

次にターゲットを追加します！

Windowsのインベントリ情報も見てみる

パッチポリシー修正後は作成時と同様にスキャンが始まります。
終わったら改めてWindowsインスタンスの情報も見てみましょう！
ありがたいことにKBで出てきますので管理しやすく便利です！

コンプライアンスレポートを出力してみよう

スキャン後はインベントリ情報の他にコンプライアンスレポートが作成されます。
このレポートはS3へエクスポートすることが可能です！

インスタンス毎の出力も可能です。
しかしお客様向けにはそれぞれAWSアカウントがあります。
そのため対象ノードのレポートを一括で1ファイルに出力する形にします！

まずはコンプライアンスレポートの画面で「S3へエクスポート」を押下します。

一旦はオンデマンドを選択します。
レポート名と対象バケットを選択して送信しましょう！

エクスポート完了！

少し待つと無事にエクスポートが完了します！

CSVを覗いてみる

S3からCSVをダウンロードして覗いてみましょう！
下記のようなCSVになっていました。

インスタンス情報と準拠していないパッチ数が表示されていますね！
アカウントごとの情報なので他の検証用EC2インスタンスの情報も出ています。
対象リソース以外はマスクしています。

Index,Instance ID,Instance name,Instance IP,Platform name,Platform version,SSM Agent version,Patch baseline,Patch group,Compliance status,Compliance severity,Noncompliant Critical severity patch count,Noncompliant High severity patch count,Noncompliant Medium severity patch count,Noncompliant Low severity patch count,Noncompliant Informational severity patch count,Noncompliant Unspecified severity patch count
0,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
1,i-002037f7c898527eb,otake-patchmanager-test-windows,10.0.1.131,Microsoft Windows Server 2025 Datacenter,10.0.26100,3.3.3572.0,pb-04762034a2f675c8c,,NON_COMPLIANT,UNSPECIFIED,0.0,0.0,0.0,0.0,0.0,1.0
2,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
3,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
4,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
5,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
6,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
7,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
8,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
9,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
10,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
11,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
12,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
13,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
14,i-0a8f35732bd2690f8,otake-test-ansible,10.0.1.245,Amazon Linux,2023,3.3.3572.0,pb-01c525952f9e7bbc9,,NON_COMPLIANT,HIGH,0.0,21.0,0.0,0.0,0.0,0.0
15,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
16,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********
17,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********,********

無事に出力が確認できたところで前編は以上です！！
次回はついに本題のBacklog Wikiへの転記方法を紹介します！
お楽しみに！