Méthodologie de conception d’une couche d’accès

La deuxième couche de la méthodologie de conception correspond à la couche d’accès qui est définie pour chaque groupe d’utilisateurs.

La création d’une conception appropriée pour la couche d’accès joue un rôle important dans le processus de virtualisation de bureaux. Cette couche gère la validation de l’utilisateur par authentification et orchestre l’accès à tous les composants nécessaires à l’établissement d’une connexion de bureau virtuel sécurisée.

Les décisions de conception de la couche d’accès sont basées sur les exigences de mobilité de chaque groupe d’utilisateurs, ainsi que sur les appareils de point de terminaison utilisés.

Authentification

L’accès aux ressources est basé sur l’identité de l’utilisateur. La définition de la stratégie d’authentification prend en compte le point d’entrée de l’utilisateur dans l’environnement, ainsi que la manière dont l’utilisateur s’authentifie.

Décision – Fournisseur d’authentification

Traditionnellement, les utilisateurs avaient besoin d’un nom d’utilisateur et d’un mot de passe Active Directory pour accéder à leurs ressources XenApp et XenDesktop. Comme la plupart des entreprises ont normalisé sur un déploiement Active Directory local, cette exigence particulière était simple à satisfaire.

Les entreprises utilisent désormais des sous-traitants externes, ce qui nécessite un compte pour accéder aux ressources XenApp et XenDesktop. Elles examinent ainsi la possibilité d’utiliser un fournisseur d’identité tiers comme Azure Active Directory, Google ou LinkedIn au lieu de gérer leur propre fournisseur.

Avec la mise en œuvre du service d’authentification fédérée de Citrix (FAS), XenApp et XenDesktop prennent en charge l’utilisation d’un fournisseur d’identité tiers. Un administrateur peut demander à un sous-traitant d’utiliser son compte Google pour accéder à ses applications et bureaux approuvés, ce qui simplifie l’intégration.

Décision – Point d’authentification

Avant qu’un utilisateur se connecte à une ressource virtuelle, il doit d’abord s’authentifier. Le lieu d’authentification est souvent déterminé par les exigences de mobilité du groupe d’utilisateurs, qui ont été définies au cours du processus Segmentation utilisateur. Il existe deux points d’authentification disponibles dans XenDesktop :

  • StoreFront : Citrix StoreFront fournit des services d’authentification et de mise à disposition de ressources pour Citrix Receiver, permettant aux magasins d’entreprise centralisés de fournir des bureaux, des applications et d’autres ressources.
  • NetScaler Gateway : NetScaler Gateway est une appliance offrant un accès sécurisé et des contrôles de stratégie plus précis au niveau des applications pour les applications et les données, tout en permettant aux utilisateurs de travailler de n’importe quel emplacement.

Le tableau suivant répertorie les points d’authentification préférés en fonction des exigences de mobilité du groupe d’utilisateurs :

Exigences de mobilité du groupe d’utilisateurs Point d’authentification préféré
Local StoreFront
Itinérance locale StoreFront
Distant NetScaler Gateway
Local NetScaler Gateway

L’authentification pour les groupes d’utilisateurs nécessitant une mobilité distante ou mobile peut se produire directement sur StoreFront si nécessaire. Par exemple, les stratégies de sécurité DMZ peuvent interdire l’accès à partir de NetScaler Gateway au domaine, ce qui est nécessaire pour prendre en charge l’authentification de certificat client par carte à puce. L’accès à StoreFront pour l’authentification peut ensuite être fourni via un serveur virtuel NetScaler SSL_BRIDGE, qui fournit un canal pour le trafic https. En règle générale, le serveur virtuel est hébergé à côté d’une instance NetScaler Gateway sur la même instance NetScaler configurée pour fournir un accès proxy HDX à l’environnement de bureau virtuel. Bien qu’un tel cas d’utilisation soit parfois nécessaire, la meilleure pratique recommandée consiste à authentifier les utilisateurs externes via NetScaler Gateway.

Décision – Stratégie d’authentification

