パッチ適用計画では、「更新できたか」に加えて、どの対象を先に更新し、何を確認して完了とするかを決めます。すべてを同じ日に更新する計画も、いつまでも延期する計画も、対象ごとの事情を判断する材料が不足しているかもしれません。
この記事では、サーバーや業務システムの更新を調整する企業の運用担当者向けに、計画へ残す項目を整理します。特定の脆弱性への緊急対応手順や、製品別の実行コマンドを示すものではありません。
対象と管理責任を確認する
最初に、対象の製品・版・利用業務・管理担当・更新方法を確認します。同じクラウド上でも、自社が更新するOSと、サービス提供者が管理する部分では、実施する作業が異なります。
管理対象の一覧が古い場合、まず実際の稼働状況との差を整理します。停止した資産が残っている一方、臨時に作った環境が抜けていると、対象を正しく決められません。管理責任の整理はクラウドの責任分界も参照してください。
更新の必要性は、製品提供者の案内や組織の脆弱性管理基準に照らして判断します。この記事の一般論だけで、特定の更新を安全に延期できるとは判断しないでください。
優先順位は、重要度と対象環境を組み合わせる
AWSの脆弱性管理ガイドは、リスク評価に基づく優先付けと修正の手順を設けることを推奨しています。重大度やリスクを考慮しないパッチ適用は、避けたい運用例として挙げられています。AWS Well-Architected
対象ごとの判断では、次の情報を揃えると、緊急度と実施条件を話し合いやすくなります。
| 観点 | 確認する内容 |
|---|---|
| 問題の内容 | 対象製品・版、該当条件、提供者の案内 |
| 利用状況 | 外部へ公開しているか、どの業務・情報に関係するか |
| 適用の影響 | 再起動、互換性、連携先への影響 |
| 実施条件 | 必要な停止時間、担当者、確認環境 |
| 未適用時の扱い | 暫定対応の可否、責任者、再判断の時期 |
単純な点数表だけで優先順位を自動決定せず、緊急性の高い案内や組織の判断基準を反映します。情報が不足している対象は、低リスクと扱うのではなく、調査が必要な項目として残します。
事前確認で、更新と業務の動作を分ける
検証環境で更新が正常終了しても、業務の動作まで確認できたとは限りません。認証、データ処理、外部連携、定期ジョブなど、対象に関係する重要な流れを選び、何を確かめるかを決めます。
検証環境と本番に差がある場合は、その差を記録します。接続先を代替しているなら、代替では確認できないことを明確にし、実施時の確認や別の検証へ割り当てます。
また、戻す方法があるかだけでなく、どの状態なら戻し、誰が判断するかも決めます。すべてのパッチを同じ方法で取り消せるとは限らないため、製品と変更内容に合う復旧方法を確認してください。
仮例：複数台の業務サーバーを更新する
以下は計画の考え方を説明する仮例です。実施済みの作業記録ではありません。
複数台で業務を支える構成を更新する場合、最初の対象と、その結果を見て次へ進む条件を決めます。順番に適用できる構成か、混在する版が許容されるかは、事前に提供者の案内や設計を確認します。
計画には、適用前の状態、更新後の版、重要な業務の確認、監視の結果、次の対象へ進む判断を残します。最初の対象に異常が出たら、自動的に残りも進めるのではなく、合意した停止条件に従います。
「再起動後にアクセスできた」だけで終わらせず、対象の役割に合う完了条件を使います。たとえば帳票処理のサーバーなら、必要な処理が完了し、出力結果を確認できることが一つの論点になります。
延期には、理由と再判断の条件を付ける
業務都合や互換性の未確認で延期する場合は、「今回は見送り」とだけ書かず、次の項目を記録します。
- 延期する対象と更新内容。
- 延期理由と、残るリスクについて判断する責任者。
- 適用までの間に行う暫定対応と、その限界。
- 次に確認する日、または再判断する条件。
- 適用へ進むために不足している情報や作業。
延期一覧が増えているなら、個々の作業だけでなく、確認環境や停止時間の確保、管理責任に問題がないかを見直します。サポート終了した製品は、パッチの運用だけで解決できない場合があるため、更改の判断も別に扱います。
完了後は、実施した版と時刻、確認結果、残る対象を保存します。手順の引き継ぎには運用手順書の作り方を参照し、対象一覧と判断条件を含めて次の担当へ渡してください。