中途半端は危険

セキュリティパッチの検証と導入はスピードが命、具体的な進め方は

ゼロデイ攻撃の危険性はかつてないほど増している。だからといって、検証していないパッチを運用システムに適用することも危険だ。運用環境の外部でパッチを迅速に検証する手段がなければ、それは重大なリスクだ。

公開 2018年02月13日 05時04分

更新 2018年02月13日 15時49分

著者

Tim Warner

[TechTarget]

印刷する

　パッチ検証環境と運用環境が同じなら散々な目に遭遇するだろう。

　企業ITの情勢は急速に変化し、大量のデータが利用されているため、パッチを運用システムに適用する前に信頼性の高いパッチ検証方法を用いる必要がある。セキュリティパッチとは、既知の脆弱（ぜいじゃく）性の解決に使用するソフトウェアパッケージだ。IT運用管理者がソフトウェアを最新状態にアップデートしていなければ、システムのセキュリティが侵害されることは避けられない。これは起きるかどうかではなく、いつ起きるかという問題だ。

　パッチ管理は多面的な取り組みによって強化する必要がある。ITサービス管理（ITSM）内でパッチ管理のプロセスを確立し、ステージング領域やテスト領域に運用環境を忠実にミラー化し、素早く更新する必要がある。

併せて読みたいお薦め記事

脆弱性対策に取り組む

パッチ管理について

プロセスを整える

　パッチ管理は、ITSM内で変更管理の一環として行うことになる。企業は「ITIL（IT Infrastructure Library）」「COBIT（Control Objectives for Information and related Technologies）」など、多くのITSM標準を選択できる。また、複数の標準を組み合わせて利用することも可能だ。各フレームワークは、IT部門のハードウェア資産とソフトウェア資産の変更を管理する計画とドキュメントを提供する。

　パッチ検証では、セキュリティパッチが攻撃への潜在的な脆弱性を解決することを検証する。企業はパッチをインストール後に再現テストを実行して、パッチが基幹業務のサーバやサービスの機能を停止しないことを確かめる必要がある。検証していないパッチを適用することは、パッチを適用しない設計よりも危険性が高くなる可能性がある。

　実用的な変更管理やパッチ管理戦略を採用していない企業は、まず、主要ITSMフレームワークを調査して、自社のニーズに最も合うものを見つけることだ。信頼性の高いパッチ管理がない企業は、重要なデータをランサムウェアなど、マルウェアの感染の脅威にさらすことになる。ランサムウェアとは、通常匿名の暗号通貨で身代金を支払うまで、データにアクセスできなくするか機密情報を公開すると脅迫する攻撃を指す。

中途半端なセキュリティパッチの危険性

ランサムウェアWannaCryがユーザーのファイルを暗号化した後に表示されるメッセージのスクリーンショット《クリックで拡大》

　2017年に起きたランサムウェア「WannaCry」攻撃では、Microsoftの古いファイル共有プロトコル「サーバーメッセージブロック（SMB）バージョン1」の「EternalBlue」という脆弱性が悪用された。Microsoftはこの脆弱性を確認し、サポート対象のWindowsデスクトップとWindows Serverバージョンのパッチを同年3月にリリースした。その後、WannaCryがもたらした打撃が原因で、サポートを終了したバージョンのWindowsもパッチの適用範囲に追加されている。

　Microsoftがパッチをリリースしたにもかかわらず、非常に多くの基幹業務システムがWannaCryの攻撃を受けている。これは、こうした企業のIT部門がMicrosoftのパッチサイクルを意図的に遅らせていたか、極めて低い頻度でしかシステムにパッチを適用していなかったことに起因する。これは、10年前から続いていると見受けられる傾向だが、現在のITシステム管理では受け入れられない。

　管理者は積極的にシステムにパッチを適用しなければならない。迅速性が重要だ。商用ソフトウェアやオープンソースソフトウェアで意図せず発生する脆弱性を突いて攻撃を行仕掛けるゼロデイ攻撃や悪意のあるソフトウェアは待ってくれない。企業は、新しいコードを配信する際と同様に、パッチについても継続的インテグレーションと継続的デプロイメントの考え方を守る必要がある。

優れたパッチ検証環境

　パッチを検証するIT部門は、運用システムへの導入に先立ってテスト環境を利用することが多い。現実的なテスト環境をセットアップすることで、より迅速なパッチ導入が促進される。

　稼働中のサービスをできるだけ多く保護するには、運用環境をテスト環境にミラー化し、両方の環境を並列にアップデートする必要がある。そうすれば、テスト環境でパッチ検証が成功すれば、運用環境でも同じようにパッチが動作することが保証されることになる。だが、パッチ検証環境で、運用環境と全く同じハードウェアを運用する必要はない。

　大抵の企業には、運用ハードウェアを複製する金銭的余裕はない。そのため、重要性の高い物理サーバを仮想サーバに置き換え、そのコピーを仮想マシンとしてマウントする。運用サーバを既に仮想マシンとして運用している場合は、このミラー化をセットアップするのは簡単だ。

　パッチ検証を支援するソフトウェアツールを利用してもよい。例えば、Microsoftは「System Center Configuration Manager」と「Windows Server Update Services」を提供しており、管理者は検証結果に基づいてMicrosoftの更新プログラムを承認するか拒否できる。

支援を結集する

　パッチ検証や管理の専門家をフルタイムで雇用するよう上司に進言することも考えられる。こうした専門家は、セキュリティ侵害に関連する数々の悪いニュースに精通し、ランサムウェアの被害にあった企業の収益や信頼性がいかに低下したかを詳しく説明できる。こうした攻撃はシステムの脆弱性を利用して行われる。だが、そうした脆弱性はシステムベンダーによって既にパッチが適用されているものだ。

　専任のパッチ検証専門家を雇用できない企業は、セキュリティパッチの検証と導入の見直しについて指導するコンサルタントを検討するのもよいだろう。Project Management as a Service（PMaaS）プロバイダーに目を向けてもよい。PMaaSプロバイダーは既存のパッチ検証インフラを管理するか、顧客のサーバ環境に自社のツールとプロセスを実装する。

　Orb Data、Datapipe、Fordway SolutionsなどのPMaaSプロバイダーは、一元管理されたWebコンソールを顧客向けに構築し、このコンソールを通じて資産インベントリの調査、自動パッチ検証と導入のスケジューリング、通知の設定を行う。

印刷する