Une fois le point d’authentification identifié, le type d’authentification doit être déterminé. Les principales méthodes disponibles sont les suivantes :

  • StoreFront : prend en charge un certain nombre de méthodes d’authentification différentes, bien que toutes ne soient pas recommandées en fonction de la méthode d’accès utilisateur, des exigences de sécurité et de l’emplacement réseau. Notez que StoreFront authentifie par défaut les utilisateurs directement avec Active Directory, et non via XML comme le faisait l’interface Web. StoreFront 3.0+ peut être configuré en option pour déléguer l’authentification au service XML si nécessaire (par exemple si les serveurs StoreFront se trouvent dans un domaine qui ne fait pas confiance aux domaines utilisateur).
    • Nom d’utilisateur et mot de passe : exige que les utilisateurs se connectent directement au site en entrant un nom d’utilisateur et un mot de passe.
    • Authentification pass-through au domaine : autorise l’authentification pass-through des informations d’identification de domaine à partir des machines des utilisateurs. Les utilisateurs doivent s’authentifier sur leur ordinateur Windows membre d’un domaine et leur session est automatiquement ouverte lorsqu’ils accèdent à leurs magasins.
    • Authentification pass-through via NetScaler Gateway : autorise l’authentification pass-through à partir de NetScaler Gateway. Les utilisateurs s’authentifient sur NetScaler Gateway et leur session est automatiquement ouverte lorsqu’ils accèdent à leurs magasins.
    • Carte à puce : autorise les utilisateurs à s’authentifier à l’aide de cartes à puce et de codes PIN via Citrix Receiver pour Windows et NetScaler Gateway. Pour activer l’authentification par carte à puce, les comptes des utilisateurs doivent être configurés au sein du domaine Microsoft Active Directory contenant les serveurs StoreFront ou au sein d’un domaine doté d’une relation d’approbation bidirectionnelle directe avec le domaine du serveur StoreFront. Les déploiements contenant de multiples forêts impliquant des relations d’approbation ou d’approbation unilatérale de types différents ne sont pas pris en charge.
    • Anonyme : autorise les utilisateurs à accéder à des applications et à des bureaux sans présenter d’informations d’identification à StoreFront ou Citrix Receiver. Les comptes anonymes locaux sont créés à la demande sur le serveur VDA lorsque les sessions sont lancées. Cela nécessite un magasin StoreFront configuré pour un accès non authentifié, un VDA basé sur un OS de serveur et un groupe de mise à disposition XenApp configuré pour les utilisateurs non authentifiés.
  • NetScaler Gateway : NetScaler Gateway prend en charge plusieurs méthodes d’authentification. La liste ci-dessous inclut celles qui sont principalement utilisées dans les environnements de bureau virtuel. Chaque méthode peut être utilisée individuellement, mais elles sont souvent combinées pour fournir une authentification multifactorielle.
    • LDAP : le protocole LDAP (Lightweight Directory Access Protocol) est utilisé pour accéder aux services d’informations d’annuaire tels que Microsoft Active Directory. NetScaler Gateway utilise LDAP pour authentifier les utilisateurs et extraire leurs informations d’appartenance à un groupe.
    • RADIUS (jeton) : la méthode RADIUS est un protocole de sécurité réseau basé sur UDP qui fournit l’authentification, l’autorisation et la comptabilité. Un serveur d’accès réseau (NetScaler Gateway dans ce cas) transmet les informations d’identification à un serveur RADIUS qui peut soit vérifier les informations d’identification localement, soit les vérifier par rapport à un service d’annuaire. Le serveur RADIUS peut alors accepter la connexion, rejeter la connexion ou contester et demander une deuxième forme d’authentification telle qu’un jeton.
    • Certificat client : les utilisateurs qui ouvrent une session sur un serveur virtuel NetScaler Gateway peuvent également être authentifiés en fonction des attributs du certificat client présenté au serveur virtuel. Les certificats clients sont généralement distribués aux utilisateurs sous forme de cartes à puce ou de cartes CAC lues par un lecteur attaché à chaque machine utilisateur.

Le type d’authentification d’un groupe d’utilisateurs est souvent déterminé en fonction des exigences de sécurité, ainsi que du point d’authentification utilisé. Le tableau suivant permet de définir la solution appropriée pour chaque groupe d’utilisateurs en fonction du niveau de sécurité requis :

Point d’authentification Exigences en matière de sécurité Type d’authentification
StoreFront Faible, Moyen, Élevé Faible : nom d’utilisateur et mot de passe LDAP, authentification pass-through. Moyen : nom d’utilisateur et mot de passe LDAP, authentification pass-through. Élevé : LDAP et/ou carte à puce.
NetScaler Gateway Faible, Moyen, Élevé Faible : nom d’utilisateur et mot de passe LDAP. Moyen : nom d’utilisateur et mot de passe LDAP. Élevé : LDAP et jeton, LDAP et carte à puce, jeton et carte à puce.

Expérience sur le terrain

  • Vente au détail : une petite entreprise privée de vente au détail offre aux utilisateurs de bureaux virtuels un accès à des données non sensibles, telles que des catalogues de marketing et des e-mails. Les utilisateurs ne sont pas tenus de respecter les règles de sécurité, telles que Sarbanes Oxley. Par conséquent, l’authentification LDAP a été mise en œuvre en fonction du nom d’utilisateur et du mot de passe.
  • Institution financière : une institution financière de taille moyenne fournit à ses utilisateurs de bureaux virtuels un accès à des données confidentielles, telles que les enregistrements de transactions bancaires. Ce type d’institution est régi par des règlements de sécurité, tels que la norme SAS (Statement on Accounting Standards) 70, et est tenu d’utiliser l’authentification multifacteur pour les utilisateurs disposant d’un accès distant. L’authentification LDAP a été mise en œuvre en fonction du nom d’utilisateur et du mot de passe, ainsi que de l’authentification RADIUS à l’aide de jetons.
  • Organisme gouvernemental : une grande institution fédérale permet aux utilisateurs de bureaux virtuels d’accéder à des données hautement confidentielles, comme les dossiers personnels des citoyens. Ce type d’organisme est soumis à la réglementation par les normes de sécurité du Département de la Défense (DOD). L’authentification LDAP a été mise en œuvre en fonction du nom d’utilisateur et du mot de passe, tout comme l’authentification par certificat client à l’aide de cartes CAC.
  • Industrie de la santé : un hôpital utilise XenApp pour fournir son application EMR aux utilisateurs. Les appareils de type client fin installés sur des chariots fixes et mobiles sont utilisés par les médecins et les infirmières pour capturer et récupérer les données des patients. L’accès non authentifié a été configuré pour empêcher le personnel médical d’avoir à s’authentifier sur le domaine, ainsi que sur l’application EMR.

StoreFront

Citrix StoreFront authentifie les utilisateurs aux ressources XenApp et XenDesktop. StoreFront énumère et regroupe les bureaux et les applications disponibles dans une interface unique accessible aux utilisateurs via Citrix Receiver pour Windows, iOS, Android ou le site Web StoreFront.

