Microsoftdownload.microsoft.com/.../AccessControlPlanning.docx · Web...

Forefront Unified Access Gateway 2010

公開のアクセス制御設計ガイド

Microsoft® Corporation

発行: 2010 年 1 月

このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更することがあります。特に記載のある場合を除き、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する会社、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人物、場所、出来事などとは一切関係ありません。お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の知的財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の知的財産権に関する権利をお客様に許諾するものではありません。

© 2009 Microsoft Corporation.All rights reserved.

Microsoft 、 MS-DOS 、 Windows 、 Windows Server 、および Active Directory は、 Microsoft Corporation の商標です。その他、記載されている会社名、製品名には、各社の商標のものもあります。

目次

公開のアクセス制御設計ガイド.....................................................................................................5このガイドについて................................................................................................................... 5

エンドポイントアクセスの設計の概要.........................................................................................5

エンドポイントアクセスの展開目標の確認..................................................................................6

展開目標とエンドポイントアクセス設計とのマッピング............................................................7

クライアント認証の計画................................................................................................................8HTTPS を利用するクライアントエンドポイントアクセス.....................................................8セッション認証について............................................................................................................9

フロンドエンド認証の計画............................................................................................................9

LDAP 認証.................................................................................................................................... 10LDAP の認証フロー..................................................................................................................10

LDAP クライアント証明書の認証................................................................................................11LDAP クライアント証明書の認証フロー..................................................................................12

RADIUS 認証................................................................................................................................ 13秘密キー.................................................................................................................................... 13チャレンジ/レスポンスモード.................................................................................................13RADIUS グループ..................................................................................................................... 13RADIUS の認証フロー..............................................................................................................13

RSA SecurID 認証........................................................................................................................ 14Next Token モード..................................................................................................................... 15New PIN モード........................................................................................................................15RSA SecurID の認証フロー.......................................................................................................15

TACACS 認証............................................................................................................................... 16TACACS の認証フロー.............................................................................................................17

WINHTTP 認証............................................................................................................................. 18WINHTTP の認証フロー...........................................................................................................18

公開サーバーに対するバックエンド認証の計画..........................................................................19

基本、NTLM、または HTTP フォームベースの認証..................................................................19

Kerberos の制約付き委任.............................................................................................................19

システム要件............................................................................................................................. 20

AD FS を使用したフェデレーションの計画................................................................................20サポートされるシナリオ..........................................................................................................21AD FS の前提条件.....................................................................................................................21

エンドポイントの正常性チェックの計画....................................................................................21組み込みのアクセスポリシー..................................................................................................22NAP のアクセスポリシー........................................................................................................23

エンドポイントアクセスポリシーの実施計画...........................................................................23エンドポイントポリシーの使用..............................................................................................23セッションエンドポイントポリシー......................................................................................24アプリケーションエンドポイントポリシー...........................................................................25エンドポイントの検出..............................................................................................................25

クライアントエンドポイントから収集される情報..............................................................26

ポータルアプリケーション承認の計画.......................................................................................26

公開のアクセス制御設計ガイドForefront Unified Access Gateway (UAG) は、リモート従業員、モバイルワーカー、パートナー、およびその他の第三者に、企業のアプリケーションやリソースにアクセスするためのゲートウェイを提供します。ゲートウェイを経由して公開されたアプリケーションをセキュリティで保護するために、Forefront UAG では、アプリケーションへのアクセスを許可するユーザーや、それらのユーザーを Forefront UAG およびアプリケーションに対して認証する方法を定義できます。Forefront UAG を使用すると、さまざまな認証サーバーを使用してポータルに対するユーザー認証を実行できます。

このガイドについてこのガイドは、Forefront UAG を認証サーバーと共に使用して、ポータルを利用しようとするエンドユーザーを特定および事前認証する方法、および公開されたアプリケーションに対するエンドユーザーの認証方法の理解を深めることを目的としています。

このガイドの対象読者は、エンドユーザーが適正に Forefront UAG ポータルおよび公開されたアプリケーションの認証を受けられるように保証する責任を負うシステム管理者です。

このガイドの使用目的:

エンドポイントアクセスおよび ID の概念の理解。詳細については、「エンドポイントアクセスの設計の概要」を参照してください。

エンドポイントアクセスおよび ID 展開の目標の確認。詳細については、「エンドポイントアクセスの展開目標の確認」を参照してください。

展開目標とエンドポイントアクセスおよび ID 設計とのマッピング。詳細については、「展開目標とエンドポイントアクセス設計とのマッピング」を参照してください。

展開方針の計画の開始。詳細については、エンドポイントアクセスの設計計画に関する記述を参照してください。

エンドポイントアクセスの設計の概要Forefront Unified Access Gateway (UAG) を使用すると、リモート従業員、モバイルワーカー、パートナー、およびその他の第三者に、企業のアプリケーションやリソースへのリモートアクセスを提供できます。ただし、企業ネットワーク上にあるアプリケーションやリソースへのリモートアクセスを提供することで、セキュリティ違反が生じる可能性があります。 Forefront UAG では、エンドポイントの正常性ポリシー、認証サーバー、およびアプリケーションアクセスの承認を組み合わせて使用することによって、アプリケーションやリソースへのアクセスを許可するユーザーおよびエンドポイントのみにセキュリティで保護されたリモートアクセスを提供できます。

正常性ポリシー - Forefront UAG には、エンドポイントのシステム設定および機能をチェックすることによって、エンドポイントデバイスの正常性をチェックする組み込みのポリシーが用意されています。必要に応じて、特定の設定や機能をチェックするように、それぞれのポリシーを編集できます。また、独自のポリシーを定義することもできます。エンドポイントデバイスの正常性をチェックする場合は、さまざまなエンドポイントデバイスを使用し、さまざまなアプリケーションへのアクセスを必要とするエンドユーザーの多様性を考慮して、厳密なポリシーを使用するか、より寛容なポリシーを使用するかについて適切なバランスを探る必要があります。

