ソフトウェアの配布とパッチの適用は、組織のITチームに課せられた最も重要な業務の2つです。
こうしたタスクを処理するために設計されたツールは数多くあり、これらは総称して「 （）」と呼ばれるソフトウェア管理の範疇に属します。。
しかし、見過ごされがちなのは、IT部門がその業務にどのようなツールを採用するかにかかわらず、組織がソフトウェア環境を真に管理できるようになるには、まずプロセスやポリシーの課題に対処する必要があるということです。
また、多くの組織では、 2000s年代初頭以来、ソフトウェア管理への取り組みを変えていません。 このブログでは、こうしたプロセス上の考慮事項のうちいくつかを取り上げ、その重要性について解説します。
チェックリスト：知っておくべき最新のソフトウェア管理手法
ソフトウェアの展開とパッチ適用を一元的に行うことが最も効果的です
私の経験から言えば、ソフトウェアの管理に分散型モデルを採用している企業は、集中型モデルを採用している企業に比べて、セキュリティ対策の徹底度がはるかに低いと言えます。
ここで「一元化」とは、組織内ではサポートスタッフは分散している場合でも、どのソフトウェアやソフトウェアの更新プログラムをいつインストールするかを決定する一元的な権限が1つあることを指します。 各地に分散しているサポートチームは、皆、その方針に従って行動しています。
一元化により、テストやパッチ適用のスピードが向上します
ソフトウェア管理において最も重要な要素の一つは、テストとパッチ適用のスピードです。 集中型モデルへの移行にあたっては、段階的またはフェーズごとの導入を行うことが望ましいでしょう。 本番環境へ移行する前に、いくつかのテスト段階を設けるべきです。 「数人」とは2、3人のことであって、 20人ではありません！
要するに、エンドポイントデバイスが長期間にわたって脆弱な状態になるのは避けたいものですから、それらの更新プログラムをできるだけ早く適用したいのです。 一般的に、現実的な目標は 7-15 日間ですが、アップデートの重要度によっては、それより短くなる場合もあります。
これが、ソフトウェア管理におけるポリシー面です。 最も重要なパッチについて、サービスレベル契約（SLA）を定義してください。 その数値をできるだけ低くしてください。 過去 20 年間に成し遂げてきたことを基に、数字を決めてはいけません。 目標については、積極的に取り組んでください。
30 日間というのは長いですね
ある企業を訪れた際、そのパッチ適用サイクルが 30 日を超えている場合、まず最初に行うべきことは、30 日以内にこれらの更新プログラムをリリースし、すべてのデバイスにインストールすることです。 それ以上悪くなることはないはずです。
こうしたアップデートが公開されると、悪意のある者たちもそれを目にするということを、ご理解いただく必要があります。 システムに侵入しようとする連中は、ドキュメントを読み、何がパッチ適用されているのか、その理由も把握できてしまいます。 時間は刻一刻と過ぎていきます。エクスプロイトが開発され、悪用される前に、ソフトウェアを更新する必要があります。 だからこそ、 30 日間というのは長い期間だと言うのです。
さて、本番環境にパッチをすぐに適用したいとは限らないかもしれません。 おそらく、アプリケーション内部の依存関係に関して課題を抱えているのではないでしょうか。 たとえば、.Netのパッチが、御社で独自に開発したアプリケーションの1つと正常に動作しない可能性があります。 こうしたことは必ず起こるものです。
通常、そうした競合を確認できる期間は、およそ1週間程度あります。 そして最終的には、その 30 日間を、できるだけ1週間に近づけることが目標です。 それが目標であるべきでしょう。
一体、どれほど深刻なのでしょうか？ 「キャッチアップ・パッチング」の世界
長年にわたり、私が目から鱗が落ちるような思いをしたのは、多くの企業が、自社の業績は好調だ、あるいは少なくとも悪くはないと考えているという点です。 彼らは自分たちの成績を「B+」と評価しています。
しかし、実際に評価を行ってみると、 2007年までさかのぼる数千もの重要なパッチが見つかりました。 明らかに、何かがうまくいっていないようです。 通常は、ツールとプロセスの組み合わせとなります。 この2つとも対処する必要があります。
多くの企業にとって、現在採用している「 」のパッチ適用手法（ ）は、2007 や2010の頃と変わっていません。 しかし、彼らが活動している環境は変わってしまいました。 彼らがそのことを知っていたかどうかに関わらず、10年分以上のパッチが未適用となっています。
オペレーティングシステムの重要かつ不可欠なセキュリティ更新プログラムから適用を始めることは、決して珍しいことではありません。 これらの更新プログラムにはすべて深刻度が割り当てられていますので、それらを参考に、お使いのオペレーティングシステムの脆弱性の程度を把握することができます。
また、 のサードパーティ製アプリケーションの更新プログラム（）には、Adobe Acrobat（Adobe Flashのサポート終了（ ）に関する当社のブログ をご参照ください）、ChromeやFirefoxなどのウェブブラウザ、 Office365などの生産性向上アプリなどに関連する深刻度も設定されています。
「パッチの遡及適用」を行う際は、最も重要かつ緊急性の高い更新プログラムから着手してください。 分散環境においては、これがコストパフォーマンスの面で最も優れていますが、それだけに留まらないでください。
ソフトウェア管理上の課題を技術的に評価するのは簡単ですが、それらを解決するのはそう簡単ではありません
ソフトウェアの配布やパッチ適用に関する手法に不備があることは、すぐに明らかになります。 しかし、そうした格差を解消するための政策や手続きについて合意を形成するには、時間がかかり、議論が紛糾することもあります。
人々は、ある特定のやり方で物事を進めることでキャリアを築いてきたため、多くの場合、そのやり方を変えたくないのです。 多くの場合、自社の方針を真剣に評価し、振り返り始めるまでは、その方針が存在する唯一の理由が「昔からそうしてきたから」であることに、気づいてさえいないのです。 アップデート後のシステムの再起動に関しては、最も強い反発に直面する可能性が高い分野の一つです。
それは、システムの再起動がエンドユーザーに影響を与えるからです。 組織が、適切な通知を行いながらエンドポイントを再起動する方法について決定を下すには、文字通り数ヶ月を要する場合があります。具体的には、従業員が昼食のために席を離れた時や、プレゼンテーションの最中、あるいは重要な文書を扱っている最中に、誤って再起動してしまうことを防ぐためです。
ここで、再起動ポリシーを徹底するためには、強力な経営陣のリーダーシップが不可欠となります。というのも、特にWindows環境においては、システムやアプリケーションが再起動するまで、パッチは完全にインストールされず、脆弱性のあるコードも置き換えられないからです。
組織によっては、再起動をエンドユーザーに任せており、再起動が必要であるという通知は行われません。 より厳しいポリシーが実施されれば、エンドユーザーはそれに順応するでしょう。
ユーザーは、通知を受け取った最初の1回か2回目――おそらく昼食前――に再起動を行うよう学ぶでしょう。そうすれば、再起動が不都合なタイミングで強制されるまで「延期」をクリックし続けるようなことはなくなるはずです。
お客様とソフトウェアの配布について協業する際、私たちがまず確認することの一つは、前回の再起動のタイミングです。 そして、組織内のシステムの 75 パーセントが再起動待ちの状態にあることがよくあります。 ところで、適用されたあのパッチについてですが？ そんなことはありません。
ソフトウェアのパッチ適用に関するあらゆる議論において、リスクは常に付きものです
組織がパッチを迅速に適用しない主な理由は、何かが正常に動作しなくなることを恐れているからです。 ソフトウェアの更新について、副社長や経営幹部の方々と話をすると、どの会話にもリスクという話題が必ず出てきます。 「システムが 45 日間脆弱なままになるリスクと、30 日目に何かをデプロイしてアプリケーションを壊してしまうリスクとでは、どちらがより大きいでしょうか？」 それは未知のものに対する恐怖です。 それは、業務の混乱への懸念です。
テスト計画と評価指標があれば、その不安を軽減することができます。 たとえそのテスト計画が、単に「このアップデートを多数のシステムに展開して、何か不具合が発生するかどうかを確認しよう」というものであったとしても。 しかし、何かが壊れたかどうかは、お分かりいただけるはずです。 そのデータは手元にあるはずですので、誰かがトラブルチケットを発行してくれるのを待つ必要はありません。
アプリケーションの所有者が、パッチが安全であることを示す確かなデータを持っているのであれば、パッチ適用サイクルを 30 日から15 日に短縮するとお伝えした際、より積極的に賛同してくれるでしょう。
Taniumが のサードパーティ製ソフトウェア管理をいかに簡素化しているかについては、 をご覧ください。また、ぜひ以下の記事もご参照ください。 「Taniumがエンドポイントソフトウェア環境の管理を可能にする9 の方法」。
実際に動作をご覧になりたい方は、 から、今すぐデモにご登録ください： 。
