「迅速なパッチ適用」を妨げる事業部門：パッチ適用を巡る諸問題【前編】
各種ソフトウェアのパッチを適用することはセキュリティリスクを低減させるが、システムが稼働しなくなるというリスクを内包している。技術的な課題を解決したIT部門は、さらに事業部門との問題も解決しなければならない。
毎月第2火曜日は「Patch Tuesday（パッチ火曜日）」として、Microsoftなどの多くの企業がパッチをリリースする。ただしパッチをテストせずに運用環境にインストールすると、特に特注のソフトウェアを使っている場合は互換性の問題が生じる恐れがある。運用システムへのパッチの適用は難しい。パッチの適用は技術的な事柄だが、業務上の考慮事項でもある。
パッチを正しく適用するプロセスは迅速にはいかない。セキュリティと安定性を確保するため、パッチの提供元を確認し、パッチのリリースノートを読んで、パッチの重要性を判断し、リスクを評価してからパッチを徹底的にテストする必要がある。それからシステムのスナップショットを取って、パッチをアップロードする。
エンドユーザー企業でリードセキュリティアーキテクトを務めるデイブ・リア氏は次のように話す。「アップデートする前に、それが機能することを確実に保証する必要がある。そのためには、特定のデプロイメントでの厳格なテストと疑いの余地のないストレステストを実施しなくてはならない。そうすれば『パッチをうまくデプロイできた』と言えるだろう」
定期アップデートに加え、重大な脆弱（ぜいじゃく）性に対する緊急パッチもある。緊急パッチは確認、テスト、アップロードを短時間で行う必要がある。
パッチの適用には時間、費用、リソースを要する。これを考慮しないと予想外の損失につながる恐れがある。パッチの適用やアップグレードにかかる時間とコストを考慮しなかったため、レガシーシステムを使い続けることになった組織もある。こうした組織は、5年後のリプレースに備えて確保した予算をパッチ適用に使ってしまう場合が多い。
「特に公共部門の組織は『Windows XP』からアップグレードできないでいる。システムのライフサイクル管理の長期予算を考慮していなかったためだ」と語るのは、Advent IMでディレクターを務めるマイク・ギレスピー氏だ。
関連記事
- もう管理しきれない……企業にまん延する「パッチ疲れ」が深刻化
- 管理できないと言わせない、パッチ管理の5つのTips
- IT管理者によるWindows Updateの制御方法
- 実用レベルに達したSUSEのライブパッチ機能、あるとないでは大違いの理由
- Linux vs. UNIX──ホットパッチ機能はLinuxがリード
事業部門との葛藤
顧客と接するシステムにパッチを適用することは、パッチを必須と考えるIT部門とシステムを常時稼働状態にしておきたい事業部門の主導権争いになる。システムアップデートスケジュールの設定は、慎重な内部交渉が求められるケースになる。ここで必要になるのがリスク評価だ。リスク評価によって、アップデートを遅らせることで生じる恐れのある危険性を伝える。
「これまで関与してきたIT部門に限って言えば、システムにパッチを適用したいセキュリティ担当者と、24時間年中無休でシステムを稼働させておきたい事業部門との間に緊張関係があった。ほとんどの場合、年中無休で完全に機能できるシステムはない。事業部門はダウンタイムがあることを認識し、それを考慮して適切な対応をしなければならない」（ギレスピー氏）
システムが重要なインフラの一部として常時稼働する必要がある場合、複数のシステムを並列に運用するという方法がある。これは冗長性の確保としても機能する。
特にコアシステムの場合、事業継続性を維持するにはパッチのテストが不可欠だ。通常はサンドボックス内にあるシステムのレプリカでテストを実施する。これにより開発チームはパッチの適用プロセスの予行演習を行い、安定性を確保するためにシステムを徹底的にテストできる。
「運用システムとテストシステムが全く同じになることはない。テストシステムは閉鎖されており、外部には接続されない。こうした重要な違いは常にある。テストシステムにダミーシステムを配置して、インターネット接続をサポートしてサーバと対話させることは可能だ」（リア氏）
当然、これには多大な時間とリソースの負担を伴う可能性がある。このようなテストを実行する費用に応じたリソースを確保する必要があるだけでなく、適切な経験を有するスタッフもいなければならない。これを怠ると、パッチによってシステム障害が起きるなど、重大なリスクにさらされる恐れがある。
後編では、自動化を巡る勘違いとテスト戦略について解説する。
Copyright © ITmedia, Inc. All Rights Reserved.