この特集のトップページへ
＞ Chapter 8：プレゼンテーション層の構築

head1.gif8.3　IISのセキュリティ

　インターネット上に公開されたWebアプリケーションは，不特定なユーザーによるアクセスを受ける可能性があるため，セキュリティには十分な注意を払わねばならない。ここでは，IISのセキュリティについて説明する。

head2.gif8.3.1　IISのセキュリティ設定
　IISのセキュリティ設定は，サイトまたは仮想ディレクトリの［ディレクトリセキュリティ］ページで設定する（Fig.8-59）。

Fig.8-59　［ディレクトリセキュリティ］ページ
fig8_59

　［ディレクトリセキュリティ］ページには，［匿名アクセスおよび認証コントロール］，［IPアドレスとドメイン名の制限］，［セキュリティ保護された通信］という3つの項目が用意されている。このうち，まずは［匿名アクセスおよび認証コントロール］と［IPアドレスとドメイン名の制限］について説明することにし，［セキュリティ保護された通信］については「8.3.2　SSLによる暗号化」にて説明する。

●認証方式と実行ユーザー
　［匿名アクセスおよび認証コントロール］の項目内では，クライアントがアクセスしてきたときにどのような認証方式を使い，どのユーザー権限を使うのかを設定する。［匿名アクセスおよび認証コントロール］の項目内にある［編集］ボタンを押すと，Fig.8-60に示す［認証方法］ダイアログボックスが表示され，どのようなユーザー権限を使うのかを設定できる。

Fig.8-60　［認証方法］ダイアログボックス
fig8_60

　IIS 5.0は，以下の4つの認証方式をサポートする。

匿名アクセス
　ユーザーに対して特別な制限を設けず，匿名でのアクセスを許す。デフォルトの設定である。
　匿名アクセスの場合，［匿名アクセスで使用されるアカウント］の横にある［編集］ボタンで設定したアカウントが実行ユーザーとなる（Fig.8-61）。デフォルトでは，IUSR_サーバー名というアカウントが設定されており，そのユーザー権限が使われる。IUSR_サーバー名は，IIS 5.0をインストールしたときにGuestsグループに属したユーザーとして作られるアカウントである。このアカウント設定は変更可能であるが，該当するアカウントは「ローカルログオン」の権限を所持していなければならないので注意してほしい。
Fig.8-61　匿名ユーザーアカウント
fig8_61

　クライアントからファイルの要求があった場合には，IUSR_サーバー名というアカウントが当該ファイルに対してNTFSのアクセス権限を所持しているかどうかを調査する。もしアクセス権限を所持していなければ，クライアントに「401 Access Denied」というステータスコードが返される。
　ASPファイルや実行形式ファイルの実行についても同様である。IUSR_サーバー名というアカウントが，クライアントの要求したASPファイルや実行形式ファイルの実行権限を所持していなければ，やはり「401 Access Denied」というステータスコードが返され，サーバー側で実行されない。
　このとき，ASPファイルや実行形式ファイルは，IUSR_サーバー名というアカウントで実行されることになる。たとえば，ASPファイルなどがCOM＋に管理されたCOMコンポーネントを使う場合には，ロール設定においてIUSR_サーバー名というアカウントに呼び出し権限がなければ失敗する。また，ファイルを書き込む場合には，IUSR_サーバー名というアカウントに書き込み権限が設定されているフォルダに対してしか，書き込むことができない。
　
［基本認証］
　暗号化しないパスワードを用いてユーザーを認証する。この方式を選択する場合には，横にある［編集］ボタンを押すと表示されるダイアログボックスで，ユーザー認証に用いるドメイン名を入力する（Fig8-62）。ドメイン名が空欄である場合には，ローカルドメインが使われる。
Fig.8-62　ドメイン名の設定
fig8_62

　［基本認証］にチェックを付けた場合，Webブラウザを使ってアクセスすると，Fig.8-63のようにユーザー名とパスワードの入力を求めるダイアログボックスが表示される。ユーザーは，この画面でFig.8-62で指定したドメインに登録されているアカウント情報を入力することになる。
Fig.8-63　ユーザー名とパスワードの入力
fig8_63

