次の方法で共有

Microsoft Forefront

  • [アーティクル]

Microsoft Forefront TMG 2010 をセキュリティで保護された Web ゲートウェイとして使用する

Yuri Diogenes、Jim Harrison、Mohit Saxena

企業でセキュリティ ポリシーを策定する際の主要目的は、従業員が、より安全にインターネットを閲覧できるようにすることです。当然、非常に広い範囲の要素を網羅して、多くの要件に対応する必要があります。たとえば、次のようなものがあります。

  • ユーザーがインターネット アクセスに関して企業が定める方針に従うようにする
  • トラフィックを検査して、マルウェアの可能性があるものや怪しいと思われる活動をブロックする
  • エンド ユーザーに Web トラフィックが検疫されたことを通知する

さいわい、この目的は、Microsoft Forefront Threat Management Gateway (TMG) 2010 のセキュリティで保護された Web ゲートウェイの機能を活用して達成できます。図 1 に、セキュリティで保護された Web アクセス ゲートウェイの実装に使用できる Forefront TMG 2010 の主要機能を示します。

 

 

図 1 セキュリティで保護された Web ゲートウェイのシナリオを実現する Forefront TMG 2010 の主要機能

ご覧のとおり、Forefront TMG では、Microsoft Update、遠隔測定、および Microsoft Reputation Service (MRS) という 3 つのクラウド コンポーネントを使用しています。Microsoft Update では、マルウェア対策ソフトウェアとネットワーク検査システム (NIS) の署名を最新の状態に保ちます。マイクロソフトのマルウェア対策チームでは、TMG の遠隔測定レポートを使用して、仕掛けられた攻撃を分析し、署名の品質向上に役立てています。MRS では、Forefront TMG 2010 がクエリできる、カテゴリ別に分類された URL の大規模なデータベースを保持しています。

このコラムでは、URL フィルターと HTTPS 検査を重点的に取り上げます。マルウェア検査については、TechNet Magazine 2009 年 2 月号のコラムで取り上げましたが、この機能は Forefront TMG 2010 でも変更はありません。

安全なインターネット閲覧を実現するために URL フィルターを使用する

URL フィルターは、企業の Web アクセスをセキュリティで保護するための、Forefront TMG の防御の最前線と言えます。URL フィルターを使用して望ましくない Web サイトへの要求をブロックすることで、Forefront TMG では、マルウェアをスキャンする時間を削減し、有益なコンテンツを提供するために、より多くの時間をかけられるようになります。

URL フィルターの主要構成要素は、Web プロキシ フィルターと MRS です。Web プロキシ フィルターでは、Web 要求を評価します。MRS では、要求を分類する際に URL フィルターで使用するカテゴリの定義を提供します。Web 要求が行われたときに発生するプロセスの概要は、次のとおりです。

  1. Web アプリケーションが TMG 経由で http://malware.contoso.com/nefarious の要求を送信します。

  2. Web プロキシ フィルターが、URL フィルター経由で要求を渡します。

  3. URL フィルターが、要求を複数の部分に分割します。たとえば、次のように分割することが考えられます。

    • com
    • contoso.com
    • malware.contoso.com
    • malware.contoso.com/nefarious

  4. URL フィルターは、ローカル キャッシュの URL カテゴリに各部分が存在するかどうかを調べます。

    注: 要求がローカル キャッシュにある URL カテゴリと一致しない場合、URL フィルターでは MRS をクエリします。MRS から "不明" という結果が返されるか、MRS にアクセスできない場合、URL フィルターでは Web プロキシ フィルターに "不明" という応答を返します。

  5. URL の各部分と関連付けられているカテゴリを特定したら、URL フィルターは、URL 全体に適用されるカテゴリを特定します。TMG では、URL 全体に適用されるカテゴリを特定する際に、MRS で提供される定義済みの優先順位リストを使用します。このリストにより、TMG は、カテゴリの優先順位を把握できます。たとえば、次のような結果が返されたとします。

    • com = Unknown (不明)
    • contoso.com = General Business (一般ビジネス)
    • malware.contoso.com = Malicious (有害)
    • malware.contoso.com/nefarious = Unknown (不明) この例では、General Business (一般ビジネス) および Malicious (有害) という 2 種類のカテゴリが検出されました。定義済みの優先順位リストによると、Malicious (有害) は General Business (一般ビジネス) よりも優先順位が高いので、URL 全体のカテゴリは Malicious (有害) と判断されます。

  6. URL 全体のカテゴリが拒否ルールに一致する場合、要求は拒否され、Web アプリケーションにはエラーが返されます。

  7. URL 全体のカテゴリが拒否ルールに一致せず、許可ルールに一致する場合、要求は一致した許可ルールの条件に従って処理されます。

  8. URL 全体のカテゴリがユーザーが作成した拒否ルールと許可ルールのいずれにも一致しない場合、要求は既定の拒否ルールで処理され、Web アプリケーションには拒否の応答が返されます。