認証サーバー - Forefront UAG ポータルおよびアプリケーションセッションにアクセスする際、ユーザーの認証を要求できます。Forefront UAG では、あらかじめ定義されたさまざまな認証スキームがサポートされています。また、カスタムスキームを作成することもできます。認証を構成するには、ユーザー資格情報の検証時に照合する認証サーバーを設定する必要があります。

ユーザーの承認 - ユーザー認証に加えて、ポータルで公開する個別のアプリケーションの承認設定を構成できます。承認に使用するユーザーおよびグループのサーバーで定義したユーザーとグループに基づいて、個別のアプリケーションにアクセスできるユーザーおよびグループを指定します。認証に使用するサーバーでユーザーおよびグループを構成することも、ある種類の認証サーバーに対する認証とユーザーおよびグループの承認とを別の認証スキームにまとめることもできます。

エンドポイントアクセスの展開目標の確認Forefront Unified Access Gateway (UAG) を適切に展開するには、エンドポイントアクセスの展開目標を正しく確認しておく必要があります。ここでは、エンドポイントアクセスの展開目標の確認に役立つ情報を提供します。これらの目標を確認することによって、目標の達成に必要なエンドポイントアクセスの設計要件を明確に正しく特定できます。組織の規模によっては、インフラストラクチャの専門家やシステムアーキテクト以外の IT スタッフが必要になる場合もあります。エンドポイントアクセスの設計に関連する既存、実証済み、および事前定義済み

のエンドポイントアクセスの展開目標を利用することも、使用するエンドポイントアクセスシナリオに応じて必要なソリューションを開発することもできます。

ここでは、次のあらかじめ定義されている目標について説明します。

従業員に対するリモートアクセスの提供 — Forefront UAG 使用の主要目標は、内部ネットワークに存在するアプリケーションおよびリソースへのリモートアクセスをセキュリティを保護して組織内の従業員に提供することです。この目標の達成には、ポータルにアクセスするエンドユーザーの認証スキーム、公開されたアプリケーションおよびリソースに接続するエンドユーザーの認証スキーム、シングルサインオン (SSO) (必要な場合)、およびエンドポイントの正常性を確認するアクセスポリシーを計画する必要があります。

この目標については次の 2 つのシナリオを使用できます。その 1 つは管理下にあるデバイスへのアクセスの提供で、もう 1 つは管理外のデバイスに対するアクセスの提供です。

管理下にあるデバイスを使用する従業員にアクセスを提供する場合は、組織内に既存の認証スキームを使用できます。認証スキームでは、スマートカード、トークン、又は証明書を使用できます。エンドポイントの正常性を判定する際は、実行する正常性チェック、つまりアクセスポリシーを使用してチェックする設定と機能によって、エンドポイントが管理下にあるか、管理外であるかを正確に識別できることを保証しなければなりません。

管理されていないデバイスを使用して従業員にアクセスを提供する場合は、内部アプリケーションおよびリソースにアクセスしようとする従業員を正しく特定できることを保証する必要があります。このシナリオで従業員を認証するには、基本レベルの認証を使用して、最小レベルのアクセスを提供します。従業員が制限のある情報にアクセスしようとする場合は、追加の資格情報の提供を要求できます。デバイスの設定および機能を管理できず、デバイスで実行される正常性チェックの徹底性に限界がある可能性があるため、このようなユーザーには機能を一部に限定して提供できます。たとえば、管理下にあるデバイスのエンドユーザーには SharePoint サイト上のファイルのダウンロードと保存を許可し、管理外のデバイスからのアクセスの場合は、ファイルの表示を許可しないでおくことができます。

パートナーへのリモートアクセスの提供 - パートナーとの協力して作業を行う場合は、パートナーの組織の個別の従業員、または従業員のグループに対して組織内のアプリケーションやリソースへのリモートアクセスを可能にすることが必要な場合があります。この目標を実現するには、Active Directory フェデレーションサービス (AD FS) を使用して、パートナーの従業員の ID 情報を組織に提供させることができます。

AD FS を使用して、パートナーの従業員を特定できない場合は、自組織の Active Directory ドメイン内でシャドウアカウントを使用できます。

自組織の管理下のデバイスを使用しないパートナーの従業員にアクセスを提供する場合は実行する正常性チェックにおいて適切な方法を探る必要があります。制限が厳しすぎると、公開するリソースおよびアプリケーションにパートナーの従業員がアクセスする必要がある場合に、アクセスできなくなる可能性があります。しかし、制限が不足していると、パートナーの従業員が社内専用の情報にアクセスして、配布できる可能性が生じます。

パートナーにアプリケーションを公開する場合は、専用の Forefront UAG トランクを使用することをお勧めします。

顧客へのリモートアクセスの提供 - 多くの企業が、顧客に対する社内アプリケーションおよびリソースへのアクセスの提供を必要としています。この目標を実現するには、顧客 ID 情報を格納するリポジトリの使用または作成が必要です。自社が公開するアプリケーションおよびリソースに顧客がアクセスしようとするときに、Forefront UAG がこのリポジトリと照らして顧客を認証します。Forefront UAG では、さまざまな認証スキームがサポートされています。また、ユーザー定義の認証サーバーを構成することもできます。

公開しているアプリケーションおよびリソースに顧客のすべてがアクセスできるようにするため、汎用的な正常性チェックのみを実行します。また、トランクおよびアプリケーションを慎重に定義して、自社ネットワークの整合性を確保することも必要です。

