More than 1 year has passed since last update.

AWSによるパッチ適用の自動化と、ジョブ実行の実装方法を考えてみた

Last updated at 2023-03-18Posted at 2023-03-14

はじめに

こんにちは、はやぴー（@HayaP）です。

皆さん、クラウド上のサーバー（IaaS）のパッチマネージメントはどのように行っていますか？

今回は、AWS(IaaS)におけるパッチマネージメント戦略について考えていきたいと思います。

対象読者

クラウド(AWS)においての、パッチマネジメント戦略を知りたい
クラウド(AWS)の、パッチ適用を自動化したい
クラウド(AWS)で、ジョブ実行を管理したい

概要

本記事は、下記構成になっています。

【Level.1】単純にパッチ適用したい
【Level.2】適用するパッチを変更したい
【Level.3】環境(dev/prd)毎に、適用するパッチを分けたい
【Level.4】パッチ適用を自動化したい
【Level.5】環境(dev/prd)毎に、パッチ適用タイミングを分けたい
【Level.6】パッチ適用の前後にジョブを挟みたい

TL;DR(忙しい人用)

【Level.1】単純にパッチ適用したい
- AWS System Managerの一つである、『Patch Manager』を用いる（Patch Manager前提条件を満たしていること）
- 『事前定義されたパッチベースライン』を用いることで、Patch Managerサポートの上でパッチ管理が行える
【Level.2】適用するパッチを変更したい
- 『事前定義されたパッチベースライン』を使うだけでなく、『カスタムパッチベースライン』も作成できる
- 『カスタムパッチベースライン』を用いることで、パッチ適用の基準等を変更する事ができる
【Level.3】環境(dev/prd)毎に、適用するパッチを分けたい
- Patch Managerの『パッチグループ』機能を用いる事で、論理的にパッチ適用基準を分ける事ができる
- EC2インスタンスタグ(key=PatchGroup value={PatchGroup名})を用いる事で、インスタンス毎にパッチ適用基準を変更できる
【Level.4】パッチ適用を自動化したい
- AWS System Managerの一つである、『Maintenance Windows』を用いる
- タスクに、RunCommandを設定する。
- RunCommandで、SSMドキュメント『AWS-RunPatchBaseline』を実行する
【Level.5】環境(dev/prd)毎に、パッチ適用タイミングを分けたい
- 【Level.4】で設定した、『Maintenance Windows』のターゲットに、PatchGroupを設定する
【Level.6】パッチ適用の前後にジョブを挟みたい
- 【Level.4】で設定した、『Maintenance Windows』のタスクに、『StepFunctions』を設定する
- 上記タスク登録時、入力オプションを下記に設定する事で、ターゲットのインスタンスIDを引数として渡すことができる
  - {"targetInstanceId": "{{RESOURCE_ID}}"}

詳細

前提

パッチの定義

各OSのセキュリティパッチとします。

対象OS

検証済のOSは以下の通りです。

Amazon Linux2
Windows2019
RHEL8
Ubuntu20.04

Patch Managerの前提条件

本記事では、AWS Systems Manager(以下、SSM) の一機能である Patch Managerを使用します。前提条件は、最新のAWS公式ドキュメントをご確認下さい。

ネットワークの前提

各OSのパッチソースリポジトリと疎通できる事が前提です。
もし、サーバーがインターネット疎通できない場合は、下記を参考にしてください。

[参考]代替パッチソースリポジトリを指定する方法 (Linux)

Windowsの場合はオンプレ環境のWindows Server Update Services (WSUS) サーバの使用を検討してください。

【Level.1】単純にパッチ適用したい

SSMの、Patch Managerを利用する事でワンクリックで行えます。
また、AWSがサポートしている「事前定義されたパッチベースライン（※）」を用いることで、簡単にパッチ管理を行う事ができます。
（Patch Managerが、「事前定義されたパッチベースライン」を基にOSに応じたセキュリティパッチを適用します。）

パッチ適用に限りませんが、AWSがサポートしている部分は積極的に頼りましょう。
パブリッククラウドを利用する上での大きなメリットになります。

