設計手法アクセスレイヤー

設計手法の2番目のレイヤーはアクセスレイヤーです。アクセスレイヤーは、それぞれ固有のユーザーグループが定義します。

アクセスレイヤーに適した設計を作成することは、デスクトップ仮想化プロセスの重要な部分です。このレイヤーは認証を通してユーザーの検証を処理し、安全な仮想デスクトップ接続を確立するために必要なすべてのコンポーネントへのアクセスをオーケストレーションします。

アクセスレイヤーの設計で決定する事項は、各ユーザーグループのモビリティ要件と使用されるエンドポイントデバイスに基づいて決まります。

認証

リソースへのアクセスは、ユーザーのIDに基づいて行われます。認証方法の定義では、環境に対するユーザーのエントリポイントとユーザーの認証方法が考慮されます。

決定する事項:認証プロバイダー

従来、ユーザーは自身のXenAppおよびXenDesktopリソースにアクセスするのに、Active Directoryのユーザー名とパスワードが必要でした。ほとんどの組織でオンプレミスのActive Directory環境が標準だったため、この特定の要件を満たすのは簡単でした。

組織では、XenAppおよびXenDesktopリソースにアクセスするのにアカウントが必要な外部の契約社員を使用するようになっています。組織は自身でアカウントを管理する代わりに、Azure Active Directory、Google、LinkedInといったサードパーティのIDプロバイダー(Idp)の使用について調査を進めています。

Citrix Federated Authentication Serviceを実装すると、XenAppおよびXenDesktopでサードパーティのIdPの使用がサポートされます。管理者は、契約社員にはGoogleアカウントを使用して承認済みのアプリケーションやデスクトップにアクセスさせて、オンボーディングを簡素化することができます。

決定する事項:認証ポイント

ユーザーは仮想リソースに接続する前に、まず認証を受ける必要があります。認証の実施箇所は、多くの場合、ユーザーセグメンテーションプロセスの間に定義されたユーザーグループのモビリティ要件によって決まります。XenDesktopには次の2つの認証ポイントがあります:

  • Storefront - Citrix StoreFrontがCitrix Receiverへの認証およびリソースデリバリーサービスを提供するように構成して、デスクトップ、アプリケーション、およびそのほかのリソースをユーザーに配信する一拠点のエンタープライズリソースストアを作成することもできます。
  • NetScaler Gateway - NetScaler Gatewayはアプリケーションアクセスのセキュリティを保護するアプライアンスで、アプリケーションレベルのポリシーの詳細な制御機能を管理者に提供し、ユーザーがどこにいても作業できるようにします。

次の表に、ユーザーグループのモビリティ要件に応じた優先認証ポイントを示します:

ユーザーグループのモビリティ要件 優先認証ポイント
ローカル StoreFront
ローミングローカル StoreFront
リモート NetScaler Gateway
ローカル NetScaler Gateway

リモートまたはモバイルのモビリティ要件を持つユーザーグループの認証は、必要に応じてStoreFrontで直接行われます。たとえば、DMZセキュリティポリシーにより、NetScaler Gatewayからドメインへにアクセスできない場合があります。これは、スマートカードクライアント証明書認証をサポートするために必要です。認証のためのStoreFrontへのアクセスは、httpsトラフィックのルートを提供するNetScaler SSL_BRIDGE仮想サーバーを介して配信される場合があります。通常、仮想サーバーは、仮想デスクトップ環境へのHDXプロキシアクセスを提供するように構成された同じNetScaler上のNetScaler Gatewayと共にホストされます。このようなユースケースが必要な場合もありますが、ベストプラクティスとして推奨されるのは、NetScaler Gatewayを介した外部ユーザーの認証です。

決定する事項:認証ポリシー