Décision – Haute disponibilité

Si le serveur hébergeant StoreFront n’est pas disponible, les utilisateurs ne pourront pas lancer de nouveaux bureaux virtuels, des applications publiées ou gérer leurs abonnements. Par conséquent, au moins deux serveurs StoreFront doivent être déployés pour éviter que ce composant ne devienne un point de défaillance unique. En mettant en œuvre une solution d’équilibrage de charge, les utilisateurs ne rencontreront pas d’interruption de leur service. Les options sont les suivantes :

  • Équilibrage de la charge matérielle : une appliance intelligente capable de vérifier la disponibilité du service StoreFront et d’équilibrer activement les demandes des utilisateurs de manière appropriée. Citrix NetScaler fournit un excellent exemple d’équilibrage de charge matérielle. Il s’agit d’un outil d’équilibrage de charge idéal, préconfiguré avec les vérifications d’intégrité de StoreFront.
  • Méthode DNS « round robin » : fournit un équilibrage de charge élémentaire sur plusieurs serveurs sans effectuer de vérification de disponibilité. Si un serveur StoreFront devient indisponible, DNS round robin continue d’acheminer les utilisateurs vers le serveur défaillant. Pour cette raison, la méthode DNS « round robin » n’est pas recommandée par Citrix.
  • Équilibrage de la charge réseau Windows : service Windows capable d’effectuer des vérifications élémentaires pour vérifier que le serveur est disponible, mais incapable de déterminer l’état des services individuels. Cela peut entraîner le transfert des utilisateurs vers des serveurs StoreFront qui ne peuvent pas traiter de nouvelles demandes. L’utilisateur ne serait alors pas en mesure d’accéder aux applications ou aux bureaux.

Décision – Référence du Delivery Controller

Pour fournir aux utilisateurs des bureaux et des applications, StoreFront doit être configuré avec l’adresse IP ou le nom DNS d’au moins un contrôleur dans chaque site XenDesktop et XenApp. Pour la tolérance aux pannes, plusieurs contrôleurs doivent être saisis pour chaque site et/ou batterie spécifié(e). Par défaut, StoreFront traite une liste de serveurs dans l’ordre de basculement (actif/passif).

Pour les déploiements volumineux ou les environnements avec une charge d’ouverture de session élevée, une distribution active de la charge utilisateur (actif/actif) est recommandée. Cela peut être réalisé au moyen d’un équilibrage de charge avec des moniteurs XML intégrés, tels que Citrix NetScaler, ou en configurant StoreFront pour équilibrer la charge de la liste des contrôleurs au lieu de les traiter comme une liste ordonnée.

Décision – Balises

Citrix Receiver utilise des balises (sites Web) pour identifier si un utilisateur est connecté à un réseau interne ou externe. Les utilisateurs internes sont connectés directement à StoreFront pour l’authentification tandis que les utilisateurs externes sont connectés via Citrix NetScaler Gateway. Il est possible de contrôler ce qu’un utilisateur voit en limitant les applications en fonction de la balise à laquelle il a accès.

La balise interne doit être un site qui ne peut pas être résolu à l’extérieur. Par défaut, la balise interne est l’URL de base de StoreFront. Cette configuration doit être réglée si la même URL externe et interne est utilisée. La balise externe peut être n’importe quel site externe qui produit une réponse HTTP. Citrix Receiver surveille en permanence l’état des connexions réseau (par exemple, liaison vers le haut, liaison vers le bas ou modification de la passerelle par défaut). Lorsqu’un changement d’état est détecté, Citrix Receiver vérifie d’abord que les points de balise internes sont accessibles avant de passer à l’étape pour vérifier l’accessibilité des points de balise externes. StoreFront fournit à Citrix Receiver les adresses HTTP des points de balise pendant le processus initial de téléchargement de la connexion et de la configuration et fournit des mises à jour si nécessaire. Vous devez spécifier au moins deux balises externes hautement disponibles qui peuvent être résolues à partir des réseaux publics.

Décision – Présentation des ressources

Par défaut, StoreFront permet aux utilisateurs de choisir les ressources (s’abonner aux ressources) qu’ils veulent utiliser régulièrement après leur ouverture de session (favoris). Cette approche, dite « libre-service », permet aux utilisateurs de limiter les ressources qu’ils voient sur leur écran d’accueil à celles qu’ils utilisent régulièrement. Les ressources choisies par chaque utilisateur pour chaque magasin sont enregistrées par le service d’abonnement Subscription Store Service et stockées localement sur chaque serveur StoreFront (synchronisé automatiquement entre les serveurs du même groupe de serveurs) afin qu’elles puissent être affichées sur l’écran d’accueil Citrix Receiver à partir de n’importe quel appareil auquel l’utilisateur se connecte. Bien que les abonnements soient configurés par défaut par magasin et par groupe de serveurs, les administrateurs peuvent configurer deux magasins au sein d’un groupe de serveurs pour partager une base de données d’abonnement et/ou synchroniser les abonnements entre deux magasins comportant le même nom dans deux groupes de serveurs distincts selon un calendrier défini si nécessaire.

Les administrateurs doivent déterminer quelles applications doivent toujours être affichées sur l’écran d’accueil des utilisateurs ou sur l’onglet Sélection. En général, ces applications sont des applications courantes telles que Microsoft Office Suite et toutes les autres applications dont chaque utilisateur d’un environnement peut avoir besoin. StoreFront peut filtrer/présenter ces ressources à l’aide de mots-clés définis dans le champ de description des propriétés de l’application publiée.