（※パッチベースラインとは？）
OSに対するセキュリティパッチの自動適用を管理するための設定の集合です。パッチベースラインでは、AWSが提供するセキュリティパッチを自動的に適用する基準を定義することができます。例えば、パッチの自動適用時期、適用するパッチの種類やバージョン、除外するパッチなどを指定することができます。

【Level.2】適用するパッチを変更したい

独自のセキュリティポリシー等で、「事前定義されたパッチベースライン」
を使えない場合は、パッチベースラインを編集しましょう。

Patch Managerから、パッチベースラインタブを開き「パッチベースラインを作成」を押下します。

オペレーションシステムから、設定したいOSの種類を選択します。

その際、「デフォルトのパッチベースライン」にチェックを入れます。
こうする事で、適用されるパッチの基準を変更する事が出来ます。（OS単位で設定できます）

【Level.3】環境(dev/prd)毎に、適用するパッチを分けたい

パッチグループを使用することで、インスタンスをグループ化し、異なるグループに異なるパッチを適用する事ができます。

パッチベースラインの作成

まず、パッチベースラインを作成します。
先ほどと同じく、Patch Managerから、パッチベースラインタブを開き「パッチベースラインを作成」を押下します。

今回は、環境(dev/prd)毎なので下記のように作成します。

AML2-dev

AML2-prd

パッチグループの作成＆パッチベースラインの紐付け

次に、パッチグループの作成を行います。
パッチグループは、Patch Managerのパッチグループタブからは作成できないので注意してください。

パッチグループに紐づけたいパッチベースラインを開き、そこからパッチグループの追加(作成)を行います。

先ほどの例を用い、AML2の本番環境用のパッチグループを作成してみます。

1. 先ほど作成した、パッチベースライン(AML2-prd)を選択します。
2. アクションから、パッチグループの変更を押下します。

3. 作成したパッチグループ名を入力し、作成を押下します。

これで、パッチグループの作成と、パッチベースラインの紐付けが完了しました。

[参考]パッチグループについて

パッチグループとインスタンス(EC2)の紐付け

各インスタンス(EC2)に、パッチグループを定義するにはタグキー "Patch Group" または "PatchGroup" を使用します。

Key	Value
PatchGroup	AML2-prd
PatchGroup	AML2-dev

Patch Managerは、上記で設定したパッチグループの値に基づいて、使用するパッチベースラインを評価します。
これで、環境毎に適用するパッチを変更する事が出来ました。

【Level.4】パッチ適用を自動化したい

中規模～大規模になれば、パッチ適用を自動化したい要件も出てくると思います。
方法は様々ありますが、今回はSystem ManagerのMaintenace Windowsを使用した方法を解説します。

Maintenace Windowsでは、

When(メンテナンスウィンドウ)
What(タスク)
Where(ターゲット)

を設定します。
少々、癖のあるUIなので是非記事を見ながら理解してもらえればと思います。

(When)メンテナンスウィンドウの作成

"create Maintenance Window"を押下します。

次に、スケジュールを入力していきます。

上記を例に、【期間】と【タスクの開始を停止する】を解説すると、
メンテナンスウィンドウが午後3時に開始し、【期間】が3時間ある場合、ウィンドウの終了時刻は午後6時になります。

加えて、【タスクの開始を停止する】値が1時間に設定されている場合、午後5時以降にはメンテナンスウィンドウ内のタスクを開始できません。つまり、午後3時から5時までの2時間の間しか、タスクが実行されません。

詳細は、公式ドキュメントをお読み下さい。

(Where)ターゲットを作成する

次にターゲットグループを作成します。
先ほど作成したメンテナンスウィンドを選択し、ターゲットの登録を押下します。

今回は、インスタンスを手動で選択します。

(What)タスクを登録する

次に、タスクを登録します。今回は、パッチ適用タスクを登録します。
実施前に、パッチ適用時に使用するIAMロールを作成します。

(前提)IAMサービスロール作成
IAMサービスロールは、下記のように作成します。
(今回は、検証目的のため簡易的に作成します。権限等はかなり緩いため、productionで使用しないでください)

IAMロール作成

aws iam create-role --role-name <ロール名> --assume-role-policy-document file://trust-policy.json