認証ポイントを特定したら、認証の種類を決める必要があります。利用可能な主な方法は次のとおりです:

  • StoreFront - さまざまな認証方法がサポートされますが、ユーザーのアクセス方法、セキュリティ要件、ネットワークの場所によっては推奨されない方法もあります。デフォルトでは、StoreFrontはWeb InterfaceのようにXMLを介してではなく、Active Directoryを使ってユーザーを直接認証します。StoreFront 3.0以降は、必要に応じて(StoreFrontサーバーがユーザードメインを信頼しないドメイン内にある場合など)認証をXMLに委任するようにオプションで設定できます。
    • ユーザー名とパスワード - ユーザーはユーザー名とパスワードを入力してサイトに直接ログオンする必要があります。
    • ドメインパススルー - ユーザーデバイスからのドメイン資格情報のパススルーを許可します。この場合、ユーザーはドメインに参加しているWindowsコンピューターにログオンするときに認証されるため、ストアにアクセスするときは自動的にログオンできます。
    • NetScaler Gatewayパススルー - NetScaler Gatewayからのパススルー認証を許可します。ユーザーはNetScaler Gatewayにログオンするときに認証されるため、ストアにアクセスするときは自動的にログオンできます。
    • スマートカード - Citrix Receiver for WindowsおよびNetScaler Gatewayを介したスマートカードとPINの使用による認証を許可します。スマートカード認証を有効にする場合、StoreFrontサーバーが属しているMicrosoft Active Directoryドメインか、そのドメインと直接の双方向の信頼関係が設定されているドメインのいずれかにユーザーアカウントが属している必要があります。一方向の信頼関係または異なる種類の信頼関係を含んでいるマルチフォレスト展開環境はサポートされません。
    • 匿名ユーザー - StoreFrontまたはCitrix Receiverでの認証が不要なアプリケーションやデスクトップへのアクセスを許可します。セッションが開始されると、ローカルの匿名アカウントがサーバーVDA上にオンデマンドで作成されます。これには、認証されていないアクセス用に設定されたStoreFrontストア、サーバーOSベースのVDA、および認証されていないユーザー用に設定されたXenAppデリバリーグループが必要です。
  • NetScaler Gateway - NetScaler Gatewayはいくつかの認証方法をサポートしています。以下のリストには、仮想デスクトップ環境で主に使用される認証方法が示されています。それぞれ個別に使用できますが、組み合わせて多要素認証として使用されることもよくあります。
    • LDAP - ライトウェイトディレクトリアクセスプロトコル(LDAP)は、Microsoft Active Directoryなどのディレクトリ情報サービスにアクセスするために使用されます。NetScaler GatewayはLDAPを使用してユーザーを認証し、そのグループメンバーシップ情報を抽出します。
    • RADIUS(トークン) - リモート認証ダイヤルインユーザーサービス(RADIUS)は、認証、承認、およびアカウンティングを提供するUDPベースのネットワークセキュリティプロトコルです。ネットワークアクセスサーバー(この場合はNetScaler Gateway)がRADIUSサーバーに資格情報を転送します。RADIUSサーバーは、資格情報をローカルでチェックするかディレクトリサービスと照合してチェックできます。その後、RADIUSサーバーが接続の受け入れまたは拒否、またはトークンなどの第2の形式の認証のチャレンジおよび要求を行います。
    • クライアント証明書 - Netscaler Gateway仮想サーバーにログオンするユーザーは、仮想サーバーのクライアント証明書の属性に基づいて認証することもできます。クライアント証明書は通常、スマートカードまたはCommon Access Card(CAC)の形式でユーザーに配布され、それらは各ユーザーデバイスに接続されたリーダーによって読み取られます。

ユーザーグループの認証の種類はたいてい、セキュリティ要件と使用される認証ポイントに基づいて決定されます。次の表は、必要なセキュリティレベルに基づいて、各ユーザーグループに適したソリューションを定義するのに役立ちます:

認証ポイント セキュリティ要件 認証の種類
StoreFront 低、中、高 低:LDAPのユーザー名とパスワード。パススルー。中:LDAPのユーザー名とパスワード。パススルー。高:LDAPまたはスマートカード、またはその両方
NetScaler Gateway 低、中、高 低:LDAPのユーザー名とパスワード。中:LDAPのユーザー名とパスワード。高:LDAPとトークン。 LDAPとスマートカード。トークンとスマートカード

実際の例

  • 小売 - ある小規模な民間小売企業では、仮想デスクトップユーザーが、マーケティングカタログやメールなどの機密性の低いデータにアクセスできます。それらのユーザーは、Sarbanes Oxleyなどのセキュリティ規制を遵守する必要がありません。そのため、ユーザー名とパスワードに基づいたLDAP認証が実装されています。
  • 財務 - ある中規模の金融企業では、仮想デスクトップユーザーが、銀行取引記録などの機密データにアクセできます。これらのユーザーは、米国監査基準(SAS)第70号などのセキュリティ規制によって管理され、リモートアクセスユーザー向けの多要素認証を使用する必要があります。ユーザー名とパスワードに基づいたLDAP認証が、トークンを使用したRADIUS認証とともに実装されています。
  • 政府 - ある大規模な連邦機関では、仮想デスクトップユーザーが、一般市民の個人レコードなどの機密性の高いデータにアクセスできます。これらのユーザーは、国防総省(DOD)のセキュリティ標準による規制の対象となっています。ユーザー名とパスワードに基づいたLDAP認証が、CACカードを使用したクライアント証明書認証とともに実装されています。
  • ヘルスケア - ある病院は、XenAppを使用してEMRアプリケーションをユーザーに配信しています。据え付けと移動式のカート上のThinClientデバイスを、医師や看護師が患者データを取得するために使用します。医療スタッフがドメインやEMRアプリケーションに対して認証を受ける必要がないように、認証不要アクセスが設定されています。

StoreFront

Citrix StoreFrontは、XenAppおよびXenDesktopリソースに対してユーザーを認証します。StoreFrontでは、利用可能なデスクトップとアプリケーションが単一のインターフェイスに集約されて列挙され、ユーザーはCitrix Receiver for Windows、iOS、Android、またはStoreFrontのWebサイトを介してそれにアクセスできます。

決定する事項:高可用性

