コンテキストベースのアプリルーティングとリソースロケーションの選択

• 管理者は、同じアプリを異なるユーザーに対して異なる方法でルーティングしたいと考えています。たとえば、一部のユーザーに対しては、トラフィックがSecure Private Accessサービスにルーティングされるのを防ぐために、内部アプリのURLを外部にルーティングする必要があります。
• パフォーマンスを向上させるために、最適なデータセンターにリクエストをルーティングするために、異なるユーザーに対して異なるリソースロケーションを使用する必要がある。

• コンテキストベースのルーティング
• ユーザーコンテキストベースのリソースロケーション選択
• 内部企業ユーザーをバックエンドアプリケーションに直接ルーティングする

ユースケース: コンテキストベースのルーティング

• グループAユーザー: Secure Private Accessを介してOutlookアプリとMicrosoft TeamsアプリにアクセスするABC社の従業員で、内部的にルーティングされます。
• グループBユーザー：ABCと協力しているサードパーティ企業の従業員。彼らは特定のアプリケーション（Outlookを除く）にセキュアプライベートアクセスを介してアクセスします。また、インターネット経由でアクセスする独自のOutlookアプリケーションを持っており、Outlookトラフィックをセキュアプライベートアクセス経由でルーティングしたくありません。

• グループBユーザーは、ABCアプリにアクセスするためにセキュアアクセスエージェントにログインします。
• 彼らのネイティブブラウザを介したOutlookへのアクセス要求は、セキュアプライベートアクセス経由でルーティングされ、アクセス拒否につながります。
• Outlookアプリケーションの宛先ドメインは、グループAユーザーとグループBユーザーの両方で同じです。
• アクセスポリシーはグループAユーザーのみにアクセスを許可しているため、グループBユーザーがMicrosoft TeamsまたはOutlookを起動しようとするとアクセスが拒否されます。
• このルーティングの問題により、グループBユーザーは会社のOutlookにアクセスできません。

1. Office 365アプリにアクセスするグループBユーザー専用の新しいアクセスポリシーを定義します。
2. アクセスポリシーで、ルーティング例外オプションを有効にします。
   管理者は、アクセスポリシーに関連付けられているすべての内部アプリのすべてのURLと関連ドメインのリストを表示できます。
3. すべてのOffice365アプリのURLについて、ルーティングが外部で行われるように構成します。
   これにより、グループBユーザーのOutlookアプリケーションへのアクセス要求がインターネット経由でルーティングされ、セキュアプライベートアクセスをバイパスすることが保証されます。
   これらの変更を実装することで、グループBユーザーは、セキュアプライベートアクセスを経由せずにインターネット経由で会社のOutlookアプリケーションにアクセスできるようになり、必要に応じて他のABCアプリケーションへのアクセスも維持できます。

ユースケース: ユーザーコンテキストに基づくリソースロケーションの選択

• XYZ社: 米国東海岸と米国西海岸にそれぞれユーザーグループがあります。
• データセンター: 東海岸と西海岸にそれぞれ1つずつ、合計2つのデータセンターがあり、どちらも同じJiraアプリケーションをホストしています。
• 目的: 管理者は、最適なパフォーマンスとルーティングを確保するために、ユーザーコンテキスト（地理的位置、ネットワーク位置、ユーザー名、ユーザーグループ）に基づいて、エンドユーザーのアクセス要求を選択されたリソースロケーションにルーティングしたいと考えています。

1. Jiraアプリケーションに関連付けられているアクセスポリシーを編集して、新しいルーティング要件に対応します。
2. アクセスポリシー内で、ルーティング例外オプションを有効にします。
3. ユーザーコンテキストごとにリソースロケーションを変更します。

ルーティングタイプまたはリソースロケーションを変更する手順

1. アクセスポリシーを作成または編集します。詳細については、「アクセスポリシーの作成」を参照してください。
2. 手順3: アクションページで、ルーティング例外トグルスイッチをスライドして、コンテキストルーティングドメイン構成を有効にします。 ルーティング例外トグルを使用すると、アクセスポリシーに追加されたアプリケーションのドメインのリソースロケーションとルーティング情報を編集できます。
   • トグルがオンの場合: すべてのアプリのURLと関連ドメインのリストが、グローバルルーティングとリソースロケーション構成とともに表形式で表示されます。このリストには、アクセスポリシーに追加されたすべてのアプリケーションのURLと関連ドメインが含まれています。ドメインの横にある編集アイコンをクリックすると、そのリソースロケーションとルーティングタイプを変更できます。このルーティング例外は、アクセスポリシー内のすべてのユーザーにのみ適用されます。
   • トグルがオフの場合: ドメインの既存のルーティング例外は削除され、適用されません。エンドユーザーは、アプリケーション設定時に設定されたグローバル構成に基づいてのみルーティングされます。
   ルーティングタイプの変更(/en-us/citrix-secure-private-access/media/spa-modify-app-routing-type.png)
3. ルーティングタイプを変更するドメインの横にある編集アイコンをクリックします。
4. ルーティングタイプで、ルーティングタイプを変更します。
   • 内部: トラフィックはコネクタアプライアンスを経由して流れます。
     • Webアプリの場合、トラフィックはデータセンター内で流れます。
     • SaaSアプリの場合、トラフィックはコネクタアプライアンスを介してネットワーク外にルーティングされます。
   • 内部 – プロキシバイパス: ドメインのトラフィックはCitrix Cloud Connector™アプライアンスを介してルーティングされ、コネクタアプライアンスで構成された顧客のWebプロキシをバイパスします。
   • 外部: トラフィックはインターネットに直接流れます。
   • Google Secure Gateway経由の外部: トラフィックはGoogle Secure Gatewayを介してインターネットに流れます。
   注:
   このルーティングタイプは、Secure Private Accessクラウドおよびハイブリッド展開でGoogle Chrome Enterprise Premiumと統合された顧客のSaaSアプリにのみ適用されます。

5. 必要に応じて、リソースの場所でリソースの場所を変更します。このオプションは、内部ルーティングされたドメインにのみ適用されます。
   注:
   アプリがIPアドレスを使用して作成されている場合、ルーティングタイプリストにはコネクタ経由の内部オプションのみが表示されるため、ルーティングタイプを外部に変更することはできません。リソースの場所のみを変更できます。ただし、この制限はFQDNを使用して作成されたアプリには適用されません。
   ルーティングタイプIPの変更(/en-us/citrix-secure-private-access/media/spa-modify-app-routing-type2.png)
6. 「保存」をクリックします。

ユースケース：社内ユーザーをバックエンドアプリケーションに直接ルーティングする

Monitor でのコンテキストルーティングのインサイト

• 「ルーティングコンテキスト」：「概要」セクションの「ルーティングコンテキスト」フィールドは、ルーティング中に適用されるポリシータイプ（アクセスポリシー、セッションポリシー、またはアプリケーションドメイン）を指定します。ルーティングコンテキストは、ルーティングの決定に影響を与える優先順位の階層（アクセスポリシー > セッションポリシー > デフォルトのアプリケーション構成）を特定するのに役立ちます。
  セッションポリシーの場合、「詳細を表示」リンクはセッションポリシーに関する追加の詳細を提供します。
• アクションルーティング: ポリシー評価セクションのアクションルーティングフィールドには、ユーザーのリクエストがSecure Private Accessサービスを介して辿るルーティングパス（ダイレクト、コネクタ経由の内部、ゲートウェイ経由の内部）が表示されます。