Server patch management 101: Strategies for secure infrastructure

サーバーはノートパソコンのようにパッチを適用できません。 従業員のワークステーションでの更新の失敗は、1人の人に迷惑をかけてしまいます。 データベースサーバーでの更新処理が失敗すると、事業部門全体にわたるトランザクションが混乱したり一時的に停止したりする恐れがあるため、ロールバック計画の策定が不可欠となります。

エンドポイント向けに設計された標準的なデバイス管理の手法は、サーバー環境にはそのまま適用できません。 運用上のリスク、依存関係、および稼働時間の要件は、根本的に異なります。

その爆風半径の違いによって、パッチ適用計画の立案、段階的な実施、および実行方法のすべてが変わってきます。 サーバーのパッチ管理では、稼働時間の要件、アプリケーション間の依存関係、および変更管理のワークフローを考慮した調整が必要となりますが、エンドポイントのパッチ適用では通常、こうした調整は不要です。

本ガイドでは、サーバーへのパッチ適用を他と一線を画す運用上の制約について解説します。具体的には、資産管理や依存関係のマッピングから、リスクに基づく優先順位付け、リング方式による展開、チーム間の連携、そして展開後の検証に至るまでを網羅しています。

サーバーのパッチ適用には、なぜ異なる運用アプローチが必要なのでしょうか

データベースサーバーでの更新処理が1回失敗するだけで、事業部門全体が機能停止に陥る可能性があります。 だからこそ、サーバーへのパッチ適用は、単に のパッチ管理 を大規模化したものではなく、根本的に異なる運用上の取り組みなのです。

一般的なパッチ管理プロセス には、適用されていない更新プログラムのスキャン、ステージング環境でのパッチのテスト、メンテナンス時間帯でのパッチの展開、および結果の報告が含まれます。 のベストプラクティスには、反復的なタスクの自動化、Windows環境におけるMicrosoftの「パッチ・チューズデー」のような定期的なパッチ適用スケジュールの順守、Linuxやその他のプラットフォームにおけるベンダー固有のリリースサイクルの順守、および更新プログラムを適用する前のバックアップやスナップショットの作成などが含まれます。

しかし、それが標準的な枠組みです。 サーバーを管理する企業チームの現実は、もっと複雑です。

サーバーでは、多くの場合、 24/7 のワークロードが稼働しており、そのメンテナンス時間は数週間前から調整された、限られた時間枠に設定されています。 その機会を逃すと、パッチがすでに承認され、適用準備が整っている場合でも、公開期間が数週間延長されてしまいます。 標準の エンドポイント管理では、業務の合間にデバイスを再起動しても、業務への影響を最小限に抑えることができます。 サーバーには、そのような柔軟性はありません。

それから、依存関係の問題もあります。 サーバーが単独で稼働することはめったにありません。 あるサーバーへのパッチ適用により、別のサーバーが依存しているAPIが動作しなくなる可能性があり、その結果、下流にある第3のシステムにも影響が及ぶことがあります。 サービスと依存関係が相互に絡み合ったこのネットワークこそが、サーバーへのパッチ適用をエンドポイントへのパッチ適用よりも根本的に複雑にしている要因であり、変更を一括で展開するのではなく、慎重に順序立てて実施しなければならない理由でもあります。

サーバーへのパッチ適用に関する制約があっても、作業が不可能になるわけではありません。 それにより、運用上の区別が明確になります。 以下のセクションでは、新たな運用上の問題を引き起こすことなくリスクを低減できるよう、各制約に対処する方法について順を追って説明します。

サーバーのインベントリおよび依存関係のマッピング

何かを展開する前に、どのようなパッチを適用するのか、またそれに依存しているものが何なのかを把握しておく必要があります。 サーバーのインベントリが不完全だと、展開が始まる前からパッチ適用作業に支障をきたす恐れがあります。

パッチ適用を目的としたサーバーのインベントリ作成は、単なる資産の特定にとどまりません。 これには、オペレーティングシステムのバージョン、インストールされているアプリケーション、パッチの適用状況、および各サーバーがサポートする業務機能が含まれます。 この情報がないと、チームは、特定のサーバーがテスト用ワークロードを実行しているのか、本番用データベースを実行しているのかが分からず、手探りの状態でパッチを適用することになってしまいます。