StoreFrontをホストしているサーバーが利用できない場合、ユーザーは新しい仮想デスクトップや公開アプリケーションを起動したり、サブスクリプションを管理したりできません。したがって、このコンポーネントが単一障害点にならないようにするために、少なくとも2つのStoreFrontサーバーを展開する必要があります。負荷分散ソリューションを実装することで、ユーザーはサービスの中断に直面しなくなります。次のオプションがあります:

  • ハードウェア負荷分散 - StoreFrontサービスの可用性を検証し、ユーザーの要求を適切に負荷分散できるインテリジェントなアプライアンスです。Citrix NetScalerは、ハードウェアロードバランサーの優れた例です。Citrix NetScalerは、事前設定済みのStoreFrontヘルスチェックが付属しした理想的なロードバランサーです。
  • ドメインネームシステムラウンドロビン - 可用性チェックを実行せずに、基本的な複数サーバーでの負荷分散を提供します。StoreFrontサーバーが使用できなくなった場合でも、ドメインネームシステムラウンドロビンは障害が発生したサーバーにユーザーをルーティングします。このため、シトリックスはドメインネームシステムラウンドロビンを推奨していません。
  • Windowsネットワーク負荷分散 - サーバーが使用可能であることを検証する基本チェックを実行できるWindowsサービスですが、個別のサービスの状態は判別できません。これにより、ユーザーが、新しいリクエストを処理できないStoreFrontサーバーに転送される可能性があります。その場合、ユーザーはアプリケーションやデスクトップにアクセスできなくなります。

決定する事項:Delivery Controllerの参照

ユーザーがデスクトップとアプリケーションを提供するには、XenDesktopサイトとXenAppサイトのそれぞれで、1つ以上のControllerのIPアドレスまたはドメインネームシステム名をStoreFrontに設定する必要があります。フォールトトレランスのために、指定された各サイトまたはファーム、またはその両方で、複数のControllerを入力する必要があります。デフォルトでは、StoreFrontはフェイルオーバー順のサーバーのリストを扱います(アクティブ/パッシブ)。

ログオンの負荷が高い大規模な展開または環境の場合は、ユーザー負荷のアクティブな分散(アクティブ/アクティブ)が推奨されます。これを実現するには、Citrix NetScalerなどの組み込みXMLモニターが付属したロードバランサーを使用するか、またはControllerのリストを順序付きリストとして扱うのではなく負荷分散するようにStoreFrontを設定します。

決定する事項:ビーコン

Citrix Receiverはビーコン(Webサイト)を使用して、ユーザーが内部ネットワークと外部ネットワークのどちらに接続されているかを特定します。内部ユーザーは認証のためにStoreFrontに直接接続され、外部ユーザーはCitrix NetScaler Gatewayを介して接続されます。どのビーコンにアクセスできるかによってアプリケーションを制限することで、ユーザーに表示される内容を制御することができます。

内部ビーコンは、外部から解決できないサイトにする必要があります。デフォルトでは、内部ビーコンはStoreFrontベースURLです。外部URLと内部URLに同じURLが設定されている場合、これを調整する必要があります。外部ビーコンは、HTTP応答を生成する任意の外部サイトに設定できます。Citrix Receiverはネットワーク接続の状態(たとえば、リンクアップ、リンクダウン、デフォルトゲートウェイの変更など)を継続的にモニターします。状態の変化が検出されると、Citrix Receiverは最初に内部ビーコンポイントにアクセスできることを確認してから、外部ビーコンポイントにアクセスできるかを確認します。StoreFrontは、最初の接続および構成ダウンロードプロセス中に、ビーコンポイントのHTTP(HTTPS)アドレスをCitrix Receiverに提供し、必要に応じてアップデートも提供します。パブリックネットワーク上で解決できる、可用性の高い外部ビーコンを2つ以上指定する必要があります。

決定する事項:リソースの表示

StoreFrontでは、デフォルトで、ログオンした後に定期的に使用するリソース(お気に入り)を選ぶ(サブスクライブする)ことができます。この「セルフサービス」のような手法により、ホーム画面に表示するリソースを、定期的に使用するリソースに制限できます。それぞれのストアで各ユーザーが選択したリソースは、サブスクリプションストアサービスによって記録され、各StoreFrontサーバーにローカルに保存されます(同じサーバーグループ内のサーバー間で自動的に同期されます)。これにより、接続されているすべてのデバイスから、Citrix Receiverのホーム画面にそれらのリソースを表示できます。デフォルトでは、サブスクリプションはストアごとおよびサーバーグループごとですが、管理者はサーバーグループ内に2つのストアを構成して、サブスクリプションデータベースを共有したり、必要に応じて、定義したスケジュールに従って2つの同じ名前のストア間でサブスクリプションを同期したりできます。

管理者は、ユーザーのホーム画面や機能タブに常に表示するアプリケーションを決める必要があります。通常、これらのアプリケーションは、Microsoft Office Suiteなどの一般的なアプリケーションや、環境内のすべてのユーザーに必要な可能性があるその他のアプリケーションです。StoreFrontは、公開アプリケーションのプロパティの[説明]フィールドに定義されたキーワードを使用して、これらのリソースをフィルタリングまたは表示できます。

次の表では、キーワードオプションについて説明します:

キーワード 説明
自動 ストアのすべてのユーザーを自動的にアプリケーションにサブスクライブします。ユーザーがストアにログオンすると、そのアプリケーションを手動でサブスクライブしなくても自動的にプロビジョニングされます。必要に応じて、ユーザーが後でこのサブスクリプションを削除することもできます。
固定 StoreFront 2.5の新機能である固定キーワードを使用すると、アプリケーションはストアのユーザーに自動的にサブスクライブされます。ただし、ユーザーがアプリケーションを削除することはできません。この設定は、すべてのユーザーに対して常に表示する必要があるアプリケーションの基本セットを作成する場合に便利です。
おすすめ ユーザーが特定のアプリケーションに簡単にアクセスできるようにするために、そのアプリケーションをユーザーのCitrix Receiverの[おすすめ]一覧に表示できます。
優先 Citrix Receiverで提供されるアプリケーションではなく、ローカルにインストールされたアプリケーションが使用されるように指定します。Citrix Receiverは指定された名前やパスを検索して、アプリケーションがローカルにインストールされているかどうかを判別します。アプリケーションがローカルにインストールされている場合、Citrix Receiverはそのアプリケーションをサブスクライブし、ショートカットは作成しません。ユーザーがReceiverからそのアプリケーションを起動すると、ローカルにインストールされたアプリケーション(ここでは「優先アプリケーション」と呼びます)が起動します。ユーザーがReceiverを使用せずに優先アプリケーションをアンインストールすると、Receiverの次回更新時までそのアプリケーションのサブスクリプションは解除されます。ユーザーがReceiverを使用して優先アプリケーションをアンインストールすると、Receiverはそのアプリケーションのサブスクリプションを解除しますが、アンインストールはしません。
TreatAsApp Receiver for Webサイトのデフォルトでは、XenDesktop VDIデスクトップおよびXenAppでホストされる共有デスクトップはほかのデスクトップと同じように表示されます。キーワード「TreatAsApp」を使用すると、デスクトップはデスクトップビューではなくReceiver for Webサイトのアプリケーションビューに表示されます。ユーザーがデスクトップにアクセスするには、サブスクライブする必要があります。
プライマリ 複数サイト環境の場合、このキーワードを使用すると、指定したサイトからアプリケーションが配信されます。アプリケーションが同じ名前で複数のサイトから使用可能な場合、セカンダリサイトのアプリケーションは、プライマリサイトから使用できない場合にのみ表示されます。
セカンダリ セカンダリサイトのアプリケーションを指定する点を除き、「プライマリ」のキーワードの説明と同じ内容となります。

決定する事項:集合体グループ

XenApp/XenDesktopソリューションに複数のデリバリーサイトが含まれる場合、StoreFrontは使用可能なリソースをマージするため、ユーザーは公開されたすべてのリソースに対して単一のインターフェイスを使用できます。ただし、1つのアプリケーションが複数回表示されるため、複数のサイトで同じリソースを公開している場合、ユーザーが混乱する可能性があります。

アグリゲーションなしのユーザーエクスペリエンスの画像

StoreFront集合体グループは、複数のサイトのリソースをマージしてユーザーに単一のわかりやすいビューを提供する方法を定義します。StoreFrontは、重複した公開リソースを単一のアイコンに集約します。

アグリゲーションありのユーザーエクスペリエンスの画像

アイコンがアグリゲーションの場合、管理者が異なるXenApp/XenDesktopサイトでユーザーをどのように負荷分散するかを決める必要があります。使用できるオプションは、次のとおりです:

  • 負荷分散 - 重複サイトが推奨容量に基づいて作成される場合に使用されます。StoreFrontは、構成されたすべてのサイトにユーザー要求を分散します。
  • フェイルオーバー - 停止時に地理的にリソースを使用可能にする必要がある場合、または(XenAppの移行プロジェクトのように)あるサイトから別のサイトにユーザーを移行する場合に使用されます。

設計段階でユーザー、ストア、集約方法を文書化することをお勧めします。

ユーザーグループ 使用可能なストア 負荷分散ストア フェイルオーバーストア
NA_FinanceUsers NA_West_Store、NA_East_Store、EMEA_Store NA_West_Store、NA_East_Store EMEA_Store
EMEA_SalesUsers EMEA_Store、NA_East_Store EMEA_Store NA_East_Store

決定する事項:スケーラビリティ

単一のStoreFrontサーバーでサポートするCitrix Receiverユーザーの数は、割り当てられたリソースとユーザーアクティビティのレベルにより異なります。Receiver for Webユーザーは、平均的にネイティブのCitrix Receiverユーザーよりも多くのRAMを消費しますが、どんな場合も、ベースラインとしてStoreFrontサーバーごとに最低4GBのRAMが推奨されます。さらに、ストアごとに列挙されるサイトやファームがさらに多くなれば、CPU使用率とサーバーの応答時間の両方が増加し、スケーラビリティに与えるXenApp IMAファームの影響は、XenApp/XenDesktop FMAサイトよりも大きくなります。

StoreFront展開環境 CPU使用率 同時アクティビティ
スタンドアロン展開環境:4CPU、4GB RAM、多用(ログオン、列挙、サブスクライブ、サブスクリプションの解除、ログオフ) 75% 1秒あたり291
スタンドアロン展開環境:4CPU、4GB RAM、多用(ログオン、列挙、サブスクライブ、サブスクリプションの解除、ログオフ) 90% 1秒あたり375
クラスターStoreFront展開環境。 それぞれ2ノード:4CPU、4GB RAM、多用(ログオン、列挙、サブスクライブ、サブスクリプションの解除、ログオフ) 75% 1秒あたり529
クラスターStoreFront展開環境。 それぞれ2ノード:4CPU、4GB RAM、多用(ログオン、列挙、サブスクライブ、サブスクリプションの解除、ログオフ) 90% 1秒あたり681

