EC2パッチ運用(Linux) をSystems Managerで実現する

Linux on EC2 のパッチ運用を Patch Manager で行う方法を紹介します
2019.10.15

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

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。

以前、AWS運用設計 パッチ運用を考える を投稿しました。 さらに一歩進んで Linux 系 OS のパッチ運用を考えてみます。

前提条件

本エントリでは Systems Manager を利用してパッチ運用を行います。 Systems Manager の利点は EC2 をグループ化して一括管理が実現できることです。

  • EC2 に SSM エージェントのバージョン 2.0.834.0 以降がインストールされている
  • サポートされる OS
  • Amazon Linux 2012.03 - 2018.03
  • Amazon Linux 2 2 - 2.0
  • CentOS (6.5~7.6)
  • Red Hat Enterprise Linux (RHEL) 6.5 ~ 7.6
  • SUSE Linux Enterprise Server (SLES) 12.0 および 12.x 以降のバージョン
  • Ubuntu Server 14.04 LTS、16.04 LTS、18.04 LTS

最新の情報は パッチマネージャーの前提条件 を参照ください。

Systems Manager で何をするのか

主に Patch Manager を使います。 Patch Manager は OS ネイティブのパッケージ管理ツール (yum,apt,zypper など) を使って パッチを適用するプロセスを自動化します。 サーバーをスキャンしパッチ適用状態をレポートすることや、スキャン後に自動的にパッチを適用することが可能です。

承認済み・拒否済みパッチリストを作成して適用するパッチをコントロールすることが可能です。

メンテナンスウィンドウでパッチ適用をスケージュールし システム運用に影響の無い時間帯にパッチを適用します。

準備

システム管理者がしておくタスクを整理します。

パッチソースリポジトリの設定

OS ネイティブのパッケージ管理ツールのソースリポジトリは 予め設定しておく必要があります。

デフォルトで設定されているソースリポジトリ以外の代替リポジトリを使いたい場合、 または、AWS が提供している AMI 以外のイメージで起動している場合には 代替リポジトリを指定します。 方法は以下を参照ください。 セキュリティに関連するパッチの選択方法 代替パッチソースリポジトリを指定する方法 (Linux)

パッチベースラインの設定

パッチベースラインは、インスタンスへのインストールを承認、または、拒否するパッチを定義します。

パッチベースラインには、AWS が事前定義している汎用的なパッチベースラインと システム管理者が定義するカスタムパッチベースラインがあります。 事前定義されたパッチベースラインは以下を参照ください。 事前定義されたパッチベースラインについて

カスタムパッチベースラインでは自動承認ルール、承認済みリスト、拒否済みリストを定義可能です。 カスタムパッチベースラインは以下のような要件がある場合に検討します。

  • 事前定義されたパッチベースラインに含まれないパッチを適用したい
  • 特定のパッケージだけパッチ適用したい
  • 特定のパッケージはパッチ適用したくない
  • パッチリリース後に即適用したい、または、十分に期間を空けてから適用したい
  • 事前定義されたパッチベースラインのほとんどはパッチリリースから7日後に適用

パッチグループの設定

パッチグループは必須ではありませんが、 パッチ管理をするうえで非常に便利なので是非活用ください。

パッチグループはパッチベースラインに関連付けます。 パッチベースラインで設定したルールに基づいたパッチ適用対象をグルーピングします。

パッチグループの指定は EC2 のタグで行います。 タグキーは「Patch Group」にします (大文字、小文字、半角スペースまで正しく指定) 。 タグバリューは任意です。

例えば、このようなパッチベースラインがあるとします。

パッチベースライン名 ルール 関連付けるパッチグループ
Baseline-7 パッチリリース後7日経過したセキュリティパッチを適用 Dev
Baseline-14 パッチリリース後14日経過したセキュリティパッチを適用 Prod

AWS-RunPatchBaseline で Amazon Linux 2 を対象としたパッチ適用を実行したとします。 パッチグループ = Dev とタグ付けされた開発機のインスタンスにはパッチリリース後7日経過したパッチが適用されます。 パッチグループ = Prod とタグ付けされた本番機のインスタンスは14日です。 この差分7日間は、アプリケーションの動作検証や修正を行う期間になります。

パッチ適用スケージュールの設定

メンテナンスウィンドウを使用してパッチ適用スケージュールを設定します。 システムで許容されたメンテナンス時間中にパッチが適用されるようスケージュールします。

注意

パッチをインストールすると Systems Manager によってインスタンスが再起動されます。 再起動される前提でスケジュールを組むようにします。

コマンド出力 S3 バケットの作成

メンテナンスウィンドウでのパッチ適用は Run Command で AWS-RunPatchBaseline が実行されます。 Run Command の出力結果は Systems Manager では2,500文字しか保存されず かつ日本語が文字化けします。 万が一問題が発生した際に、2,500文字かつ日本語文字化けでは解析が困難になります。

出力結果を S3 に保存できるように System Manager 出力専用 S3 バケットを作成します。 メンテナンスウィンドウのタスク、及び、手動で Run Command を実行する際に S3 バケットを指定するように設定します。

通知設定

メンテナンスウィンドウでのタスク実行結果を SNS で通知することが可能です。 パッチ適用が失敗する可能性もありますので メールや Slack など適切な通知先を設定します。

パッチコンプライアンス

Patch Manager を使用してインスタンスにパッチを適用すると Systems Manager の マネージドインスタンス からパッチインストールステータスを確認できます。

期待のパッチがインストールされていることをマネジメントコンソールや AWS CLI で確認できます。

インストールステータスの詳細は以下を参照ください。 パッチコンプライアンスについて

おわりに

パッチ運用は難しい課題になりがちです。 最新のパッチを適用することがセキュリティ面や機能面で理想であるのですが 適用作業にかかるコストやパッチ適用後のアプリケーション動作確認など 実際の運用で考慮しなければならない点が多くあります。

Systems Manager を利用することで少しでもパッチが適用しやすいシステムになれば幸いです。

参考

AWS運用設計 パッチ運用を考える
AWS Systems Manager Patch Manager

以上、吉井 亮 がお届けしました。