第2回 何が変わった？ エッジ層を保護するISA Server 2006

高橋 桂子
NRIラーニングネットワーク株式会社
ラーニングソリューション部
（Microsoft MVP for Windows Server System - ISA Server）
2007/1/18

---

　認証の委任とシングルサインオン

　認証の委任は、ユーザーに表示する認証画面の数を減らし、ユーザーの利便性を高める機能です。次のような環境を考えてみます。

図4　Webサーバー公開時の構成

　ISA Serverを通じて、Webサーバが公開されています。このときISA Server上では、HTMLフォームの認証を有効化しています。さらに、公開されているWebサーバ上では基本認証が有効化されています。

　このとき、外部の利用者が公開Webサーバに接続しようとすると、まずゲートウェイとして配置されているISA ServerがHTMLフォームの認証を要求し、クライアントには（1）の認証画面が表示されます。ここで、適切なユーザー名とパスワードを入力すると要求はISA Serverによって内部の適切な公開サーバに転送され、次にWebサーバが基本認証を要求し、クライアントには（2）の認証画面が再度表示されます。

　ISA Serverでも、WebサーバでもActive Directoryドメインのユーザーアカウントを使用した認証を構成している場合、利用者は、まったく同じActive Directoryのユーザー名とパスワードを2回入力しないと公開Webサーバを参照することができません。このような場合に、ISA ServerのWebサイト公開ルールで認証の委任を構成することで、クライアントに提示される認証をゲートウェイレベルのものだけにすることができます。

　認証の委任を構成すると、（1）でクライアントから送信された認証データを指定された方法でISA Serverが公開サーバに代理で送信します。つまり、クライアント側には（1）の認証画面しか表示されず、（2）の認証はISA Serverが代理実行します。

	認証の委任を構成しない場合の設定 ・［委任できません。クライアントは直接認証できません。］ ・［委任できません。クライアントは直接認証できます。］ 認証の委任を構成する場合の設定 ・基本認証 ・NTLM 認証 ・ネゴシエート(Kerberos/NTLM) ・Kerberos制約付き委任 認証の委任を構成する場合、公開Webサーバーでの認証と一致した認証方法を選択する。
図5　Webサイト公開ルールでの認証の委任（画像をクリックすると拡大します）

　シングルサインオン（以下、SSO）も認証の委任と同じ、ユーザーに表示する認証画面の数を減らしユーザーの利便性を高める機能です。認証の委任がISA Serverでのゲートウェイ認証と、公開サーバでのバックエンド認証を統合する機能であるのに対し、SSOは、ISA Serverでのゲートウェイ認証を統合する機能です。例えば次のような環境を考えてみます。

図6　複数Webサイト公開時の構成例

　ISA Serverを通じ、IIS上のWebサイト、SharePoint Portal Services（以下、SPS）のサイト、Exchange Outlook Web Access（以下、OWA）のサイトが3つの公開ルールにより公開されています。それぞれのルールで、クライアント認証としてフォームの認証が有効になっているとします。

　ユーザーがまずExchange OWAにアクセスし、自分あてのメールを読もうとします。このときに、フォームの認証画面がユーザーに表示されます。次にメールに含まれていたSPSサイトのリンクをクリックします。すると、SPSサイトを参照する際に、再度フォームの認証画面がユーザーに表示されます。

　次にユーザーはSPSサイトに含まれるIISサイト上のWebサイトへのリンクをクリックします。するとIIS参照時にもう一度フォームの認証画面がユーザーに表示されることになります。つまりユーザーは評価される公開ルールに応じた数の認証を通過しないと、公開されている複数のWebサイトを参照できません。

　このようなゲートウェイレベルでの認証を統合するのがSSOです。SSOは、Webリスナ作成時に構成します。SSOを構成することで、ユーザーはISA Serverで一度認証を受ければ、どの公開Webサーバ（IIS、SPS、OWAなど）でもSSO環境で利用できシームレスにサーバ間を移動できます。

	SSOの条件 ・同じWebリスナーを共有しているWeb公開ルールで公開されたサーバー ・クライアント認証方法は[HTMLフォームの認証]に設定 ・公開サイトがドメイン名を共有していること
図7　SSOの構成（画像をクリックすると拡大します）

　Exchange公開ルールウィザード

　OWAなどExchange ServerのWebクライアントアクセス環境を公開する場合、専用のウィザードであるExchange公開ルールウィザードを利用することで、容易にセキュリティレベルを確保した公開ができます。ISA Serverの管理ツールのコンソールツリーで、ファイアウォールポリシーを右クリックし、［新規作成］−［Exchange Webクライアントアクセスルール］を選択すると、ウィザードが起動します。

図8　Exchangeサーバ公開ルールウィザードの起動

　ウィザードの［サービスの選択］ページで、Exchangeのバージョンを選択すると、そのバージョンのExchange Serverに搭載されているWebクライアントアクセスの種類が表示されるので、公開したいWebクライアントメールサービスを選択するだけで、必要なファイアウォールルールが作成されます。

図9　Exchange公開ルールウィザード 公開するExchangeのバージョンを選択すると、［Webクライアントメールサービス］エリアにそのバージョンのExchange Server がサポートするWebクライアントアクセス環境がリスト表示される

　ISA Serverの公開機能を使用すると、次のようなセキュリティを構成して、安全にExchange Webクライアントアクセスをインターネットに公開することができます。

• SSLブリッジ
  • ISA Serverが公開Webサーバの代わりにSSLのエンドポイントとして動作し、SSLの暗号化を解除した後、HTTPのトラフィックを検査し、問題のないトラフィックだけを、公開Webサーバに転送する。
  • WebリスナやWebサイト公開ルール作成時に、HTTPは許可せず、SSLの使用を強制できる。
• アプリケーションレベルの検査
  • HTTPフィルタを使用した、HTTPプロトコルのアプリケーションデータの高度な検査によりWebサーバに対するアプリケーションレベルの攻撃を防ぐ。
• フォルダへのアクセス制限
  • Exchange Webクライアントアクセスに不必要なIIS上のフォルダへのアクセスをブロックする。例えば、Exchange Server 2003のOWAを公開する指定をした場合、［パス］の指定が、/Public/*、/Exchweb/*、/Exchange/*の3つが指定され、それ以外のフォルダにはアクセスできない。
• HTMLフォームの認証
  • ISA ServerのHTMLフォームの認証により、OWAのフォームベース認証相当の認証を、Exchange Serverではなく、ゲートウェイレベルのISA Serverで実行でき、認証を受けていないユーザーが、内部のOWAサイトに接続するのを防ぐ。また、添付ファイルブロックやセッションCookieのTTLをすべてISA Serverで調整できる。

　設定はウィザードベースなので、設定ミスをする可能性はとても少なくなります。

2/3

Index
何が変わった？ エッジ層を保護するISA Server 2006
	Page1 ISA Server 2006の機能強化点 認証の強化〜クライアント認証方法と認証の検証方法
	Page2 認証の委任とシングルサインオン Exchange公開ルールウィザード
	Page3 SharePoint公開ルールウィザード Web公開の負荷分散

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）