[包括的なリアルタイムのIT資産インベントリが、セキュリティ侵害に発展する前にリスクを管理する能力をどのように変革するかをご覧ください]

依存関係のマッピングにより、さらに別のレイヤーが追加されます。 サーバーは、他のシステムから呼び出されるサービスをホストすることがよくあります。 ミドルウェアサーバーで再起動が必要なパッチを適用すると、下流のアプリケーションへの接続が一時的に途切れることがあります。 のクラウドやコンテナを多用する環境 では、パッチ適用とは、長期稼働するインスタンスをその場で更新するのではなく、ゴールデンイメージを再構築し、ワークロードを再デプロイすること（不変インフラストラクチャ）を意味する場合もあります。

各サーバーがどのサーバーと連携しているか、またどのサーバーから影響を受けるかを把握することで、チームはパッチの適用順序を適切に決定し、影響を受ける関係者に通知することができます。

手作業による在庫管理プロセスでは、サーバーの無秩序な増加に追いつくのが困難です。 クラウド環境ではサーバーの起動や停止が頻繁に行われますが、オンプレミスのインフラストラクチャも同様に頻繁に変化しており、廃止や再構成、新たな導入などが行われていますが、それらが必ずしも記録されるとは限りません。 設定のずれは、時間の経過とともに蓄積されていきます。 四半期ごとの監査に依存しているチームは、パッチの適用に失敗したり、監査でカバー範囲の不足が指摘されたりして初めて、その不備に気づくことがよくあります。

のリアルタイムな資産可視化機能は、サーバーの状態を継続的に追跡することで、この課題に対処できます。 新しいサーバーが稼働を開始したり、既存のサーバーの設定が変更されたりした場合、設定や接続状況に応じて、インベントリが自動的に更新されることがあります。

最新のパッチ管理ソフトウェアでは、このリアルタイムの資産管理機能をパッチ適用ワークフローに直接統合し、チームに古いスナップショットではなく最新の状況を把握できるようにするとともに、従来のアプローチの足を引っ張っていた手作業による照合作業を排除する必要があります。

完全な資産一覧と依存関係マップが整ったところで、次に浮かぶ疑問は、「どのサーバーにまずパッチを適用すべきか」ということです。

EPSS、CISA KEV、および資産の重要度を用いて、サーバーのパッチ適用優先順位を決定する方法

すべての脆弱性が同じリスクを伴うわけではありません。 ネットワークに接続されていないテストサーバーにおける共通脆弱性評価システム（CVSS）スコア 9.8 は、顧客の取引を処理する本番サーバーにおけるCVSSスコア7.5 よりも緊急性が低いと言えます。 効果的な優先順位付けには、脆弱性の深刻度とビジネス上の状況を組み合わせることが重要です。 これは、 の成熟した脆弱性管理プログラム の基盤となるものであり、単に問題をスキャンするだけでなく、悪用されるリスクを積極的に低減するものです。

CVSSのスコアそのものだけでなく、優先順位付けをより的確に行う上で役立つ3つの指標があります：

1. エクスプロイト予測スコアリングシステム（EPSS）： EPSSは、脆弱性が今後 30 日以内に実環境で悪用される確率を推定します。 CVSSスコアは高いもののEPSSスコアが低い脆弱性は、CVSSスコアが中程度でEPSSスコアが高い脆弱性よりも、緊急性が低い可能性があります。
2. CISAのKEVカタログ： CISAのKEVリストに脆弱性が掲載された場合、攻撃者はすでにその脆弱性を悪用しています。 このリストに掲載されている脆弱性は、他のスコアにかかわらず、優先順位が最上位となります。 これは、Windows Server や一般的な Linux ディストリビューションなど、広く導入されているサーバープラットフォームにおいて特に当てはまります。これらのプラットフォームは、企業環境やインターネットに公開されている環境で広く利用されているため、KEV のリストに頻繁に登場しています。
3. 資産の重要度： サーバーが事業運営において果たす役割によって、パッチ適用をどの程度急ぐべきかが決まります。 収益を生み出すアプリケーション、規制対象のデータ、または顧客向けサービスを支えるサーバーについては、通常、より迅速な是正措置が求められます。 また、ランサムウェアの運営者にとっても、彼らは最も魅力的な標的となっています。運営者は、影響力を最大限に高めるために、意図的に高価値なシステムを探し出しているのです。

