パッチ管理のベストプラクティス

ソリューション・アーキテクトである私は、パッチ管理に関する Red Hat のベストプラクティスは何かとよく尋ねられます。この記事では、必要に応じて関連する著作や資料にリンクしつつ、ベストプラクティスとは何か、またパッチ管理ツールキットの一部としてどのツールを活用できるかについて、的を絞ったガイダンスを提供します。

この記事を読むことで、パッチを提供するために活用できるツールとアプローチ、そして組織としてそのプロセスを定義するためのベストプラクティスについて、より明確に理解できるようになります。

何かを「ベストプラクティス」と呼ぶのは、確かに少々厚かましいものです。ある組織にとってベストなものが、別の組織にとってもベストとは限りません。そのため、1 つのアプローチに「ベスト」のラベルを付けるのではなく、所定のリスクレベルに最も適しているという観点からプロセスを検討するほうがよいと考えます。パッチ管理は、最終的にはリスク管理または変更管理を意味します。

どの組織にも、リスクに対処するためのアプローチが必要です。しかし、それぞれに、定義の方法、何に焦点を当てるか、さまざまなビジネス上の制約、影響、または結果をどのように考慮するかについて、独自のアプローチが必要です。

私は、より適切な表現として「グッドプラクティス」を推奨しています。たとえば、Automation Community of Practice は、現場の顧客支援から得た知見に基づいて自動化のグッドプラクティス・ドキュメントを公開しています。

パッチ管理のツールキットおよびアプローチの一部として何を活用できるか

インフラストラクチャ内でパッチを管理する方法を定義するためのツールと手法があります。

1.エラータの定義

Red Hat はコードまたはコンテンツの変更 (エラータ) を 3 つの異なるカテゴリに分類します。各カテゴリの目的と変更の度合いはそれぞれ異なります。組織の目標や変更に対する許容度によっては、あるオプションが別のオプションよりも目的と変更の度合いに適している場合があります。

• Red Hat Security Advisory (RHSA)：システムを保護するための緊急変更が行われた場合
• Red Hat Bug Advisory (RHBA)：影響を受けた可能性がある、または受けなかった可能性があるバグの修正
• Red Hat Enhancement Advisory (RHEA)：新機能が追加された場合

詳細については、Red Hat のセキュリティ・バックポート・プラクティス、および 「バックポートとは、そして RHEL や他の Red Hat 製品にどのように適用されるか」を参照してください。

この原則を使用して、エラータを種類とリスクで分離し、必要と見なすパッチと任意と見なすパッチを選択できます。 

たとえば、インターネット向けのインフラストラクチャや、高度なセキュリティプロファイルを備えた DMZ (非武装地帯) がある場合、その環境でリリースされるのと同じ頻度で、Red Hat Security Advisory のエラータのみを適用することもできます。これにより、リスクの高いインフラストラクチャのニーズに対処しながら、変更を小規模で使いやすいバッチに分割することができます。 

以下のリンクは、パッチプロセスでセキュリティエラータのみを適用する方法の例です。

• Yum を制限して、セキュリティアップデートのみを一覧表示またはインストールすることは可能か
• Red Hat Satellite のセキュリティエラータを適用する方法

検討すべき追加のアプローチは、パッケージのサブセットでパッチを適用して変更リスクをさらに軽減することです。また、パッチが予期しない方法でシステムとやり取りした場合に、ロールバックの柔軟性も実現します。他のアプローチと同様に、この場合も、注意と管理が必要なトレードオフがあります。人によっては細かすぎるプロセスになるかもしれず、他の人にとってはこの方が変更を許容しやすくなる場合もあります。

2. 標準運用環境 (SOE) をビルドするための 10 のステップ

この記事では、Red Hat Satellite を使用して標準運用環境を有効化し、管理する方法を詳しく説明します。すべてのトピックについて細かく解説しており、ベストプラクティスに関するよくある質問に答えるための参照ポイントとして提供されています。このコンテンツは数年前に Red Hat Satellite 6 が最初に導入されたときに書かれたものですが、基本概念は現在も適用できます。

コンテンツ管理とコンテンツのステージングは、パッチ適用プロセスにとって最も重要です。これは、パッチコンテンツをインフラストラクチャに提示する方法の基盤となり、リスク管理とリスク低減のためのパッチ適用プロセスにおいて大きな役割を果たします。

とくに、Satellite のライフサイクル環境とコンテンツビューに焦点を当てます。これらは、コンテンツのステージングとインフラストラクチャへのプロモーション (またはロールバック) にとって重要な概念です。