統計上、ユーザーには Web の使用について習慣的な行動が見られるので、Forefront TMG でユーザーからの要求を処理するにつれて、URL カテゴリのキャッシュは企業に適切な状態になります。そのため、MRS にユーザーの要求がクエリされる頻度は低下します。URL カテゴリは変更される可能性があるため、MRS では、各エントリに有効期限を割り当てています。そのため、ユーザーが、いつも同じサイトにアクセスする場合でも、MRS にクエリする要求の数が完全になくなることはありません。

URL フィルターのしくみを十分に理解するには、Web アプリケーションが接続を確立する方法と要求を発行する方法についても理解する必要があります。通常、Web アプリケーションは、Web プロキシ クライアントとして動作するものと、そうでないものの 2 種類に分類できます。

  • Web (CERN) プロキシ: この種類の Web アプリケーションは、Web プロキシを認識して、適切に動作するように構成されています。Web アプリケーションは、Web プロキシ リスナーに接続し、特定の形式で要求を発行します。

HTTP の場合

METHOD http://website.contoso.com/path/page.aspx?querystring HTTP/1.x
METHOD http://1.2.3.4/path/page.aspx?querystring HTTP/1.x

この場合、Forefront TMG (つまり、URL フィルター) では、URL フィルターのデータベースと比較するのに使用できる完全な URL を保持しています。

注: METHOD の部分には、GET、POST など、任意の有効な HTTP メソッドを指定します。

HTTPS の場合

CONNECT website.contoso.com:443 HTTP/1.x
CONNECT 1.2.3.4:666 HTTP/1.x

HTTPS 要求の場合、Forefront TMG と URL フィルターでは、URL フィルターのデータベースとの比較に使用できる情報として、ホスト名または IP アドレス (クライアント側で要求が発行された方法によって異なります) とポートしか保持していません。

  • Web プロキシ以外: Web アプリケーションが CERN プロキシ クライアントとして動作するように構成されていない場合、アプリケーションでは Web サイトの名前を IP アドレスに解決しようとします。IP アドレスに解決できた場合は、元の URL に含まれていたポートを使用して、その IP アドレスに接続します。クライアントが TMG クライアント (旧称、ファイアウォール クライアント) または SecureNET クライアント (別称、SecureNAT クライアント) のどちらでも、要求は次の形式で送信されます。
METHOD /path/page.aspx?querystring HTTP/1.x

この場合、URL フィルターで要求を評価できるかどうかは、次の 2 つの条件にかかっています。

  • 接続で既定の HTTP ポートを使用しているか。既定のポートを使用している場合、Web プロキシでは、この要求を傍受して、URL フィルターに渡して比較できます。既定のポートを使用していない場合、要求は URL フィルターで認識されないのでデータベースと比較できません。
  • 接続で既定の HTTPS ポートを使用している場合は、HTTPS 検査が有効になっているか。有効になっている場合は、HTTPS 検査で接続がブリッジされるので、URL フィルターでは要求をデータベースと比較できます。

わかりづらいかもしれませんが、URL フィルター自体に、ブロック メカニズムはありません。Web プロキシでカテゴリが認識される (結果的には、URL フィルターでも認識される) ので、URL フィルターでは、要求された URL と関連付けられているカテゴリを使用して Web プロキシに応答しているだけです。どの場合も、URL フィルターでは、クライアント要求を受信すると、図 2 のように動作します。

 

