ISA Server: Enhance TS Gateway Security with ISA Server 2006

[アーティクル]
08/25/2016

ISA Server

ISA Server 2006 を使用して TS ゲートウェイのセキュリティを強化する

Thomas W. Shinder および Yuri Diogenes

概要 :

TS ゲートウェイと共に ISA Server を使用する 2 つのシナリオ
ISA Server 2006 の構成
テストと監視

Windows Server® 2008 のターミナルサーバーゲートウェイサービス (TS ゲートウェイ) は、Windows® ターミナルサーバーサービスの持つ柔軟性を備えているだけでなく、HTTP 接続を使用してどこからでもターミナルサーバーに接続できる機能を提供しています。このサービスでは、HTTPS (SSL) を経由した RDP (リモートデスクトッププロトコル) を使用して、セキュリティを強化します。また、ターミナルサービスリソースに一元的にアクセスできるクライアントインターフェイスを提供します。

この新しい TS ゲートウェイサービスは、コンピュータにリモートからアクセスする必要があるユーザーに、次のような大きなメリットを提供します。

RDP を使用して内部リソースに接続する前に、仮想プライベートネットワーク (VPN) セッションを確立する必要がありません。
ネットワークアクセス保護 (NAP) と Windows セキュリティ正常性チェックを使用して RDP 接続を制御し、セキュリティを強化できます。
受信 TCP ポート 3389 を開く必要がないため、ファイアウォール経由のより安全な Web 公開を実現できます。

Microsoft® Internet Security and Acceleration (ISA) Server 2006 を使用すると、TS ゲートウェイサービスのセキュリティを強化しながら、内部リソースへの外部アクセスを許可できます。ISA Server 2006 が要求を受信してこれを内部の TS ゲートウェイサービスに HTTPS を使用して渡すという SSL 間ブリッジシナリオを設定できます。要求をブリッジするだけでなく、ISA ファイアウォールでは SSL 通信を暗号化し、アプリケーション層の検査を実施します。

HTTP プロトコルストリームが検査に合格すると、通信は再び暗号化され、ターミナルサービスプロキシに転送されます。プロトコルストリームが検査に不合格になると、接続は破棄されます。

境界を越えて

マイクロソフトはセキュリティについてこれまで多大な努力をしてきました。Windows Server 2008 は、これまでで最高のセキュリティと堅牢性を備えた Windows です。また、ユーザーが同社の製品を実装する方法と、ユーザーがベストプラクティスに従って環境を安全な状態に保つことについても、心を砕いています。ベストプラクティスでは、アクセスの複数ポイント (つまり層) で保護を提供する多層防御型の方法が必要であると規定されています。この記事に関係のある層は、ポリシー、手順、および認識層、境界層、内部ネットワーク層、およびホスト層です。

ISA Server 経由で外部ユーザーが内部リソースにアクセスできるようにするには、関係する各製品の境界を把握する必要があります。境界層のセキュリティについては、ISA Server 2006 と TS ゲートウェイで提供されますが、内部リソースについては、必要に応じてアクセスを許可または拒否するポリシーを用意する必要があります。ネットワークポリシーとアクセスサービス (NPAS) を使用すると、これを実現できます。NPAS はポリシー、手順、および認識層で機能します。また、内部ネットワーク層については、内部リソース (ドライブ、クリップボード、プリンタなど) へのアクセスをターミナルサービスリソース承認ポリシーで定義して対応します。

この記事では、まず、ISA Server 2006 経由でターミナルサービスゲートウェイを公開する方法について説明します。次に、ISA Server 2006 による公開シナリオを拡張して、NAP を使用したクライアントの正常性の強制を実装します。NAP を使用することで、ホスト層レベルでのアクセス制御に役立つクライアント正常性ポリシーを作成できます。

1 つ目のシナリオ

