AWS Systems Manager とは

世はまさに大マネージドサービス時代。
「この世の全てがそこにある」と言われています（？）。

今回お話させていただくSystems Managerにはシステム管理におけるたくさんの機能があります。
※全体像を把握しにくいのですが、多分AWS裏側で構成管理/自動構築(ChefやAnsibleなど)を利用しており
　それらによってインフラ管理するサービスと捉えています。

今回はパッチ管理に関する部分だけお話をさせていただきます。

この記事で書くこと

1. パッチ管理の考え方
2. サブ機能「メンテナンスウィンドウ」について
3. サブ機能「パッチマネージャー」について
4. 実装方法

1.パッチ管理の考え方

パッチの自動適用が許容できない(逐一パッチ内容を精査する必要がある)場合に
本記事が役に立つのではないかと思います。

2.サブ機能「メンテナンスウィンドウ」について

スケジュール実行のタイミング等を定義するものです。
また、パッチ管理においては「スキャン」or「スキャン＆インストール」を決めます。
※今回は自動パッチ適用を許容しないためスキャンのみです。

3.サブ機能「パッチマネージャー」について

どのパッチ適用をするか「PatchBaseline」というルールで設定します。
以下はできることサマリです。※2020/4/13時点

• 対象EC2の制御

  • 特定のタグ設定しているものだけ自動で適用
  • (パッチグループという括りに事前に参加し)グループでまとめて指定
  • 手動でインスタンスを一つ一つ指定

• 様々なOSに対応

  • Amazon Linux
  • Amazon Linux2
  • CentOS
  • Red Hat Enterprise Linux
  • SUSE
  • Ubuntu
  • Windows

　　※より細かいOSの指定も可能です。
　　　Windowsの場合は、Win7～10/Win10LTSB/WinsServer2012R2～2019など。

• パッチ分類を指定することが可能です。

  • CriticalUpdate
  • Driver
  • SecurityUpdates
  • FeaturePacks
  • etc...

• パッチの重要度を指定することができます。

  • Critical～Low / Unspecified

• その他

  • パッチがリリースされてからパッチマネージャーの対象にするまでの待機日数を指定可能です。
  • アプリケーションのパッチ適用も自動化できます。
    • OfficeやADなど　※AWSはライセンスの問題でOffice自体ほぼ使えないですけどね。
  • 明示的に対象/非対称のパッチを指定可能です※WindowsはKB、Linuxはパッケージ名

4.実装方法

１. マネージドインスタンス対応

1-1. SSMエージェントインストール

WinServer2012R2(2016年以降公開)、Amazon Linux2などはデフォルトでインストール済みです。
　※手動インストールはリンクのとおり

1-2. EC2インストールへのSSMエージェント用権限付与

サービス[IAM]のページで、EC2用のIAM Roleを作成し、
SSMエージェント用のポリシー(AmazonSSMManagedInstanceCore)を当てます。

サービス[EC2]のページで、上記で作成したIAM Roleを使用してEC2をデプロイします。
※手順割愛

1-3. SSMエージェント再起動

EC2デプロイ後、エージェントサービスを再起動することでActive状態になります。

sudo systemctl restart amazon-ssm-agent.service

確認コマンドを実行します。

systemctl status amazon-ssm-agent.service -l

以下は結果です。

● amazon-ssm-agent.service - amazon-ssm-agent
   Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-03-16 04:43:36 UTC; 3s ago
 Main PID: 3440 (amazon-ssm-agen)
   CGroup: /system.slice/amazon-ssm-agent.service
           mq3440 /usr/bin/amazon-ssm-agent

Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [LongRunningPluginsManager] There are no long running plugins currently getting executed - skipping their healthcheck
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [MessageGatewayService] listening reply.
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [StartupProcessor] Executing startup processor tasks
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [StartupProcessor] Write to serial port: Amazon SSM Agent v2.3.714.0 is running
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [StartupProcessor] Write to serial port: OsProductName: Amazon Linux
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [StartupProcessor] Write to serial port: OsVersion: 2
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [MessageGatewayService] Opening websocket connection to: wss://ssmmessages.ap-northeast-1.amazonaws.com/v1/control-channel/i-＊＊＊?role=subscribe&stream=input
Mar 16 04:43:39 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [MessageGatewayService] Successfully opened websocket connection to: wss://ssmmessages.ap-northeast-1.amazonaws.com/v1/control-channel/i-＊＊＊?role=subscribe&stream=input
Mar 16 04:43:40 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [MessageGatewayService] Starting receiving message from control channel
Mar 16 04:43:40 ＊＊＊ amazon-ssm-agent[3440]: 2020-03-16 04:43:37 INFO [MessageGatewayService] [EngineProcessor] Initial processing

