更新するか、更新しないか？

現在働いている場所で働き始めてから、システムの更新に関して上司や同僚との果てしない闘争を続けてきました。

もちろん、アップデート（ファームウェア、OS、またはアプリケーション）が出てすぐに不注意に適用すべきではないことに完全に同意しますが、ベンダーがそれをリリースした場合、少なくとも何らかの理由があるはずだと固く信じています。最も一般的な理由は、通常、いくつかのバグを修正している...多分あなたは今経験していないが、あなたはどの可能性があり、あなたが追いつくていない場合はすぐに体験すること。

これは特にセキュリティの修正に当てはまります。例として、すでに数か月間利用可能だったパッチを誰もが単に適用した場合、悪名高いSQL Slammerワームは無害だったでしょう。

更新プログラムを展開する前に、テストと評価をすべて行います。しかし、システム管理の「壊れていない場合は触らない」というアプローチには強く反対し、実稼働Windows 2003 SP1またはESX 3.5 Update 2システムを見つけたときは本当に痛い思いをします。 「それは機能している、私たちはそれを壊したくない」。

これについてどう思う？あなたのポリシー
は何ですか？ それがあなたの会社の方針と一致しない場合、あなたの会社の方針は何ですか？

ファームウェアの更新（BIOS、ストレージなど）はどうですか？
メインのOSアップデート（サービスパック）はどうですか？
OSのマイナーアップデートはどうですか？
アプリケーションの更新はどうですか？

クライアントのパッチ管理は通常、より簡単であり、それを処理するためのよく知られたツールとベストプラクティスがあるため、私の主な関心はもちろんサーバーの更新です。

パッチ適用戦略を決定するときは、セキュリティと俊敏性を安定性と稼働時間に対してバランスを取る必要があります。これに対するプッシュバックアプローチは、「わかりましたが、これらのサーバーが侵害されてデータが盗まれたり、サーバーが機能しなくなったりするリスクがあることを知っておく必要があります」 「わかりましたが、これはこのシステムに対するベンダーのサポート、およびこのシステムが新しいシステムと対話する将来の能力に影響することを知っておく必要があります」。

長期的な「壊れない、更新しない」という考え方に対して、次のことを明確にする必要があります。

• パッチが適用されていないレガシーシステムを最新のシステムに移行することは、そのシステムを徐々に更新するよりもはるかに費用がかかり、痛みを伴うプロセスです。
• 経験豊富で熟練したIT担当者は、ITシステムを絶えず進化させている新しいテクノロジーや企業を積極的に探しています。システムが停滞し、仕事をするのが魅力的ではないために、企業が非常に熱心で創造的なITスタッフを失った場合、売り上げ、機会の喪失、知識の損失に非常に大きなコストがかかります。あとは、「生命体」だけです。

これにより、上記のことを真剣に受け止められるようになります。いつものように、彼らが取っているリスクの管理をあなたが知っていることを証明する紙の証跡を確立してください。

これは終わりのない議論であり、合理的な人々は同意しません。ユーザーのPCについて話している場合、それらを更新する必要があることに同意します。サーバーについて話している場合は、インターネットに直面しているサーバーとそうでないサーバーに別々のポリシーを検討してください。私はあなたのサーバーについては知りませんが、私の環境では、おそらく私たちのサーバーの10％がインターネットに開いているポートを持っています。これらのインターネットに接続されたサーバーは、セキュリティパッチに関して最高の優先順位を取得します。インターネットに面していないサーバーは優先順位が低くなります。

セキュリティの達人は、ハッカーがネットワークに侵入した場合、パッチが適用されていないサーバーがエクスプロイトが野火のようにネットワークを介してフリッターすることを許可するため、このアプローチには問題があると主張します。それでも、これらのインターネットに接続されたサーバーをしっかりとロックし、絶対に必要なポートのみを開くようにファイアウォールを適切に構成すると、このアプローチは機能し、パッチを恐れるマネージャーをなだめるためによく使用できると思います。

