パッチを管理する正しい方法

なぜ私が「システム管理 101」記事シリーズを再び継続することにすぐに決めたのかというと、一部の Linux システム管理者は、パッチ管理に関しては Windows システム管理者と何ら変わらないことに気づいたからです。正直に言うと、一部の領域ではさらに悪いです (特に実行時間に誇りを持っています)。したがって、この記事では、優れたパッチ管理とはどのようなものなのか、使用できる関連ツール、パッチのインストール プロセス全体がどのように実行されるのかなど、Linux でのパッチ管理の基本概念について説明します。

パッチ管理とは何ですか?

パッチ管理とは、単にソフトウェアを最新かつ最高の最先端バージョンに更新するためではなく、サーバー上のソフトウェアをアップグレードするために導入するシステムを意味します。 「安定性」のためにソフトウェアの特定のバージョンを維持する Debian のような保守的なディストリビューションでさえ、バグやセキュリティ ホールを修正するためにアップグレード パッチを随時リリースします。

もちろん、開発者が最新かつ最高のバージョンを必要としており、ソフトウェアのソース コードを取得して変更を加える必要があるため、またはあなたがソフトウェアを提供したいため、組織が特定のソフトウェアの独自のバージョンを維持することを決定した場合は、余分な作業をすると、問題が発生します。理想的には、他のソフトウェアで使用されているのと同じ継続的統合システムを使用して、ソフトウェアのカスタム バージョンを自動的に構築およびパッケージ化するようにシステムを構成する必要があります。ただし、多くのシステム管理者は、Wiki の (できれば最新の) ドキュメントに従って、ローカル ホスト上でソフトウェアをパッケージ化する古い方法を依然として使用しています。どの方法を使用する場合でも、使用しているバージョンにセキュリティ上の欠陥があるかどうかを確認する必要があります。セキュリティ上の欠陥がある場合は、カスタマイズしたバージョンのソフトウェアに新しいパッチがインストールされていることを確認する必要があります。

優れたパッチ管理とは何ですか?

パッチ管理で最初に行うことは、ソフトウェアのアップグレードを確認することです。まず、コア ソフトウェアについては、ソフトウェアのセキュリティ アップグレードについてできるだけ早く知ることができるように、対応する Linux ディストリビューションのセキュリティ メーリング リストに登録する必要があります。ディストリビューションのリポジトリから提供されていないソフトウェアを使用する場合は、そのソフトウェアのセキュリティ更新プログラムも追跡する必要があります。新しいセキュリティ通知を受信したら、通知の詳細を確認して、セキュリティの脆弱性の重大度、システムが影響を受けるかどうか、およびセキュリティ パッチの緊急性を判断する必要があります。

一部の組織では、パッチを管理するために依然として手動の方法を使用しています。このように、セキュリティパッチが登場すると、システム管理者は記憶を頼りに各サーバにログインして確認する必要があります。どのサーバーをアップグレードする必要があるかを判断したら、サーバーの組み込みパッケージ管理ツールを使用して、リリース リポジトリからこれらのソフトウェアをアップグレードします。最後に、残りのすべてのサーバーを同じ方法でアップグレードします。

パッチを手動で管理する方法には多くの問題があります。まず、そうすることでパッチ適用が面倒になり、インストールするパッチが増えれば増えるほど、より多くの人件費が必要となり、システム管理者がパッチ適用を延期したり、完全に無視したりする可能性が高くなります。第 2 に、手動管理では、システム管理者の記憶に頼って、システム管理者が担当するサーバーのアップグレードを追跡します。これにより、一部のサーバーが欠落し、アップグレードが間に合わなくなる可能性が高くなります。

パッチ管理が速くて簡単であればあるほど、パッチ管理を適切に行う可能性が高くなります。特定のソフトウェアを実行しているサーバーとそれらのソフトウェアのバージョン番号を迅速に照会できるシステムを構築する必要があり、理想的にはさまざまなアップグレード パッチをプッシュできる必要があります。個人的には、このタスクを完了するために MCollective などのオーケストレーション ツールを使用することが多いですが、Red Hat が提供する Satellite や Canonical が提供する Landscape を使用しても、統一された管理インターフェイスでサーバーのソフトウェア バージョン情報を表示し、パッチをインストールできます。

パッチのインストールもフォールトトレラントである必要があります。サービスをオフラインにせずにパッチを適用できる必要があります。システムの再起動が必要なカーネル パッチにも同じことが当てはまります。私が採用した方法は、サーバーをさまざまな高可用性グループに分割し、lb1、app1、rabbitmq1、db1 を 1 つのグループに、lb2、app2、rabbitmq2、db2 を別のグループに分けることです。こうすることで、サービスをオフラインにすることなく、一度に 1 つのグループをアップグレードできます。

それでは、どれくらいの速度が速いと考えられるのでしょうか?サービスが付属していないいくつかのソフトウェアについては、数分から長くても 1 時間でシステムにパッチをインストールできるはずです (bash の ShellShock 脆弱性など)。サービスの再起動が必要な OpenSSL などのソフトウェアの場合、パッチをインストールしてフォールト トレラントな方法でサービスを再起動するプロセスに少し時間がかかる場合がありますが、ここでオーケストレーション ツールが役に立ちます。 MCollective に関する最近の記事 (2016 年 12 月と 2017 年 1 月のチケットを参照) では、パッチ管理に MCollective を使用する例をいくつか示しました。フォールトトレラントかつ自動化された方法でパッチのインストールとサービスの再起動を簡素化するシステムを導入することが最善です。

カーネル パッチなど、パッチにシステムの再起動が必要な場合は、さらに時間がかかります。繰り返しますが、自動化ツールとオーケストレーション ツールを使用すると、このプロセスが思ったよりも速くなります。 1 ～ 2 時間以内に実稼働サーバーをフォールト トレラントにアップグレードして再起動することができました。再起動の間にクラスターの同期バックアップを待つ必要がなければ、プロセスはさらに速くなりました。

残念ながら、カーネルの緊急パッチが年に 1 回程度行われることを考えると、多くのシステム管理者は依然として稼働時間は誇りの象徴であるという時代遅れの見方に固執しています。私にとって、これは単にシステムのセキュリティを真剣に考えていないことを意味します。

多くの組織は依然として、一時的にオフラインにすることができない単一障害点となるサーバーを使用しており、そのためアップグレードや再起動ができません。システムの安全性を高めたい場合は、古い荷物を取り除き、少なくとも深夜のメンテナンス時間帯に再起動できるシステムを構築する必要があります。

基本的に、迅速かつ便利なパッチ管理は、成熟したプロフェッショナルなシステム管理チームの表れでもあります。ソフトウェアのアップグレードは、すべてのシステム管理者にとって必要なタスクの 1 つであり、時間をかけてこのプロセスをシンプルかつ迅速に行うことにより、システムのセキュリティをはるかに超えるメリットがもたらされます。たとえば、アーキテクチャ設計における単一障害点を見つけるのに役立ちます。さらに、環境内の古いシステムを特定するのに役立ち、これらの部品を交換するインセンティブを提供します。最終的に、パッチ管理が十分に行われると、システム管理者の時間が解放され、専門知識が本当に必要な領域に集中できるようになります。

---

Kyle Rankin は、シニア セキュリティおよびインフラストラクチャ アーキテクトであり、著書に『敵対的なネットワークにおける Linux Hardening』、『DevOps トラブルシューティング』、および『The Official Ubuntu Server Book』などがあります。彼は Linux Journal のコラムニストでもあります。

---

以上がパッチを管理する正しい方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。