KEVに掲載されている脆弱性については、通常のパッチ適用サイクルを中断する必要がある場合がよくあります。 成熟したパッチ適用プログラムでは、KEVに掲載されている脆弱性や影響度の高い脆弱性に対して、たとえ通常のメンテナンスサイクルが乱される場合でも、アウト・オブ・バンド対応をサポートしています。

信号を組み合わせることで、優先順位マトリックスが作成されます。 EPSS値が高く、CISA KEVに掲載されており、かつTier 1の本番サーバーに存在する脆弱性については、直ちに注目が集まります。 EPSSが低く、KEVへの登録がなく、開発サーバーに存在する脆弱性については、次回の定期メンテナンス期間まで対応を待っても差し支えありません。 目的は、すべてを一度に修正することではありません。 これは、悪用される可能性が最も高い脆弱性から順に対処することで、攻撃対象領域を体系的に縮小することを目的としています。

リスクに基づく優先順位付けを行うことで、チームはリスクを最も低減できる分野に注力できるようになります。 優先順位が決まったら、次の課題は、業務に支障をきたすことなくパッチを適用することです。

Tanium Comply による、よりスマートな脆弱性の優先順位付けの実現

脆弱性のバックログは、ただ一生懸命働くだけでは減りません。賢く働くことで初めて減るのです。 今回の「Tanium Tech Talks」では、Tanium Complyが、CVSSスコアを基盤として、 のエクスプロイトインテリジェンス（）、エンドポイントの重要度、および検出された製品データをどのように重ね合わせていくかを解説します。これにより、チームは、何を優先して修正すべきかを、より的確かつ説得力のある方法で判断できるようになります。

もし、サーバーのパッチ適用ワークフローが今でもスプレッドシートと直感に頼って始まっているのであれば、こちらの動画をご覧になる価値があります。

リングベースのロールアウトによるサーバーパッチの展開体制の構築

すべてのサーバーにパッチを同時に適用することは、広範囲にわたるサービス停止を招く原因となります。 リング方式による展開では、パッチを段階的に規模の大きいグループへと適用していくことで、本番環境の重要なシステムに影響が及ぶ前に、問題を早期に発見することができます。

典型的なリング構造は、次のようなものです：

リング 0：カナリア

重要度の低いサーバーの小さなグループに、まずパッチが適用されます。 カナリーサーバーは本番環境の設定を反映していますが、本番環境のワークロードは処理しません。 パッチによって問題が発生した場合でも、その影響は限定されます。

リング1：パイロット

カナリアサーバーが所定の期間安定して稼働した後、パッチはパイロットグループに移行されます。 パイロットグループには、より幅広い種類のサーバーが含まれており、一部の低スペックの本番システムが含まれる場合もあります。 この段階では、モニタリングが強化されます。

リング 2：広範囲での展開

カナリアフェーズとパイロットフェーズが完了したため、パッチがサーバーの大部分に展開されます。 このフェーズは、多くの場合、予定されたメンテナンス期間中に実行され、デプロイの前後に自動的な健全性チェックが含まれます。 初期のリングから得られたデータを活用することで、チームは展開が最大規模に達する前に、タイミング、バッチサイズ、および順序を最適化することができます。

リング 3：生産に不可欠

通常、最も脆弱性の高いサーバーには、エクスプロイトの深刻度や影響範囲の広さにより早急な対策が必要となる場合を除き、先行するリングでの検証が成功した後にパッチが適用されます。 この時点で、このパッチは他の数百台、あるいは数千台のサーバーにおいて安定していることが実証されています。

自動フィードバックゲートが、リング間の進行を制御します。 あるリングでエラー率が急上昇したり、ヘルスチェックに失敗したりした場合は、次の段階に進む前にデプロイが一時停止します。 これにより、問題のあるパッチが艦隊全体に波及することを防ぐことができます。