ここでは、ISA Server 2006 経由で TS ゲートウェイを公開する方法を説明します。図 1 は、接続中のコンピュータとデータフローの概要です。このシナリオでは、TS ゲートウェイ自体にネットワークポリシーサーバー (NPS) の役割を実装していますが、2 つ目のシナリオではこれを変更して、セントラル NPS サーバーを使用します。以下の処理の流れを確認して、この TS ゲートウェイ公開ソリューションの各コンポーネント間で、どのように通信が行われるかを理解してください。

図 1 ISA Server 2006 経由の TS ゲートウェイの公開 (画像をクリックすると拡大表示されます)

外部 RDP ユーザーが接続を開始します。クライアント側でまず実行する必要がある処理は、TS ゲートウェイの外部名 (ここでは tsg.contoso.com) を解決することです。外部 DNS がこの名前を解決し、ISA Server の外部 IP アドレスを提示します。
RDP クライアントと ISA Server の外部インターフェイス間で、SSL トンネルが確立されます。ISA Server には、tsg.contoso.com に対して発行された証明書を使用する、TCP ポート 443 用の Web 公開ルールがあります。
ルールを評価し、トラフィックが許可されることを確認すると、ISA Server は DNS クエリを (ドメインコントローラにある) 内部 DNS サーバーに送信して、Web 公開ルールに指定されているサーバーの名前を解決します。
次に ISA Server は、TS ゲートウェイへの SSL トンネルを開き、TS ゲートウェイに認証要求を渡します。
TS ゲートウェイサーバーがユーザーの資格情報を検証し、ユーザーに接続を確立する資格があることを確認します。
ユーザーに接続を確立する資格があることが確認できると、TS ゲートウェイサービスは TCP ポート 443 で要求を受信し、RDP パケットを TCP ポート 3389 (既定) 経由でアプリケーション (CRM アプリケーションなど) が配置されている内部のターミナルサーバーに転送します。

これ以降は、この RDP クライアントが ISA Server 経由で TS ゲートウェイに送信するパケットは、すべて内部のターミナルサーバーに転送されます。また、これと逆方向の通信も許可されます。

ここで基盤となる HTTP プロキシを経由した RPC は、RDP/RPC/HTTPS でしかないことに注意してください。RDP クライアントは RDP ヘッダー内に RPC 通信をカプセル化し、これは SSL (またはトランスポートレベルのセキュリティ、TLS) を使用して保護される HTTP ヘッダーを使ってカプセル化されます。HTTP を経由した RPC ソリューションに必要なコンポーネントは、すべて展開されている必要があります。TS ゲートウェイの役割のサービスをインストールすると、HTTP プロキシを経由した RPC が自動的にインストールされるのはこのためです。このプロトコルのしくみの詳細については、ISA Server チームのブログ (blogs.technet.com/isablog) で「Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing」(ISA Server 2006 を使用した HTTP を経由した RPC のテスト第 1 部、プロトコル、認証、および処理) を参照してください。

この実装には、Windows Server 2008 にターミナルサービスゲートウェイがインストールされている必要があります。また、この機能は、HTTP プロキシを経由した RPC に依存しています。HTTP プロキシを経由した RPC を利用する RDP が機能するには、インターネットインフォメーションサービス (IIS) 7.0 がインストールされ、実行されている必要があります。また、ネットワークポリシーとアクセスサービスも必要ですが、任意で、インターネット認証サービス (IAS) の後継にあたる NPS サーバーを使用するように TS ゲートウェイを構成して、ターミナルサービスの接続承認ポリシー (TS CAP) の保存、管理、検証を一元管理することもできます。また、TS ゲートウェイサーバー用の SSL 証明書がない場合は、これを取得する必要もあります。ISA Server 2006 が、この証明書を発行した証明機関 (CA) を信頼していることが重要です。ですから、この証明書は、必ず信頼されたルート証明機関ストアにインポートしてください。

Active Directory® ドメインサービスは、ユーザーが Active Directory セキュリティグループのメンバでないと TS ゲートウェイサーバーへの接続を許可しない TS ゲートウェイ承認ポリシーを構成する場合にのみ必要です。この記事のシナリオでは、Windows Server 2003 SP2 を実行するコンピュータで Active Directory を使用します。