1つのStoreFront展開環境が拡張されてStoreFrontノードが3~4台を超え、単一のサーバーグループで最大5~6台のサーバーがサポートされるようになると、テストで収穫逓減が示されます。

NetScaler Gateway

NetScaler Gatewayを認証ポイントとして使用するユーザーグループは、設計上の決定事項をさらに考慮する必要があります。これらの設計上の決定事項は、NetScaler Gateway認証ポイント以外には適用されません。

決定する事項:トポロジ

ネットワークトポロジの選択は、必要な機能、パフォーマンス、およびセキュリティを確実にサポートできるようにリモートアクセスアーキテクチャを計画する上で重要です。リモートアクセスアーキテクチャの設計は、企業のセキュリティ要件が順守されるように、セキュリティチームと連携して行う必要があります。考慮すべき2つの主要なトポロジがあり、それぞれがセキュリティレベルの向上をもたらします:

  • 1アーム(通常のセキュリティ) - 1アームトポロジでは、NetScaler Gatewayは1つの物理または論理結合インターフェイスを使用して、関連付けられたVLANとIPサブネットにより、ユーザーのフロントエンドトラフィックと、仮想デスクトップインフラストラクチャサーバーおよびサービスのバックエンドトラフィックの両方を転送します。

アームトポロジの画像

  • 2アーム(高セキュリティ) - 2アームトポロジでは、NetScaler Gatewayは、関連付けられたVLANとIPサブネットにより、2つ以上の物理または論理結合インターフェイスを利用します。ユーザーへのフロントエンドトラフィックの転送は、これらのインターフェイスの1つに向けられます。フロントエンドトラフィックは、仮想デスクトップインフラストラクチャサーバーとサービス間のバックエンドトラフィックから分離され、2つ目のインターフェイスに転送されます。これにより、個別の非武装地帯(DMZ)の使用が可能になり、ファイアウォールをきめ細かく制御してモニターしながら、フロントエンドとバックエンドのトラフィックフローを隔離できます。

アームトポロジーの画像

決定する事項:高可用性

NetScaler Gatewayが利用できない場合、リモートユーザーは環境にアクセスできません。したがって、このコンポーネントが単一障害点にならないようにするために、少なくとも2つのNetScaler Gatewayホストをデプロイする必要があります。

NetScaler Gatewayを高可用性(アクティブ/パッシブ)ペアとして構成する場合、セカンダリNetScaler Gatewayは、ハートビートメッセージ(ヘルスチェック)とも呼ばれる定期的なメッセージを送信して最初のアプライアンスをモニターし、最初のアプライアンスが接続を受け入れているかどうかを判別します。ヘルスチェックが失敗した場合、セカンダリNetScaler Gatewayが、プライマリアプライアンスが機能していないと判断するまで、指定された時間、接続を再試行します。セカンダリアプライアンスがヘルスチェックの失敗を確認すると、セカンダリNetScaler GatewayがプライマリNetScaler Gatewayを引き継ぎます。

