Patch Manager、パッチベースライン、メンテナンスウィンドウ、コンプライアンスの基本的な役割は既習です。

既存環境を改善するときに問題になるのは、

Patch Managerを使っている
=
安全な更新プロセスになっている

とは限らないことです。

例えば、

月1回のパッチ適用

↓

承認済みパッチを
本番サーバーへ一斉インストール

↓

Systems Managerの実行が成功

↓

作業完了

という運用では、

• 緊急性の高い脆弱性への対応が次回作業まで遅れる
• パッチ後の再起動による影響を十分に考慮していない
• アプリケーションが正常か確認していない
• 再起動待ちのノードを修復済みとして扱う
• 更新失敗や未適用ノードが残っても作業を終了する

といった問題が起こり得ます。

ここでは、

現在状態の確認
↓
パッチ適用リスクの評価
↓
適用する更新を決定
↓
変更時間を決定
↓
パッチ適用
↓
再起動を制御
↓
アプリケーション確認
↓
コンプライアンス確認
↓
未完了対象を追跡

という一連の更新プロセスの改善を扱います。

ゴール

既存環境について、

• AWS Systems Manager / Patch Managerを更新プロセス全体の中で位置付ける
• パッチベースラインと実行タイミングを混同しない
• セキュリティ上の緊急性と変更による障害リスクを両方評価する
• メンテナンスウィンドウを変更影響の制御に利用する
• パッチ適用時の再起動を明示的に設計する
• パッチ適用前後にアプリケーション状態を確認する
• コンプライアンスを更新完了の確認に利用する
• 通常の更新経路と緊急時の更新経路を使い分ける

ことを目指します。

1. 最初に「現在の更新プロセス」を見る

既存環境では、最初から新しいAWSサービスを追加するのではなく、現在の更新プロセスを分解します。

例えば、

パッチ公開
↓
誰が確認する？

↓

いつ承認される？

↓

対象はどう決まる？

↓

いつインストールする？

↓

再起動はいつ行う？

↓

アプリケーション確認は？

↓

未適用をどう確認する？

を確認します。

単に、

Patch Manager
有効

だけを確認しても、更新プロセスの安全性は分かりません。

改善対象は、

パッチの選択
+
適用タイミング
+
変更影響
+
適用後確認

です。

2. パッチ適用リスクには2方向ある

パッチ適用では、

早く適用しないリスク

だけを考えるのは不十分です。

一方で、

急いで適用するリスク

もあります。

整理すると、

したがって、

速ければ安全

でも、

遅ければ安全

でもありません。

必要なのは、

脆弱性を残す時間と、変更による業務影響を両方小さくすること

です。

3. 更新プロセスを一続きで設計する

既存環境の更新プロセスは、例えば次のように整理できます。

Scan
↓
現在の不足パッチを把握
↓
パッチ適用リスクを評価
↓
適用対象を決定
↓
変更タイミングを決定
↓
Install
↓
必要な再起動
↓
アプリケーション確認
↓
再Scan
↓
コンプライアンス確認
↓
未完了対象を追跡

重要なのは、

Installが終了
=
更新プロセス完了

としないことです。

更新によって、

OS上ではパッチ適用成功

しかし

アプリケーションが起動しない

という状態も考えられます。

また、

パッチはインストール済み

しかし

再起動がまだ

という状態もあります。

4. 既習のパッチ設定を更新プロセスへ組み込む

パッチベースラインが承認対象を決め、実行タイミングは別に管理することは既習です。

ここで確認するのは、その設定自体ではなく、

必要なパッチは
承認されている

↓

しかし
実際の適用日は遅すぎないか？

というプロセス上のずれです。

例えば、重大な脆弱性へのパッチが承認済みでも、

次回の本番更新
3週間後

であれば、承認設定そのものではなく、更新プロセスの対応速度を見直す必要があります。

したがって既存環境では、

何を適用するか

だけでなく、

必要な期限までに
実際に適用できるか

まで確認します。

5. 変更前の情報をリスク判断へ使う

Scanによって不足パッチを把握できること自体は既習です。

ここでは、その結果を、

不足パッチあり

で終わらせず、

どのリソースか

何件あるか

本番か検証か

外部公開されているか

再起動が発生し得るか

といった変更判断へつなげます。

例えば、

不足パッチ
100台

という情報と、

不足パッチ
100台

うち
外部公開 5台
業務重要サーバー 10台

という情報では、更新計画の立て方が変わります。

ここでの目的は、

既に得られるパッチ状態を、変更前のリスク評価へ利用すること

です。

6. 通常更新と緊急更新を同じ周期だけで処理しない

通常の更新では、

定期的な評価
↓
決められた変更時間
↓
更新

で問題ない場合があります。

しかし、

外部公開サーバー