次に、インフラストラクチャとインベントリーを分類するために、組織、場所、ホストグループに焦点を当てます。地理的な場所、クラウド環境、類似のインフラストラクチャ、組織内の別のチームを分類するためにこの構造を使用しようとして、ライフサイクル環境やコンテンツビューを細分化しすぎることはあまりにも多く見受けられます。

3.ライブカーネルパッチ

ライブカーネルパッチは数年前から利用可能であり、いくつかのメジャー RHEL リリースに含まれています。脆弱性に迅速に対処するために、再起動せずにカーネルにライブパッチを適用できます。これにより、管理者はリスクに即座に対処することができ、再起動の実行時に、より適切なメンテナンス期間をスケジュールできます。 

Red Hat Satellite を使用してオーケストレーションすることもできます。

4.更新後にシステムの再起動が必要なパッケージを特定する

更新とエラータの内容によっては、パッチ後に再起動する理由がない場合があります。場合によっては、更新後にサービスを再起動するだけで更新されたバイナリーを利用できる場合があります。 

RHEL 7 以降、yum-utils には needs-restarting というプラグインが含まれています。このユーティリティは、パッチの適用後に再起動が必要かどうかをレポートします。これによってシステムへの変更の必要性を理解し、パッチ適用時に再起動を実行する必要性を減らすことができます。

Satellite には、Tracerと呼ばれる機能もあります。Tracer は Satellite の観点からも同じことを行い、管理者がシステムのパッチ適用後に再起動が必要なアプリケーションを特定するのに役立ちます。

5.Red Hat サポートケースを事前に作成することを検討する

特定の保守作業に関する高度な知識を持ち、事前に情報とデータを収集する機会を得ることで、ダウンタイムとパッチ適用に関連するリスクの一部を削減できます。

プロアクティブなサポートケースを作成することで、サービスの復旧に必要 なトラブルシューティングの時間を大幅に短縮でき、手順やアプローチを事前に確認することも可能になります。これは、サービス停止と MTTR (平均修復時間) メトリクスの削減に測定可能な影響を与える可能性があります。

6.自動化する

手動のステップを自動化されたアプローチに置き換えることで、ヒューマンエラーを削減し、信頼性を高め、パッチ適用プロセスを迅速化できることは周知の事実です。自動化は、組織に適切なベストプラクティスを導入する際の重要な差別化要因です。

Red Hat Satellite には、Ansible でリモート実行を使用する機能があります。Red Hat Satelliteは、RHEL インベントリーで Ansible Playbook とロールを実行し、パッチ適用作業を簡単に自動化してスケジュールすることができ ます。

実際、Red Hat Ansible Automation Platformで提供される公式のredhat.satellite Ansible コレクションを使用すると、ステージング後にパッチコンテンツを適用するのに加えて、Satellite のコンテンツ管理全体を自動化し、オーケストレーションできるようになります。

さらに一歩進んで、パッチを適用した後に Web サービスの機能テストやサービス検証を実行するために使用できる Ansible モジュールもあり ます 。

要約

Red Hat は、脆弱性管理のためのオープンアプローチを公開しました。これは、組織としての脆弱性管理へのアプローチ方法に関する簡潔かつ包括的な方法論です。リスク管理は、ビジネス上の制約、影響、結果を検討および比較した後に下す必要がある決定です。

問題は、すべての脆弱性は本当に問題なのかということです。この記事では、制約、影響、結果の評価に関連する現実とトレードオフの一部について説明します。これは、結果への期待と、それを実現するためのコストとメリットを比較検討する良い例です。すべてのリスクを考慮する必要があるとはいえ、すべてを同じように重視するべきではなく、すべてのリスクに対処するために無制限のリソースを持っているわけでもありません。この例では、最も重要なものに優先順位を付け、軽減する価値があるリスクと共存しやすいリスクを分類する戦略を用意しています。

簡単に言えば、反復とコミットメントが必要です。この記事で紹介した例はどれも、これが初めての試みではありません。Red Hat が最適と見なすリスク管理のバランスが見つかるまで、それらを再検討し、改良を重ねました。そして、このような手法は、新しい事柄を学ぶ度に、あるいは業界を取り巻く状況が変化するにつれ、改良され続けています。リスク許容度と体制を評価し続けることは、最初にアプローチを定義しておくのと同じくらい重要です。継続的な調整と改良によって、「ベスト」を「ベストプラクティス」に組み入れ続けることができます。