ターミナルサービスゲートウェイサービスのインストールが完了すると、図 2 の画面が表示され、インストールされたコンポーネントが表示されます。TS ゲートウェイに接続するには、クライアントでは、Windows Vista®、RDP 6.0 以降がインストールされている Windows XP SP2、Windows Server 2008、RDP 6.0 以降がインストールされている Windows Server 2003 SP1 のいずれかを実行している必要があります。TS ゲートウェイの構成の詳細については、『Windows Server 2008 TS ゲートウェイサーバーのセットアップに関するステップバイステップガイド』(go.microsoft.com/fwlink/?LinkId=122251) を参照してください。次は、ISA Server 2006 の構成方法について説明します。

図 2 TS ゲートウェイのインストールの概要 (画像をクリックすると拡大表示されます)

ISA Server 2006 を構成する

まず、外部の RDP クライアントからの要求を処理する Web リスナを作成します。ここでは、Web リスナに次のパラメータを割り当てました。

認証 : 基本
認証の検証 : Windows (Active Directory)
接続 : ポート 443 での SSL (HTTPS) 接続を有効にする
証明書 : tsg.contoso.com に対して発行された証明書
ネットワーク : 外部

次に Web 公開ルールを作成します。ISA Server 2006 からすると、RDP クライアントでは Outlook® Anywhere が使用するものと同じプロトコルを使用するため、Exchange Server 2007 ウィザードを選択します。それには、次の手順に従います。

[ファイアウォールポリシー] を右クリックし、[新規作成] をポイントして、[Exchange Web クライアントアクセス公開ルール] をクリックします。
[新しい Web 公開ルールウィザードへようこそ] ページで、ルール名を入力し、[次へ] をクリックします。
[ルールの動作の選択] ページで [許可する] を選択し、[次へ] をクリックします。
[サービスの選択] ページで、Exchange Server のバージョンを選択します (ここでは [Exchange Server 2007] を選択しました)。[Outlook Anywhere (RPC/HTTP)] チェックボックスをオンにし、[次へ] をクリックします (注 : [Exchange Server に Outlook 2007 用の追加のフォルダを公開する] チェックボックスはオンにしないでください)。
[公開の種類] ページで、[1 つの Web サイトまたは負荷分散装置を公開する] を選択し、[次へ] をクリックします。
[サーバー接続セキュリティ] ページで、[公開された Web サーバーまたはサーバーファームへの接続に SSL を使用する] を選択し、[次へ] をクリックします。
[内部公開の詳細] ページで、[内部サイト名] ボックスに TS ゲートウェイサーバーの名前を入力します。[コンピュータ名または IP アドレスを使用して、公開されたサーバーに接続する] チェックボックスをオンにし、[コンピュータ名または IP アドレス] ボックスにサーバー名を入力します。TS ゲートウェイサーバーの名前がわからない場合は、[参照] をクリックして、サーバーのある場所を参照します。このページで使用する名前は、TS ゲートウェイ Web サイトにバインドされている Web サイト証明書に記載された共通名またはサブジェクト名と一致している必要があります。
[パブリック名の詳細] ページで、[要求の許可] ボックスの一覧の [次に入力したドメイン名] をクリックし、[パブリック名] ボックスにこの URL に対して発行された証明書の名前と一致するパブリック名 (ここでは「tsg.contoso.com」) を入力します。[次へ] をクリックします。
[Web リスナの選択] ページで、ドロップダウンリストをクリックし、前に作成した Web リスナを選択して、[次へ] をクリックします。
[認証の委任] ページで、[委任できません。クライアントは直接認証できます] を選択し、[次へ] をクリックします。
[ユーザーセット] ページで、既定のオプション (すべてのユーザー) が選択されていることを確認して、[次へ] をクリックします。次に、[完了] をクリックして、設定を適用します。