重大な脆弱性

攻撃へ悪用されている

次回定期更新まで3週間

という状況で、

定期日まで待つ

ことが必ずしも安全とは限りません。

既存プロセスには、

通常更新経路

だけでなく、

緊急更新経路

も設けます。

例えば、

通常

定期Scan
↓
通常変更日
↓
Install
↓
確認

に対して、

緊急

高いセキュリティリスクを確認
↓
対象を限定
↓
臨時の変更時間を確保
↓
オンデマンドで更新
↓
正常性確認
↓
コンプライアンス確認

とします。

Patch Managerでは、スケジュールを待たずにオンデマンドでパッチ操作を実行する方法も利用できます。

重要なのは、

緊急対応だから検証をなくす

のではありません。

通常より時間を短縮しても、

対象
↓
変更
↓
確認

という最低限の安全策は残します。

7. メンテナンスウィンドウを「日時」だけで考えない

Systems Manager Maintenance Windowsでは、更新などの影響を伴う処理を指定した時間帯に実行できます。

更新プロセスを改善するときは、

毎週日曜 02:00

という開始時刻だけを見るのではなく、

開始
↓
パッチ適用
↓
再起動
↓
アプリケーション確認
↓
必要なら追加対応
↓
保守時間終了

が時間内に収まるかを確認します。

メンテナンスウィンドウには、

Duration
Cutoff

があります。

Cutoffは、メンテナンスウィンドウ終了前の一定時間から新しいタスクを開始しないよう制御するために使用できます。

つまり、

保守終了5分前

↓

まだ未処理ノードがある

↓

新しい変更を次々開始

という状態を避けるための判断材料になります。

ただし、

Cutoff到達
=
実行中処理を自動ロールバック

ではありません。

メンテナンス時間の終了と、変更の取り消しは別の責任です。

8. 再起動を暗黙の動作にしない

パッチ適用で特に業務影響を生みやすいのが再起動です。

AWS-RunPatchBaselineでは、RebootOptionとして、

RebootIfNeeded
NoReboot

を選択できます。

既定は、

RebootIfNeeded

です。

ここで名前だけを見て、

OSが
「このパッチは再起動必須」
と判断した場合だけ再起動する

と考えてはいけません。

Patch ManagerでRebootIfNeededを使用すると、Patch Managerが1つ以上のパッチをインストールした場合などに、マネージドノードを再起動します。

したがって、

パッチ適用
↓
予期しない再起動
↓
サービス影響

とならないよう、

再起動を更新計画の一部として明示的に設計する

必要があります。

9. NoRebootは「更新完了」を意味しない

可用性の都合で、

NoReboot

を選択する場合があります。

例えば、

今はパッチをインストール

↓

OS再起動は
別の保守時間

という設計です。

ただし、NoRebootでパッチがインストールされた場合、

INSTALLED_PENDING_REBOOT

となり、マネージドノードは非準拠として表示されることがあります。

その後、

再起動
↓
Scan
↓
コンプライアンス確認

まで進めることで、更新プロセスを閉じます。

つまり、

Install + NoReboot
↓
作業完了

ではありません。

10. NoRebootでもサービス影響がゼロとは限らない

もう1つ重要なのは、

NoReboot
=
無停止

ではないことです。

NoRebootが抑止するのはOSレベルの再起動です。

更新されるソフトウェアによっては、パッチ適用処理の中でサービスが再起動する可能性があります。

したがって、

NoRebootだから
営業時間中でも安全

とは判断しません。

確認するのは、

OS再起動
+
サービス再起動
+
アプリケーション影響

です。

11. パッチ適用前後にアプリケーションを確認する

OSの更新が成功しても、業務サービスが正常とは限りません。

更新プロセスでは、

変更前
↓
アプリケーションの正常状態を確認

↓

パッチ適用

↓

必要な再起動

↓

アプリケーションを再確認

という流れを持たせます。

Patch Managerのオンデマンドパッチ適用では、ライフサイクルフックを利用して、

インストール前

にアプリケーションを安全に停止したり、

パッチ適用後

または、

再起動後

にヘルスチェックを実行したりできます。

例えば、

更新前フック
↓
アプリケーション停止確認
↓
Patch Manager
↓
パッチ適用
↓
再起動
↓
更新後フック
↓
アプリケーションヘルスチェック

という形です。

AWS Systems Managerを、

OS更新を実行するだけのサービス

としてではなく、

更新前後の処理を含む変更プロセス

へ組み込めます。

12. 更新プロセスの完了条件を明確にする

パッチコンプライアンスの基本的な見方は既習です。

ここでは、それを更新プロセスを閉じるための確認材料として使います。

例えば、

パッチ適用処理
成功

↓

しかし
再起動待ちが残っている