ファームウェア10.5以降では、クラスタリングも可能で、複数のNetScaler Gatewayインスタンスで高可用性を実現できます。ただし、スポット構成とストリップ構成のサポートはファームウェアとゲートウェイ構成によって異なります(完全SSL VPNとICAプロキシ)。 (https://docs.citrix.com/ja-jp/netscaler/11-1/clustering/cluster-features-supported.html

決定する事項:プラットフォーム

プロジェクトの要件を満たす適切なNetScalerプラットフォームを特定するためには、主要なリソース制約を特定する必要があります。すべてのリモートアクセストラフィックはSecure Sockets Layer(SSL)を使用して保護され、HTTP形式のハイパーテキスト転送プロトコル(HTTP)によって転送されるため、対象となるリソースメトリックは次の2つとなります:

  • SSLスループット - SSLスループットは、1秒あたりに処理される可能性があるギガビット単位のSSLトラフィックです(Gbps)。
  • 1秒あたりのSSLトランザクション(TPS) - TPSメトリックは、アプリケーションデリバリーコントローラー(ADC)が1秒間に何回SSLトランザクションを行うかを特定します。容量は主に必要なキー長によって異なります。TPS容量は、SSLを最初に設定するときのネゴシエーションフェーズ中の主な考慮事項であり、セッション寿命の大半を占める一括暗号化/暗号化解除フェーズではあまり重要ではありません。TPSはモニターのための重要な測定基準ですが、実地経験では、適切なNetScaler Gatewayを特定するうえではSSLスループットが最も重要な要素であることが示されています。

SSL帯域幅のオーバーヘッドの平均は、仮想デスクトップトラフィックの量と比べるとごく少量とみなされることが多く、通常は必要なSSLスループットの一部としては考慮されません。ただし、SSL帯域幅のプロビジョニングを行うと、推定される総スループットが十分に確保されます。パケットヘッダーに追加される固定帯域幅は、使用される暗号化アルゴリズムによって異なることがあり、帯域幅全体の割合はパケットサイズによって大きく異なる場合があります。理想的には、オーバーヘッドは概念実証中またはパイロット中に測定します。ただし、そのようなデータがない場合は、ワークロード帯域幅を2%増加させるのが妥当な目安になります。したがって、NetScalerプラットフォームに必要なSSLスループットを判別するには、データセンターの最大同時帯域幅に1.02を掛けます:

SSLスループット=最大同時帯域幅×1.02

たとえば、最大同時帯域幅が128Mbpsの場合、適切なNetScalerモデルは次のように決定できます:

~130Mbps=128Mbps×1.02

SSLスループットの値をさまざまなNetScalerプラットフォームのスループット機能と比較して、環境に最も適したものを決定する必要があります。利用可能な主要なプラットフォームグループは3つあり、それぞれが幅広いスケーラビリティオプションを提供します。

  • VPX - NetScaler VPXデバイスは、ハードウェアNetScalerと同じ全機能を提供します。ただし、NetScaler VPXはホスティングに「既製の」サーバーを利用できるため、小規模から中規模の環境に適しています。通常、組織はVPXインスタンスのベースライン上限を500ユーザーとして作成します。
  • MPX - NetScaler MPXは、NetScalerデバイスのハードウェアバージョンです。MPXデバイスは仮想NetScalerよりも強力であり、大規模なエンタープライズ展開のネットワーク最適化をサポートできます。特にSSLオフロードが構成される場合、VPX上ではソフトウェアで行われるのに対してMPX上では専用SSLチップで行われるためです。
  • SDX - NetScaler SDXは、仮想および物理NetScalerデバイスを組み合わせたものです。SDXマシンは、複数の仮想NetScalerデバイスをホストできる物理デバイスです。このようなデバイスの統合により、必要なシェルフスペースとデバイスの統合を削減できます。NetScaler SDXは、大企業の環境やマルチテナントホスティングプロバイダー向けのネットワーク通信の処理に適しています。

NetScalerプラットフォームのSSLスループット機能は、「Citrix NetScalerデータシート(英語)」に記載されている場合があります。したがって、上記の計算例を基にすると、NetScaler MPX 5550アプライアンスは必要な負荷を処理するのに十分です。ただし、実際のスケーラビリティはセキュリティ要件によって異なります。NetScalerのSSLスループットは、暗号化アルゴリズムが複雑さを増し、キー長が長くなると低下します。なお、この計算は単一のプライマリNetScalerに関するものです。最低でもN+1の冗長性が推奨されます。この構成では、同一のプラットフォームとモデルのNetScalerを追加する必要があります。

通常、Citrix NetScalerデータシートには、最適なパフォーマンス条件下でのスループット能力が示されています。ただし、パフォーマンスはセキュリティ要件の影響を直接受けます。たとえば、RC4暗号化アルゴリズムと1kのキー長が使用されている場合、VPXプラットフォームは500を超えるHDXプロキシ接続を処理できる可能性があります。ただし、3DES暗号化アルゴリズムと2kのキー長が使用されている場合(これが一般的になりつつあります)、スループットは半分になる可能性があります。

決定する事項: 事前認証ポリシー

オプションの事前認証ポリシーは、NetScaler Gatewayを認証ポイントとするユーザーグループに適用できます。事前認証ポリシーは、エンドポイント分析(EPA)スキャンによってエンドポイントが特定の基準を満たすかどうかに基づいて、環境へのアクセスを制限します。

事前認証アクセスポリシーは、ウイルス対策、ファイアウォール、オペレーティングシステム、さらにはレジストリ設定をテストするように設定できます。これらのポリシーを使用して完全にアクセスできないようにすることも、これらのポリシーをXenDesktopで使用してクリップボードマッピング、プリンターマッピング、特定のアプリケーションやデスクトップの可用性などのセッション機能を制御することもできます。たとえば、ユーザーデバイスにウイルス対策ソフトウェアがインストールされていない場合は、機密性の高いアプリケーションを表示しないようにフィルターを設定できます。

次の図に、複数のポリシーを使用して仮想化リソースの機能をカスタマイズする方法の概要を示します:

スマートアクセス決定ロジックの画像

実際の例

  • 小売 - ある小規模の民間小売企業は、EPAを使用して、更新されたウイルス対策定義があるかどうかをスキャンしてから、アクセスを許可しています。
  • 財務 - ある中規模の金融機関は、EPAを使用してドメインSIDをスキャンし、ユーザーが企業ドメインのメンバーであることを確認してから、アクセスを許可しています。
  • 政府 - ある大規模な連邦機関は、EPAを使用してエンドポイントデバイスをスキャンし、特定の証明書(または証明書のセット)がデバイスにインストールされているかを確認してから、アクセスを許可しています。

決定する事項:セッションポリシー

NetScaler Gatewayを認証ポイントとして使用するユーザーグループには、対応するセッションポリシーを定義する必要があります。セッションポリシーは、認証後の全体的なユーザーエクスペリエンスを定義するために使用されます。

組織は、使用するCitrix Receiverの種類に基づいてセッションポリシーを作成します。セッションポリシーを割り当てるために、デバイスは通常、非モバイル(Windows、Mac、Linux OSベースなど)かモバイル(iOSまたはAndroid)のいずれかに分類されます。したがって、モバイルデバイス、または非モバイルデバイス、またはその両方をサポートするかどうかは、評価の段階で特定されたクライアントデバイスの要件に基づいて決定する必要があります。

デバイスのセッションポリシーを特定するには、こちらの記事で説明するような式を含めます。

  • モバイルデバイス - 式はREQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiverに設定されます。この式には非モバイルデバイスポリシーよりも高い優先度が与えられるため、モバイルデバイスは一致しますが、非モバイルデバイスは一致しません。
  • 非モバイルデバイス - 式はns_trueに設定されます。これは、この式がデバイスに送信されるすべてのトラフィックに適用されることを意味します。

セッションポリシーの別の用途として、エンドポイント分析式の適用があります。これらのセッションポリシーには事後認証が適用されますが、前述の「事前認証ポリシー」と似ています。セッションポリシーの使用は、特定のアプリケーションに対する読み取り専用アクセスなど、セキュリティ要件を完全には満たしていないエンドポイントにフォールバックシナリオを提供するためのオプションです。

決定する事項:セッションプロファイル

各セッションポリシーには、対応するセッションプロファイルが定義されている必要があります。セッションプロファイルには、ユーザーグループが環境にアクセスするために必要な詳細が定義されます。仮想デスクトップ環境へのアクセス方法を決定するセッションプロファイルには、主に2つの形式があります:

  • SSLVPN - ユーザーは仮想プライベートネットワークを作成し、IPアドレスによって設定されたすべてのトラフィックを内部ネットワーク経由でトンネリングします。ユーザーのクライアントデバイスは、内部ネットワーク上にあるかのように、許可されたイントラネットリソースにアクセスできます。これには、XenDesktopサイト、およびファイル共有やイントラネットWebサイトなどのその他の内部トラフィックが含まれます。ネットワークポートと仮想デスクトップインフラストラクチャの外部にあるサービスへのルートが開かれ、企業はVPNへのフルアクセスに伴うリスクにさらされるため、これは安全性が低いアクセス方法とみなされる場合があります。これらのリスクには、サービス不能攻撃、内部サーバーへのハッキングの試行、またはその他の悪質な行為が含まれます。それはインターネットベースのクライアント経由で侵入したマルウェア、トロイの木馬、またはその他のウイルスにより、脆弱なエンタープライズサービスに対し、ルートやポートを介して引き起こされる可能性があります。

SSLVPNが必要な場合に考慮すべきもう1つの決定事項は、クライアントネットワークトラフィックに対して分割トンネリングを有効にするかどうかです。分割トンネリングを有効にすると、Citrix Receiverによってイントラネットに転送されたクライアントネットワークトラフィックが、特定のサービスに関連付けられたルートとポートに制限される場合があります。分割トンネリングを無効にすると、すべてのクライアントネットワークトラフィックがイントラネットに転送されるため、内部サービス宛てのトラフィックと外部サービス(インターネット)宛てのトラフィックの両方が企業ネットワークを通過します。分割トンネリングを有効にする利点は、企業ネットワークの公開が制限され、ネットワーク帯域幅が確保されることです。分割トンネリングを無効にする利点は、Webフィルターや侵入検知システムなどのシステムを介してクライアントトラフィックをモニターまたは制御できることです。

SSL VPNの画像

  • HDXプロキシ - HDXプロキシを使用すると、ユーザーは内部アドレスを外部に公開することなく、NetScaler Gatewayを介して自身の仮想デスクトップおよびアプリケーションに接続できます。この構成では、NetScaler GatewayはMicro VPNとして機能し、HDXトラフィックのみを処理します。プライベートメールや個人のインターネットトラフィックなど、クライアントのエンドポイントデバイス上の他のタイプのトラフィックは、NetScaler Gatewayを使用しません。

使用するエンドポイントとCitrix Receiverに基づいて、各ユーザーグループでこの方法がサポートされるかを判断する必要があります。デスクトップセッションに固有のトラフィックのみが企業のインフラストラクチャへを通過できるため、HDXプロキシはリモート仮想デスクトップにアクセスする安全な方法と考えられています。Citrix Receiverの大半がHDXプロキシをサポートしており、これが推奨される方法です:

HDXプロキシの画像

決定する事項:優先データセンター

多くの企業は、ミッションクリティカルなアプリケーションで高可用性を実現する複数のアクティブなデータセンターを保有しています。このカテゴリに分類される仮想デスクトップまたはアプリケーションもありますが、特定の優先データセンターからのみアクセスされるものもあります。したがって、複数のアクティブなデータセンターのある環境でユーザーが認証を受ける最初のNetScaler Gatewayは、ユーザーのVDIリソースに対応する優先データセンター内にない場合があります。StoreFrontは、ユーザーに割り当てられたリソースの場所を特定し、それらのリソースにHDXセッションを送信できます。ただし、結果として得られるパスはサブオプションです(LAN接続ではなく、NetScaler Gatewayから仮想デスクトップ/アプリケーションリソースへのWAN接続)。

HDXセッションをプライマリデータセンターの仮想デスクトップリソースに送信する方法には、静的な方法と動的な方法があります。どちらの方法を選択するかは、サイトリンクを動的に割り当てるテクノロジの可用性に基づいて決定する必要があります。それらのテクノロジには、グローバルサーバー負荷分散(GSLB)のほか、イントラネットとインターネットの帯域幅のネットワーク評価や、QoS(サービス品質)機能などがあります。

GSLBの静的な方法と動的な方法の設定について詳しくは、シトリックスの製品ドキュメント「GSLBの近接度の設定」を参照してください。

静的

  • 直接 - プライマリデータセンターのNetScaler Gateway専用のAレコードにマッピングされた完全修飾ドメイン名がユーザーに付与され、ユーザーは世界中のどこからでも仮想デスクトップに直接アクセスできます。この方法では、動的割り当てによる複雑さが解消されます。ただし、この方法ではフォールトトレランスのオプションもなくなり、プライマリデータセンターの機能停止がアクセスインフラストラクチャに限定されている場合に、代替イントラネットパスを介して仮想デスクトップにアクセスする機能などが使用できなくなります。

動的

  • イントラネット - 動的環境の大半では、認証用に選択されている最初のデータセンターはユーザーの最も近くにあります。GSLBの動的近接度などのプロトコルにより、ユーザーのローカルDNSサーバーとNetScaler Gateway間の最小遅延が計算されます。その後、デフォルトで、HDXセッションは同じNetScaler Gatewayを経由して、ユーザーの仮想デスクトップとアプリケーションをホストするデータセンターにルーティングされます。この方法の利点は、HDXセッションの大部分が、QoS(サービス品質)が使用される可能性がある社内WANを通過することです。

イントラネット接続の画像

  • インターネット - バックエンドのVDIデスクトップ/XenAppサーバーに最も近い代替NetScaler Gatewayを経由してHDXセッションを再ルーティングできるため、HDXセッションの大半がインターネット上を移動することになります。たとえば、米国内で専用デスクトップを持ち、ヨーロッパを旅行しているユーザーは、近接度に基づいて、ヨーロッパのデータセンターでホストされているNetScaler Gatewayに誘導される可能性があります。ただし、ユーザーがデスクトップを起動したときには、米国内にある優先データセンターでホストされているNetScaler Gatewayを介して仮想デスクトップへのHDX接続が確立されます。

この方法は、WANネットワークの使用量が(QoS(サービス品質)を犠牲にして)削減されるため、ユーザーのインターネット接続の信頼性が企業WANよりも高い可能性がある場合に推奨されます。

インターネット接続の画像

ある地理的地域内で(北米など)GSLBの複雑さにさらされることことなくフォールトトレランスが実現されるように、ジオスペシフィックな動的URLなどの方法を組み合わせて利用するお客様もいます。

サイト間の接続性

XenAppおよびXenDesktopのサイトは、複数の場所にわたるサイトにすることができます。 複数サイトソリューションを適切に実装するには、最良のユーザーエクスペリエンスを提供するために、サイト間のリンクや各場所の間のXenAppおよびXenDesktopセッションのルーティングを設計で考慮する必要があります。

決定する事項:HDX最適化ルーティング

複数サイトのXenAppおよびXenDesktopソリューションでは、最速の応答時間や最短距離などの特定の条件により、ユーザーは最適なサイトに誘導されます。これらのアルゴリズムでは、ユーザーがアクセスするリソースについては考慮されません。

ユーザーセッションのルーティングが不適切な場合、次のようになります:

HDXルーティングの画像

  1. 近接度または応答時間に基づいて、ユーザーを最も優先度の高いサイトにルーティング
  2. NetScaler Gatewayは、企業WAN内の正しいリソースにICAトラフィックをプロキシします。

理想的には、最適化されたルーティングは次のようになります:

ルーティング最適化の画像

  1. 近接度または応答時間に基づいて、ユーザーを最も優先度の高いサイトにルーティング
  2. 選択したリソースに基づいて、NetScaler Gatewayはセッションを優先サイトのNetScaler Gatewayに再ルーティングします。
  3. NetScaler Gatewayは、ローカルLAN内の正しいリソースにICAトラフィックをプロキシします。

StoreFront内の最適化されたHDXルーティングオプションを使用すると、トラフィックは企業WANから軽減され、パブリックネットワークに配置されます。

決定する事項:仮想WAN

支社が存在するシナリオでは、XenAppおよびXenDesktopの設計で、アプリケーションとデスクトップのリソースをホストするデータセンターに対する支社の接続を見積もる必要があります。支社とデータセンター間のWAN接続がユーザー要件を満たすことができない場合、全体的なユーザーエクスペリエンスが低下します。組織のWAN接続には、いくつかの選択肢があります:

  • スケールアップ - 組織は支社とデータセンターを接続するWANパイプのサイズを簡単に拡大できます。通常はかなりのコストがかかります。
  • スケールアウト - 組織は現在のWAN接続を維持し、複数の低コストな代替手段によってWAN接続を強化できます。支社とデータセンター間のすべての接続を統合することで、NetScaler SDWANのようなソフトウェア定義の仮想WANを作成します。アプライアンスは、仮想WAN内に定義されているすべてのWAN接続に、重複したネットワークパケットを送信します。WANの反対側にあるアプライアンスは、最初に到着したパケットを使用し、それ以降のパケットはすべて廃棄します。複数のリンクの状態は1日を通して変わるため、この方法により、可能な限り最高のエクスペリエンスが保証されます。

NetscalerSdWanの画像

設計手法アクセスレイヤー