AWS Systems Manager高速セットアップで組織をパッチ管理する設計ポイント

2022年末にAWS Systems Manager Patch Manager(以下 SSM Patch Manager)が高速セットアップに対応し、AWS Organizationsに対して一括でパッチ管理(パッチポリシーを定義)できるようになりました。

• Systems Manager Quick Setup のパッチポリシーで AWS Organizations 配下のアカウントとリージョン全体に簡単にパッチ適用ができるようになりました | DevelopersIO
• Centrally deploy patching operations across your AWS Organization using Systems Manager Quick Setup | AWS Cloud Operations & Migrations Blog

※ 引用 https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/

SSM Patch Managerの構成技術をあまり意識せずに、ウィザード形式でかんたんにセットアップできるようになった一方で、従来のようにAWSアカウント単位できめ細かく設定できなくなりました。

高速セットアップをのOrganizationsへ導入する際の設計ポイントを紹介します。

管理範囲を決める

高速セットアップは以下の粒度でパッチ管理対象を指定できます。

• OU
• リージョン
• タグ

極端な例では、Organization全体に対して同じポリシーを適用できます。

• 同じOU内でアカウントによって異なる設定がほしい場合はOU分割
• 同じAWSアカウント・リージョン内でインスタンスによって異なる設定が必要な場合はタグ設定

を検討しましょう

OU 構成

AWSベストプラクティスに則り、以下のようなベーシックなOU構成があるとします。

root/
│
├── Workloads/
│
├── Security/
│
└── Sandbox/

SSM Patch Manager 高速セットアップを利用するなら、さらに Suspended OU と PolicyStaging OU も検討してください。

root/
│
├── Workloads/
│
├── Security/
│
├── Sandbox/
│
├── Suspended/
│
└── PolicyStaging/

Suspended OU

Suspended OUはSuspended状態のアカウントを管理するOUです。

高速セットアップはCloudFormation StackSetsを利用して設定を組織に展開します。

StackSetsの仕様として、Suspended状態のアカウントにもデプロイを試み、デプロイが失敗します。

https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/1177

このようなアカウントはSuspended OUで管理し、高速セットアップの対象外にしましょう。

高速セットアップに限らず、StackSetsを利用している場合は、 Suspended OUの導入をおすすめします。

Policy Staging OU

Policy Staging OUは組織で利用するSCPなどのポリシーを検証するOUです。

Patch Managerでカスタムパッチベースライン(どういうパッチを適用するか定義)を利用する場合、このOUを高速セットアップの対象外にし、このOUでベースラインを検証しましょう。

ホームリージョンの設定

高速セットアップ初回利用時にホームリージョンを決定します。このリージョンはカスタムパッチベースラインなどで利用されます。 ホームリージョンは後から変更できません。

現在のホームリージョンは、パッチポリシーの編集画面のPatch baseline → Custom patch baseline から確認できます。

カスタムベースライン運用

SSM Patch Managerでは、適用するパッチ群をカスタムパッチベースラインとしてユーザーが定義できます。 高速セットアップでは、このベースラインをホームリージョンに定義します。

カスタムベースラインの変更は1時間以内に各アカウントに同期されます。

Policy Staging OUなど特定のOUでベースラインを検証し、このOUを高速セットアップの適用対象外としましょう。

パッチをインストールするか決める

SSM Patch Managerのパッチ操作では

• スキャン
• インストール
  • 必要に応じて再起動する・しない

を設定できます。

パッチ操作は State Manager の関連付けで行われており、スキャン・インストールそれぞれ1種類のUTC指定のスケジュールしか保持できません。

デフォルトのスケジュールは以下です。

• スキャン : 毎日午前1時
• インストール : 日曜午前2時

パッチのスキャンは基本的に参照系操作のため、EC2インスタンスへの影響は軽微ですが、パッチのインストールはシステムに変更を与え、場合によっては再起動によるダウンタイムを伴います。 システムによって再起動可能なタイミングが異なり、複数リージョンでシステムが動作している場合、深夜帯のUTC時刻もまちまちです。

冗長構成のシステムであれば、再起動に伴う影響も軽微でしょうが、すべてのシステムがそういった構成とは限りません。

パッチをインストールするのか、インストールする場合、再起動もするのか慎重に決定しましょう。

パッチスキャン結果の上書きに注意

SSM Patch Managerのパッチ操作には

• SSM Patch Manager高速セットアップのスケジュール操作
• SSM Patch Managerの従来のスケジュール操作
• "Patch now" のオンデマンド操作

など複数の方法があります。

パッチコンプライアンスデータは、スキャン実行のたびに上書きされます。

同じインスタンスに対して異なる設定でスキャンすると混乱の元になるため、パッチ管理は一種類にしましょう。

高速セットアップだけに限定しても

• Patch Manager(今回紹介)
• Host Management

と2種類のパッチスキャンが可能です。

参考 https://docs.aws.amazon.com/systems-manager/latest/userguide/avoid-patch-compliance-overwrites.html

パッチポリシーを要件ごとに定義

同じインスタンスに対して、複数のパッチ管理をすることは推奨されていませんが、インスタンスによってパッチ管理を分けることは問題ありません。

具体的には、本番系OUとその他のOUなど、要件によってパッチポリシーを分ける運用が考えられます。

高速セットアップの設定一覧からはパッチポリシーの設定名を確認できず、詳細画面で確認する必要があることにはご注意ください。

コンプライアンス違反をSecurity Hubに集約

パッチのコンプライアンス違反はSecurity Hub にデータ連携できます。

具体的には、以下のような設定で可能です。

1. Security Hubを有効化
2. Security Hubのセキュリティ基準「AWS 基礎セキュリティのベストプラクティス」を有効化
3. AWS Config でリソース「AWS::SSM::PatchCompliance」の記録を有効化 ※ あるいは全てのリソースを記録
4. SSM Patch Manager でパッチ管理(スキャンを実施)

Security Hubでは次のコントロールでレポートされます。

[SSM.2] Amazon EC2 instances managed by Systems Manager should have a patch compliance status of COMPLIANT after a patch installation

その後、Security Hubを組織・リージョン間で集約し、必要に応じて EventBridge などから通知するといいでしょう。

最後に

AWS Systems Manager高速セットアップを利用すると、コンソールからウィザードに従ってポチポチ操作するだけで組織全体をかんたんにパッチ管理できます。

• スキャンから始める
• 管理の難しいシステムはOUを分けて高速セットアップから除外する
• 要件に応じて設定を分ける
• 要件を高速セットアップが提供するものに寄せる

などと極力頑張らないように設計すると、高速セットアップのメリットを享受しやすくなると思います。

それでは。