ルールをダブルクリックし、[パス] タブを参照すると、/rpc/* というパスしか表示されません。これは、Exchange Server 2007 Outlook Anywhere ウィザードを使用したことによる現象です。

クライアントアクセスをテストおよび監視する

前述のとおり、TS ゲートウェイに接続するには、RDP 6.0 以降のクライアントが必要です。RDP クライアントアプリケーションを構成するには、これを起動して、接続先のターミナルサーバーの名前をコンピュータフィールドに入力します。[オプション] ボタンをクリックし、[詳細設定] タブの [設定] をクリックし、TS ゲートウェイサーバーの外部名を入力します (図 3 参照)。この記事の例では、これは、受信要求を受け付けるための Web 公開ルールで使用している Web リスナにバインドされている証明書に記載されている名前です。この例では、Windows NT® LAN Manager 認証が使用されています。この一連の操作が完了したら [OK] をクリックし、[接続] をクリックします。認証用のダイアログボックスが表示されたら、ターミナルサーバーへのアクセス権を持つユーザーの資格情報を入力し、[OK] をクリックします。

図 3 RDP クライアントの構成 (画像をクリックすると拡大表示されます)

RDP 6.0 クライアント (Windows XP と Windows Server 2003 の場合) では、図 3 の画面が表示されます。認証は 2 回求められます。1 回目は TS ゲートウェイコンピュータでの認証で、2 回目はアクセスするターミナルサーバーでの認証です。これは、重要なポイントです。2 回認証が行われるのは ISA Server の構成によるものだと思われるかもしれませんが、実際には、Web 公開ルールが "すべてのユーザー" に適用されているため、ISA Server では認証をまったく処理していません。これにより、ISA ファイアウォール経由の匿名接続を可能にしています。

Windows Server 2008 付属の RDP クライアントには、[リモートコンピュータに TS ゲートウェイの資格情報を使用する] というチェックボックスがあります (図 4 参照)。このチェックボックスをオンにすると、資格情報を 2 回入力する必要がなくなり、ユーザーの操作性が高まります。このシングルサインオンオプションは、SP1 を適用すると Windows Vista でも利用できます。

図 4 Windows Server 2008 の RDP クライアント (画像をクリックすると拡大表示されます)

接続は、TS ゲートウェイマネージャの監視オプションを使用して監視できます。また、TS ゲートウェイサービスでは、承認されていないユーザーがサーバーへの接続を試みた場合に詳細情報を提供します。図 5 は、TS ゲートウェイ経由で接続するアクセス許可のないユーザーによる接続試行イベントが表示されているイベントビューアの画面です。

図 5 TS ゲートウェイサービスに記録されたイベント (画像をクリックすると拡大表示されます)

このイベントでは、ISA Server 2006 の内部 IP アドレスが記録されています。これは、Web 公開ルールで [ISA Server コンピュータからの要求にする] が有効にされているためです。元のクライアント IP アドレスを記録する場合は、ISA Server 2006 Web 公開ルールを変更して、[公開先] タブで [元のクライアントからの要求にする] を選択する必要があります。

ISA Server から監視する

ISA Server 2006 Supportability Update の新機能を使用すると、内部ネットワークへの接続を詳細に監視して把握することができます。図 6 では 1 つの接続が選択されていて、この接続の Request: 行には HTTP プロキシを経由した RPC 用の URL を伴う RPC_IN_DATA 動詞が表示されています。

図 6 Supportability Update を使用した ISA Server 2006 のログ (画像をクリックすると拡大表示されます)

さらにログの内容を確認すると、もう 1 つの HTTP を経由した RPC 動詞、RPC_OUT_DATA があることを確認できます。ここでは RDP/HTTP 用の RPC_IN_DATA と RPC_OUT_DATA ですが、どの HTTP メソッドが使用されているかを把握しておくことが重要です。というのも、これらのメソッドをブロックするように HTTP フィルタが構成されている場合、ISA Server でトラフィックがブロックされてしまうからです。環境をロックダウンする場合は、これらの 2 つのメソッドのみを許可する RDP/HTTP Web 公開ルールを構成できます。通常公開に使用される HTTP メソッドの詳細については、「ISA Server 2004 の HTTP フィルタリング」(technet.microsoft.com/library/cc302627) を参照してください。

2 つ目のシナリオ

このシナリオでは、TS ゲートウェイは、別のサーバー上にある NPS セントラルポリシーを使用します。TS ゲートウェイ経由でリモートから接続するクライアントに、NAP ポリシーを強制します。このシナリオでは、NPS サーバーを追加する以外は、1 つ目のシナリオで使用したのと同じコンポーネントを再び使用します。ただし、NAP 強制により、クライアント側ではより多くのコンポーネントが使用されます (図 7 参照)。

図 7 シナリオ 2 のトポロジの主なコンポーネント (画像をクリックすると拡大表示されます)

個々のコンポーネントについて説明します。Windows Vista クライアントにインストールされているシステム正常性エージェント (SHA) は、クライアントの正常性の状態を監視し、レポートするクライアント側コンポーネントです。Windows Vista には Windows SHA が付属していますが、独自の SHA を開発している他のベンダもあります。

クライアントがネットワークへのアクセスを試行すると、クライアント側の NAP エージェントによって NAP 強制サーバーとの通信が確立されます。NAP エージェントは、クライアントの正常性ステートメント (SoH) を NAP サーバーに送信します。

TS ゲートウェイ上にある TS のリソース承認ポリシー (TS RAP) は、着信 RDP 要求の受信に利用できるコンピュータを特定するためのコンポーネントです。また、TS RAP では、どのユーザーがどのサーバーへの RDP 接続を確立できるかについても特定できます。

セントラル NPS サーバーは、内部コンピュータへのアクセスを規制する条件、制約、および設定を制御します。セントラル NPS サーバーにインストールされているシステム正常性検証ツール (SHV) では、クライアントが発行した SoH が、管理者によって設定されたポリシーに準拠しているかどうかを評価します。

では、セントラル NPS サーバーをポイントするように、TS ゲートウェイを変更しましょう。TS ゲートウェイマネージャコンソールを開き、サーバーの名前を右クリックし、[プロパティ] をクリックします。サーバーのプロパティウィンドウで、[TS CAP ストア] タブをクリックし、[セントラル NPS サーバー] を選択します。次に、NPS サーバーの名前または IP アドレスを入力し、[追加] をクリックします。[共有シークレット] ダイアログボックスが表示されます。シークレットを入力し、[OK] をクリックします。もう一度 [OK] をクリックして、ダイアログボックスを閉じます。このシークレットは NPS サーバーで使用されるので、覚えておく必要があります。

NPS が既に別のサーバー上にインストールされているという前提条件で実行する必要がある手順を次に示します。

ネットワークポリシーサーバーコンソールを開き、左側のウィンドウで [NPS (ローカル)] をクリックします。
右側のウィンドウで、[NAP を構成する] をクリックします。[NAP で使用するネットワーク接続方法の選択] ページが表示されます。
[ネットワーク接続の方法] ボックスの一覧の [ターミナルサービスゲートウェイ (TS ゲートウェイ)] をクリックし、[次へ] をクリックします。
[Specify NAP Enforcement Servers Running TS Gateway] (TS ゲートウェイを実行する NAP 強制サーバーの指定) ページで [追加] ボタンをクリックします。
[New TS Gateway] (新しい TS ゲートウェイ) ウィンドウで、TS ゲートウェイサーバーのフレンドリ名と IP アドレスを入力します。このウィンドウの下部に共通シークレットを入力します。これには、TS ゲートウェイサーバーの構成に使用したのと同じシークレットを使用します。[OK] をクリックします。
[クライアントデバイスのリダイレクトと認証方法の構成] ページでは、リダイレクトされるデバイスとすべての許可される認証方法 (パスワードまたはスマートカード) を指定できます。この例では、既定のオプションを使用し、[次へ] をクリックします。
[ユーザーグループとコンピュータグループの構成] ページで、接続の確立を許可するユーザーグループを追加します。この例では、[ユーザーグループ: (必須)] の [ユーザーの追加] をクリックし、[Domain Admins] を選択します。[OK] をクリックして、[次へ] をクリックします。
[NAP 正常性ポリシーの定義] ページでは、既定の SHV が既に選択されています。また、このページの下部では、非準拠のコンピュータのアクセスが拒否されることを確認できます。既定のオプションを使用して、[次へ] をクリックします。
[NAP 強制ポリシーおよび RADIUS クライアント構成の完了] ページで、これまでに選択したオプションの内容を確認します。ハイパーリンクをクリックすると、[NAP 強制ポリシーおよび RADIUS クライアント構成の完了] ページが表示され、選択した項目についての概要を確認できます。処理が完了したら、[完了] をクリックします。

このウィザードを使用すると、さまざまな重要なポリシー (接続要求ポリシー、ネットワークポリシー、および正常性ポリシー) の設定を構成できるので、このシナリオの NAP の構成に必要な作業を大幅に軽減できます。

クライアントについて

サーバーのセットアップと構成は完了しましたが、最後にクライアント側で必要な作業について説明しましょう。

NAP 強制ポリシーを利用するには、クライアントでは Windows Server 2008 または Windows Vista が実行されている必要があります。Windows XP の場合は、NAP クライアントが含まれる SP3 をインストールしておく必要があります。

オペレーティングシステムの要件以外に、クライアント側で有効にする必要がある関連サービスと設定がいくつかあります。これは、次のとおりです。

TS ゲートウェイサーバーの名前を信頼済みサーバーの一覧に追加します。
NAP エージェントサービスを開始し、サービスのスタートアップの種類を [自動] に設定します。
TS ゲートウェイ検疫強制クライアントを有効にします。

このソリューションを容易に展開できるよう、マイクロソフトではターミナルサービス NAP クライアント構成コマンド (Tsgqecclientconfig.cmd) を作成しました。これは、go.microsoft.com/fwlink/?LinkId=122267 からダウンロードできます。このコマンドを実行すると、クライアントは TS ゲートウェイ用の NAP 強制クライアントとして構成されます。このコマンドはシステム特権を使用して実行する必要があることに注意してください。

この記事では、Windows Server 2008 が提供する新しい TS ゲートウェイ機能について説明し、TS ゲートウェイを ISA Server 2006 経由で安全に公開する方法を紹介しました。また、この 2 つの製品を連携して使用することで得られるセキュリティ上のメリットの概要についても説明しました。

現在の世の中では、どこからでも接続できることが、ほとんどすべての成功するビジネスにとっての重要な要件の 1 つになっています。ただし、このような接続を実現するために、優れたユーザーエクスペリエンスが犠牲にならないようにする必要もあります。また、さらに重要なことですが、これはセキュリティを確保した状態で実現される必要があります。

Dr. Thomas W. Shinder は、MCSE および ISA Server MVP 資格保持者です。1996 年以来、テクノロジ関連の教育者、ライター、およびコンサルタントとして活躍しており、ISA ファイアウォールについての書籍を 6 冊執筆しています。また、ISA ファイアウォールの管理者と愛好者のインターネット上の最大のコミュニティである ISAserver.org の思想的指導者であり、中心的な運営者でもあります。

Yuri Diogenes は、MCSE+S、MCTS、MCITP、Security+、Network+、および CCNP 資格保持者であり、Microsoft ISA Server/IAG チームのセキュリティサポートエンジニアです。Microsoft TechNet ライブラリと ISA Server チームのブログの記事を執筆しており、1993 年以来、マイクロソフトテクノロジに携わっています。マイクロソフトに入社する以前は、マイクロソフトトレーナー、サポートアナリスト、およびコンサルタントとして働いていました。

目次

その他のリソース