Webサーバ・ソフトウェアとしてWindows付属のIIS(Internet Information Services。Ver.5.0まで、最後の“S”はServerの略だったが、Ver.5.0からはServicesの略と改められた)を使っていると聞くと、顔をしかめるネットワーク管理者が少なくない。こうした傾向は、経験豊富な熟練管理者ほど強いように思う。 実際、企業に導入されたWindowsシステムの事例取材などで、現場のネットワーク管理者と情報交換してみると、社内のイントラネット向けはよいとして、社外のインターネットに向けてサービスを提供するWebサーバとしては、IISはあまり使いたくないという意見を聞くことがある。理由はたいてい共通しており、「クラッカーからの攻撃や侵入などを受けやすく、不正アクセスを許してしまうセキュリティ・ホールもたくさんあるから」というものだ。 Webサーバとしては後発となるIISが、Windowsにもれなく付いてくるとはいえ、どれほどインターネットで使われるのか、最初のうちは当のマイクロソフトも測りかねていた節があった。しかしマイクロソフトの予想を大きく超えて、IISは世界中のWeb発信に利用されていた。このことを図らずも証明したのが、昨年に猛威をふるった、IISをターゲットとして感染を広げるCode Red(コード・レッド)とNimda(ニムダ)ワームである。これらは、IISに潜んでいたセキュリティ・ホールを突いて感染を広げるコンピュータ・ワームで、一時はインターネットがこの感染パケットであふれかえる事態に至った(Code Red、Nimdaの詳細については、それぞれ別稿「Insidre's Eye:Code Redワームの正体とその対策」「Insider's Eye:ネットを震撼させたコンピュータ・ワーム、Nimdaを検証する」を参照)。 ただしマイクロソフトの名誉のために申し添えておくと、Code RedやNimdaが悪用したIISのセキュリティ・ホールは、それが猛威をふるう何カ月も前にセキュリティ・パッチ(修正モジュール)が提供されていた。Windows 2000までは、システムをインストールすると、デフォルトでIISがインストールされ、外部に向けてHTTPのサービスを開始する仕様になっていた(これは危険な状態だということから、後にマイクロソフトは、使っていないIISの機能をロックダウンするツールを配布した。また次期Windows .NET Serverでは、明示的に指定しないかぎり、デフォルトではIISはインストールされない)。このような手軽さから、情報セキュリティなどにはあまり敏感ではないイージーな管理者が、IISをいったんセットアップしてWebページを公開できる状態にし、後はほったらかしにするというケースが多く、これらほったらかしのWebサーバがワーム増殖の温床となった。 狙いすまして特定のサイトに侵入するのではなく、愉快犯的に世の中を騒がせたいと考えているクラッカーにとっては、ユーザー数が多く、影響力も大きな獲物ほど魅力的である。この意味では、数的には圧倒的で、しかも脇の甘いイージーなユーザーが多いWindowsは格好の標的に違いない。けれどもだからといって、IISがセキュリティ的に脆弱というわけではないし、マイクロソフトはセキュリティ・ホールのレポートやそれへの対応を積極的に行っているので、マメにメンテナンスするように心がければ、重大な事態には至らないはずだ。事実、IISを使った本格的なBtoCサイトなども数多く運営されている。 それでも、管理者はIISを避けたがる。理屈はともかく、過去に問題を引き起こしたのは事実であるし、上記のような理由からアタックが多いのも事実である。精神的なものも含めて、リスクを少しでも回避したいという気持ちは分からなくはない。 Microsoft .NETへの大きなハードル周知のとおり、マイクロソフトは現在、次世代の情報戦略であるMicrosoft .NETに向けた施策を次々と打ち出している。@ITに付設されたInsider.NET会議室の発言状況を見ても、.NETに対応した開発環境であるVisual Studio .NET(以下VS.NET)が今年の3月に発売されて以来、.NETプログラミングの門をたたくプログラマーが続々と増えていることが分かるだろう。組織的に比較したわけではないが、複数のプログラマーの声を聞くかぎり、開発環境としてのVS.NETが、非常に高機能で生産性も高いプログラム開発環境の1つであることは間違いなさそうだ。 またサーバ・サイドのWebアプリケーション開発を支援する最新のASP.NET(Active Server Pages .NET)では、Webページ・デザインとスクリプト・コードの完全な分離を可能にする分離コード(コードビハインド)機能や、Visual Basic .NETやC#などの高度な言語を使ったサーバ・サイド・プログラム開発がサポートされるなど、より効率よくWebアプリケーションを開発するためのさまざまな支援機能が提供されている。聞くところでは、JavaをベースとするWebアプリケーション開発では、いまなお、テキスト・ベースのJDK(Java Development Kit)を使うプログラマーも少なくないという。このようなプログラマーにとって、VS.NET+ASP.NETは、実に魅力的な開発環境として写っているのではないか。 開発環境だけに注目すれば、マイクロソフトの未来はばら色に見える。魅力的な開発環境がプログラマーを誘い、やがては.NET対応ソリューションが時代の趨勢となる、といいたいところだが、現実はそう簡単ではない。 そう、問題はIISである。少なくとも現時点では、VS.NET+ASP.NETで開発したWebアプリケーションやWebサービスを実行するには、Windows OS+IISが不可欠だ。つまり、開発したサービスを広く公開するには、ネットワーク管理者の先入観を払拭して、毛嫌いされているIISを使ってもらわなければならない。 もちろんこの問題は、マイクロソフトも座視しているわけではない。次世代のサーバOSとして、現在開発が進められているWindows .NET Server 2003では、新規に設計し直したIIS(IIS 6.0)が搭載される予定である。このIIS 6.0では、信頼性の向上やセキュリティ性能の向上などが図られている。 信頼性を向上し、セキュリティを強化したIIS 6.0例えば既存のIIS 5.0では、Webアプリケーション自体は外部プロセスで実行されるものの、それら複数のプロセスを管理する部分が1つにまとまっており、いずれかのプロセスが停止して、その余波を受けて管理プロセスも停止してしまうと、IIS全体が停止してしまう危険性がある。これに対しIIS 6.0では、プロセス・モデルを根本的に見直して、アプリケーション・プロセスの完全な分離を達成し、あるプロセスが停止しても、IIS全体は影響を受けずに処理を続行できるように改良された(IIS 6.0の詳細は別稿「Insider's Eye:Windows .NET Serverを支えるIIS 6.0」を参照)。 その証拠にIIS 6.0には、かなり力技ではあるものの、限られた期間でWebアプリケーションのカットオーバー(サービス開始)を迫られているプログラマーにとっては、思わずすがりたくなるような機能が追加されている。これは、エラーを繰り返し発生したWebアプリケーションを強制的に停止したり、一定の条件(一定時間経過、要求回数、タイマ指定、メモリ消費量)を満たしたアプリケーション・プロセスを強制的に再起動したりする機能だ。つまりこの機能を使えば、メモリ・リークのバグが残されたアプリケーションでも、リークするメモリ・サイズが一定量になるまで実行させておき、これが一定量を超えたらプロセスを再起動し、最初から(すなわちリークのない状態から)処理を継続できる。甘えてよい機能とは思わないし、有効なのは限定的な状況だと考えられるが、プロセスの分離が完全に達成されていなければ、提供できない機能であることは間違いない。
セキュリティ・ホールの多少については現時点ではまだ判断しかねる。Trustworthy Computing(信頼できるコンピューティング)というビル・ゲイツ氏の号令によって、マイクロソフトのプログラム・コードがどれほど強固なものに生まれ変わったのか? IISがこれまでの汚名を返上して、ネットワーク管理者が抱く負の先入観を払拭できるかどうか? その結論を得るには、まだしばらく時間がかかるだろう。 ■ しかしいずれにせよ、当面のMicrosoft .NETの成否のカギはIIS 6.0が握っていると考えてよいだろう。マイクロソフトが社運をかける.NET戦略が、今後どのような展開を見せるのか? Webアプリケーションで先行するJava陣営に対し、手厚い開発者サポートで流れを変えることができるか? オープンなWebプロトコルを使いながらも、Webブラウザの90%以上をInternet Explorerが占めているように、オープンなWebサービス・プロトコルを使いながらも、その実装ではマイクロソフトが圧倒的なシェアを握ることができるのか? 2003年初頭にも発売されると予想されているWindows .NET Server 2003と、それに含まれるIIS 6.0の出来映えによって、この答えに対するヒントが得られるだろう。 小川 誉久(おがわ よしひさ) |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|