リングベースの展開は、変更管理プロセスと統合された場合に最も効果を発揮します。 その連携こそが、パズルの次のピースなのです。

IT運用、セキュリティ、および変更管理の各部門にわたるサーバーのパッチ適用を調整する

サーバーへのパッチ適用は、たいてい1つのチームの管轄範囲にとどまることはありません。 複雑なIT環境において、セキュリティ部門は脆弱性を特定し、是正措置のスケジュールを策定します。一方、IT運用部門はサーバーを管理し、デプロイメントを実行します。そして、変更管理部門が、変更の実施時期や方法を規定します。 これらの機能間で明確な連携が取れていないと、パッチは承認待ちの列で滞留したり、適切な監督なしに展開されたりしてしまいます。

役割が明確であることは役立ちます。 一般的なモデルでは、責任は次のように割り当てられます：

• セキュリティ： は、脆弱性を特定し、優先順位付けの基準を設定し、是正措置に関するSLAを定義します。
• IT運用： サーバーのインベントリ管理、パッチの適用、適用後の状態監視を行います
• 変更管理： 変更を承認し、メンテナンスの時間帯をスケジュールし、例外事項を記録します

変更諮問委員会（CAB）の承認は、特に本番システムにおいて、サーバーのパッチ適用を左右することがよくあります。 ServiceNowなどのITサービス管理（ITSM）プラットフォームとパッチ適用ワークフローを統合することで、このプロセスを効率化できます。 パッチのリクエストは標準の変更チケットを通じて処理され、承認はサーバーの階層に基づいて自動的に行われ、デプロイ状況はチケットにリアルタイムで反映されます。

社内であれ、マネージドプロバイダーを通じてであれ、パッチ適用がITサービスとして提供されている組織においては、こうしたワークフローの統合こそが、大規模かつ一貫性があり、監査可能な実行を可能にするものです。 特にマネージド・サービス・プロバイダー（MSP）は、この統合の恩恵を大きく受けています。これにより、クライアント環境ごとに独自のワークフローを構築することなく、複数のクライアント環境全体で一貫したパッチ適用基準を徹底することができるからです。

多くのMSPは、リモート監視・管理（RMM）プラットフォームを通じてパッチ適用を行っています。これらのプラットフォームは、クライアント環境全体を一元的に可視化し、制御することを可能にしますが、複雑なサーバー間の依存関係やリングベースの展開ロジックへの対応能力には、プラットフォームによって差があります。

例外処理にも連携が必要です。 業務上の制約、ベンダーへの依存、あるいは技術的な制約により、一部のサーバーでは予定通りにパッチを適用できない場合があります。 例外事項を、是正措置とともに記録しておくことで、監査証跡を明確な状態に保ち、セキュリティチームが残存リスクを確実に把握できるようになります。

のパッチが適用されていないサーバー（ ）はリスクが高いため、セキュリティ情報イベント管理（SIEM）プラットフォームにアラートを統合することで、是正措置が可能になるまで、攻撃の試みを検知するために必要な継続的な監視を実現できます。

パッチの適用と変更記録の更新が完了しましたので、最後のステップとして、すべてが正常に動作していることを確認します。

サーバー群全体でのパッチ適用が正常に行われたかを確認する

パッチを展開することと、パッチのインストールが正常に完了することは別物です。 パッチの適用が失敗する原因は多岐にわたります。ディスク容量の不足、ソフトウェア間の競合、ネットワークの中断、あるいは再起動が完了しなかったことなどが挙げられます。

検証がなければ、チームは事実ではなく仮定に基づいて行動することになります。 その違いこそが、成熟したパッチ適用プロセスと、誤った安心感を生み出すプロセスとを分けるものです。

全車両を対象としたリアルタイムの照会こそが、クローズドループ検証を大規模に実用化できる要因となっています。 サンプルを抜き取り検査して残りを推測する代わりに、チームはパッチの適用状況を、展開から数分以内に管理対象のすべてのサーバーで確認でき、インストールに失敗したケースは自動的に特定され、是正措置が講じられます。