図 2 URL フィルターの基本的な処理の流れ

Forefront TMG で MRS をクエリする必要がある場合、要求は、MRS Web サービス ポータルに対する 1 回の Web サービス呼び出しによって行われます。MRS では、Forefront TMG から提示されたデータを処理し、MRS が受け取ったデータに適用される現在の URL のカテゴリを返します。Forefront TMG 2010 では、Forefront TMG のリリース時に有効であったポータルを含むドメイン セットが定義されています (図 3 参照)。

 

図 3 MRS のドメイン セット

URL フィルターから返された URL のカテゴリが拒否ルールに含まれている場合、Forefront TMG では、クライアントに拒否の応答 (HTTP 結果コード 502) を返します。クライアントがブラウザーと他の Web アプリケーションのどちらであるかによって、ユーザーに表示される情報が異なります。ブラウザーの場合は、Forefront TMG の応答ページが表示されます。ブラウザー以外のアプリケーション (Windows Media Player、CERN プロキシ FTP アプリケーションなど) の場合、ユーザーには、アプリケーションから返されるエラー メッセージだけが表示されます。

URL のカテゴリを特定するために Forefront TMG で実行する必要がある最もコストのかかるタスクは、MRS のクエリですが、この処理は、ユーザーが Web サイトにアクセスすることを許可して、ユーザーが要求する全コンテンツについてマルウェア スキャンを実行することと比べると、CPU、メモリ、およびネットワーク リソースのコストはかかりません。

HTTPS 検査を使用して暗号化チャネルを制御する

長年にわたって、ユーザーは、セキュリティで保護されたオンライン トランザクションを実行するように教えられてきたので、SSL を使用した HTTP (HTTPS) を利用する必要があると考えています。ただし、このセキュリティで保護されたチャネルは、悪意のある目的にも使用されてきました。HTTPS を使用してユーザーがトランザクションを開始すると、通常、このトラフィックはエンド ツー エンドで (ユーザーから接続先のサーバーまで) 暗号化されるので、やり取りするコンテンツが、その間に配置されているデバイスで読み取れなくなります。第三者にクレジット カードのオンライン トランザクションを見られるのは好ましくないので、これは望ましい動作ですが、このようなチャネルで行われた悪意のある操作を評価できないという欠点もあります。図 4 に、ISA Server 2006 をファイアウォールとして使用した場合の、この操作の概要を例示します。

 

図 4 従来の HTTPS シナリオ

図 4 は、クライアントが HTTPS サイトにアクセスしている完全なプロキシのシナリオです。このシナリオで実行される操作は、次の 2 つのフェーズにわけることができます。

フレーズ 1 – SSL トンネル

  1. クライアントが Web プロキシに接続します。
  2. クライアントが CONNECT malicious.contoso.com:443 HTTP/1.1 という SSL トンネルの要求を発行します。
  3. Web プロキシが malicious.contoso.com を 1.2.3.4 という IP アドレスに解決します。
  4. Web プロキシが TCP ポート 443 で 1.2.3.4 に接続します。
  5. Web プロキシがクライアントに "200 OK" という応答を返します。

フェーズ 2 – 暗号化通信

  1. クライアントと Web サーバー間で、SSL ハンドシェイク メッセージ、暗号化キー、および証明書を交換します。
  2. クライアントは、接続先サーバーとの間で暗号化されたエンド ツー エンドのトンネルを確立し、このトンネルを使用して送受信トラフィックを開始します。
  3. ISA Server では、クライアントとサーバー間で確立されたトンネルを開いた状態で維持しますが、検査機能がないので、このトラフィックを検査することはありません。

このシナリオの潜在的なリスクは、フェーズ 2 で、エッジ ファイアウォールが、このチャネルで転送されているコンテンツを一切把握していないことです。接続先のサーバーが乗っ取られて、悪意のあるコードが配置された場合、接続先のサーバーが、この暗号化チャネルを使用してマルウェアを送信し、(信頼できる接続で提供されているものなので) クライアントが躊躇することなくマルウェアを受け取るという潜在的なリスクがあります。

Forefront TMG の HTTPS 検査では、トラフィックを検査し、ユーザー側とサーバー側で個別の暗号化チャネルを維持することで、この脅威を軽減します。図 5 に、Forefront TMG で、この処理を実現するしくみを示します。

 