Le tableau suivant couvre les options de mots clés :

Mot clé Description
Auto Abonne automatiquement tous les utilisateurs d’un magasin à une application. Lorsque les utilisateurs ouvrent une session dans le magasin, l’application est automatiquement provisionnée sans qu’ils aient à y souscrire manuellement. Les utilisateurs peuvent choisir de supprimer ultérieurement cet abonnement s’ils le souhaitent.
Mandatory Le mot clé « Mandatory » est une nouvelle propriété dans StoreFront 2.5 et permet aux utilisateurs du magasin d’être automatiquement abonnés aux applications. Toutefois, les utilisateurs n’ont pas la possibilité de supprimer l’application. Ce paramètre est utile lors de la création d’un ensemble d’applications de base qui doit toujours être présenté à tous les utilisateurs.
Featured Permet d’avertir les utilisateurs de la présence d’une application ou de faciliter la recherche des applications les plus couramment utilisées en les répertoriant dans la liste Sélection de Citrix Receiver.
Prefer Permet de spécifier l’utilisation d’une application installée localement plutôt qu’une application disponible dans Citrix Receiver. Receiver recherche le nom/le chemin spécifié pour déterminer si l’application est installée localement. Si c’est le cas, Receiver souscrit à l’application et ne crée pas de raccourci. Lorsque l’utilisateur démarre l’application à partir de la fenêtre de Receiver, Receiver démarre l’installation installée localement (préférée). Si un utilisateur désinstalle une application préférée en dehors de Receiver, l’abonnement à l’application est annulé lors de la prochaine actualisation de Receiver. Si un utilisateur désinstalle une application préférée à partir de Receiver, Receiver annule l’abonnement à l’application mais ne la désinstalle pas.
TreatAsApp Par défaut, les bureaux VDI XenDesktop et les bureaux partagés hébergés XenApp sont traités comme tout autre bureau par les sites Receiver pour Web. En utilisant le mot clé « TreatAsApp », le bureau s’affiche dans les vues de l’application de Receiver pour les sites Web plutôt que dans les vues du bureau. Les utilisateurs doivent s’abonner avant de pouvoir accéder au bureau.
Primary Lors d’un déploiement multisite, l’utilisation de ce mot clé garantit qu’une application est fournie à partir d’un site désigné. Si une application portant le même nom est disponible à partir de plusieurs sites, l’application du site secondaire n’est affichée que si l’application n’est pas disponible à partir du site principal.
Secondary Une propriété semblable au mot clé « Primary », sauf qu’elle désigne une application dans le site secondaire.

Décision – Groupes d’agrégation

Si la solution XenApp et XenDesktop inclut plusieurs sites de mise à disposition, StoreFront fusionne les ressources disponibles afin que l’utilisateur dispose d’une interface unique pour toutes les ressources publiées. Toutefois, si plusieurs sites publient les mêmes ressources, cela peut porter à confusion car une seule application apparaît plusieurs fois.

Expérience utilisateur sans image d'agrégation

Les groupes d’agrégation StoreFront définissent la fusion des ressources de plusieurs sites pour fournir à l’utilisateur un affichage unique et facile à comprendre. StoreFront regroupe les ressources publiées dupliquées en une seule icône.

Expérience utilisateur avec l'image d'agrégation

L’administrateur doit déterminer comment équilibrer la charge des utilisateurs sur les différents sites XenApp et XenDesktop lorsque l’icône est une agrégation. Les options sont les suivantes :

  • Équilibrage de charge : utilisé lorsque les sites dupliqués sont créés en fonction des recommandations de capacité. StoreFront distribue les demandes des utilisateurs sur tous les sites configurés.
  • Basculement : utilisé lorsque les zones géographiques doivent disposer de ressources en cas de panne ou lors de la migration d’utilisateurs d’un site vers un autre site (par exemple un projet de migration XenApp).

Il est conseillé de documenter les utilisateurs, les magasins et les méthodes d’agrégation pendant la phase de conception.

Groupe d’utilisateurs Magasin(s) disponible(s) Magasins d’équilibrage de charge Magasins de basculement
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

Décision – Évolutivité

Le nombre d’utilisateurs Citrix Receiver pris en charge par un seul serveur StoreFront dépend des ressources affectées et du niveau d’activité de l’utilisateur. Notez que les utilisateurs Receiver pour Web consomment plus de RAM en moyenne que les utilisateurs Receiver natifs, mais un minimum de 4 Go de RAM est recommandé par serveur StoreFront dans tous les cas en tant que ligne de base. En outre, un plus grand nombre de sites ou batteries énumérés par magasin augmente à la fois l’utilisation du processeur et le temps de réponse du serveur, les batteries XenApp IMA ayant un impact plus élevé sur l’évolutivité que le site XenApp et XenDesktop FMA.

Déploiement de StoreFront Utilisation du processeur Activités simultanées
Déploiement autonome : 4 processeurs, 4 Go de RAM, utilisation intensive (ouverture de session, énumération, abonnement, désabonnement, fermeture de session) 75 % 291 par seconde
Déploiement autonome : 4 processeurs, 4 Go de RAM, utilisation intensive (ouverture de session, énumération, abonnement, désabonnement, fermeture de session) 90 % 375 par seconde
Déploiement de cluster StoreFront : 2 nœuds, chacun avec 4 processeurs, 4 Go de RAM, utilisation intensive (ouverture de session, énumération, abonnement, désabonnement, fermeture de session) 75 % 529 par seconde
Déploiement de cluster StoreFront : 2 nœuds, chacun avec 4 processeurs, 4 Go de RAM, utilisation intensive (ouverture de session, énumération, abonnement, désabonnement, fermeture de session) 90 % 681 par seconde

