小規模環境でのパッチ適用

エンタープライズITショップでは、システムのパッチ適用は複雑なプロセスであり、OSやソフトウェアベンダーから届く各新しいパッチが組織で利用可能なハードウェアとソフトウェアの組み合わせとどのように相互作用するかを確認するために、本番環境をミラーリングした多数のテストシステムを使用します。理想的な世界では、すべてのショップが管理されたパッチ適用プロセスを持ち、新しく公開されたパッチに即座に対応し、即座にテストし、パッチが安全かつ適用可能と判断されたらすぐに適用されるでしょう。しかし世界は理想的ではなく、現実には物理的・時間的・財務的なリソースの制限の中でやりくりする必要があります。

パッチは一般的にいくつかの主要な理由でリリースされます。セキュリティ、安定性、パフォーマンス、そして時には新機能の提供です。通常は別のリリースプロセスで処理される新機能の追加を除いて、パッチは既知の問題に対する修正を表しています。これは「壊れていなければ直すな」というシナリオではなく、「壊れているがまだ完全に失敗していない」というシナリオであり、注意が必要です——できるだけ早く対応するに越したことはありません。パッチに対して「様子を見て待つ」アプローチを取ることは賢明ではありません。新しいパッチの存在は、悪意のあるハッカーが分析できる「修正」があることを意味し、以前に悪用手段が存在しなかったとしても、すぐに出現するでしょう。パッチのリリース自体が、そのパッチを即座に必要とするトリガーとなり得ます。

このパッチエコシステムは「迅速にパッチを適用する」という考え方の必要性を生み出しています。パッチを放置すべきではなく、リリースされテストされたらすぐに適用する必要があります。パッチ適用を遅らせることは、重大なセキュリティバグを抱えたまま運用したり、システムを不必要に不安定な状態に置くことを意味します。

小規模なITショップでは、サーバー、ネットワーク機器、デスクトップのいずれについても、テスト環境がほとんど、あるいはまったく存在しません。理想的ではありませんが、現実的には、たとえそれらの環境が利用可能であったとしても、小規模ショップではそれらのテストを適時に実行するための余剰IT人材リソースがほとんどありません。

これは聞こえるほど暗澹としたものではありません。ほとんどのパッチに対して行われるテストは、ベンダーがすでにテスト済みのパッチと重複しています。ベンダーは自社製品で発生しうるすべてのハードウェアとソフトウェアの相互作用をテストすることは不可能ですが、一般的には幅広い組み合わせをテストし、相互作用が最も発生しやすい領域を調べます。主要なベンダーが悪いパッチで自社ソフトウェアを損なうことはまれです。はい、それは起こり得ますし、良好なバックアップとロールバックプランを持つことは重要ですが、日常業務において、パッチ適用は比較的安全なプロセスであり、発生する可能性があるかもしれない機会を待つよりも迅速に行う方がはるかに重要です。

他のシステム変更と同様に、パッチは頻繁に少量ずつ適用するのが最善です。パッチが迅速に適用されれば、通常は1つまたは少数のパッチのみを同時に適用する必要があります。OSについては、特に週次でパッチを適用する場合、複数のパッチを同時に処理しなければならないことがありますが、この方法で行えば、一度に数十または数百のファイルにパッチを当てることはほとんどありません。このように行うと、パッチの悪影響を評価し、パッチ適用プロセスがうまくいかない場合にロールバックすることがはるかに容易になります。

適切なパッチテストワークフローを持たない中小企業にとって最悪のシナリオは、パッチを待つことです。待つということは、システムが長期間にわたって必要なケアを受けられず、パッチが最終的に適用されるときには大量のパッチを一括して適用することになります。多数のパッチを一度に適用すると何か問題が発生する可能性が高まり、問題が発生したときにどのパッチが原因かを特定し、修復の道筋を見つけることがはるかに難しくなります。

遅延パッチ適用は、ITやビジネスにとってほとんどまたは全くメリットをもたらさないプロセスですが、セキュリティ、安定性、パフォーマンスに対して実質的なリスクをもたらします。小規模環境でのパッチ適用のベストプラクティスは、システムができるだけ早く自己パッチを適用できるようにするか、ビジネスがパッチ適用の失敗やパッチ修復の処理に最も備えている時間帯に定期的（おそらく週次）なパッチ適用プロセスをスケジュールすることです。自動的にパッチを適用するか、単に手動プロセスを通じて定期的に行うかに関わらず、最良の結果を得るために頻繁かつ迅速にパッチを適用してください。