展開目標とエンドポイントアクセス設計とのマッピングForefront Unified Access Gateway (UAG) のエンドポイントアクセスおよび ID の設計プロセスを開始するには、まず展開の目標を確認する必要があります (「エンドポイントアクセスの展開目標の確認」を参照してください)。これらの目標を評価した後に、エンドポイントアクセスおよび ID 展開の目的に応じた設計の選択が可能になります。

次の表は、想定される展開目標のそれぞれと、その目標の実現に向けて実行が必要な計画タスクを示しています。

展開目標計画タスク

リモート従業員のアクセスフロントエンド認証の計画、特に LDAP 認証

公開サーバーに対するバックエンド認証の計画

ポータルアプリケーション承認の計画

エンドポイントの正常性チェックの計画

エンドポイントアクセスポリシーの実施計画

パートナーのアクセス AD FS を使用したフェデレーションの計画



エンドポイントアクセスポリシーの実施計

注意:

展開目標計画タスク

画

顧客のアクセスフロンドエンド認証の計画



エンドポイントアクセスポリシーの実施計画

クライアント認証の計画Forefront Unified Access Gateway (UAG) を使用すると、次の方法を使用して公開されたリソースへのクライアントエンドポイントアクセスを制御できます。

クライアントエンドポイントと Forefront UAG サーバー間で HTTPS チャネルを要求。

セッション認証を適用。ポータルに接続しようとするクライアントエンドポイントに認証を受けることを要求したり、Web アプリケーションを個別に公開することができます。

HTTPS を利用するクライアントエンドポイントアクセスポータルを公開するトランクや、特定の Web アプリケーションを作成する際は、クライアントエンドポイントから Forefront UAG サーバーとの通信に HTTPS 接続を要求することを指定できます。これを指定する場合は、トランクの構成時にサーバー証明書を選択する必要があります。この証明書は、Forefront UAG サーバーがクライアントエンドポイントの認証を受ける際に使用されます。

セッション認証についてForefront UAG enables では、認証データベースに照らしてエンドユーザーの資格情報を検証することにより、内部リソースへのアクセスを制御できます。ポータルまたはアプリケーションセッションは、認証が正常に完了したエンドユーザーに対してのみ開かれます。認証に失敗したエンドユーザーはアクセスが許可されません。アクセスは、エンドユーザーごとに許可され、各認証インスタンスは、1 回のセッションに限り有効です。Forefront UAG がサードパーティの認証サーバーのクライアントとして機能する場合など、実装する方式が保護対象のアプリケーションで本来サポートされない場合でも、Forefront UAG は、さまざまな認証スキームとシームレスに統合します。さらに、Forefront UAG は、ログオフスキームを適用することによって、定期的な再認証も有効化します。あらかじめ定義された時間が経過すると、エンド

ユーザーは資格情報を再提示しなければ作業を続行できません。再提示しない場合はセッションが終了します。

セッションの認証を定義するには、ポータルやアプリケーションセッションに接続するエンドユーザーの資格情報を検証する認証サーバーを定義する必要があります。Forefront UAG のクライアント認証スキームの詳細については、フロントエンド認証サーバーの展開に関する記述を参照してください。

フロンドエンド認証の計画Forefront Unified Access Gateway (UAG) では、エンドユーザーが Forefront UAG ポータルの認証を受ける際にさまざまな種類の認証プロトコルの使用がサポートされます。これらの認証プロトコルを使用することによって、2 要素認証やスマートカード認証などの強力な認証機能を装備できます。

サポートされる認証プロトコルについては、次の各トピックで説明します。

LDAP 認証

LDAP クライアント証明書の認証

RADIUS 認証

RSA SecurID 認証

TACACS 認証

WINHTTP 認証

Forefront UAG で提供される認証スキームのいずれも使用しない場合は、カスタムの認証スキームを構成できます。

注意:

LDAP 認証LDAP (ライトウェイトディレクトリアクセスプロトコル) は、ディレクトリサービスのクエリおよび変更に使用されるインターネットプロトコルの 1 つです。LDAP 認証サーバーでは、ユーザーのプロパティ、認証スクリプトなどの認証情報をはじめとしたユーザーに関する情報が、"ディレクトリ " と呼ばれる専用データベースに保管されています。 Forefront Unified Access Gateway (UAG) が接続要求を受信すると、LDAP ディレクトリと照合してユーザー名とパスワードの認証が実行されます。

Forefront UAG では、次の LDAP 認証スキームが実装されます。

Netscape Directory Server (V. 4.1)

Notes Directory Server

Novell Directory Server

Windows Server 2008 の Active Directory ライトウェイトディレクトリサービス (AD LDS) 、および Windows Server 2003 または Windows 2000 Server の Active Directory

ディレクトリサービス

次の機能がある LDAP 認証スキームがサポートされます。

2 つの LDAP 認証サーバーによる運用 - プライマリ LDAP サーバーに障害が発生すると、Forefront UAG は代替の LDAP サーバーにアクセスします。

セキュリティで保護されたポートのサポート - 認証サーバーがセキュリティで保護されたポートを使用する場合、スキームの定義時に構成されていなくても Forefront UAG は、セキュリティで保護された接続を使用します。

Novell Directory Server では、ユーザーが一意である場合はユーザー名の入力時に各自のコンテキストを入力する必要がありません。一意のユーザーはツリー内の 1 つのコンテキストのみに表示されます。また、"ベース" が定義されている場合、ユーザーはそのベース下の 1 つのコンテキストのみに表示されます。

LDAP の認証フロー次の図は、1 つの認証サーバーに LDAP 認証スキームが実装されている場合のユーザーの認証プロセスを示しています。

このフローでは、ログインの試行が 3 回まで許可されます。3 回失敗すると最終的にログインが失敗します。ユーザーに許可されるログインの試行回数は構成可能です。