Les tests ont montré une diminution des rendements après qu’un déploiement StoreFront unique dépasse 3 à 4 nœuds StoreFront avec un maximum de 5 à 6 serveurs pris en charge dans un seul groupe de serveurs.

NetScaler Gateway

Les groupes d’utilisateurs utilisant NetScaler Gateway comme point d’authentification ont des décisions de conception supplémentaires à prendre en compte. Ces décisions de conception ne s’appliquent pas aux points d’authentification autres que ceux de NetScaler Gateway.

Décision – Topologie

La sélection de la topologie de réseau est essentielle à la planification de l’architecture d’accès distant pour s’assurer qu’elle peut prendre en charge les fonctionnalités, les performances et la sécurité nécessaires. La conception de l’architecture d’accès distant doit être effectuée en collaboration avec l’équipe de sécurité afin d’assurer le respect des exigences de sécurité de l’entreprise. Il existe deux topologies principales à considérer, chacune offrant des niveaux de sécurité croissants :

  • Topologie à une branche (sécurité normale) : NetScaler Gateway utilise une interface physique ou logique liée, avec un VLAN et un sous-réseau IP associés, pour transporter à la fois le trafic frontal pour les utilisateurs et le trafic principal pour les serveurs et services d’infrastructure de bureau virtuel.

Image de topologie de branche

  • Topologie à deux branches (haute sécurité) : NetScaler Gateway utilise au moins deux interfaces physiques ou logiques liées, avec des VLAN et des sous-réseaux IP associés. Le transport du trafic frontal pour les utilisateurs est dirigé vers l’une de ces interfaces. Le trafic frontal est isolé du trafic principal (entre les serveurs et les services d’infrastructure de bureau virtuel) qui est dirigé vers une deuxième interface. Cela permet l’utilisation de zones démilitarisées (DMZ) distinctes pour isoler les flux de trafic frontal et de trafic principal, ainsi qu’un contrôle et une surveillance précis du pare-feu.

Image de topologie de branche

Décision – Haute disponibilité

Si NetScaler Gateway n’est pas disponible, les utilisateurs distants ne peuvent pas accéder à l’environnement. Par conséquent, au moins deux hôtes NetScaler Gateway doivent être déployés pour éviter que ce composant ne devienne un point de défaillance unique.

Lors de la configuration de NetScaler Gateway dans une paire haute disponibilité (actif/passif), l’instance NetScaler Gateway secondaire surveille la première appliance en envoyant des messages périodiques (également appelés messages de pulsation ou vérifications d’intégrité) afin de déterminer si la première appliance accepte les connexions. Si une vérification d’intégrité échoue, l’instance NetScaler Gateway secondaire tente à nouveau la connexion pendant une durée spécifiée jusqu’à ce qu’elle détermine que l’appliance principale ne fonctionne pas. Si l’appliance secondaire confirme l’échec de la vérification d’intégrité, l’instance NetScaler Gateway secondaire prend la relève de l’instance NetScaler Gateway principale.

