SUS の構築の実際

はじめに

本誌をお読みの方であれば、「Microsoft 社は、セキュリティ強化プログラムである STPP (Strategic Technology Protection Program) の一貫として、2002年6月24日に SUS (Microsoft Software Update Service) というプロダクトを無償でリリースしています。SUS は企業内 Windows Update サーバともいうべきもので、企業内の各クライアントに対するホットフィックスの配布とその管理を行ないます。」というような説明文(注 1)は、各所の Web サイトなどで嫌というほど読まされていると思いますので、いまさら繰り返すまでもないでしょう。
このように、一見聞こえのよいセリフの並んだ SUS ですが、本当に使えるプロダクトなのか大いに気になるところです。筆者も早速この SUS について検証などを行なってみましたので、以下その結果をふまえて SUS の実体について説明していきたいと思います。

Windows Update の概要

SUS の説明を始める前に、SUS のベースとなった Windows Update について簡単に説明しておきましょう。
ご存知のように、Windows Update (http://windowsupdate.microsoft.com/)は、セキュリティ関連のホットフィックス (HotFix) や、Microsoft 社が重要だと考える製品のアップデートなどを、比較的簡単にインストールすることを可能にする Web サイトです。

• 怪しい Active X Control をインストールされてしまう
• セキュリティ関連のホットフィックスが Windows Update で提供可能になるまでには、ホットフィックス自体が入手可能になってから若干のタイムラグがある
• すべてのホットフィックスが Windows Update からインストール可能というわけではない

しかし、図 2に示すように、Windows Update はどちらかというと個人ユーザをターゲットとしたサービスのため、企業内での利用を考えると以下に挙げるような問題点がありました。

問題1: マシンにインストールするホットフィックスなどの管理ができない

企業システムでは、管理上の手間を削減するために、各マシンの環境を同一にしている場合が多いと思いますが、Windows Update には、マシンにインストールするホットフィックスなどをシステム管理者が指定したものに限定する、あるいは指定したものについては強制的にインストールする、また各マシンにどのようなホットフィックスがインストールされているかをシステム管理者から簡単に参照できるようにするといった管理機能は全くありません。管理が行き届かないままに、各マシンで Windows Update からホットフィックスや Internet Explorer の最新版などをダウンロードしてインストールしてしまうと、最悪業務システムが動作しないなどの問題を引き起こしてしまうこともあります。

問題2: 通信量が増大する

Windows Update を利用してホットフィックスなどをインストールしようとすると、インターネット上の Windows Update サイトからファイルをダウンロードします。しかも、古いモジュールをインストールできないようにするという配慮のためか、キャッシュを無効にする設定が行なわれているため、途中にキャッシュサーバなどを配置していても、毎回インターネット上からファイルのダウンロードが行なわれてしまいます。ファイルには Internet Explorer など数十MBに達するものもありますので、マシンの台数が多いと、インターネット回線の通信量にも無視できない影響が発生してしまいます。

問題3: インターネット接続が大前提である

プロキシ (キャッシュ) サーバ経由でも構いませんが、とにかく HTTP プロトコルで Windows Update サイトに接続できる環境が必要ですので、完全にクローズドなシステムでは利用できません。

こうした理由のため、企業内では Windows Update を無効にする、もしくは利用を禁止せざるを得ないケースが多かったのではないかと思います。

SUS の概要

SUS は、Windows Update のこうした現状をふまえて、企業内での利用を前提としてデザインが行なわれています。

図 3のように、SUS を利用すると、各クライアントのマシンは、SUS サーバから修正プログラムをダウンロード、インストールすることが可能になります。SUS サーバ自身はインターネット上のW ndows Update サイトや、別の SUS サーバから修正プログラムをダウンロードします。インターネット上の Windows Update サイトと通信する必要がある SUS サーバは最低1台あればすみますので、インターネットとの通信量を最低限に押えることが可能となり、問題 2 や問題 3 が解決します。また、具体的な方法は後述しますが、SUS サーバ間の複製は、オフラインでのファイル受渡しで行なうことも可能ですので、物理的にインターネットと接続されていない完全にクローズドなネットワークでも、SUS の恩恵を受けることが可能です。
さらに、SUSサーバでは、Windows Update サイトからダウンロードした修正プログラムのうち、どれをクライアントからインストール可能にするかを個別に制御できますので、問題 1 で指摘した修正プログラムの管理の問題もある程度解消します。ただし、クライアント側にインストールされる「Windows の自動更新」も、指定した SUS サーバから修正プログラムをダウンロードすることや、Active Directory の GPO などを使って設定を一元的に制御することが可能となっている新しいものにバージョンアップすることが必要です。

・SUS と Windows Update や SMS

このように、SUS は、Windows Update の問題点の幾つかを解決することにより、企業内で Windows Update の機能を活用することが可能とするソリューションであるといえます。ただし、完全に Windows Update を置き換えることが可能なものではありません。以下に SUS ではできない Windows Update の機能を示します。

(1) サポートOS
SUS は Windows 2000/XP のみをサポートします。一方 Windows Update は Windows 98 以降の Windows 9x 系 OS と、Windows NT 4.0 で Internet Explorer 4.0 以上が動作する Windows NT 系 OS からアクセスできます。

(2) インストール可能な修正プログラム
SUS でインストールできるのは、

• Windows 重要な修正プログラム
• Windows 重要なセキュリティ修正プログラム
• Windows セキュリティ ロールアップ

また、従来からMicrosoft社が企業内でのファイル配布用途などに用いる製品として販売している SMS (Systems Management Server)と競合しないようにという意図があってか、前述した特定の修正プログラム以外の配布は行なえない仕様になっている他、スケジューリング機能や、配布状況の管理機能などが意図的に中途半端なものになっているという感じがします。

要点を表1に簡単にまとめましたので、参照してみてください。

SMS (またその他のファイル配布プロダクト) をすでに使って修正プログラムの配布を行なっているのであれば、あえて SUS を使う必要はないでしょう。 なお、管理性については特に説明していませんが、これについては以下具体的なインストールや設定方法について説明しますので、そちらを参照してください。機能が限定されていることもあって、設定や管理は非常にシンプルです。

SUS のインストール

それでは、以下具体的なインストール方法について説明していきましょう。といっても、SUS のインストールは非常に簡単ですので、迷うことはないと思います。

ただし、SUS サーバになれるのは、Internet Explorer 5.5 以上を搭載しており、IIS 5.0 がインストールされたWindows 2000 Server SP2 以降のみとなっています。しかも、FAQ のページ(注 3)に記載がありますが、ドメインコントローラは SUS サーバになることができませんので、SUS をインストールできるのは、メンバサーバかスタンドアロンサーバのいずれかに限定されます。また、インストール先のパーティション (やボリューム)は、NTFS でフォーマットされている必要があります。

ただしFAQのページにある

x86 または互換 P700 レベル プロセッサ、512 メガバイト (MB) の RAM、および 6 ギガバイト (GB) のディスク空き容量が必要です。

という最低限必要なハードウェアについての記述については、あまり気にする必要はないようです。実際筆者の手元では、

「Celeron 566/256MB/空き容量5GB(インストール時)」

・バイナリの取得とインストールの開始

まずは、SUS のバイナリをダウンロードしてください。MSI 形式のバイナリがSUSのホームページ(注 4)から取得できます。ファイルの容量が 47MB ありますので、回線が細い場合には注意してください。

ダウンロードが完了したら、インストールを行なう前に「インターネットインフォメーションサービス」から、動作中の IIS の Web サイト(注 5)をすべて停止しておくことをお勧めします。

・IIS Lockdownの実行

インストールの過程で図 6のように IIS Lockdown が実行されます。これは強制的に実行され、回避することはできません。IIS Lockdown が実行されると、表 2のように ASP 以外の動的コンテンツが禁止され、サンプルや管理サイトなどが削除されますので、ある意味セキュアにはなります。しかし IIS を他の用途にも使っている場合や試験用サーバなどの場合は、勝手に設定を変更されてしまい迷惑でもあります。Microsoft が推奨するように、専用サーバにしてしまえばよいのでしょうが、小規模なサイトではそうもいかないのが現実だと思いますので、この仕様は筆者としてはちょっと乱暴過ぎるように思います。セキュリティ強化を促す意味で、IIS Lockdown が自動起動されるところまではよいと思うのですが。

・IISサイトの生成

最終的にインストールが完了すると、図 7のように SUS という Web サイトが作成されます(注 7)。SUS 関連のファイルやフォルダについては図 8のように ACL が設定され、基本的には Administrators ローカルグループのアカウント以外が利用できないように設定されています。逆にいえば、Administrators グループのアカウントであれば、別マシンから管理することも可能です。

content という仮想ディレクトリや、SUSAdmin というディレクトリなどが確認できます。

Administrators と SYSTEM はフルコントロールですが、それ以外の 2 つのアカウントには書き込み拒否という特殊なアクセス権のみが設定されていますので、基本的にはまったくアクセス権はありません。また、Everyone など、ACL のないアカウントについても、当然アクセス権はありません。

SUS クライアントのインストール

SUS を利用するには、クライアント側にも SUS に対応した「Windows 自動更新」をインストールする必要があります(注 8)。ドキュメントなどには明記されていませんが、これは Windows Update などからインストール可能な「Windows 自動更新 2002年6月」と同じものですので、既にこれをインストールしている場合は、改めてインストールする必要はありません。新規にインストールする場合は、Windows Update から行なっても構いませんし、SUS のホームページ(注 9)の下の方にあるリンクから行なっても構いません。インストール時には特にオプションなどはありません。

このファイルは MSI 形式のファイルになっていますので、Active Directory の GPO を利用するなどして一括して自動的にインストールすることも可能です。

SUS の初期設定

インストールが完了すると、「http://localhost/SUSAdmin/」にアクセスすることで、図 9のような SUS の管理画面が表示されます。SUS の設定や管理や、すべてここから行ないます。

実環境で設定を行なう上では、予め運用のポリシーを決めておく必要がありますが、まずは機能説明を兼ねて、一通り各メニューを紹介しておきます。 最初に行なうことは、「オプションの設定」から SUS サーバの設定を確認することです。「オプションの設定」メニューを表示すると、右側のペインに現れる設定項目を図 に示します。みての通り、設定項目はたったこれだけです。

以下個々の項目について説明します。

(1) プロキシ サーバーの構成を選択します
　Windows Update サイトへの接続にプロキシサーバを経由する必要がある場合は、ここで設定を行ないます。

(2) この更新サーバーを見つけるためにクライアントが使用する名前を指定してください
　文字通り、クライアントマシンが SUS サーバにアクセスする際に使う名前を指定します。

(3) コンテンツを同期するサーバーを選択します
　修正プログラムのダウンロード元を指定します。
SUS サーバを選択した場合に、「許可された項目の一覧を同期する(置換モード)」のチェックボックスをチェックすると、クライアントにどの修正プログラムを配布するかという「許可された項目」情報も、ダウンロード元の SUS サーバから取得するようになります。この場合、このサーバ上では情報を変更できません。

(4) 以前に許可された更新の新しいバージョンを処理する方法を選択してください
　一度「許可された項目」に追加した修正プログラムが更新された時に、自動的に「許可された項目」に追加するかどうかを決定します。デフォルトでは追加しません。

(5) 更新を保管する場所を選択します
　修正プログラムをローカルに保管するかどうか、また保管する場合にどの言語のものを保管するかを設定します。 　ここで「Microsoft Windows Updates サーバーで更新を維持する」を選択した場合は、クライアントマシンは SUS サーバからではなく、Windows Updateサイトから修正プログラムをダウンロードしますが、クライアントマシンは「許可された項目」の情報を SUS サーバから取得します。
　この設定は、クライアントマシンに適用する修正プログラムは管理したいが、修正プログラム自体は SUS サーバから配布したくないという状況で使いますが、通常この設定にする必要はないと思いますので、本記事でもこれ以上は触れません。保管する言語については、インストール時に行なった設定が反映されている筈です。

このうち、設定を変更する必要があるのは、(1)と(2)だけでしょう。(4)、(5)の設定は、インストール後で変更することはあまりないと思います。(3)については後で説明しますが、1台目の SUS サーバの場合は設定を変更する必要はありません。

設定が一通りすんだら、図 11の「サーバの同期」メニューから「今すぐ同期」を選択してください。しばらく時間がかかりますが、Windows Update サイトから修正プログラムが一式ダウンロードされます。定常運用にはいったら「同期スケジュール」から設定を行なって、夜間などにダウンロードを行なうようにするとよいでしょう。

ダウンロードが完了したら、図 12のような「更新の許可」メニューを開いてください。このように SUS サーバにダウンロードされたクライアントに配布可能な修正プログラムが一覧になって表示されていますので、実際に配布を行ないたいものにチェックボックスをつけ、「許可」ボタンを押してください。配布可能となったものは、通常は図 13のように、各修正プログラムの右に「(許可済み)」という表示が行なわれています。なお、一括で許可という機能はありませんが、右側のペインのスクロールバーで囲まれた「利用可能な更新」にフォーカスを合わせれば、後はTABキーで移動しながらスペースを押してチェックボックスをチェックしていくことで、比較的素早く多数の修正プログラムを「許可」することが可能です。

これで、SUSサーバについては、初期設定が完了です。

なお、ここで説明した以外のメニューのうち「関連項目」にある各種メニューは、みての通りドキュメントや外部の Web サイトへのリンクです。「ログの表示」と「サーバーの管理」については、SUS サーバの管理に利用するものですので、後で説明します。

コラム1: ローカルポリシーによる「Windows 自動更新」の設定

とりあえず手軽に設定する方法として、ローカルポリシーによる設定方法について説明しておきましょう。 まずは、「スタート」メニューの「ファイル名を指定して実行」から gpedit.msc を実行して、ローカルコンピュータポリシーの MMC スナップインを起動します。ついで図 14のように「管理用テンプレートのコンテキストメニューから「テンプレートの追加と削除」を選択して、本文でも説明した wuau.adm を追加します。
これで、「管理用テンプレート」-「Windows コンポーネント」の下に「Windows Update」というフォルダが現れ、中にポリシーが2つ現れますので、適宜設定して下さい。設定項目自体は、本文で説明したレジストリと同じです。

図 14: 「テンプレートの追加と削除」メニューの選択

・SUSクライアントの設定

SUSでは、冒頭で説明したように各クライアントマシンが SUS サーバ(や Windows Update サイト)から修正プログラムを取得するというプル型のモデルですので、クライアント側でもSUSサーバを利用するため、先ほどインストールした「Windows 自動更新」の設定が必要になります。
設定は基本的にレジストリを修正することで行ないます。もちろんローカルポリシー、GPO やシステムポリシーを使ったり、スタートアップスクリプトで REG ファイルを自動的に読み込ませるなどの方法で自動的に設定することが可能です。ローカルポリシーや GPO を利用する場合のポリシーテンプレートとしてwuau.admというファイルが予め用意されています。なお各方式の具体的な方法は SUS とは外れますのでここでは説明しません。以下、レジストリとその意味について説明します。

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

  REG_DWORD: NoAutoUpdate
    0 = 自動更新を行ないます
    1 = 自動更新を行ないません

  REG_DWORD: UseWUServer
    0 = WUServerで指定されたSUSサーバを使いません
    1 = WUServerで指定されたSUSサーバを使います

  REG_DWORD: AUOption
    2 = 更新をダウンロードする前、およびインストールする前に通知する
    3 = 更新を自動的にダウンロードし、インストールの準備ができたら通知します
    4 = 更新を自動的にダウンロードし、ScheduledInstallDayとScheduledInstallTime
        で指定されたスケジュールでインストールします

  REG_DWORD: ScheduledInstallDay
    0 = 毎日
    1〜7 = 日曜日(1) から土曜日 (7) の曜日
    AUOption = 4の時に、自動インストールが行なわれる曜日を指定します。

  REG_DWORD: ScheduledInstallTime
    0〜23 = 24時間形式の時刻。AUOption = 4 の時に、自動インストールが行なわれる
    時刻を指定します。

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\

 REG_SZ: WUServer
  SUSサーバのURLを指定します。例えばSUSサーバがSHIORIという名前で参照可能な
  場合、「http://shiori」のように指定します。
  なお、値が設定されていない場合は、Windows Updateサイトから修正プログラムの
  ダウンロードが行なわれます。

 REG_SZ: WUStatusServer
  後述するステータスサーバのURLを指定します。良くわからない場合はSUSサーバと
  同じ値を設定して下さい。

通常は、自動更新を有効にするには、NoAutpUpdate=0, UseWUServer=1 に設定して、WUServer と WUStatusServer に SUS サーバの URL を指定した上で、ポリシーに応じて AUOption を3か4に設定することになるでしょう。いずれにしても、上記レジストリを設定すると、各マシンの GUI による設定画面は図 15のようにグレーアウトして設定できなくなります。

自動更新が有効になっている各マシンは、1日に1回定期的に SUS サーバに接続して、SUS サーバが「許可された更新」に含めた修正プログラムをダウンロードし (AUOption=2 の時は、ダウンロードをしてよいか通知します)、ダウンロード完了後に、ユーザに通知、もしくは指定された時刻に自動的にインストールを行ないます。なお、SUS サーバに接続する時間は制御することができませんので、厳密なトラヒック管理ができません。この辺りも、SMS を意識して故意に機能を落しているような感じがします。
インストール後再起動が必要な修正プログラムを自動でインストールすると、インストール完了後に自動で再起動が行なわれますので、自動でインストールする (AUOption=4) 場合は、自動的な再起動で編集中のファイルが破棄されるなどの問題が発生しないように運用に注意する必要があります。また、SMS とは違い、SUS では一度クライアントがインストールした修正プログラムをアンインストールする機能は提供されていません。どうしてもアンインストールが必要になった場合は、SUS 以外の方法で行なう必要があります。

SUS の管理

一度インストールして運用を開始してしまえば、これ以降行なうことは、新規修正プログラムがダウンロードされる度にそれを「許可された更新」に含めるかどうかを判断して設定すること以外、基本的にログの監視になります。
SUSサーバのログ監視は、基本的に前述した図 9の SUS の管理画面にある図 16のような「同期ログの表示」と図 17のような「許可ログの表示」画面から行ないます。なおこれらのファイルは SUS の Web サイト以下の \AUtoupdate\Administration フォルダ以下に、各々history-sync.xmlとhistory-approve.xmlという名前の XML 形式のファイルとして保管されていますので、スクリプトなどでログの解析を行なうことも可能です。

また、図 18の「サーバーの監視」では、 メモリ中に格納されている最新の修正プログラムに関する情報を参照することが可能です。

実際にトラブルが発生した場合の対応方法や、発生しそうなトラブルの一覧については、「Microsoft Software Update Services の展開」の「トラブルシューティング(P.64)」などに詳細な情報がありますので、そちらを参照してください。

・ステータスサーバによるクライアントの状態の管理

SUS を管理していく上で、各クライアントへの修正プログラムの配布状況などは把握しておきたいことでしょう。SUS ではちょっとトリッキーな方法で IIS のログファイルを活用することで、こうした情報を収集しています。
SUS のクライアントは、何らかのアクションを行なうと、ステータスを示す様々な引数を指定してステータスサーバとして指定されたサーバ上の /wutrack.bin というダミーのファイルを GET します。これにより、IIS のログに /wutrack.bin ファイルへのアクセスという形で記録が行なわれ、ログファイルを解析することで SUS クライアントの状態を把握できるようになっています(注 10)。ここまでやるなら、ログファイルを解析する画面(やツール)もつけてくれても良さそうなところですが、SMS との競合を避けるためか、そうしたツールはついていません。

(2)WANで複数サイトに分割されている組織
事務所が複数あって、間が WAN で接続されている場合は、WAN の帯域と各拠点のクライアントマシンの台数にもよりますが、ある程度以上の規模であれば図 22 のような多段構成を検討するとよいと思います。この場合、クライアントに配布する修正プログラムは、本社側のサーバで一元管理できるように、支社側のサーバでは、コンテンツを同期するサーバとして、本社のSUSサーバを指定するとともに、「許可された項目の一覧を同期する(置換モード)」のチェックボックスをチェックしておきましょう。

(3)完全にクローズドなネットワークな組織
この場合は、Windows Update サイトから修正プログラムをダウンロードして蓄積するインターネットに接続した環境にある SUS サーバと、手動による複製を行ない、クローズドなネットワーク内で SUS サーバとして機能させる内部 SUS サーバの最低2台の SUS サーバが必要となります。具体的な複製の方法は、コラムを参照してください。クローズドなネットワーク内の各クライアントは、内部 SUS サーバから、自動的に修正プログラムをダウンロードして、インストールすることが可能となります。

とりあえずの評価

ここまで、SUS について一通り説明しました。筆者自身、まだ使い込むというところまではいっていないので、今後予想外の問題点が出てくるかも知れませんが、とりあえずの評価としては「可もあり不可もあり」といったところでしょうか。
操作性に関しては、非常にシンプルで評価できます。今まで Windows Update に頼ってきた組織にとっては、ネットワークトラヒックの低減という点だけでも導入する価値があるのではないでしょうか? 一方各クライアントを厳格に管理して運営しているような組織にとっては、スケジューリング機能の低さがネックになって、今一つ導入しづらいと思います。特に SUS クライアントがいつ SUS サーバに接続できるかを制御できない点は、問題となるケースも多いと思います。こうした点から考えると、SUS は主にあまり厳格な管理の必要でない、OA 系ネットワークに Windows Update の代替として導入するのが一番似合っているように思います。ネットワークトラヒックが制御できない点を除けば、ある程度厳格な管理もできますが、他のプロダクトとの連携機能がないなど、厳格な管理を行なうにははがゆい点が多いので、導入は注意深く行なうことが必要でしょう。
もっとも、ある程度機能や目的を限定しているからこそ、最近の多機能指向の Microsoft 社製品の中にあって非常にシンプルな操作性が実現されているわけです。SUS だけですべてが解決できるわけではないですが、SUS をうまく既存のシステムに取り込めば、役立ってくれるのも確かでしょう。こうしたツールをどう使うか、生かすも殺すも後はわれわれ管理者の腕にかかっているといったところでしょうか。
最後になりましたが、SUS の導入にあたっては、事前に SUS のホームページ(注 16)から参照、ダウンロードできる各種ドキュメント、中でも特に本文中でも何度か紹介した「Microsoft Software Update Services の展開(注 17)」に目を通しておくことを強く推奨します。90ページ以上あるのでちょっと読みこなすのは骨ですが、これを読み通せば SUS の設定、運用を行なう上で充分な知識が身につくと思います。

編集者・追加情報

・WSSR：Microsoft，企業内セキュリティ・パッチ適用ツールSUS新版でサービス・パックを適用可能に
http://wssr.nikkeibp.co.jp/news/030922/4.shtml

> 　Microsoftは米国時間の9月19日，同社が無償提供するセキュリティ・パッ
> チ適用ツール「Software Update Services（SUS）」をバージョンアップし
> た（該当サイト）。新版「Software Update Services with Service Pack 1
> 」では従来サポートされていた重要なセキュリティ・パッチに加えて，通常
> のセキュリティ・パッチやロールアップ・パッケージ（累積パッチ），サー
> ビス・パックの適用が可能になっている。

・@IT： Microsoft Software Update Servicesの実力を探る
http://www.atmarkit.co.jp/fwin2k/operation/sus1/sus1_01.html

・@IT：HotFix管理を始めよう
http://www.atmarkit.co.jp/fwin2k/operation/hotfixman/hotfixman_01.html

・Windows 2000 Server セキュリティ運用ガイド
http://www.microsoft.com/japan/technet/treeview/default.asp?url=/japan/technet/security/prodtech/windows/windows2000/staysecure/default.asp

・『Windows 2000 Server セキュリティ運用ガイド』日経BP (ISBN 4-89100-334-0)
http://store.nikkeibp.co.jp/item/main/148910033400.html

・ZDNet：セキュリティ対策のポイントは自社なりの深刻性評価とパッチ適用前のテスト
http://www.zdnet.co.jp/enterprise/0305/17/epn01.html

・ZDNet：管理者を悩ませるパッチ適用作業を支援する「SUS」と「SMS」
http://www.zdnet.co.jp/enterprise/0302/14/epn15.html

・WSSR：パッチ管理の悪夢を解決するMicrosoft Updateが2004年初めに登場
http://wssr.nikkeibp.co.jp/news/030703/2.shtml

・MSKB:[HOWTO] Windows XP、Windows 2000、または Windows Server 2003 で自動更新をスケジュールする方法
http://support.microsoft.com/default.aspx?scid=kb;ja;327838

・MS:Microsoft Software Update Services についてよく寄せられる質問 (FAQ)(http://www.microsoft.com/japan/windows2000/windowsupdate/sus/susfaq.asp)