パッチをWindows Updateのみに依存している場合（実行しているOSについては言及しませんでしたが、ほとんどがWindowsの男なので、これが私の参考です）、毎月リリースされる実際の修正プログラムをご覧ください。Windows Updateを実行すると50以上のパッチが必要であると通知されるサーバーがいくつかありますが、それらのパッチをスクロールして各パッチを調査すると、パッチであるアイテムの90％がセキュリティではないことがわかります関連するが、そのボックスで実行しないサービスに影響するバグを修正する。パッチ管理システムを使用する大規模な環境では、リリースされるものすべてをレビューし、絶対に必要なものだけを気にするのが一般的です。通常、Microsoftがリリースするものの約10％になります。

私の主張は、「パッチを適用するかしないか」についてのこの議論は、本当にこれが巨大な灰色の領域であるとき、あなたはどちらか一方でなければならないことを示唆しているということです。

私はサーバーについてのみ話すことができますが、「四半期更新」体制があり、毎年4つの事前に決定され発表された日付に更新要求をまとめ、参照環境に適用し、1か月間実行して安定性をテストし、適切に展開されている場合次のn日間/週中。さらに、緊急アップデートポリシーを適用します。このポリシーでは、重大度がそのような場合、1〜2日以内に緊急アップデートを参照、テスト、および展開できます。ただし、これは最後に2/3回しか使用されていません4年かそこら。

このツインアプローチにより、当社のサーバーは合理的ではあるが、愚かではなく、最新であり、更新はベンダーではなく主題専門家（つまり、ファームウェア、ドライバー、OS、アプリスタッフ）によって行われますが、必須。もちろん、ビジネス全体（10種類未満のサーバーバリエーション）で非常に少数の異なるハードウェアモデルがあり、テスト対象のかなりの、そして最新の参照プラットフォームがあるのは幸運です。

私は、「できるだけ早くパッチを適用し、動作しているものを壊しても構いません-その時点でそれらをバックアウトします」から「2週間なしでは何も適用されない」から、継続的にポリシーを持つさまざまな企業で働いてきましたテストの。」当社がトレードオフを理解している限り、両極端（およびその間のポイント）は問題ありません。

それが重要なポイントです。この質問に対する特定の正解または不正解はありません。特定の環境での安定性と安全性または機能のバランスの問題です。テストのためにパッチを遅らせると、マルウェアに対してより脆弱になる可能性があることを管理チェーンが理解している場合、それは問題ありません。同様に、利用可能になり次第パッチを適用しても機能しなかったり、特定のシステム構成が壊れたりする可能性があることを理解していれば、それも問題ありません。これらのトレードオフが理解されていない場合、問題が存在します。

私の見解では、最高のコースは両極端の真ん中にあるということです。たとえば、ESDをアップグレードする明確な理由がないのに、ESXを必死にアップグレードしたいのはなぜですか。確かにそれが公共に面していれば脆弱であるかもしれませんが、ネットワークの外部から直接アクセスできる方法はないはずですので、リスクはどこにありますか？アップグレードする理由を実際に示しているバグや機能の欠如はありますか？

そのためにアップグレードすることは、実際にはあなたが提案していることです（「すぐに経験するかもしれません」）、そうではないと主張していても、不条理で危険な旅行の道です。理論的に考えられる理由とは対照的に、実際の理由を提示できない限り、アップグレードに反対する人を他の人に納得させることはできません。

アップグレードを実行する本当の理由があると思われる場合は、長所と短所の両方を文書化する必要があり、常に短所があり、それをツリーの上位に提示します。適切に文書化されていれば、抵抗はほとんどないはずです。説得力のある議論を提供できない場合は、しばらく座ってその事実を真剣に考えてください。

編集

ソフトウェアまたはOSのアップグレードを実行する場合と比較して、必要なセキュリティパッチと安定性パッチの適用に大きな違いがあることを明確にする必要があると考えました。最初に適切なテストの後に実装します。後者は、本当の利益がある場合にのみ行います。

セキュリティ更新プログラムはステージングサーバーに送信され、その後、爆発しないことを示した後に本番サーバーに送信されます。本当のブリーピング緊急事態がない限り（私は数回ヒットしています:(）、その場合はPRODUCTION NOW。

最初にすべきことは、更新プログラムを重大度別に "分類"し、分類に基づいてパッチスケジュールを設定することだと思います。ゼロデイセキュリティ修正をすぐに適用する必要があることは間違いありません。一方、Service Packは慎重に評価してから待つことができます。