導入後の検証では、次の3つの疑問に答えます：

• パッチはインストールされましたか？ OSまたはパッケージマネージャーに更新が記録され、期待されるパッケージ、KB、ビルド、またはバージョンの状態が反映されていることを確認してください。
• パッチは適用されましたか？ 必要な再起動やサービスの再起動が完了していることを確認し、実行中のカーネルおよびサービスのバージョンが修正後の状態になっていることを確認してください。
• そのパッチによって問題が発生しましたか？ ヘルスチェックおよびサービスレベル指標（ログ、エラー率、レイテンシ）を検証し、問題が発生した場合はロールバック／フェイルオーバーの経路を確認してください。

自動化された検証により、このプロセスを大規模な車両群全体に展開することが可能になります。 サーバーのサンプルを抜き打ちでチェックするのではなく、チームはすべてのサーバーに対してリアルタイムでクエリを実行し、パッチの適用状況を確認することができます。 インストールに失敗したサーバーには、是正措置の対象としてフラグが付けられます。 インストールが正常に完了したサーバーは、構成管理データベース（CMDB）内のレコードを更新します。

検証によって、一連のプロセスが完結します。 これにより、パッチ適用は単なる導入作業から、測定可能な成果をもたらすリスク低減活動へと変化します。

サーバーのパッチ適用状況に関する監査対応態勢の維持

PCI DSS、HIPAA、DORA（EUデジタルオペレーショナルレジリエンス法）などのコンプライアンス枠組みでは、組織に対し、パッチおよび脆弱性管理の実践内容を文書化し、その実施状況を証明することが求められています。

監査担当者は、単にパッチが適用されたかどうかを知りたいだけではありません。 彼らは証拠を求めています。具体的には、導入ログ、カバレッジレポート、例外に関する文書、および是正措置のスケジュールです。 で文書化されたパッチ管理ポリシー（）は、役割、スケジュール、例外処理手順、およびエスカレーション手順を定義したものであり、監査人が最初に要求する資料となることが多く、また、コンプライアンス審査において、このポリシーが存在しないことがよく指摘される問題点の一つです。

監査への備えは、一貫した記録管理から始まります。 パッチの展開が行われるたびに、以下の質問に答える記録が生成されます：

• どのサーバーが標的となったのでしょうか？
• どのパッチが適用されましたか？
• 配備はいつ行われたのでしょうか？
• 成功率はどのくらいでしたか？
• どのサーバーに障害が発生し、どのような復旧措置が講じられたのでしょうか？
• どのサーバーが除外され、どのような補完的な統制措置が講じられているのでしょうか？

パッチ適用ツールをCMDBやITSMプラットフォームと統合することで、こうした証拠を一元管理できるようになります。 監査人がPCI対象サーバーのパッチ適用状況について尋ねた場合、その回答は手作業によるスプレッドシートでの照合ではなく、クエリによって得られます。

例外に関するドキュメントには、特に注意を払う必要があります。 監査担当者は、すべてのサーバーにすぐにパッチを適用できるわけではないことを理解しています。 彼らが求めているのは、例外事項が追跡され、リスク評価が行われ、かつ是正措置が講じられているという証拠です。

ベンダー側の制約によりパッチを適用できないサーバーについては、ネットワークのセグメンテーションや監視機能の強化といった代替的な統制措置が講じられている場合があります。

Taniumによるサーバーのパッチ管理のサポートについて

Taniumの自律型ITプラットフォーム「 」は、サーバーのパッチ管理を、継続的かつデータ駆動型のプロセスとして捉えています。 データベースのスナップショットや定期的なスキャンサイクルに依存するのではなく、エンドポイントに直接クエリを送信するため、判断は前回のスキャン時点の状況ではなく、現在の状況に基づいて行われます。

IT運用およびセキュリティチームは、単一のコンソールから、Windows、Linux、 、macOS、 にまたがり、どのサーバーにパッチが適用されていないか、どのサーバーがパッチ適用準備が整っているか、どのサーバーの適用を延期する必要があるかといった最新状況を把握できます。

