第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記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間