　入力された情報が正しければ，そのアカウント情報を使ってファイルへのアクセスが試みられる。つまり，静的なファイルであれば，入力されたアカウントが読み取り権限を有していなければアクセスに失敗することになるし，ASPファイルや実行形式ファイルであれば，入力されたアカウントのユーザー権限に基づいて実行されることになる。また，それ以外に，入力されたアカウントがローカルログオンの権限を所持していない場合にも，アクセスは失敗するので注意してほしい。
　［基本認証］は，いかなるWebブラウザでもサポートされているため，汎用性は高い。しかし半面，暗号化しないパスワードを使うため，ネットワーク経路で覗き見られる危険を否定できず，セキュリティはあまり高くない。もし，［基本認証］を使う場合にセキュリティレベルを向上させたいのであれば，SSLを使って暗号化通信することが望ましい。
　また，［基本認証］の場合には，ユーザーが入力したユーザー名はおろか，パスワードさえもASPファイルから参照することができる（具体的にはRequest.ServerVariables("AUTH_PASSWORD")として取得できる）。よって，ASPファイルの開発者が信頼できるユーザーでない場合には，セキュリティの問題を引き起こしかねない（たとえば，ユーザーが入力したユーザー名とパスワードの組み合わせをメールで開発者宛に送信するルーチンを組み込まれてしまうといった危険がある）。
　
［Windowsドメインサーバーでダイジェスト認証を使用する］
　動作は［基本認証］と同じだが，アカウント情報そのものをネットワークに送信するのではなく，代わりにハッシュキーを用いる。ハッシュキーとは，一方向関数から求められる値のことで，異なるアカウント情報から作られたハッシュキーは異なる値をとり，ハッシュキーからアカウントを逆に求めることはできない，という性質を備える。そのため，アカウント情報がネットワーク上で漏洩することはなく，安全な認証を実現できる。ダイジェスト認証の詳細は，RFC2069に記されている。
　ただし，ダイジェスト認証はHTTP 1.1の拡張機能であり，すべてのWebブラウザでサポートされているとは限らず，汎用性という点ではやや問題がある。
　なお，ダイジェスト認証をサポートするのはWindows 2000のドメインコントローラで運用されているWindows 2000ドメインのみであり，かつ，認証に用いるユーザーは［暗号化を元に戻せる状態でパスワードを保存する］という設定になっていなければならない。この項目の設定状況は，［Active Directoryユーザーとコンピュータ］管理ツールで該当ユーザーのプロパティを開き，［アカウント］ページを開くと確認できる（Fig.8-64）。ただし，［暗号化を元に戻せる状態でパスワードを保存する］にチェックを付けても，即座にパスワードが元に戻せる状態で保存されるようになるわけではない。チェックを付けたあと，パスワードを再設定しなければ，暗号化を元に戻せる状態として保存されないので注意してほしい。
　なお，［暗号化を元に戻せる状態でパスワードを保存する］という設定は，グループポリシーで一括設定することも可能であるが，その方法の説明は割愛する。グループポリシーについては，Windows 2000 Serverのヘルプファイルや『Microsoft Windows 2000 Serverリソースキット1〜8』（日経BPソフトプレス）などを参照してほしい。
Fig.8-64　暗号化を元に戻せる状態でパスワードを保存する
fig8_64


　
［統合Windows認証］
　統合Windows認証は，従来「NTLM認証」や「NTチャレンジ/レスポンス」と呼ばれていた認証方式である。HTTPの機能ではなく，Windowsドメインに参加する場合と同様の方法でユーザー認証を試みる。この認証方式をサポートしているクライアントは，Internet Explorer 2.0以降のみである。動作は［基本認証］と同じで，正しく認証できたならば，そのユーザーの権限を使ってファイルの読み取り権限や，ASPファイルおよび実行形式ファイルの実行権限を調査する。
　統合Windows認証がサポートされている場合，ユーザーが所属しているドメインに対して自動的に認証を試みるため，ユーザーがWebアクセスのたびにアカウント情報を入力しなくともすむという利点がある（ただしInternet Explorer 4.0以降では，設定により自動的な認証を抑制することはできる）。しかし，HTTPの機能を使わないため，ファイアウォールを越えることはできず，インターネットでの利用には適さない。主にイントラネットで用いる認証方式である。

　少々ややこしいのだが，以上の4つの認証方式をまとめるとTable 8-3のようになる。ただし，これ以外にSSLをサポートするように設定すると，クライアント証明書を使った認証方式も利用できるようになる。クライアント証明書については，「8.3.3　クライアント証明書を使った認証」で説明する。

　なお，Fig.8-60では，複数の設定項目にチェックを付け，複数の認証方式をサポートさせることもできる。たとえば，［匿名アクセス］と［統合Windows認証］の両方にチェックを付けた場合，まず，IUSR_サーバー名というアカウントを使ってアクセス権限が調査され，もし権限がないのであれば，次に統合Windows認証方式を使って権限が調査される。

Table 8-3　認証方式のまとめ
認証方式暗号化サポートするブラウザ主な用途
匿名アクセス−（認証そのものがない）すべて認証が不要な不特定多数へのアクセスを提供する場合
基本認証なしすべて認証が必要な不特定多数へのアクセスを提供する場合。ただし，パスワードが暗号化されないので，セキュリティの危険性は高い
ダイジェスト認証ハッシュHTTP 1.1の拡張機能をサポートするブラウザ認証が必要で，HTTP 1.1の拡張機能をサポートするブラウザのみをサポートすればよい場合
統合Windows認証ありInternet Explorer 2.0以降認証を必要とし，イントラネットで利用する場合
Prev 32/43 Next