• エンドポイントのリアルタイム可視化： Windows、Linux、macOS における最新のパッチ適用状況をオンデマンドで確認できます（定期的なスキャン結果ではありません）
• リスクに基づく優先順位付け： の脆弱性データを、EPSS、CISA KEV、資産の重要度、および信頼度スコアと組み合わせて、リスクを最も低減できる分野にリソースを集中させます。
• 信頼度スコア（Windows）： Windowsパッチの展開による影響に関する予測分析。これは、広範囲な展開に先立ち、インストール成功率、クラッシュ頻度、およびパフォーマンス指標に基づき、参加顧客からの匿名化された展開テレメトリデータから算出されたスコアに基づいています。そのため、この指標は仮定ではなく、実際のパッチの挙動を反映しています。
• リングベースの段階的導入: スケールアップする前に、信頼性閾値に基づいて結果を検証する段階的な展開であり、重要なサーバーへのパッチ適用は最後に実施されるため、本番環境やビジネスに不可欠なシステムは、影響を受ける前に、先行するリングでの検証結果の恩恵を受けることができます
• ガバナンス対応の自動化プレイブック「」： オペレーターによる承認ゲートと完全な監査証跡を備えた、条件に基づいた多段階ワークフロー
• へのサードパーティ製ソフトウェアのパッチ適用： ベンダーのサイトから手動でパッケージを入手することなく、アプリケーションのパッチ適用やサードパーティ製ソフトウェアの更新を行うための組み込みテンプレート
• Tanium Guardianの脅威インテリジェンス： Tanium VERTを基盤として、多くの重大な脆弱性やゼロデイ脆弱性に対して、タイムリーなアラートと的を絞った是正措置のガイダンスを提供します。新たな脅威を検知し、ツールを切り替えることなく、コンソールに直接具体的な是正措置を提示します。
• クローズドループ検証： 管理対象のエンドポイント全体におけるパッチの状態をデプロイ後に確認し、インストールに失敗したケースを迅速に特定します。
• コンプライアンス評価「」： PCI、HIPAA、SOX、およびその他のフレームワークに関連する技術的統制に準拠した、SCAPおよびOVALに基づく評価で、コンテンツは毎日更新されます。
• 監査準備のためのレポート： 例外の追跡機能やコンプライアンス・ダッシュボードを備えた、組織およびデバイスレベルのレポート
• ITSMとの連携： は、ServiceNowやその他のITSMツールと連携したパッチ適用ワークフローを提供し、チケットのステータスを自動的に更新します。
• AIを活用した運用： エンドポイントデータ、調査、およびソフトウェア管理のための自然言語クエリ 。また、「ヒューマン・イン・ザ・ループ」方式による承認機能により、自動化されたアクションを適切に管理し、監査可能な状態に保ちます。

ここで説明されている機能および成果は、Taniumの製品ドキュメント、検証済みの顧客事例、および実際の利用状況に基づいています。 実際の結果は、導入環境、設定、および組織の成熟度によって異なる場合があります。

実運用における成果：サーバーのパッチ適用状況に関する「唯一の信頼できる情報源」

Taniumを導入する前、 ハネウェル社には、チーム間で一貫してコンプライアンスを測定するための信頼できる方法が ありませんでした。セキュリティ部門とIT運用部門はそれぞれ異なる指標を追跡しており、数値をめぐる意見の相違が日常茶飯事でした。

Taniumは両チームに同じデータを可視化したため、セキュリティ部門からのものであれIT運用部門からのものであれ、コンプライアンスに関する数値に一貫性が保たれました。 その一貫性のおかげで、ハネウェルのITチームは、経営幹部やサービス責任者の双方に対して、正確な数値を報告する自信を持つことができました。

[Read the case study]

「Taniumを導入する前は、当社のパッチ適用率は低かったのです。 現在、Taniumの導入により、パッチ適用率 90％を3ヶ月連続で達成しました。 それは重要な点ですね。”

ハネウェル社のITディレクター、マニッシュ・チョプラ氏

サーバーのパッチ管理に関するよくある質問

サーバーへのパッチ適用には、一般的なパッチ管理ガイドではしばしば触れられない調整上の課題が伴います。 以下は、サーバーのパッチ適用プログラムを構築または改善する際、企業チームからよく寄せられる質問です。

