トップページ»3.3.セキュリティ»2つのセキュリティアップデート方法の相違点

3.3.セキュリティ



2つのセキュリティアップデート方法の相違点

今日Microsoftのセキュリティの更新が数件リリースされた。 早速朝一でMicrosoft Software Update Services(以降SUS)の同期を行い、アップデートが取得されていることを確認した上で、全クライアントに対し更新の許可をした。

これをやっている間、若干の待ち時間ができるのだが、この間いつも同じ事を「ぼけっ」とした顔をして考える。 それは現状のSUSの弱点だ。




この手の仕組みには大分して2通りの方法がある。 それはプッシュ型及びプル型だ。 SUSの場合後者の方になる。

言葉の通り、プッシュ型は配布サーバーから各クライアントに対して押し込む方法で、プル型はクライアントが配布サーバーに対し取りに行くという形態になる。

この2つの方法の大きな相違点は、配布そのものに対する積極性になるのではないだろうか。

配布サーバー側からみると、プッシュ型は既知のクライアントに対し積極的に配布を試みる。 反対にプル型はクライアントから配布の要求が来るまで待機の状態、つまりかなり消極的な配布方法だと言えるだろう。

例えば同様の仕組みとして存在するものの1つにアンチウイルスソフトのパターンファイル配布サーバーというものがある。

ウチではSymantec Antivirus Corporate Edition(以降SAVCE)を使用しているが、こちらはプッシュ及びプルの両方ともサポートしている。

ウチではSAVCEに対し通常はプッシュ型をデフォルトとして設定しているのだが、この場合配布サーバー上のパターンファイルが更新されると同時に配布が開始される。 そして数百台といったクライアントがみるみるうちに更新されていくのが管理コンソールによって確認できるのだ。

これに対しプル型、例えば今回話に上がっているSUSの場合、クライアントがいつ取りに来るのかは分からない。 またSUSの弱いところとして管理コンソールの類が無いため、本当に配布が行われているのかすら表面的には分かりづらい。 勿論クライアントのパッチ取得状況のログはあるにはあるのだが、SUSが直接吐くものではなく、単にIISが吐いたテキストベースのアクセスログとなっている。(SUSの配布はhttpベースで行われる)

クライアント側で見ても両者には圧倒的な違いが見られる。

SAVCEの場合は、自PCが管理下に置かれる配布サーバーが、パターンファイルを取得後、自分のクライアントがアップデートされるまでにかかる時間は、体感的におよそ1~2分程度。

勿論配布サーバーが配布先PCに対し同時にセッションを張れる数は有限な為、なんらかの法則に基づいて順番に配布するようになっているのだろうから、更新の早い遅いはあるだろうと思う。 しかしローカルネットワークであるが故に1つの配信ジョブにかかる時間も短い。 従って数百台程度であれば5~10分もあればほぼ全数に配布が完了するのではないだろうか。 これはやはり現時点では高速だと評価できると思う。

これに対しSUSの場合、配布サーバーがアップデートされてからなかなかクライアント側のWindows自動更新が反応しない。 ウチでは例えば朝SUSの同期を行って配布準備が整ったとして、やや早いタイミングで例の「インストールする準備が整いました」というメッセージが出るものもあるが、PCによっては、その日は更新されることなく、翌日にメッセージが出るなんていう事もあるようだ!

これはもしかしたらウチの設定がまずいのかもしれない(とはいえこちらで修正可能な箇所は少ない)。 しかしプッシュ型とプル型には明らかに目に見える程の更新速度差がある。

このタイムラグは当然大きな危険性をはらんでいることは明白だろう。

過去においてセキュリティホールに関する情報は、様々な機関による脆弱性の警告→ウイルス・ワーム発生というが流れが多かった。 しかしこれが逆転するケースが発生することは大いに考えられる。 この場合、内部セグメントにあるホストが全滅する恐れもあるのだ。

これに対し他のエントリーにも書いた、パーソナルファイアウオールを個々に導入するという対処法もあるだろうが、現在の所導入したホスト全数をいかにしてコントロールするのか、またそのポリシーはどのように定義するかといった部分、運用管理面でまだまだ導入に踏み込めない所ではないだろうか。

結局現状で一番効果的な対策としてあげられるのは、インシデント発生時、とにかく早急に管理下にある全PCにセキュリティパッチを適用する事、インシデントレスポンスを向上させる事なのではないかと思う。 これに対しプル型の方法は、今のところ弱い。 個人的にはそう感じている。

SUSは基本的に無料だ。 文句があるならSMSを使え。 と怒られるかもしれないが、別にSUSを貶しているつもりはないので誤解されないようお願いしたい。 あくまで使ってみた私個人の所感だ。

しかし色々な人に聞いてみると、意外とSUSを導入している機関は多い。 なぜなのだろうと考えてみると、結局予算の問題や、「無いよりはまし、とりあえず早急に対応したい」というニーズが高かった結果なのだろう。

反面プッシュ型に問題がないかというとそうではない。 例えば通常クライアントサイドにサーバーと通信しあうための常駐プログラムが必要となるため、管理下のPC全数にそれをインストールする手間がある。 これは例えばActive Directoryのグループポリシーやログインスクリプトの定義等により対処可能かもしれない。 しかしインストール後、常駐プログラムが正常稼働していない場合は更新の対象から除外されてしまうという問題が発生する。(これはプル型も同様の問題としてあげられるが…)

どちらにも一長一短があるのかもしれない。 適材適所という事だろうか。

なんにせよ、こういった対策の必要性は今後更に必要になっていくことだろう。 この手の問題と対策はいたちごっこで、よく言われるように「これで完璧ということありえない」のだ。

ウチはSUS入れているから安心だと思われている世の情報システム部門マネージャー様。 思わぬしっぺ返しがあるかもしれません。 危機意識をもう少し高め、セキュリティ対策及びITにかける予算を上乗せできるよう上層部に打診してください。

放っておくと…大変な事になりますよ…(by某番組)

と、脅すのはこれくらいにして。(苦笑) まぁ実際問題、管理台数が多い場合、SUSを導入しておけば単発のWindows Updateよりは確実に安全にはなると思うのでひとまずご安心いただきたい。

ただそういう危険性は残っていると言うことだけ頭の隅に置いておく事をお勧めする。

またこういった仕組みが今後どういう風に変貌を遂げていくのか楽しみでもある。 我々があっと驚くような画期的な手法が出ることを期待したい。


投稿日 : 2004年7月14日

この記事に関する言及

このエントリーのトラックバックURL:
http://akionweb.com/mt-tb.cgi/14

コメント

このページに対する感想、意見をお寄せ下さい。




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)

おことわり

当サイトに掲載している全ての情報は、全て当サイト管理者が個人的、実験的に試した事、又は独自に調査したものです。 従ってその情報に誤りがある可能性も多分にあります。 当サイトの情報をそのまま鵜呑みにされませんようお願い申し上げます。 また当サイトの情報を元に作業されたりする場合はそれをご理解頂いた上で、あくまで自己責任の元で行ってください。

トップページ»3.3.セキュリティ»2つのセキュリティアップデート方法の相違点