Patch ManagementとCompliance

1. パッチ管理は「自動更新を有効化」で終わらない

例えば「重大なセキュリティパッチは一定期間内に適用」「本番は検証後」「未適用状態は毎日把握」という標準がある場合、必要なのは何を・いつ・どこへ適用し、結果をどう確認するかの分離です。

2. Patch Managerは組織標準を実行可能なルールへ落とす

AWS Systems ManagerのPatch Managerは、マネージドノードに対するパッチのスキャンや適用を自動化します。しかしPatch Managerを使うだけで組織標準に準拠するわけではありません。

組織標準
↓
パッチベースライン何を承認 / 拒否するか
↓
スキャン / インストールいつ評価・適用するか
↓
対象範囲どこへ適用するか
↓
コンプライアンス
結果が基準を満たすか

3. パッチベースラインは「何を承認するか」を決める

パッチベースラインは、対象OSでどのパッチを承認済みとして扱うか、またどのパッチを拒否するかを定義します。インストール日時そのものを決める機能ではありません。

パッチ候補
↓
パッチベースライン
├─ 承認済み
└─ 拒否
↓
実行スケジュールでスキャン / インストール

4. 自動承認の待機期間はOSごとに利用可否を確認する

OSによっては、分類や重要度に一致するパッチを「リリース後N日で自動承認」とする待機期間を利用できます。検証期間を表す手段の1つです。

ただし、すべてのOSで同じ方式が使えるとは限りません。Ubuntu ServerやDebian Serverではパッケージのリリース日を確実に利用できないため、自動承認の待機日数を前提にしません。

組織標準
「7日間検証してから本番へ」
↓
対象OSは承認待機期間を利用可能？
├─ はい
│  → パッチベースラインへ反映を評価
└─ いいえ
   → 環境別の適用スケジュールなどで実現

組織標準は同じでも、OSの能力に合わせて実装方法を変えます。

5. 拒否済みパッチとBLOCKを分けて考える

既知の不具合があるパッチを承認対象から外すには拒否を使用できます。ただしLinuxでは、拒否にしただけで依存関係としても絶対にインストールされなくなるとは限りません。

承認対象から外す
→ 拒否

依存関係でも
Patch Managerから絶対に適用させない
→ 拒否 + BLOCK

6. スキャンとインストールを分ける

「毎日不足パッチを把握したいが、本番変更は週末だけ」という要件では、スキャンとインストールを別の周期にします。

毎日
→ スキャン
→ 現在の不足状態を把握日曜日
→ インストール
→ 承認済みの不足パッチを適用

コンプライアンスを毎日確認したいからといって、毎日インストールする必要はありません。

7. スキャンとインストールではコンプライアンスデータの見方が異なる

AWS-RunPatchBaselineをスキャンで実行すると、適用対象で不足している承認済みパッチを検出し、不足などの状態を報告します。

インストールでは承認済みかつ適用可能な不足パッチをインストールします。インストール操作から生成されるコンプライアンスデータでは不足として残すのではなく、インストール失敗などが失敗として表れる場合があります。

現在の不足を知る
→ スキャン
→ 不足を確認実際に適用する
→ インストール
→ 失敗などを確認適用後の不足状態を確認したい
→ 必要に応じて再スキャン

8. 新規の中央管理ではQuick Setupのパッチポリシーを優先的に評価する

現在のAWSでは、組織や複数アカウントへ新しくパッチ管理を設計する場合、Systems Manager Quick Setupのパッチポリシーが推奨方式です。

パッチポリシーでは、OSごとのパッチベースライン、スキャン / インストールスケジュール、対象OU・アカウント・リージョンを中央から設定できます。

AWS Organizations
↓
Quick Setup
↓
パッチポリシー
├─ 対象OU / アカウント
├─ 対象リージョン
├─ OS別パッチベースライン
├─ スキャンスケジュール
└─ インストールスケジュール

9. 対象リージョンがパッチポリシー対応か確認する

パッチポリシーは複数リージョンへ展開できますが、すべてのAWSリージョンで利用できるわけではありません。

複数アカウント / 複数リージョン
↓
対象リージョンはパッチポリシー対応？
├─ はい
│  → Quick Setupのパッチポリシーを優先評価
└─ いいえ
   → そのリージョンで利用可能な
      Patch Managerの実行方式を別途設計