サーバーへのパッチ適用とエンドポイントへのパッチ適用は、どのように異なるのでしょうか？

サーバーでは通常、メンテナンスの時間が限られている中で 24/7 のワークロードが実行されていますが、エンドポイントについては、ユーザーの利用が中断している間に再起動を行うことができます。 また、サーバー間にはより複雑な依存関係があるため、あるサーバーに適用されたパッチが、他のサーバー上で実行されているアプリケーションに影響を及ぼす可能性があります。

サーバーのパッチ適用に失敗した場合の影響範囲は、通常、エンドポイントのパッチ適用に失敗した場合よりも広範囲に及ぶため、チームがテスト、ステージング、およびロールバック計画に取り組む方法も変わってきます。

サーバーは、パッチを適用せずにどのくらいの期間、安全に稼働し続けることができるのでしょうか？

これに対する普遍的な答えはありません。 CISAのKEVリストに掲載されている重大な脆弱性については、攻撃者によって積極的に悪用されているため、早急な対応が必要です。 その他の脆弱性については、対応のスケジュールは、サーバーの公開状況、補完的な対策、および業務上の制約といった要因によって異なります。

コンプライアンス要件は、フレームワーク やリスクの状況によって異なります。 PCI DSS に関しては、組織は通常、リスクに基づいてパッチ適用に関する SLA を運用化しています（多くの場合、高リスクの脆弱性についてはおよそ 30 日を目安とし、低リスクの問題についてはより長い期間を設定しています）。これに加え、文書化された例外事項や代替的統制措置も併せて実施されています。

期間を超過したチームは、セキュリティリスクと監査上の指摘事項の両方を抱えることになります。

サーバーに予定通りにパッチを適用できない場合、どうなるのでしょうか？

例外事項を記録し、残存リスクを評価した上で、代償的統制を実施してください。 対策としては、リスクへの露出を制限するためのネットワークのセグメンテーション、悪用試みを検知するための監視体制の強化、あるいは脆弱性の影響を軽減するためのアプリケーションレベルの対策などが挙げられます。 監査人は、この書類に加え、将来的な是正措置に関する計画も提示されることを期待しています。

常時稼働中のサーバーで、再起動が必要なパッチについて、各チームはどのように対応しているのでしょうか？

選択肢としては、ライブパッチ適用技術（特定のディストリビューションおよびサポート契約において、一部の Linuxカーネルアップデート で利用可能です）、再起動ウィンドウ中の冗長サーバーへのフェイルオーバー、あるいはトラフィックが少ない時間帯に再起動をスケジュールし、関係者に通知する方法などが挙げられます。

適切なアプローチは、サーバーの役割、組織のダウンタイムに対する許容度、および冗長性が確保されているかどうかに依存します。 セキュリティ更新プログラムの中には、有効化するために再起動やサービスの再起動のみを必要とするものもあり、その点を踏まえた計画を立てることは、サーバーのパッチ適用における重要な手順の一部です。

インストールはされているものの、適用されていないパッチがある場合、その脆弱性は依然として残ったままとなります。 実際には、特にクラスタ化されたシステムや業務に不可欠なサービスにおいては、パッチの適用そのものではなく、再起動の調整こそが真のボトルネックとなることがよくあります。

本番環境のサービスにおいては、パッチ適用計画には、ロールバックの基準や、必要に応じてスナップショット、あるいはクラスタ環境や高可用性（HA）環境におけるフェイルオーバーなどの復旧手順も盛り込む必要があります。

企業規模でのサーバーのパッチ適用には、単なるチェックリスト以上のものが必要です。 これには、リアルタイムでの可視化、リスクに基づく優先順位付け、段階的な導入、そしてパッチ適用によって実際にリスクが低減されたことの検証が必要となります。
Taniumは、これらの機能を単一のプラットフォームに統合しており、ITおよびセキュリティチームが、当て推量ではなく確信を持ってサーバーへのパッチ適用を行えるよう支援します。 今すぐ無料デモをご予約ください（ ）。Taniumの実際の動作をぜひご覧ください。