エンドポイントにパッチを適用する時がやってきました。 もしかしたら、楽しいことかもしれませんが、私の推測では、おそらくそうではないでしょう。 パッチを適用するのは大変な作業で、多くの組織ではいまだに手作業で行っています。パッチの適用には、誰もが考えたくないほど多くの時間とリソースを費やしています。

パッチの適用にすべての時間とリソースを費やすのであれば、せめてそれがスムーズに行われるようにしたいところです。 パッチ管理にエネルギーを費やして、混乱と失敗のもつれた網の目の中に身を置きたいと思う人はいません。

そこで、月例パッチの問題で最もよくある 2 つの問題に陥らないように気を付けましょう。

  1. パッチは機能していますか？
  2. 環境でパッチをテストしましたか？

パッチの問題 1：パッチは機能していますか？

セキュリティパッチや更新に失敗することは珍しいことではありません。 時には、独特の環境問題が原因であることもあります。 また、パッチ自体に問題があることもあります。

やみくもにデプロイする前に、パッチをチェックしようと決めたのは正しい判断です。 しかし、失敗している今、どのような対処ができるのでしょうか。もちろん、それは状況によって異なります。

解決策 1: サードパーティのパッチ管理会社に問い合わせる

サードパーティのパッチ会社を利用してパッチの更新を管理しているのであれば、最初に連絡を取りたいのはその会社です。

サードパーティのパッチを管理する企業は、顧客にプッシュするコンテンツを精力的にテストしていますが、すべてのユースケースのシナリオをテストすることはできません。 エッジケースがセットアップされているか、エンドポイントがサードパーティのパッチ会社の予想とは異なるパッチを処理している可能性があります。

どのような理由であれ、ベンダーは常に最初に行動するべき相手です。 障害を報告することは、修正してもらうために重要なだけでなく、サードパーティのパッチ会社にとっても有益です。

システム的な問題を見つけた可能性もあります。 あなたは、今、パッチ管理会社が一丸となって迅速に解決できるような大きな問題を警告したヒーローなのです。

もしかしたらシステム的な問題ではないかもしれませんが、一般的な問題であるため、パッチ会社は、将来、他の顧客から問い合わせがあったときのために、より効果的に準備を整えることができるのです。 言うまでもなく、パッチ会社のデフォルトテストプロトコルに追加できる新しいユースケースシナリオの可能性を提供したのです。

解決策 2: パッチの問題の可能性について、より広範なオンラインコミュニティに確認する

しかし、サードパーティのパッチ適用会社を利用していない場合はどうでしょうか。 組織が手作業でこれらのパッチを選別しているとします。

他の組織も同じ問題を抱えているかどうかを調べるには、以下のような素晴らしいオンラインリソースがあります。

  • PatchManagement.org: 「パッチ管理の議論に特化した業界初のメーリングリスト」
  • r/sysadmin、infosec.exchangeなどのさまざまなRedditやMastodonコミュニティ、またはベンダー固有のコミュニティ。
  • Ivanti の Patch Tuesday リソース: どのようなパッチがリリースされ、そこから何が予想されるかを議論するために設計されています。

どの方法を取るにしても、失敗したパッチの何が問題だったのかを特定するためには、多くの選択肢から選ぶことができます。

パッチの問題 2: 環境でパッチをテストしましたか？

さて、あなたはすべてのパッチをテストすることを決めました。 もう大丈夫ですよね。

だめです。

また、組織全体から試験的にデバイスにプッシュするパッチをテストすることも忘れてはなりません。

なぜでしょうか。 結局のところ、それは単なる Chrome の更新です。 しかし、本当にそうなのでしょうか。

システムに新しいパッチを導入することは、家で新しいペットを飼うことと変わりません。 ペットを飼ったことがあり、世話の仕方は心得ているつもりでも、部屋や人に対しては、前のペットにはなかった反応を示すものです。

同じように、各パッチには独自のニュアンスの変更と更新があります。 これらは多くの場合、システムやプログラムが設計されている目的と矛盾し、たとえ以前のテストに合格していたとしても、環境やパッチの有効性を損ねる可能性があります。

結局のところ、ソフトウェア会社はシステムを念頭に置いて製品にパッチを当てることはありません。 むしろ、自分たちのアプリケーションの更新とパッチの適用に集中しており、すべてのユースケースに対応できるわけではありません。

パッチ問題のドミノ効果を解決する

これらの更新をテストする専用の試験的なエンドポイントグループを設定することで、企業が依存しているシステム、プログラム、あるいはプロセスを壊していないことを確認することができます。 小さなパッチの更新がもたらすドミノ効果は、企業の経営に悪影響を及ぼす可能性があります。

たとえば、4 月上旬に、Chrome はいくつかのバグに対処するためのパッチを配布しました。 しかし、新たなバグも導入され、そのうちの 1 つは Chrome の印刷機能に影響を及ぼしました。

もしあなたの組織が印刷を多用する環境で、Chrome で印刷できることが業務に必須のオプションだとしたらどうでしょうか。

このように、すべてのパッチをテストすることで、小さな些細なものであっても、大惨事を避けることができます。

覚えておいてほしいのは、何か問題が発生すると、エラーは最初に影響を受けた部門やユーザーに波及するということです。 ほとんどのユーザーや組織は、小さなパッチが十分にテストされていない場合、それが下流に及ぼす影響について考えていません。 結局のところ、障害や停電の後始末をするのは IT 部門であることがほとんどです。

だから、パッチを適用するときには、成功するように準備したいものです。 そのために、パッチをテストするための様々なエンドポイントを見つけ、回避可能なダウンストリームへの影響を生じさせないことを確認します。また、パッチが失敗した場合に備えて、コミュニティのリソースも準備しています。

こちらもご覧ください。

時には、最善のパッチ管理戦略とは、単なる古き良き準備であることもあります。 幸運を祈ります！