図 5 HTTPS 検査のしくみ

このシナリオでも実行される操作は、2 つのフェーズにわけることができますが、今回は検査が含まれます。

フェーズ 1 – クライアント要求

  1. クライアントが TMG Web プロキシ リスナーに接続します。
  2. クライアントが CONNECT malicious.contoso.com:443 HTTP/1.1 という SSL トンネルの要求を発行します。
  3. TMG が malicious.contoso.com を 1.2.3.4 という IP アドレスに解決します。
  4. TMG が TCP ポート 443 で 1.2.3.4 に接続します。
  5. TMG がサーバーと SSL 接続をネゴシエートして、証明書を評価します。
  6. 証明書が有効で信頼できる場合、TMG は、クライアントに "200 OK" という応答を返します。

フェーズ 2 – 暗号化通信と検査

  1. クライアントと TMG 間で、SSL ハンドシェイク メッセージ、暗号化キー、および証明書を交換します。TMG では、Web サーバーの証明書の情報を使用してサーバー証明書を作成するので、クライアントでは、Web サーバーと通信していると見なされます。

  2. クライアントは、Forefront TMG との間で暗号化トンネルを確立し、Forefront TMG では、接続先サーバーとの間で暗号化トンネルを確立します。Forefront TMG では、次の順序で、クライアントとサーバー間で送受信された、すべてのトラフィックを検査できます。

    a)     TMG は、接続先サーバーからの暗号化トラフィックを受信して暗号を解読します。

    b)     TMG は、マルウェア検査と NIS フィルターをトラフィックに適用します。

    c)      マルウェア検査と NIS フィルターでトラフィックが許可されると、TMG は、結果を暗号化して、クライアント ワークステーションに送信します。

    d)     クライアントは、トラフィックを受信して暗号を解読し、トラフィックを処理します。

クライアントとの間で SSL ハンドシェイクを確立するには、Forefront TMG 側でサーバー証明書が必要です。サーバー証明書を作成するために、Forefront TMG では、元のサーバー証明書のデータに基づいて偽装した証明書を作成し、HTTPS 検査の CA 証明書で署名します。Forefront TMG では、最大限のパフォーマンスを確保するために複製したサーバー証明書のキャッシュを維持します。TMG は、ローカル キャッシュに複製したサーバー証明書があるかどうかを検索し、証明書が見つからない場合は、上位サーバーの証明書の複製を作成して、キャッシュに格納します。キャッシュはメモリ内でのみ保持されます。そのため、偽装した証明書のキャッシュは、ファイアウォール サービスの再開後には空になります。

注: キャッシュのサイズ (証明書の数) は、COM の LowLevelSettings.ClonedCertificatesCacheSize プロパティで制御しています。

HTTPS 検査のオプション

HTTPS 検査を構成する前に、この機能を構成する一連の機能とオプションを理解することが重要です。図 6 に、HTTPS 検査を構成できる場所を示します。

 

図 6 HTTPS 検査の機能セット

HTTPS 検査の実装を計画する際には、まず、証明書の設定を検討し、自己署名の証明書と内部の CA で発行された証明書のどちらを使用するのかを決める必要があります。既存の信頼された証明機関から証明書をインポートする際には、証明機関の証明書と秘密キーを含む PFX ファイルが必要です。この秘密キーは、TMG が発行する偽装した証明書の署名に必要です。また、証明書のキーの用途が、証明書の署名に設定されるようにする必要があります。この CA 証明書は、クライアント コンピューターに展開する必要があります (ローカル コンピューターの証明書ストアの "信頼されたルートの証明機関" に展開します)。展開しないと、クライアントでは、TMG から受信したサーバー証明書が信頼されません。

Forefront TMG では、Web Access Policy (Web アクセス ポリシー) を使用して、HTTPS 検査を有効にできます。この機能を有効にするには、次の手順を実行します。

  1. Forefront TMG のコンソールで、[Web Access Policy] (Web アクセス ポリシー) をクリックし、[Tasks] (タスク) の [Web Protection Task] (Web 保護タスク) で [Configure HTTPS Inspection] (HTTPS 検査を構成する) を選択します。
  2. [HTTPS Outbound Inspection] (HTTPS 発信検査) ダイアログ ボックスの [Enable HTTPS inspection] (HTTPS 検査を有効にする) チェック ボックスをオンにします (図 7 参照)。

 