<ロール名>: 任意のロール名
trust-policy.json: 以下のJSONを含むファイル

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAMポリシーの作成:

aws iam create-policy --policy-name <ポリシー名> --policy-document file://policy.json

<ポリシー名>: 任意のポリシー名
policy.json: 以下のJSONを含むファイル

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:*",
      "Resource": "*"
    }
  ]
}

IAMロールと、IAMポリシーのアタッチ:

aws iam attach-role-policy --role-name <ロール名> --policy-arn <ポリシーARN>

以上で、IAMロールの作成は終了です。

タスクを登録
まず、タスクの登録から「Run Commandタスクの登録」を押下します。

次に、コマンドドキュメントから「AWS-RunPatchBaseline」を選択してください。

あとは、パラメーターを入力してきます。
ターゲットは先ほど作成した【ターゲットグループ】を指定してください。

IAMロールは、先ほど作成したものを選択してください。

Operationは、ScanとInstallから選ぶことができます。
今回は、Installを選択します。他の項目は、適宜選択をしてください。

詳細は、公式ドキュメントをご覧ください。

以上、簡単ですがタスクの登録でした。
これで、選択したインスタンスに自動でパッチが適用されるようになりました！

【Level.5】環境(dev/prd)毎に、タイミングを分けたい

Level.3で作成した、メンテナンスウィンドウのターゲットグループを変更する事で実現します。
ターゲットの登録を選択、【インスタンスタグの指定】を押下し、下記のように入力します。

Key	Value
PatchGroup	AML2-dev

あとは、パッチグループ毎にメンテナンスウィンドウを作成し、起動時刻を変えるだけです。（Level.3の手順範囲の為、省略）
Level.2で作成したパッチグループを用いる事で、簡単に適用タイミングを分けることができます！

【Level.6】パッチ適用の前後にジョブを挟みたい

既存の運用をAWSに持ってくる場合、特にジョブ管理システムを別で持っていた場合は
パッチ適用前後にジョブを実行したい。というケースはかなり多いです。

例えば、

事前バックアップ
前後にジョブ(Shell)を実行したい
監視システムを無効化するAPIを投げたい
etc...

これを実現する方法も沢山ありますが、今回はAWS Step Functionsを使用したいと思います。

全体像

先ほど作成したメンテナンスウィンドウのタスクでAWS Step Functionsを呼び出したいと思います。
呼び出す際は、対象のインスタンスIDを入力値に設定する事とします。

targetInstanceId=xxxx

AWS Step Functionsの作成

今回は、下記３つのタスクを作成します。

事前ジョブ実行(Shell)
バックアップ作成(AWS Backup)
パッチ適用

早速、作成していきましょう。
ステートマシーンの作成を押下し、「ワークフローを視覚的に設計」を選択します。

3つのアクションを置きます。識別できるよう、状態名も変えておきます。

事前ジョブ実行(Shell)
- System Manager:SendCommand
パッチ適用
- System Manager:SendCommand
バックアップ作成(AWS Backup)
- Backup: StartBackupJob

では、それぞれのアクションにパラメーターを設定していきます。

事前ジョブ実行(Shell)
APIパラメーターに下記を設定します。

ちなみに、$.targetInstanceIdと設定する事で
StepFunctionsの入力で設定した、targetInstanceIdを参照する事ができます。

{
  "DocumentName": "AWS-RunShellScript",
  "InstanceIds.$": "States.Array($.targetInstanceId)",
  "Parameters": {
    "commands": [
      "{起動したい.shのPath}"
    ]
  }
}

パッチ適用

{
  "DocumentName": "AWS-RunPatchBaseline",
  "InstanceIds.$": "States.Array($.targetInstanceId)",
  "Parameters": {
    "Operation": [
      "Install"
    ]
  }
}

バックアップ作成(AWS Backup)

{
  "BackupVaultName": "Default",
  "ResourceArn.$": "States.Format('arn:aws:ec2:ap-northeast-1:{account_id}:instance/{}', $.targetInstanceId)",
  "IamRoleArn": "｛backup IAMロール→設定値は公式docを参照して下さい｝",
  "Lifecycle": {
    "DeleteAfterDays": 180
  }
}

上記入力が完了したら、次へを押下します。