LDAP の認証フロー

注意:

LDAP クライアント証明書の認証クライアント証明書の認証スキームでは、エンドユーザーがデバイスにインストールされたクライアント証明書を提示して認証を受ける必要があります。認証プロセスでは、ユーザー名、パスワードなどのログイン情報は要求されません。クライアント証明書の認証は、HTTPS 接続を介して公開された Forefront Unified Access Gateway (UAG) サイトでのみ使用できます。

LDAP クライアント証明書の認証スキームは、1 つまたは 2 つの LDAP 認証サーバーと共に稼動する Forefront UAG でサポートされます。LDAP 認証サーバーでは、ユーザーのプロパティやアクセス権など、認証および承認情報を含むユーザー関連の情報が保管されます。

トランクの構成によって LDAP クライアント証明書の認証スキームが適用される場合、Forfront UAG サーバーに接続要求が着信すると、認証スキームによって次のように実行されます。

ユーザーの認証 - 接続を要求するユーザーには、ブラウザーからクライアント証明書を選択するように求められます。ユーザーが証明書を選択すると、Forefront UAG は、証明書の有効性とユーザーの ID を検証します。

ユーザーの承認 - 証明書が検証され、ユーザーが認識されると、Forefront UAG と LDAP 認証サーバーが連携して、そのユーザーにアプリケーションサーバーへのアクセスが承認されているかどうかが検証されます。

LDAP サーバーに登録されている各ユーザーには、たとえば organization\organizational_unit\username のような識別名 (DN) が割り当てられています。

LDAP クライアント証明書スキームが 2 つの LDAP 認証サーバーを使用して運用されている場合は、プライマリ LDAP サーバーに障害があると、ユーザーマネージャーが代替の LDAP サーバーにアクセスします。

LDAP クライアント証明書の認証フロー次の図は、1 つの認証サーバーに LDAP クライアント証明書の認証スキームが実装されている場合のユーザーの認証プロセスを示しています。

LDAP クライアント証明書の認証フロー

RADIUS 認証RADIUS スキームでは、内部ネットワークでの認証情報の交換の管理にリモート認証ダイヤルインユーザーサービス (RADIUS) プロトコルが適用されます。 Forefront Unified Access Gateway (UAG) で認証に RADIUS サーバーを使用した場合、 RADIUS 認証サーバーと Forefront UAG がクライアント - サーバーモードで動作し、これによって Forefront UAG は RADIUS サーバーのクライアントとして構成されます。

秘密キーRADIUS プロトコルは、秘密キーを利用してユーザーがログインスクリプトで入力した資格情報を暗号化します。その後、認証サーバーによってデータの暗号化が解除され、データベースと比較されます。

チャレンジ/レスポンスモードRADIUS 認証スキームでは、RADIUS サーバーで使用可能なすべてのチャレンジ/レスポンス認証モードがサポートされます。これはたとえば、ユーザーに対する新しい暗証番号 (PIN) の作成の許可、ユーザーに対する新しい暗証番号作成の要求、ユーザーに対する認証システムに表示されるトークン入力の要求などです。

RADIUS グループRADIUS 属性からユーザーのグループメンバーシップを抽出する RADIUS 認証スキームを構成できます。

RADIUS の認証フロー次の図は、RADIUS 認証スキームがチャレンジ/レスポンスモードで実装されている場合にユーザーに適用されるサンプルの認証プロセスを示しています。このモードでは、ユーザーは、要求が受け入れられるまで、RADIUS サーバーの構成に従って特定回数試行することができます。

このフローでは、ログインの試行が 3 回まで許可されます。3 回失敗すると最終的にログインが失敗します。ユーザーに許可される実際のログイン試行回数は構成可能です。

RADIUS 認証スキーム - サンプルフロー

注意:

RSA SecurID 認証Forefront Unified Access Gateway (UAG) では、RSA SecurID 認証スキームがサポートされます。このスキームでは、RSA ACE/Server 上でユーザーが認証されます。試行時にユーザーは、

RSA によって指定された暗証番号 (PIN) と、RSA SecurID 認証システムに表示される番号であるトークンコードの 2 つの番号を組み合わせたパスワードを入力します。

RSA SecurID スキームでは、後述のように Next Token モードと New PIN モードという 2 つのチャレンジ/レスポンスモードもサポートされます。

Next Token モードNext Token モードは、認証プロセスでトークンコードの追加検証が必要な場合に適用されます。ユーザーは Neｘｔ Token コードを入力するように要求されます。つまり、認証システムに表示された番号が変化するまで待ってから新しい番号 (PIN なし) を入力します。

New PIN モードNew PIN モードは、認証プロセスで PIN の追加検証が必要な場合に適用されます。この場合、ユーザーは新しい PIN を使用する必要があります。RSA ACE/Server の構成に従って、ユーザーは新しい PIN の選択および入力が求められるか、サーバーによってユーザーに新しい PIN が提供されます。その後ユーザーは新しい PIN を使用して再認証を受けます。

New PIN モードの使用はオプションで、認証サーバーと Forefront UAG 管理コンソールのいずれでも、有効と無効を切り替えることができます。設定が揃っていない場合は、認証サーバーの設定より Forefront UAG 管理コンソールが優先されます。

セキュリティを考慮して、New PIN モードは有効にしないことをお勧めします。

RSA SecurID の認証フロー次の図は、RSA SecurID スキームが実装されている場合のユーザーの認証プロセスを示しています。

このフローには、Next Token モードと New PIN モードの両方が含まれています。これらは上述の条件でのみ適用が可能になります。


RSA SecurID の認証フロー

注意:

注意:

TACACS 認証Forefront Unified Access Gateway (UAG) では、 Terminal Access Controller Access Control System (TACACS) を使用したユーザー認証がサポートされます。TACACS プロトコルを使用すると、ネットワークアクセスサーバー (NAS) はユーザー管理をセントラルサーバーにオフロードできます。TACACS 認証スキームが適用されると、ユーザーの接続要求は NAS によっ

て TACACS 認証サーバーにダイレクトされます。そこでユーザー ID がサーバーのユーザーデータベースと照合され、その結果に応じてユーザーにアクセスを許可するか拒否するかが判定されます。

Forefront UAG と TACACS 認証サーバーはクライアント - サーバーモードで動作し、Forefront UAG が TACACS サーバーのクライアントとして構成されます。

TACACS 認証スキームでは、認証要求の暗号化に秘密キーが使用されます。このキーは、Forefront UAG と TACACS 認証サーバーの両方で同じ構成にする必要があります。

TACACS 認証スキームは、NTTacPlus 認証サーバーに対してテストされています。

TACACS の認証フロー次の図は、TACACS 認証スキームが実装されている場合のユーザーの認証プロセスを示しています。


TACACS の認証フロー

注意:

注意:

WINHTTP 認証Forefront Unified Access Gateway (UAG) では WINHTTP 認証を使用してユーザーを認証できま

す。

WINHTTP 認証スキームでは、次のようにしてユーザーの資格情報がチェックされます。

HTTP 401 要求を使用して、ユーザーに認証を要求する Web ページの URL を割り当てます。

定義した Web サーバーによって、要求された URL へのアクセスがユーザーに承認されているかどうかがチェックされます。URL へのアクセスが許可されているユーザーのみが認証されたユーザーと見なされます。

WINHTTP の認証フロー次の図は、WINHTTP 認証スキームが実装されている場合のユーザーの認証プロセスを示しています。

WINHTTP の認証フロー


公開サーバーに対するバックエンド認証の計画Forefront Unified Access Gateway (UAG) では、資格情報を委任できるため、Forefront UAG サイトセッションへのログオンの際のクライアントの認証時に、提供された資格情報を、認証を必要とするバックエンドサーバーに送信できます。このシングルサインオン (SSO) メカニズムを使用することによって、ユーザーが 1 組の資格情報を使用して Forefront UAG にログオンすると、その後はその資格情報を有効とする任意のアプリケーションの認証とアクセスの獲得にも最初に使用した資格情報を適用できます。

Forefront UAG では、次の方法を使用し、公開されたバックエンドアプリケーションに対する認証にセッション資格情報を使用することによって、シングルサインオンを実装できます。

基本、 NTLM 、または HTTP フォームベースの認証 - Forefront UAG では、基本認証、NTLM 認証、および HTTP フォームベース認証がサポートされます。バックエンドサーバーで基本認証または NTLM 認証が要求される場合は、HTTP 401 応答が Forfront UAG サーバーに送信されます。バックエンドサーバーで HTTP フォームベース認証が要求される場合は、Forfront UAG サーバーの構成によってユーザーの資格情報が自動的に提供されます。

Kerberos の制約付き委任 - Forefront UAG では、Forefront UAG で Kerberos 以外の認証方法を使用して ID が検証された後に、ユーザー認証での Kerberos の制約付き委任の使用がサポートされます。

基本、NTLM、または HTTP フォームベースの認証Forefront Unified Access Gateway (UAG) では、ユーザーが公開された Web サーバーの認証を受ける際に、基本認証、NTLM 認証、または HTTP フォームベース認証を使用できます。

Forefront UAG でこれらの認証方法を使用するには、一般にフロントエンド認証プロセスの際に収集されるユーザーとパスワードが必要です。ユーザー名とパスワードは、ユーザーがリソースにアクセスしようとしたときにバックエンドサーバーに送信されます。

注意:

Kerberos の制約付き委任Forefront Unified Access Gateway (UAG) では、Kerberos 制約付き委任 (KCD) を使用して、シ

ングルサインオン (SSO) 機能を提供できます。KCD を使用すると、ユーザーはスマートカード認証、Active Directory フェデレーションサービス (AD FS)、ワンタイムパスワードなどのクライアント証明書認証を使用して Forefront UAG サイトおよび UAG サイトを介して有効化されたアプリケーションの両方にアクセスできます。KCD を使用すると、エンドユーザーはサイトの認証を一度受ければ、ユーザー認証を要求するアプリケーションへのログオン時に資格情報を提示する必要がなくなり、また、ドメインパスワードの入力も要求されません。