1-4. SSMエージェントが有効になったことを確認

サービス[Systems Manager]のページで、マネージドインスタンス画面に対象EC2が表示されることを確認します。

２. PatchBaselineの作成

2-1. 作成

「パッチマネージャー」画面を表示しようとすると、はじめての場合に以下の画面が表示されます。
「事前定義されたパッチベースラインの表示」を選択します。

「パッチベースラインの作成」を選択します。

「名前」など必要項目を入力します。
※今回はOSをAmazonLinux2にしていますが、Windows系OSでも殆ど設定項目が変わりません。
必要項目を入力し終わったら、画面下部の「パッチベースラインの作成」を選択します。

すると、パッチベースラインの一覧画面に戻るかと思います。

３. メンテナンスウィンドウの作成

3-1. 作成

先程作成したパッチベースラインにチェックを入れ、「パッチ適用の設定」を選択します。

パッチ管理を自動化する対象のEC2インスタンスをどのように決めるか設定します。
今回はEC2の「インスタンスタグを入力する」を選択します。
※Tag Keyに「PatchGroup」、Tag Valueに「Linux-PatchBaseline」を入力し、
「Add」を選択すると以下の画像のように表示されます。

「新しいメンテナンスウィンドウでスケジュールを作成する」にチェックを入れます。
スケジュールの設定方法は「CRON/Rate式を入力する」にしました。
※画面で表示されるCronスケジュールは毎月最終日の午前2時に実行を意味しています。
Cron構文の参考ページ

「メンテナンスナンスウィンドウ名」を入力、「パッチ適用オペレーション」を
「スキャンのみ」にチェックを入れ、最後に「パッチ適用の設定」を選択します。

メンテナンスウィンドウ一覧画面に推移するので、
作成したメンテナンスウィンドウが表示されることを確認します。

４. スキャン実行

4-1. スケジュール実行

パッチスキャンはスケジュール実行のみで手動実行はできません。
※検証用に短めの時間で設定をしてすぐに結果がでるように変更しましょう。

５. スキャン後、パッチ情報の確認

５-1. 実行環境の用意

今回は、先程SSM AgentをインストールしたサーバからAWS CLIを実行します。
AWS CLIリファレンス

※LambdaからPythonやJAVAの言語で実行してもいいです。

５-２. CLI実行権限の付与

AWS CLIで実行する際には、EC2のIAM Roleに対してPolicyを付与してあげる必要があります。
「1-2. EC2インストールへのSSMエージェント用権限付与」で作成したRoleの
詳細画面を開きます。
「ポリシーをアタッチします」を選択します。

「AmazonSSMReadOnlyAccess」か「AmazonSSMFullAccess」を設定する必要があります。
Policyにチェックを入れ、「ポリシーをアタッチ」を選択します。

５-３. パッチスキャン結果のリスト表示

サーバにログインし、以下のコマンドを実行すると未適用パッチを一覧で表示してくれます。

[ec2-user@＊＊＊ ~]$ aws ssm describe-instance-patches --instance-id i-＊＊＊ --filters Key=State,Values=Missing

実行結果は以下のように表示されます。

{
    "Patches": [
        {
            "KBId": "curl.x86_64", 
            "Severity": "Medium", 
            "Classification": "Security", 
            "Title": "curl.x86_64:0:7.61.1-12.93.amzn1", 
            "State": "Missing", 
            "InstalledTime": 0.0
        }, 
・
・
・

5.あとがき

いかがでしょうか。
かんたんな管理であればSystems Managerで十分だと思います。

作り込み次第では、以下のような構成も可能です。

◎未適用パッチスキャンの自動化
　１．CloudWatchEventsでメンテナンスウィンドウの終了を検知
　２．Lambdaでパッチ未適用リストを作成＆S3にアップロード
　Amazon CloudWatch Events による Systems Manager イベントのモニタリング

◎セベリティでセキュリティのみ自動適用
　１．パッチベースラインの作成時に、分類で「Security」を選択
　２．メンテナンスウィンドウの作成時に、パッチ適用オペレーションで
　　「スキャンとインストール」を選択
　スケジュール実行時に常にセキュリティ関連のパッチのみインストールしてくれます。
　※インストールが失敗する可能性を考慮した実装、運用が必要となります。