対応リージョン一覧を暗記するのではなく、中央管理機能を採用する前に対象リージョンで利用可能か確認します。

10. パッチポリシーではパッチグループを前提にしない

従来のPatch Manager構成ではパッチグループタグとパッチベースラインを関連付ける方式があります。しかしQuick Setupのパッチポリシーでは、パッチグループを作成・維持することを前提にしません。

新規の組織中央管理
↓
パッチグループを必ず作るではなく
↓
パッチポリシー
+ 対象範囲
+ OS別ベースライン
+ スケジュール

11. 環境ごとの段階適用をスケジュールへ落とす

同じ組織標準でも、開発へ先に適用し、一定期間後に本番へ展開することがあります。この場合はOUやアカウントなどの環境境界ごとにスケジュールを分けます。

開発
↓
先行適用
↓
検証
↓
本番
↓
後続適用

「同じ標準」は「全環境へ同時適用」という意味ではありません。

12. メンテナンスウィンドウも現在有効な選択肢

パッチポリシーが推奨されていてもメンテナンスウィンドウが不要になったわけではありません。単一アカウント / リージョンで決められた保守時間にAWS-RunPatchBaselineなどのタスクを実行し、その後に運用タスクを続けたい場合などに候補になります。

13. ポリシーの実行状態とパッチコンプライアンスを混同しない

パッチポリシーを中央展開したからといって、組織全体でコンプライアンス状態が1つになるわけではありません。

Quick Setupでは中央設定の実行状態を確認できます。一方、各ノードのパッチコンプライアンスデータは、どのパッチが不足 / 失敗などの状態かを把握するための情報で、AWSアカウント・リージョンの組み合わせごとに報告されます。

中央ポリシー
→ 設定・実行を展開各アカウント / リージョン / ノード
→ パッチコンプライアンスデータ
→ 非準拠の場所を特定

14. コンプライアンスは評価時点の状態

昨日のスキャンで準拠でも、今日新しいパッチが公開されたなら現在も必ず準拠とは限りません。パッチコンプライアンスレポートは成功したパッチ操作によって生成された時点情報として扱います。

また複数方式でスキャンを行う場合、後のスキャンによって以前のパッチコンプライアンスデータが更新され得ます。

組織標準
「毎日現在状態を把握」
↓
毎日のスキャン
↓
最新のコンプライアンスデータ
↓
非準拠を確認

15. 承認期限とインストール周期を両方確認する

「重大なパッチは7日以内」という標準で、ベースラインが7日後に承認しても、インストールが月1回なら期限を超える可能性があります。

承認ルール
+
インストールスケジュール
↓
組織標準の期限内に実際に適用される？

承認と実行は別の設計要素です。

16. 判断フロー

組織のパッチ標準
        ↓
対象OSで使える承認方式を確認
        ↓
パッチベースライン承認 / 拒否
        ↓
必要なら
拒否 + BLOCK
        ↓
どの頻度で状態を知る？
→ スキャンスケジュール
        ↓
いつ変更できる？
→ インストールスケジュール
        ↓
対象範囲は？
        ↓
パッチポリシー対応リージョン？
├─ はい
│   → Quick Setup パッチポリシーを評価
└─ いいえ
    → 利用可能な実行方式を設計
        ↓
段階適用が必要？
→ 環境ごとにスケジュール分離
        ↓
パッチ操作
        ↓
コンプライアンスデータ
        ↓
非準拠を把握
        ↓
組織標準への準拠を維持

17. 混同ポイント

まとめ

組織標準
↓
OSごとのパッチベースライン能力
↓
承認 / 拒否
↓
スキャン / インストールを分離
↓
対象アカウント / OU / リージョン
↓
適切な実行方式
↓
コンプライアンス
↓
非準拠を把握
↓
組織標準への準拠を維持

サービス名ではなく、承認基準・実行周期・対象範囲・評価結果の4つを組織標準から逆算して設計します。

主要AWS公式資料

• AWS Systems Manager Patch Manager
• Quick Setup — パッチポリシー
• パッチベースライン — Linux / Windows
• AWS-RunPatchBaseline
• メンテナンスウィンドウ
• AWS Systems Manager コンプライアンス / パッチコンプライアンスレポート