KCD テクノロジの詳細は、Kerberos のプロトコル遷移と制約付き委任 (http://go.microsoft.com/fwlink/?LinkId=122608) に関する記述を参照してください。

システム要件Forefront UAG の展開で KCD を使用する際の要件は次のとおりです。

Forefront UAG サーバーがドメインに属している必要があります。

アプリケーションが属するトランクに対して、認証サーバーを 1 つ以上定義する必要があります。

内部ネットワーク内のすべてのドメインコントローラーが、Windows Server 2008 または Windows Server 2003 を実行しているコンピューターである必要があります。

ユーザーが Forefront UAG サーバーおよびアプリケーションサーバーと同じ Active Directory フォレストに属している必要があります。

Forefront UAG サーバーとアプリケーションサーバーが同じドメインに属している必要があります。

AD FS を使用したフェデレーションの計画Active Directory フェデレーションサービス (AD FS) は、Web シングルサインオンテクノロジを提供して、単一のセッションの存続期間にわたってユーザーが複数の Web アプリケーションの認証を受けられるようにします。AD FS では、デジタル ID とアクセス権、つまり "クレーム" をセキュリティおよびエンタープライズの境界を越えて安全に共有することによってこれを実現します。 Active Directory Lightweight Directory Service (AD LDS) または Active Directory ディレクトリサービスを使用した場合は、組織のセキュリティまたはエンタープライズの境界内で Windows 統合認証によってシングルサインオン機能の利点を活用できます。AD FS は、この機能をインターネットに接続するアプリケーションにも拡張し、組織の Web ベースアプリケーションにアクセスする顧客、パートナーおよびサプライヤーにも同様に効率化された Web シングルサインオンのユーザーエクスペリエンスを使用できるようにします。さらに、フェデレーションサーバーを複数の組織に展開して、パートナー組織間で連合化した

http://go.microsoft.com/fwlink/?LinkId=122608

企業間 (B2B) 取引を推進できます。たとえば、AD FS を使用すると、企業 A の従業員を企業 B のリソースで識別して、企業 B のリソースに対するアクションの実行を承認できます。Forefront Unified Access Gateway (UAG) では、AD FS パッシブモデル認証を使用してフェデレーションユーザーが Forefront UAG サイト、およびそのサイトで公開されるアプリケーションにアクセスできます。

サポートされるシナリオForefront UAG の AD FS には、次の環境が必要です。

1. AD FS v1 サーバー 1 つ。

2. AD FS サーバーは、Forefront UAG によって公開されます。AD FS サーバーへのユーザーアクセスはすべて、Forefront UAG を介する必要があります。AD FS サーバーは、ポータルトランク内ではなく、直接、アプリケーショントランクに公開する必要があります。

3. 次の場合にはシャドウアカウントが必要です。

リソース組織がユーザー組織内のユーザーを厳密に特定する必要がある場合。また、ユーザーの組織からリソースの組織のグループにユーザーを割り当てる方法もあります。グループのマッピングには、シャドウアカウントではなくシャドウグループが必要です。

公開されたアプリケーションが Kerberos 制約付き委任をサポートし、Kerberos を使用してシングルサインオンをサポートする必要がある場合。

Forefront UAG の AD FS には、次のアプリケーションおよび認証要件があります。

1. Forefront UAG ポータルへのログオンには NT トークンが必要です。Forefront UAG では、クレームを使用できません。

2. 公開されたバックエンドアプリケーションで NT トークンまたはクレームが要求される場合があります。いずれの場合も、ユーザーとバックエンドアプリケーション間の認証は、直接実行されます。アプリケーションのプロパティで、 [Use single sign-on to send credentials to published applications] の設定をオフにします。

3. Kerberos 制約付き委任は公開されたアプリケーションでサポートされる場合にのみ使用できます。

AD FS の前提条件Forefront UAG で AD FS を使用する場合は、次の要件が適用されます。

1. Forefront UAG をインストールする前に、Forefront UAG サーバーの外部ネットワークアダプターで静的 IP アドレスを 2 つ定義する必要があります。

2. Forefront UAG が境界ネットワークにインストールされている場合も、Forefront UAG サーバーはドメインメンバーである必要があります。これは、Forefront UAG サーバーにインストールする必要がある AD FS Web エージェントによる要件です。

3. 認証には Active Directory リポジトリを使用する必要があります。

4. AD FS 対応アプリケーションの公開は HTTPS トランクを使用した場合にのみ可能です。

エンドポイントの正常性チェックの計画Forefront Unified Access Gateway (UAG) のアクセスポリシーによって、Forefront UAG セッションおよび公開されたリソースへのリモートエンドポイントアクセスが制御されます。クライアントエンドポイントが Forefront UAG サイトまたはポータルへのセッションを確立しようとすると、エンドポイント上の設定がアクセスポリシーと比較され、許可されるアクセスの種類が決定されます。Forefront UAG クライアントエンドポイントポリシーを使用すると、サイトおよびアプリケーションのアクセスを多層化できます。エンドポイントポリシーを使用すると、クライアントエンドポイントデバイスから内部のサイトおよびアプリケーションへのアクセスを許可するかどうか、アプリケーションサーバー上で特定の操作の実行を許可するかどうかを、エンドポイントデバイスの設定と機能に応じて決定できます。

構成可能なアクセスポリシーの種類は次のとおりです。

組み込みのアクセスポリシー - Forefront UAG には、あらかじめ定義されたアクセスポリシーが組み込まれています。これらの事前定義ポリシーを必要に応じて変更することも、新たにポリシーを作成することもできます。

ネットワークアクセス保護 (NAP) ポリシー - Forefront UAG は、ネットワークポリシーサーバー (NPS) からダウンロードした NAP ポリシーを基準にしてリモートエンドポイントを評価できます。

組み込みのアクセスポリシーForefront UAG に組み込みのエンドポイントポリシーを使用すると、エンドポイントデバイスから内部のサイトおよびアプリケーションへのアクセスが許可されるかどうか、アプリケーションサーバー上で特定の操作の実行が許可されるかどうかを、エンドポイントデバイスのセキュリティ設定に応じて決定して、アクセスを多層化できます。

エンドポイントポリシーに含めることができるものは次のとおりです。

プラットフォーム固有ポリシー - このポリシーは、ユーザーが Forefront UAG サイトへのアクセスに使用するエンドポイントデバイスのオペレーティングシステムに従って適用されます。Windows、Mac OS、Linux、またはその他の任意のプラットフォームから選択できます。

式 - 変数、VB スクリプトのフリーテキスト、またはこれらの組み合わせで構成される条件です。式には、ユーザーが Forefront UAG サイトへのアクセスに使用するエンドポイントデバイスのプラットフォームに従って適用されるプラットフォーム固有式も含まれます。プラットフォーム固有の問題に対処する必要がない場合は、展開内のポリシーの定義に式を使用します。また、プラットフォーム固有の式も含め、式を使用して複数の条件を一度定義して、それをいくつかのポリシーで使用することもできます。

Forefront UAG に用意されているポリシーを使用し、必要に応じてそれらを編集して、追加のポリシーを定義できます。ポリシーを使用して複数の条件を一度定義すれば、それらを Forefront UAG サイトおよび複数のアプリケーションに適用できます。

組織のセキュリティのニーズに合わせて、既定のポリシーを調整することをお勧めします。たとえば、すべてのプラットフォーム固有の既定の Web アプリケーションアクセスポリシーを編集し、企業のエンドポイントコンピューターで実行しているウイルス対策ソフトウェアのチェックなどを行います。

NAP のアクセスポリシーForefront UAG に組み込みのポリシー以外に、NPS サーバーからダウンロードした NAP ポリシーでエンドポイントの設定を評価できます。Forefront UAG 管理コンソールで NPS サーバーの場所と設定を指定します。NAP ポリシーは指定されたサーバーから取得されます。

エンドポイントアクセスポリシーの実施計画Unified Access Gateway (UAG) クライアントエンドポイントポリシーを使用して、サイトおよびアプリケーションのアクセスを多層化できます。エンドポイントポリシーを使用すると、クライアントエンドポイントデバイスから内部のサイトおよびアプリケーションへのアクセスを許可するかどうか、アプリケーションサーバー上で特定の操作の実行を許可するかどうかを、エンドポイントデバイスの設定と機能に応じて決定できます。

ここでは、以下について説明します。

エンドポイントポリシーの使用 - エンドポイントポリシーのセットアップおよび使用方法

セッションエンドポイントポリシー - セッションエンドポイントポリシーの概要、および Forefront UAG のアクセス制御に役立つ理由の説明

アプリケーションエンドポイントポリシー - アプリケーションエンドポイントポリシーの概要、および Forefront UAG のアクセス制御に役立つ理由の説明

エンドポイントの検出 - Forefront UAG のエンドポイント検出コンポーネント、およびポリシーに基づくリモートユーザーから Forefront UAG へのアクセスの許可の原則がどのように指定されるかに関する説明

エンドポイントポリシーの使用エンドポイントポリシーをセットアップすることによって、内部アプリケーションへのアクセスを次のようにして許可できます。

企業のラップトップから - すべてのアプリケーションへのアクセスが可能です。

注意:

インターネットキオスクから - Microsoft Office Outlook Web Access にのみアクセスが可能です。

使用する要件によっては、その他のアクセスシナリオも使用できます。

エンドポイントポリシーを使用することによって次へのアクセスを制御できます。

Forefront UAG サイトの既定および特権のあるセッション

個別のアプリケーション

Web アプリケーションのダウンロードやアップロード、URL によって定義される Web アプリケーションのゾーン、プリンター、クリップボード、および RemoteApp のドライブリダイレクトなどの個別のアプリケーション機能

アプリケーションを公開するには、Forefront UAG トランクを作成して、アプリケーションをトランクに追加する必要があります。トランクの作成時に、適切なエンドポイントポリシーをトランクに割り当てます。アプリケーションをトランクに追加するときに、適切なポリシーをアプリケーションに割り当てます。エンドポイントポリシーには、すべてのエンドポイントデバイスに適用される条件が含まれ、Windows や Linux など、コンピューターで実行されるオペレーティングシステムに応じて解釈されます。定義するポリシーに従って、オペレーティングシステムごとに異なる条件を適用できます。

エンドポイントポリシーは、次のようにオペレーティングシステム固有のポリシーや式で構成できます。

プラットフォーム固有ポリシー - プラットフォーム固有ポリシーは、ユーザーが Forefront UAG サイトへのアクセスに使用するエンドポイントデバイスのオペレーティングシステムに従って適用されます。使用可能なオペレーティングシステムは、 Windows、Mac OS、および Linux です。

式 - 式は、変数、VB スクリプトのフリーテキスト、またはこれらの組み合わせで構成される条件です。式のそれぞれには、ユーザーが Forefront UAG サイトへのアクセスに使用するエンドポイントデバイスのオペレーティングシステムに従って適用されるプラットフォーム固有式も含まれます。プラットフォーム固有の問題に対処する必要がない場合は展開内のエンドポイントポリシーの定義に式を使用します。また、プラットフォーム固有の式も含め、式を使用して複数の条件を一度定義して、それをいくつかのポリシーで使用することもできます。

Forefront UAG に用意されているエンドポイントポリシーと式を使用し、必要に応じてそれらを編集して、追加のポリシーと式を定義できます。エンドポイントポリシーを使用して複数の条件を一度定義するだけで、それらを Forefront UAG サイトおよび複数のアプリケーションに適用できます。

組織のセキュリティのニーズに合わせて、既定のエンドポイントポリシーを調整することをお勧めします。たとえば、すべてのプラットフォーム固有の既定の Web アプリ

注意:

注意:

ケーションアクセスポリシーを編集し、企業のエンドポイントコンピューターで実行しているウイルス対策ソフトウェアのチェックなどを行います。

ポリシーと式の作成、編集、および削除の詳細については、Forefront UAG アクセスポリシーの構成に関する記述を参照してください。

セッションエンドポイントポリシートランクの作成時に、次のセッションポリシーの両方を割り当てることができます。

セッションアクセスポリシー - サイトのアクセス許可を定義します。選択したポリシーに適合するエンドポイントにのみアクセスが許可されます。

特権エンドポイントポリシー - エンドポイントを特権エンドポイントにする条件を定義します。特権エンドポイントには、セッション特権が認められます。

まず、トランクの作成時にセッションポリシーを選択します。セッションポリシーは、後から Forefront UAG 管理コンソール内で変更できます。

アプリケーションエンドポイントポリシーアプリケーションエンドポイントポリシーは、次の種類のいずれかになります。

アプリケーションへのアクセスを制御するアクセスポリシー

アクセスが許可されていないエンドポイントへの機密データの拡散防止に役立つダウンロードポリシー (Web アプリケーションおよびブラウザー埋め込みアプリケーション専用)

エンドポイントから内部ネットワークへのウイルスなどの有害データの送信防止に役立つアップロードポリシー (Web アプリケーションおよびブラウザー埋め込みアプリケーション専用)

アプリケーションの重要領域へのアクセスを制限する、制限付きゾーンポリシー (Web アプリケーションおよびブラウザー埋め込みアプリケーション専用)

RemoteApp 用のプリンター、クリップボード、およびドライブリダイレクトポリシー

まず、トランクの作成時に、アプリケーションエンドポイントポリシーを選択します。アプリケーションエンドポイントポリシーは、後から Forefront UAG 管理コンソール内で変更できます。

エンドポイントの検出エンドポイントが Forefront UAG のエンドポイントポリシーに適合しているかどうかを評価するため、Forefront UAG は、ユーザーがサイトにアクセスしようとすると即座に、エンドポイントにどのセキュリティコンポーネントがインストール、実行されているかを特定しようとします。これは、エンドポイント上にインストールされた Forefront UAG エンドポイント検出コンポーネントによって実行されます。エンドポイント検出コンポーネントは、 Forefront UAG サイトの ID を、サイトのサーバー証明書と照合して検証し、このサイトがユーザーの信頼済み

サイトの一覧に含まれているかどうかを調べます。サイトが信頼済みである場合に限り、エンドポイント検出コンポーネントはエンドポイントコンピューター上で実行され、コンピューター上にインストールされ実行中の各コンポーネントの種類を識別するデータを収集します。検出機能がエンドポイントコンピューター上で正しく動作しない場合、このエンドポイントがポリシー要件に準拠していたとしても、アクセスが拒否される可能性があります。たとえば、アプリケーションのポリシーによってウイルス対策プログラムの実行が要求されている場合に、コンピューター上でこうしたプログラムが既に実行されている場合であっても、Forefront UAG はこのコンピューター上でこのプログラムが実行されていることを検出できないため、アプリケーションへのアクセスが拒否されてしまいます。

Forefront UAG には、既定のエンドポイント検出スクリプト (Detection.vbs) が用意されています。また、独自にカスタマイズした検出スクリプトを作成することもできます。

Forefront UAG エンドポイントポリシーに準拠しているかどうかは、クライアントエンドポイントコンピューターがサイトに最初にアクセスしたときに評価されます。ログイン後、ポリシーへの準拠に影響するクライアントコンピューター設定を変更した場合は、ユーザーはこの変更を適用するため、再度ログインする必要があります。NAP ポリシーを使用する場合は、ポリシーの適用がセッションの期間中実施されます。

クライアントエンドポイントから収集される情報Forefront UAG サイトで作業を行う間、エンドポイント検出がクライアントエンドポイント上で有効にされている場合は、エンドポイント検出コンポーネントによってクライアントエンドポイントの設定および機能が識別されるだけでなく、以下の情報が収集されます。

ネットワークドメイン - ドメインネームシステム (DNS) および NetBIOS。

ユーザー情報 - ユーザー名およびユーザータイプ。

証明書ストア内の証明書 - 証明書の発行者およびサブジェクト。

必要に応じて (法規制や企業ガイドラインへの遵守が問われる場合など)、ユーザーのデバイスから情報収集が行われる前にユーザーに通知し、サイトでのこのような情報の収集について、ユーザーが同意するかどうかを確認するように Forefront UAG を構成することもできます。これを設定するには、 [Advanced Trunk Configuration] ダイアログボックスの [Endpoint Access Settings] タブで、[Prompt user before retrieving information from endpoint] チェックボックスをオンにします。ユーザーの同意が得られないエンドポイント上では、検出は実行されません。

ポータルアプリケーション承認の計画既定では、Forefront Unified Access Gateway (UAG) ポータル内で公開されたアプリケーションの表示およびアクセスがすべてのユーザーに許可されます。アプリケーションごとに既定の [All Users Are Authorized] の設定を無効にして、アプリケーションのアクセス承認を構成できます。アプリケーションのアクセス承認を使用すると、ポータルで公開されるアプリケーション

のそれぞれについて、表示およびアクセスを許可するユーザーを制御できます。これによって、承認されたアクセス権に応じてユーザーごとに個別設定された機能が提供されます。

アプリケーション承認を使用するには、ユーザーまたはグループの承認リポジトリを構成し、これと照合してポータルアプリケーションへのアクセスを要求するユーザーを評価します。既存の認証サーバー上で定義されたリポジトリを使用することも、代替の承認リポジトリを構成することもできます。詳細については、ポータルアプリケーション承認のためのユーザーおよびグループの展開に関する記述を参照してください。

アプリケーションの個人別設定は、Forefront UAG に用意されている既定のポータルホームページを使用している場合にのみ機能することに注意してください。既定またはカスタムのポータルホームページで、アクセスの承認を構成できます。

アクセスの承認を定義する手順は次のとおりです。

アプリケーションへのアクセスを要求するユーザーの評価に使用されるユーザーまたはグループのサーバーを定義します。ユーザー認証用に定義されたサーバーを使用することも別のサーバーを承認用に指定することもできます。詳細については、クライアント認証の計画に関する記述を参照してください。

ポータルで公開される個別のアプリケーションの承認設定を実行します。

Microsoftdownload.microsoft.com/.../AccessControlPlanning.docx · Web...

Documents

Transcript of Microsoftdownload.microsoft.com/.../AccessControlPlanning.docx · Web...