図 7 HTTPS 検査を有効にする

この例では、Forefront TMG の自己署名証明書を使用します。[Generate] (生成) をクリックすると、図 8 のようなダイアログ ボックスが表示されます。

 

図 8 [Generate Certificate] (証明書の生成) ダイアログ ボックス

  1. [Generate Certificate] (証明書の生成) ダイアログ ボックスで、発行者名、有効期限、発行者のステートメントを企業のニーズに応じて入力し、[Generate Certificate Now] (今すぐ証明書を発行) をクリックします。
  2. 新しい証明書が生成され、[Certificate] (証明書) ダイアログ ボックスが表示されます。証明書の構成を確認して、[Close] (閉じる) をクリックします。
  3. [OK] をクリックして、ダイアログ ボックスを閉じます。
  4. [HTTPS Outbound Inspection] (HTTPS 発信検査) ダイアログ ボックスの [HTTPS Inspection Trusted Root CA Certificate Options] (HTTPS 検査の信頼済みルート CA 証明書のオプション) ボタンをクリックします。[Certificate Deployment Options] (証明書の展開オプション) ダイアログ ボックスが表示されます (図 9 参照)。

 

図 9 証明書の展開方法を選択する

  1. TMG がドメインに参加している場合、推奨の展開方法は "Automatically through Active Directory" (Active Directory 経由で自動的に展開する) です。このオプションを選択すると、TMG の CA 証明書は、グループ ポリシーを使用して、クライアント コンピューターに自動で展開されます。[Domain Administrator Credentials] (ドメイン管理者の資格情報) ボタンをクリックし、この操作に使用する資格情報を入力します。[OK] をクリックします。ユーザー名のフィールドには、ドメイン名を含めないようにする必要があります。
  2. Forefront TMG では、TMG の CA 証明書を Active Directory に公開するのに certutil ツールを使用しているので、コマンド プロンプト ウィンドウが一瞬表示される場合があります。証明書の自動展開が正常に完了したことを知らせるメッセージ ボックスで [OK] をクリックし、[Certificate Deployment Options] (証明書の展開オプション) ダイアログ ボックスの [OK] をクリックします。
  3. [OK] をクリックして、作業を完了します。

重要: 企業のセキュリティ ポリシーを満たすだけでなく、HTTPS 検査を有効にする前には、法令順守についても評価する必要があります。HTTPS 検査に適していないと思われるサイトについては、例外リストに追加できます。

強化されたユーザー エクスペリエンス

Forefront TMG の HTTPS 検査と URL フィルターは、エンド ユーザーにセキュリティで保護されたインターネット環境を提供するのに役立つだけでなくだけでなく、エンド ユーザーにわかりやすい独自のエラー メッセージや具体的なエラー メッセージを提供して、エンド ユーザー エクスペリエンスを強化する機能も用意されています。

HTTPS クライアント通知

企業のプライバシー ポリシーに準拠するには、クライアント側の通知を有効にできます。この通知では、SSL サイトが検疫されたときにユーザーに通知を表示して、ユーザーの個人情報や機密情報を保護するために、そのサイトにアクセスしないことを選択するオプションを提示します。図 10 に、この動作の例を示します。

 

図 10 HTTPS 検査のクライアント側で行われる通知

ユーザーが HTTPS 検査の通知を受け取るには、クライアント コンピューターに Forefront TMG Client がインストールされ、ローカル コンピューターの "信頼されたルートの証明機関" 証明書ストアに HTTPS 検査の信頼されたルート証明機関の証明書がインストールされている必要があります。TMG で上位サーバーと下位サーバーを構成している場合、HTTPS 検査の通知は、上位プロキシではなく、下位プロキシで有効にする必要があることに注意してください。

