承知いたしました。内容を修正し、「最低でも1時間以上」を「最低1時間」に調整するとともに、手動でオーバーライドファイルを使用してパッチ適用を行う手順を追記します。
AWS Systems Manager Patch Manager: ベースラインで承認したパッチが適用されない事象と対処法
はじめに
AWS Systems Manager Patch Managerを利用したOSパッチ適用において、パッチベースラインで承認したはずの特定のパッチが適用されず、異なるバージョンや意図しないパッチが適用されてしまう 事象が発生する場合があります。本記事では、この予期せぬパッチ適用事象の原因と、今後の運用における対処法について解説します。
事象
Patch Managerのパッチベースラインで「20XX年11月OSパッチ」のように特定のOSパッチを承認し、パッチ適用タスクを実行したにもかかわらず、実際には「20YY年3月OSパッチ」のような、ベースラインで承認していない、あるいは想定とは異なるバージョンのパッチが適用されてしまう。
原因
この事象の主な原因は、Patch Managerの内部処理における、承認済みパッチ設定の伝播タイミングの遅延 にあります。具体的には、パッチベースラインの設定が、実際にパッチ適用プロセスで参照される内部データストア(baseline_overrides.json として表現されているもの)に反映されるまでに時間差があるためです。
baseline_overrides.json は、パッチベースラインの設定に基づき、定期的に(例: 1時間おきに)自動更新されます。しかし、ユーザーがパッチベースラインを更新した直後には、この内部データストアはすぐに更新されません。
これにより、以下のような時間間隔で処理が行われた場合に、最新のベースライン設定がパッチ適用に反映されない問題が発生します。
- 内部データストアの自動更新 (例: 14:00) - この時点では古いパッチ設定が有効
- ユーザーがパッチベースラインを更新 (例: 14:15) - ここで「20XX年11月OSパッチ」を承認済みに変更
- パッチ適用タスクを実行 (例: 14:45) - この実行時、内部データストアはまだ14:00に更新された古い設定のままであるため、「20YY年3月OSパッチ」のような承認済みの古いパッチやデフォルトのパッチが適用されてしまう。
- 内部データストアの次の自動更新 (例: 15:00) - ここで初めてステップ2で変更した最新のベースライン設定が反映される
このように、ユーザーがパッチベースラインを更新してから、その変更が内部システムに完全に伝播するまでの"タイムラグ"が、承認したパッチが適用されない事象を引き起こします。
対処法
パッチベースラインを変更し、特定のKBやパッチバージョンを承認した場合は、その変更がシステム全体に確実に反映されるまで十分な時間を空けてからパッチ適用タスクを実行する ことが不可欠です。
1. 時間間隔を空ける運用回避策
確実な運用回避策として、以下の対応を強く推奨します。
- パッチベースラインの変更後、最低1時間、可能であれば2時間以上の間隔を空けてからパッチ適用タスクを実行してください。 この時間間隔を設けることで、内部データストアが新しいベースライン設定で更新される可能性が大幅に高まります。
- (高度な運用の場合)関連する内部設定ファイルの更新日時を何らかの方法で確認できる場合は、そのファイルが最新のベースライン設定を反映していることを確認してからパッチ適用を開始してください。
2. BaselineOverrideオプションによる手動でのパッチベースライン指定
緊急時や、より厳密に適用するパッチベースラインを制御したい場合、AWS-RunPatchBaselineドキュメントのBaselineOverrideオプションを利用して、適用したいパッチベースラインの内容を直接指定することができます。
この方法では、内部データストアの更新を待つ必要がなく、指定した内容で即座にパッチ適用タスクを実行できます。
手順:
-
適用したいパッチベースラインの ARN を確認し、その内容を取得します。
--baseline-idには、取得したいパッチベースラインのARNまたはIDを指定します。aws ssm get-patch-baseline --baseline-id arn:aws:ssm:ap-northeast-1:************:patchbaseline/pb-***************** -
手順1で取得した出力をもとに、オーバーライドファイル (
overrides.jsonなど) を作成します。
取得したJSONデータから、BaselineId、BaselineName、CreatedDate、ModifiedDateなどのフィールドはBaselineOverrideでは不要なため、取り除きます。GlobalFilters、ApprovalRules、ApprovedPatches、RejectedPatches、PatchGroups、Sourcesなどの、パッチ適用ロジックに関わる部分のみを抽出してJSON形式で保存します。
ファイルは配列形式([])で囲む必要があります。overrides.jsonの例:[ { "OperatingSystem": "WINDOWS", "GlobalFilters": { "PatchFilters": [ { "Key": "PRODUCT", "Values": [ "*" ] } ] }, "ApprovalRules": { "PatchRules": [ { "PatchFilterGroup": { "PatchFilters": [ { "Key": "CLASSIFICATION", "Values": [ "CriticalUpdates", "SecurityUpdates" ] }, { "Key": "MSRC_SEVERITY", "Values": [ "Critical", "Important" ] } ] }, "ComplianceLevel": "UNSPECIFIED", "ApproveAfterDays": 7, "EnableNonSecurity": false } ] }, "ApprovedPatches": [], "ApprovedPatchesComplianceLevel": "UNSPECIFIED", "ApprovedPatchesEnableNonSecurity": false, "RejectedPatches": [], "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", "PatchGroups": [], "Sources": [] } ] -
作成したオーバーライドファイルを、インスタンスからアクセス可能な任意の S3 バケットに保存します。
aws s3 cp overrides.json s3://my-bucket/ -
S3 バケットに保存したオーバーライドファイルをもとに、
AWS-RunPatchBaselineドキュメントを直接実行します。
BaselineOverrideパラメーターにS3バケットのパスを指定します。OperationにはScan(スキャンのみ)またはInstall(インストール)を指定できます。aws ssm send-command --targets 'Key=InstanceIds,Values=i-*****************' --document-name AWS-RunPatchBaseline --parameters 'BaselineOverride=s3://my-bucket/overrides.json,Operation=Install'
この運用上の注意点を守ることで、AWS Systems Manager Patch Managerで設定した承認済みパッチが確実に適用されるようになり、意図しないパッチ適用やバージョンのずれを防ぎ、パッチ適用の安定性と信頼性を向上させることができます。
まとめ
AWS Systems Manager Patch Managerにおいて「ベースラインで承認したはずのパッチが適用されない」という事象は、パッチベースライン変更から内部設定反映までの時間差が主な原因です。このタイムラグを理解し、ベースライン変更後には最低1時間の待機時間を設けてからパッチ適用タスクを実行する、または**BaselineOverrideオプションを利用して適用したいパッチベースラインを直接指定する** という運用を徹底することで、パッチ適用の確実性を高めることができます。