Citrix ADC/NetScaler en DMZ ou accès par VPN?

Je comprends que les clients utilisent Citrix Receiver (maintenant Workspace) pour se connecter à un ADC, puis ils peuvent télécharger des fichiers ICA pour des applications spécifiques auxquelles ils veulent accéder à distance. Cependant, mes connaissances sur Citrix ne vont pas beaucoup plus loin.

Cela dit, je suis intéressé de savoir s’il existe une bonne pratique acceptée pour faire en sorte que les utilisateurs finaux se connectent, en utilisant soit la mise en place de l’ADC en DMZ, soit en gardant votre ADC accessible uniquement via un VPN. J’ai lu un article de base de connaissances de Citrix qui décrivait de maintenir l’ADC à jour, activer MFA, et s’assurer que des suites de chiffrement sécurisées soient utilisées, mais je ne comprends toujours pas quelle est la meilleure pratique (DMZ ou simplement utiliser un VPN ?).

Est-ce considéré comme une implémentation assez sécurisée d’avoir votre ADC dans une DMZ tant que MFA est configuré ? Des choses comme le géoblocage IP pour certains pays sont-elles également généralement effectuées ? Le MFA semble être un facteur déterminant ici, mais si les identifiants AD d’un utilisateur étaient usurpés (par exemple via une page ADC factice) avec le OTP, cela pourrait être une voie d’entrée. L’autre exemple sont des exploits ciblant l’ADC puisqu’il est dans une DMZ.

Je m’excuse si je me trompe complètement sur certains points - j’essaie simplement de comprendre.

Les ADC sont tout à fait corrects dans une DMZ ! Et oui, tu peux faire du géoblocage IP.

Toutes tes inquiétudes peuvent également s’appliquer à l’accès VPN et, dans la plupart des cas, la défense repose sur la conscience des utilisateurs.

La décision de placer l’ADC dans la DMZ doit être envisagée dans le contexte des ressources publiées, du profil des utilisateurs (seront-ils heureux d’accéder uniquement aux ressources publiées par Citrix ou ont-ils besoin d’un accès VPN plus large), de la configuration du réseau interne et du coût.
J’ai un client qui était très content avec des ADC dans la DMZ, les utilisateurs n’avaient besoin que de quelques applications et y accédaient avec des laptops et des iPads.
Un autre a tout misé sur un VPN Cisco en configuration toujours active. L’appareil a Internet = il est connecté au réseau de l’entreprise. Ils n’ont pas été convaincus de mettre l’ADC en DMZ, et je comprends leur point de vue.

L’ADC est un SSL-VPN.
Il serait redondant et inutile d’avoir une seconde connexion VPN.

L’ADC offre-t-il le MFA pour les utilisateurs censés se connecter ? J’ai demandé à mon intégrateur système, la réponse est non, il faut mettre en place par exemple une infra RSA (coûteuse et hors budget). Mais je n’utilise que XenApp et la base d’utilisateurs n’est pas grande. Existe-t-il une meilleure solution ? L’entreprise utilise Okta, mais la configuration avec l’équipe en charge est comme escalader le Mont Everest.

Si vous avez une connectivité VPN établie, vous pouvez permettre aux utilisateurs de se connecter directement à storefront. Ou vous pouvez avoir un Netscaler interne, où les utilisateurs en VPN se connectent au portail du Netscaler interne.

Si vous souhaitez un accès au portail externe pour vos utilisateurs, oui, il faut absolument héberger le portail sur la DMZ, port 443 uniquement. Assurez-vous que vos DDC et serveurs SF ont des certificats liés et configurés uniquement pour des connexions https.

Et mettez en place MFA (radius) pour l’accès externe. Vous pouvez le faire avec le rôle serveur MS NPS, ou Azure MFA. Il y en a d’autres comme RSA et Symantec.

Ce n’est pas tout à fait exact. Le Netscaler peut être utilisé comme VPN, mais utiliser des connexions ICA uniquement avec Workspace/Receiver ne nécessite pas de VPN.

Nous utilisons MFA Azure avec Nfactor et FAS, synchronisé avec notre AD pour Office 365. Nous avons deux DMZ : une DMZ interne pour le storefront et WEP vips pour l’équilibrage de charge, et une DMZ externe pour le VIP de la passerelle externe.

Récemment, nous avons mis en place Cisco Duo. Vous l’installez sur vos serveurs d’applications, et il demande la 2FA lors de la connexion de session côté Windows.

Je m’assurerais que vous avez un MFA à un moment donné du processus sur l’ADC, ne vous fiez pas uniquement à la 2FA sur la machine de réception.

Je peux utiliser Okta MFA sur nos services ADC depuis quelques années maintenant, très facile à configurer avec les tutoriels inclus d’Okta, je peux en mettre en place en moins de 30 minutes. Nous avons des passerelles ICA ainsi que des services SSL/VPN.

Ce que j’ai dit est totalement exact.

Quand le NetScaler ADC est utilisé avec Virtual Apps et Desktop, il serait configuré comme un CAG qui est un SSL-VPN. Ajouter un VPN devant la fonctionnalité CAG est inutile et redondant.

Il semble que vous suggérez qu’ils utilisent un VPN à la place de l’ADC, ou vous parlez d’autres charges en plus de Virtual Apps et Desktop.

Source : Je possède tous les certificats CTXS.

Merci pour la suggestion. J’ai entendu parler d’une configuration DMZ à deux niveaux similaire avec le StoreFront là-bas.

Merci. Je vais vérifier cela.

Existe-t-il une capacité intégrée dans VPX/MPX ? S’il vous plaît, éclairez-moi. Je n’arrive pas à la trouver.

Lorsque le Netscaler ADC est utilisé avec des Virtual Apps et Desktops, il peut être configuré comme un SSL VPN, un proxy ICA, sans client, pour navigation sécurisée ou proxy RDP. SSL VPN est une de ces options. Quand vous dites “NetScaler ADC avec Virtual Apps et Desktop configuré comme un CAG, c’est une SSL-VPN” ce n’est pas correct. Je suis d’accord que rajouter un VPN devant le Netscaler est redondant, mais honnêtement, ce n’était pas clair dans la question si l’auteur parlait du VPN du Netscaler ou d’un autre produit.

J’ai aussi des certificats.

FYI : Tu peux demander aux mods d’ajouter ton certificat en tant que flair !

Dis-moi la différence technique entre un proxy ICA et un SSL-VPN.

Ce sont la même chose.

Le CAG est techniquement un SSL-VPN limité uniquement au trafic VAD et appelé un “proxy ICA”.

Tu te trompes si tu penses que j’ai fait des déclarations incorrectes.

Je ne suis pas très actif ici. Je pensais juste apporter un peu d’aide.