Notez que dans le firmware 10.5 et supérieur, le clustering est également possible avec plusieurs instances NetScaler Gateway afin de fournir une haute disponibilité, bien que la prise en charge des configurations dites « spotted » ou « striped » varie selon le firmware et la configuration de Gateway (VPN SSL complet par rapport au proxy ICA)(https://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html).

Décision – Plate-forme

Afin d’identifier une plate-forme NetScaler appropriée pour répondre aux exigences du projet, les principales contraintes de ressources doivent être identifiées. Étant donné que tout le trafic d’accès distant est sécurisé à l’aide de SSL (Secure Sockets Layer) et transporté par HTTP (Hypertext Transfer Protocol) sous la forme HTTP, deux mesures de ressources doivent être ciblées :

  • Débit SSL : le débit SSL correspond aux gigabits du trafic SSL qui peuvent être traités par seconde (Gbits/s).
  • Transactions SSL par seconde (TPS) : la mesure TPS identifie le nombre de fois par seconde qu’une instance ADC (Application Delivery Controller) peut exécuter une transaction SSL. La capacité varie principalement en fonction de la longueur de clé requise. La capacité TPS est principalement prise en compte pendant la phase de négociation lorsque SSL est configuré pour la première fois ; elle est moins pertinente dans la phase de cryptage/décryptage en bloc, qui représente la majorité de la durée de vie de la session. Bien que TPS soit une mesure importante à surveiller, l’expérience sur le terrain a montré que le débit SSL est le facteur le plus important pour identifier l’instance NetScaler Gateway appropriée.

La charge moyenne de bande passante SSL est souvent considérée comme négligeable par rapport au volume de trafic de bureaux virtuels et n’est généralement pas prise en compte dans le débit SSL requis. Cependant, en prenant des dispositions pour la bande passante SSL, vous pouvez garantir que le débit total estimé est suffisant. La bande passante fixe ajoutée aux en-têtes de paquets peut varier en fonction des algorithmes de chiffrement utilisés ; le pourcentage global de bande passante peut également varier considérablement selon la taille du paquet. Idéalement, la charge devrait être mesurée au cours d’une preuve de concept ou d’un pilote. Toutefois, en l’absence de telles données, l’augmentation de la bande passante de la charge de travail de 2 % est une règle raisonnable. Par conséquent, pour déterminer le débit SSL requis par une plate-forme NetScaler, multipliez la bande passante simultanée maximale d’un centre de données par 1,02 :

Débit SSL = bande passante simultanée maximale x 1,02

Par exemple, en supposant une bande passante simultanée maximale de 128 Mbits/s, le modèle NetScaler approprié peut être déterminé comme suit :

~ 130 Mbits/s = 128 Mbits/s x 1,02

La valeur de débit SSL doit être comparée aux capacités de débit des différentes plates-formes NetScaler afin de déterminer la valeur la plus appropriée pour l’environnement. Trois principaux groupes de plates-formes sont disponibles, chacun offrant de nombreuses options de capacité à monter en charge.

  • VPX : un appareil NetScaler VPX offre les mêmes fonctionnalités complètes qu’une instance NetScaler matérielle. Cependant, NetScaler VPX peut exploiter les serveurs commerciaux pour l’hébergement et convient aux environnements de petite et moyenne taille. En règle générale, les entreprises créent une limite de référence pour les instances VPX à 500 utilisateurs.
  • MPX : NetScaler MPX est la version matérielle des appareils NetScaler. L’appareil MPX est plus puissant que l’instance NetScaler virtuelle et peut prendre en charge les optimisations réseau pour les déploiements d’entreprise à grande échelle, en particulier lorsque le déchargement SSL est configuré dans le logiciel sur VPX par rapport aux puces SSL dédiées sur MPX.
  • SDX: Une instance NetScaler SDX est une combinaison d’appareils NetScaler virtuels et physiques. Une machine SDX est un appareil physique capable d’héberger plusieurs appareils NetScaler virtuels. Cette consolidation d’appareils permet de réduire l’espace de stockage requis. NetScaler SDX convient à la gestion des communications réseau pour les déploiements de grandes entreprises et/ou les fournisseurs d’hébergement multi-locataire.

Vous trouverez les capacités de débit SSL des plates-formes NetScaler dans la fiche technique Citrix NetScaler. Par conséquent, en utilisant l’exemple de calcul ci-dessus, une appliance NetScaler MPX 5550 serait suffisante pour gérer la charge requise. Cependant, la capacité actuelle à monter en charge dépend des exigences de sécurité. Le débit SSL NetScaler diminue avec l’utilisation d’algorithmes de chiffrement de plus en plus complexes et des longueurs de clés plus longues. En outre, ce calcul représente une instance NetScaler principale unique. Au minimum, la redondance N+1 est recommandée, ce qui nécessite une instance NetScaler supplémentaire de la plate-forme et du modèle identiques.

Remarque

La fiche technique Citrix NetScaler représente généralement les capacités de débit dans des conditions optimales de performances. Cependant, les performances sont directement affectées par les exigences de sécurité. Par exemple, si l’algorithme de chiffrement RC4 et une longueur de clé 1k sont utilisés, une plate-forme VPX peut être capable de gérer plus de 500 connexions proxy HDX. Toutefois, si un algorithme de chiffrement 3DES et une longueur de clé 2k sont utilisés (ce qui devient de plus en plus courant), le débit peut être réduit de moitié.

Décision – Stratégie de pré-authentification

Une stratégie de pré-authentification facultative peut être appliquée aux groupes d’utilisateurs avec NetScaler Gateway comme point d’authentification. Les stratégies de pré-authentification limitent l’accès à l’environnement et dépendent de la capacité du point de terminaison à répondre à certains critères par le biais de l’analyse de point de terminaison EPA (Endpoint Analysis).

Les stratégies d’accès de pré-authentification peuvent être configurées pour tester les paramètres d’antivirus, de pare-feu, de système d’exploitation ou même de registre. Ces stratégies peuvent être utilisées pour interdire complètement l’accès ; elles peuvent être également utilisées par XenDesktop pour contrôler les fonctionnalités de session, telles que le mappage de presse-papiers, le mappage d’imprimante et même la disponibilité d’applications et de bureaux spécifiques. Par exemple, si un antivirus n’est pas installé sur une machine utilisateur, un filtre peut être défini pour masquer les applications sensibles.

La figure suivante fournit une vue d’ensemble de la façon dont plusieurs stratégies peuvent être utilisées pour personnaliser les fonctionnalités d’une ressource de virtualisation :

Image de logique de décision pour Smart Access

Expérience sur le terrain

  • Vente au détail : une petite entreprise privée de vente au détail utilise l’analyse de point de terminaison EPA pour rechercher la présence de définitions d’antivirus mises à jour avant d’autoriser l’accès.
  • Institution financière : une institution financière de taille moyenne utilise l’analyse EPA du SID de domaine pour vérifier que les utilisateurs sont membres du domaine d’entreprise avant d’autoriser l’accès.
  • Organisme gouvernemental : une grande institution fédérale utilise EPA pour analyser les appareils de point de terminaison afin de s’assurer qu’un certificat spécifique (ou un ensemble de certificats) a été installé sur l’appareil avant d’autoriser l’accès.

Décision – Stratégie de session

Les groupes d’utilisateurs avec NetScaler Gateway comme point d’authentification doivent détenir des stratégies de session correspondantes définies. Les stratégies de session sont utilisées pour définir l’expérience utilisateur globale après l’authentification.

Les entreprises créent des stratégies de session en fonction du type d’instance Citrix Receiver utilisé. En vue de l’attribution de stratégie de session, les appareils sont généralement groupés comme étant non mobiles (tels que Windows, Mac et Linux OS) ou mobiles (tels qu’iOS ou Android). Par conséquent, la décision de prendre en charge les appareils mobiles, les appareils non mobiles ou les deux devrait être prise en fonction des exigences relatives aux appareils clients identifiées au cours de la phase d’évaluation.

Pour identifier les stratégies de session d’appareils, incluez des expressions telles que celles décrites dans cet article.

  • Appareils mobiles : l’expression est définie sur « REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver », qui bénéficie d’une priorité plus élevée que la stratégie des appareils non mobiles pour s’assurer que les appareils mobiles sont appariés alors que les appareils non mobiles ne le sont pas.
  • Appareils non mobiles : l’expression est définie sur « ns_true », ce qui signifie qu’elle doit s’appliquer à tout le trafic qui lui est envoyé.

Une autre utilisation des stratégies de session consiste à appliquer des expressions d’analyse de point de terminaison. Ces stratégies de session sont appliquées après l’authentification tout en imitant les stratégies de pré-authentification mentionnées précédemment. L’utilisation de stratégies de session est une option permettant de fournir un scénario de secours aux points de terminaison qui ne répondent pas aux exigences de sécurité complètes, telles que l’accès en lecture seule à des applications spécifiques.

Décision – Profil de session

Chaque stratégie de session doit détenir un profil de session correspondant défini. Le profil de session définit les détails requis pour que le groupe d’utilisateurs puisse accéder à l’environnement. Il existe deux formes principales de profils de session qui déterminent la méthode d’accès à l’environnement de bureau virtuel :

  • VPN SSL : les utilisateurs créent un réseau privé virtuel et tunnélisent tout le trafic configuré par des adresses IP via le réseau interne. La machine cliente de l’utilisateur peut accéder aux ressources intranet autorisées comme si elles se trouvaient sur le réseau interne. Cela inclut les sites XenDesktop et tout autre trafic interne tel que les partages de fichiers ou les sites Web intranet. Le VPN SSL est considéré comme une méthode d’accès potentiellement moins sécurisée car les ports réseau et les routes vers les services en dehors de l’infrastructure de bureau virtuel peuvent être ouverts, ce qui laisse l’entreprise vulnérable aux risques qui peuvent accompagner un accès VPN complet. Ces risques peuvent inclure des attaques par déni de service, des tentatives de piratage de serveurs internes ou toute autre forme d’activité malveillante pouvant être lancée à partir de logiciels malveillants, de chevaux de Troie ou d’autres virus via un client basé sur Internet contre des services d’entreprise vulnérables à travers des routes et des ports.

Une autre décision pour déterminer lorsque le VPN SSL est nécessaire est de savoir s’il faut activer le split tunneling pour le trafic réseau client. En activant le split tunneling, le trafic du réseau client dirigé vers l’intranet par Citrix Receiver peut être limité aux routes et ports associés à des services spécifiques. En désactivant le split tunneling, tout le trafic du réseau client est dirigé vers l’intranet. Par conséquent, le trafic destiné aux services internes et aux services externes (Internet) traverse le réseau de l’entreprise. L’avantage d’activer le split tunneling est que l’exposition du réseau d’entreprise est limitée et que la bande passante réseau est conservée. L’avantage de désactiver le split tunneling est que le trafic client peut être surveillé ou contrôlé par des systèmes, tels que des filtres Web ou des systèmes de détection d’intrusion.

Image du VPN SSL

  • Proxy HDX : les utilisateurs se connectent à leurs applications et bureaux virtuels via NetScaler Gateway sans exposer les adresses internes à l’extérieur. Dans cette configuration, NetScaler Gateway agit comme un micro VPN et ne gère que le trafic HDX. Les autres types de trafic sur l’appareil de point de terminaison du client, tels que la messagerie privée ou le trafic Internet personnel, n’utilisent pas NetScaler Gateway.

En fonction du point de terminaison et de l’instance Citrix Receiver utilisés, vous devez décider si cette méthode est prise en charge pour chaque groupe d’utilisateurs. Le proxy HDX est considéré comme une méthode d’accès sécurisé pour l’accès aux bureaux virtuels distants puisque seul le trafic spécifique à la session de bureau est autorisé à passer par l’infrastructure de l’entreprise. La plupart des instances Citrix Receiver prennent en charge le proxy HDX. Il s’agit de la méthode préférée :

Image du proxy HDX

Décision – Centre de données préféré

Les entreprises disposent souvent de plusieurs centres de données actifs offrant une haute disponibilité pour les applications stratégiques. Certains bureaux virtuels ou certaines applications virtuelles peuvent entrer dans cette catégorie alors que d’autres ne peuvent être accessibles qu’à partir d’un centre de données préféré spécifique. Par conséquent, l’instance NetScaler Gateway initiale à laquelle un utilisateur s’authentifie dans un environnement de centre de données multi-actif peut ne pas se trouver dans le centre de données préféré correspondant aux ressources VDI de l’utilisateur. StoreFront est capable de déterminer l’emplacement des ressources assignées à l’utilisateur et de diriger la session HDX vers ces ressources ; cependant, le chemin résultant peut être sous-facultatif (connexion WAN de NetScaler Gateway vers les ressources de bureau virtuel/application virtuelle par opposition à une connexion LAN).

Il existe des méthodes statiques et dynamiques pour diriger les sessions HDX vers leurs ressources de bureau virtuel dans leur centre de données principal. La décision concernant la méthode à sélectionner doit être basée sur la disponibilité de la technologie permettant d’attribuer dynamiquement des liens de sites, tels que l’équilibrage de charge de serveur global (GSLB), ainsi que sur l’évaluation du réseau de la bande passante intranet et Internet, et sur les capacités de qualité de service (QoS).

Remarque

Pour plus d’informations sur la configuration des méthodes statiques et dynamiques de GSLB, consultez la documentation produit Citrix Configurer GSLB pour la proximité.

Méthode statique

  • Direct : l’utilisateur peut se voir attribuer un nom de domaine complet mappé à un enregistrement A dédié au centre de données principal NetScaler Gateway, ce qui lui permet d’accéder directement à son bureau virtuel où qu’il se trouve dans le monde. Cette approche élimine une couche de complexité ajoutée avec l’allocation dynamique. Toutefois, cette approche élimine également les options de tolérance aux pannes, telles que la possibilité d’accéder au bureau virtuel via un autre chemin intranet lorsqu’une panne de centre de données principal est limitée à l’infrastructure d’accès.

Méthode dynamique

  • Intranet : pour la plupart des environnements dynamiques, le centre de données initial sélectionné pour l’authentification est celui le plus proche de l’utilisateur. Des protocoles, tels que la proximité dynamique GSLB, calculent la latence la plus faible entre le serveur DNS local de l’utilisateur et NetScaler Gateway. Par la suite, par défaut, la session HDX est acheminée via la même instance NetScaler Gateway vers le centre de données qui héberge les applications et bureaux virtuels de l’utilisateur. L’avantage de cette approche est que la majorité de la session HDX traverse le réseau WAN d’entreprise où la qualité de service peut être utilisée.

Image de connexion à l'intranet

  • Internet : la session HDX peut également être réacheminée via une autre instance NetScaler Gateway située à proximité du serveur de bureau VDI principal/XenApp, ce qui entraîne le transit de la plupart de la session HDX sur Internet. Par exemple, un utilisateur disposant d’un bureau dédié aux États-Unis et voyageant en Europe peut être dirigé vers une instance NetScaler Gateway hébergée dans un centre de données européen en fonction de sa proximité. Toutefois, lorsque l’utilisateur lance son bureau, une connexion HDX est établie au bureau virtuel via une instance NetScaler Gateway hébergée dans le centre de données préféré aux États-Unis.

Cette méthode permet de conserver l’utilisation du réseau WAN (au prix de la qualité de service) et est recommandée dans les cas où la connexion Internet de l’utilisateur peut fournir une expérience plus fiable que le réseau WAN d’entreprise.

Image de la connexion Internet

Certains clients utilisent une combinaison de ces méthodes, telles que des adresses URL dynamiques géospécifiques, de sorte que la tolérance aux pannes est fournie dans une zone géographique (comme l’Amérique du Nord) sans encourir la complexité de l’équilibrage de charge de serveur global.

Connectivité site à site

Un site XenApp et XenDesktop est capable de couvrir plusieurs emplacements. Afin de mettre en place une solution multisite, la conception doit prendre en compte les liens de site à site et le routage de session XenApp et XenDesktop entre les emplacements afin de fournir la meilleure expérience utilisateur.

Décision – Routage HDX optimal

Dans une solution XenApp et XenDesktop multisite, certains critères, tels que le temps de réponse le plus rapide ou la proximité la plus proche, acheminent les utilisateurs vers le site optimal. Ces algorithmes ne prennent pas en compte les ressources auxquelles un utilisateur souhaite accéder.

Un routage incorrect de la session d’un utilisateur entraîne le scénario suivant :

Image du routage HDX

  1. L’utilisateur est acheminé vers le site préféré, en fonction de la proximité ou du temps de réponse.
  2. NetScaler Gateway transmet par proxy le trafic ICA vers la ressource appropriée, qui peut se trouver sur le réseau WAN d’entreprise.

Idéalement, le routage optimal devrait ressembler à ce qui suit :

Image du routage optimal

  1. L’utilisateur est acheminé vers le site préféré, en fonction de la proximité ou du temps de réponse.
  2. En fonction de la ressource sélectionnée, NetScaler Gateway réexécute la session vers une instance NetScaler Gateway dans le site préféré.
  3. NetScaler Gateway transmet par proxy le trafic ICA vers la ressource appropriée, qui reste sur le réseau local.

L’utilisation de l’option de routage HDX optimal dans StoreFront décharge le trafic du réseau WAN d’entreprise et le place sur le réseau public

Décision – Réseau WAN virtuel

Dans les scénarios de succursale, une conception XenApp et XenDesktop doit évaluer la connexion de la succursale aux centres de données hébergeant les ressources d’application et de bureau. Si la connexion WAN entre la succursale et le centre de données n’est pas en mesure de répondre aux besoins de l’utilisateur, l’expérience utilisateur globale se détériorera. Les entreprises ont à disposition plusieurs options sur leurs connexions WAN :

  • Évolutivité verticale : les entreprises peuvent simplement augmenter la taille du canal WAN reliant les succursales au centre de données, généralement à un coût considérable.
  • Évolutivité horizontale : les entreprises peuvent maintenir leur connexion WAN actuelle et l’augmenter avec plusieurs alternatives économiques. L’intégration de toutes les connexions entre la succursale et le centre de données crée un réseau WAN virtuel défini par logiciel, tel que NetScaler SD-WAN. L’appliance envoie des paquets réseau en double sur toutes les connexions WAN définies dans le réseau WAN virtuel. L’appliance à l’autre extrémité du réseau WAN utilise le premier paquet arrivé, rejetant tous les paquets suivants. Comme les conditions des liens multiples changent tout au long de la journée, cette approche garantit la meilleure expérience possible.

Image de NetScaler SD-WAN

Méthodologie de conception d’une couche d’accès