のであれば、更新プロセス全体としては未完了です。

同様に、

更新後

↓

非準拠ノードが残る

のであれば、

どのノードか
↓
なぜ残ったか
↓
次に何をするか

まで決めます。

完了条件は、

コマンドが終了した

だけではなく、

必要な再起動を完了

+

業務サービスが正常

+

意図したコンプライアンス状態

+

未完了対象の処理方針が確定

まで含めて考えます。

13. 失敗や未完了を次回まで放置しない

パッチ適用が100台中99台で成功した場合、

99%
成功

↓

ほぼ完了

として残り1台を忘れてはいけません。

更新プロセスでは、

成功
↓
完了

失敗
↓
原因調査

再起動待ち
↓
再起動計画

未適用
↓
適用計画

対象外
↓
理由と期限を確認

のように、結果ごとの次の処理を決めます。

特にセキュリティ更新では、

1台だけ未適用

でも、その1台がインターネットへ公開されていれば重要なリスクになる可能性があります。

割合だけでなく、

どのリソースにリスクが残っているか

を確認します。

14. パッチ適用リスクから優先順位を決める

すべての更新を同じ緊急度で処理する必要はありません。

判断材料には、

脆弱性の重大度

実際に悪用されているか

リソースが外部公開されているか

保護するデータの重要性

対象ワークロードの業務重要度

変更による停止リスク

冗長化されているか

必要な再起動

影響対象数

などがあります。

例えば、

インターネット公開

+

重大な脆弱性

+

実際の悪用あり

↓

未適用状態を長く維持する
セキュリティリスクが高い

なら、通常の月次周期より早い対応を検討します。

一方、

重要な単一サーバー

+

冗長化なし

+

パッチ後に再起動

↓

変更による
可用性リスクも高い

なら、

何も考えず即時更新

ではなく、

復旧手段を確認
↓
変更時間を確保
↓
更新
↓
正常性確認

という安全策を追加します。

15. 更新プロセスの改善例

既存運用：

月末

↓

全本番サーバーへ
パッチを一括適用

↓

Systems Manager
成功

↓

完了

改善後：

定期Scan
↓
不足パッチを可視化
↓
パッチ適用リスクを評価
│
├─ 通常
│    ↓
│  通常変更経路
│
└─ 緊急
     ↓
   緊急変更経路

↓

既存の承認ルールに基づき
適用対象を確認

↓

メンテナンス時間を確保

↓

パッチ適用

↓

必要な再起動

↓

アプリケーション確認

↓

再Scan

↓

コンプライアンス確認

↓

失敗 / 未適用 / 再起動待ち
を追跡

改善の中心は、

Patch Managerを導入することそのものではなく、Patch Managerを安全な更新プロセスへ組み込むこと

です。

16. 混同しやすいポイント

17. SAP-C02での判断手順

既存環境について、

パッチ適用は自動化済み

と書かれていても、それだけで改善不要とは判断しません。

まず、

何を適用する？
↓
既存の承認ルール

必要な期限に間に合う？
↓
通常 / 緊急の更新経路

変更影響は？
↓
再起動 / サービス停止

適用後は？
↓
正常性確認

未完了は？
↓
残存リスクを確認

と分解します。

次に、

セキュリティリスク
と
変更リスク

を比較します。

例えば、

重大な脆弱性
+
次回更新まで長い

なら、

緊急更新経路

を検討します。

一方、

再起動でサービス停止
+
冗長化なし

なら、

即時一斉更新

ではなく、変更時間や復旧手段を先に整えます。

最後に、

Install成功
↓
再起動
↓
アプリケーション確認
↓
再Scan
↓
コンプライアンス確認

まで閉じられているかを確認します。

まとめ

既存環境のパッチ管理を改善するときは、

Patch Managerを使う

だけでは不十分です。

見るべきものは、

既存の承認ルール
↓
必要な更新を選べているか

パッチ適用リスク
↓
どれだけ急ぐか

メンテナンスウィンドウ
↓
いつ変更するか

RebootOption
↓
再起動をどう扱うか

更新前後の確認
↓
業務が正常か

コンプライアンス
↓
未完了が残っていないか

です。

安全な更新プロセスは、

現在状態の確認
↓
リスク評価
↓
更新
↓
再起動
↓
正常性確認
↓
コンプライアンス確認

までを一続きとして扱います。

SAP-C02では、

更新を速くすることだけでも、変更を慎重にすることだけでもなく、脆弱性を残すリスクと変更による障害リスクを両方抑える設計

を判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Systems Manager Patch Manager
• Predefined and custom patch baselines
• AWS-RunPatchBaseline
• AWS-RunPatchBaselineWithHooks
• Systems Manager Maintenance Windows
• Patch Manager compliance reports
• Patch now