HTTPS 検査のクライアント側の通知を実装するには、Forefront TMG サーバーとクライアントの両方で、この機能を有効にする必要があります。サーバー側で HTTPS 検査の通知を有効にするには、次の手順を実行します。

  1. Forefront TMG の管理コンソールで [Web Access Policy] (Web アクセス ポリシー) をクリックします。
  2. 右ウィンドウの [Tasks] (タスク) で [Configure HTTPS Inspection] (HTTPS 検査を構成する) をクリックします。
  3. [Client Notification] (クライアント通知) タブの [Notify users that HTTPS content is being inspected] (HTTPS コンテンツが検疫されたことをユーザーに通知する) をクリックし、[OK] をクリックします。

Forefront TMG Client で HTTPS 検査の通知を有効にするには、次の手順を実行します。

  1. システム トレイの [TMG Client] アイコンを右クリックし、[Configure] (構成) をクリックします。
  2. [Secure Connection Inspection] (セキュリティで保護された接続の検査) タブの [Notify me when content sent to secure Web sites is inspected] (セキュリティで保護された Web サイトに送信したコンテンツが検疫されたときに通知する) をクリックし、[OK] をクリックします。

URL フィルターのエラー メッセージ

管理者は、URL のカテゴリに基づいて、エンド ユーザーが Web サイトにアクセスすることを許可または拒否できます。アクセスが拒否されているサイトにユーザーがアクセスすると、図 11 のようなエラー ページが表示されます。このエラー ページには、Forefront TMG の管理者によって、サイトが悪意のあるサイトとして分類されているためにアクセスが拒否されたことを示すメッセージが表示されます。

 

図 11 アクセスが拒否された Web ページ

Forefront TMG の管理者は、このエラー メッセージをカスタマイズできます。エラー メッセージをカスタマイズするには、次の手順を実行します。

  1. Forefront TMG の管理コンソールを起動して、[Web Access Policy] (Web アクセス ポリシー) をクリックします。
  2. アクセスを許可または拒否するために管理者が作成したルールをダブルクリックして表示します。
  3. [Action] (操作) タブをクリックします (図 12 参照)。

 

図 12 URL フィルターのエラー メッセージをカスタマイズする

[Display denial notification to user] (拒否の通知をユーザーに表示する) ボックスには任意のカスタム メッセージを追加できます。HTML コンテンツを使用することは可能ですが、スクリプトは含められません (ただし、HTML は HTML の <body> 要素で有効なコンテンツでなければなりません)。

サイトへのアクセスが拒否された原因となったカテゴリを表示することもできます。カテゴリを表示するには、[Add denied request category to notification] (通知に拒否された要求のカテゴリを追加する) チェック ボックスをオンにします。この情報は、サイトが適切に分類されていない場合に、ユーザーが管理者に通知できると言う点で便利です。このような場合には、遠隔測定レポートを使用してマイクロソフトにフィードバックとして情報を提供し、このカテゴリの問題が修正されるまで、優先カテゴリを設定して、サイトが適切に分類されるようにすることが可能です。

URL フィルターのエラー メッセージのページの外観を変更する場合は、12232.htm ページを編集する必要があります。エラー メッセージ ページの外観を変更する方法の詳細については、Forefront TMG (ISA Server) 製品チーム ブログの「Deny Page Customization on Forefront TMG 2010 (Forefront TMG 2010 でアクセス拒否のページをカスタマイズする、英語)」を参照してください。

Jim Harrison は、2003 年 1 月に QFE テスターとして ISA Server Sustained Engineering チームに加わりました。 現在は、Forefront Edge CS のプログラム マネージャーですが、ISA Server の熱狂的なファンであり、システムの実装を担当しています。また、“Tales from the Edge” と呼ばれる Forefront コミュニティ ページの共同執筆者の 1 人でもあります。

Yuri Diogenes は、マイクロソフトの ISA Server/IAG チームでシニア セキュリティ サポート エスカレーション エンジニアとして働いています。彼は、"Tales from the Edge" と呼ばれる Forefront コミュニティ ページの共同執筆者の 1 人です。

Mohit Saxena は、Microsoft ISA Server サポート チームのテクニカル リードです。このチームは、故障の修理に関する問題、バグ、デザイン変更の要求に関するサポートをユーザーに提供しているサポート エンジニアとエスカレーション エンジニアで構成されています。

関連コンテンツ