Netskope Client pour l’infrastructure de bureau virtuel (VDI)

Ce document décrit principalement les instructions pour déployer Netskope Client dans un environnement VDI. Il couvre également les configurations, les limitations et les meilleures pratiques qui s'appliquent aux différents types de déploiements VDI utilisés dans votre organisation.

Environnements VDI pris en charge

Persistent vs Non-Persistent VDI

Les VDI persistants et non persistants offrent principalement deux types de solutions VDI qui présentent divers avantages et cas d'utilisation pour les organisations.

VDI persistante

Une VDI persistante, communément appelée VDI avec état, est une approche dans laquelle chaque utilisateur se voit attribuer une machine virtuelle dédiée. Il enregistre toutes les configurations et autres paramètres mis à jour par l'utilisateur, et persiste à partir d'une session, offrant ainsi la même expérience qu'un bureau physique.

La section suivante décrit les différentes méthodes de déploiement de Netskope Client dans un environnement VDI persistant :

Méthode de déploiement du MDM

Dans Persistent VDI, il n'est pas nécessaire d'installer Netskope Client à l'avance sur l'image maître (image dorée). MDM peut instrumenter le déploiement de Netskope Client et gérer la machine VDI.

Les administrateurs peuvent déployer Netskope Client par l'intermédiaire des MDM de deux manières, en fonction de la méthode d'enrôlement du client choisie, décrite ici.

Image maître (Golden Image) Pré-installation

Quelles que soient les solutions VDI, l'administrateur doit installer Netskope Client sur l'image maître avant de créer l'instantané utilisé dans l'environnement VDI.

Pour déployer Netskope Client à l'aide d'une image maître dans un environnement VDI persistant :

Téléchargez Netskope Client MSI depuis le support Netskope.
Copiez MSI dans l'image principale ou l'image dorée.

Consultez la documentation Microsoft Azure et Citrix Virtual Apps pour créer une image en or.
L'administrateur peut maintenant installer Netskope Client à l'aide de CLI (cmd ou Powershell).

Les administrateurs peuvent déployer Netskope Client via une image d'or de deux manières, en fonction de la méthode d'enrôlement du client choisie, décrite ici.

Non-Persistent VDI

Les administrateurs gèrent les bureaux virtuels en permettant aux utilisateurs de partager un seul bureau, et le système supprime toutes les applications et tous les paramètres installés lorsque l'utilisateur ferme la session VDI.

Master Image (Golden Image)

Les administrateurs ne peuvent pas utiliser la méthode MDM pour déployer Netskope Client dans une VDI non persistante. La seule méthode de déploiement pour installer le site Netskope Client est l'utilisation de la Golden Image.

Pour déployer Netskope Client à l'aide d'une image maître dans un environnement VDI non persistant :

Téléchargez Netskope Client MSI depuis le support Netskope.
Copiez le MSI dans l'image principale ou l'image dorée.

Consultez la documentation Microsoft Azure et Citrix Virtual Apps pour créer une image en or.
L'administrateur peut maintenant installer Netskope Client à l'aide de CLI (cmd ou Powershell).

Les administrateurs peuvent déployer Netskope Client via une image d'or de deux manières, en fonction de la méthode d'enrôlement du client choisie, décrite ici.

Netskope Client Méthode d'inscription

UPN

PDI

Choisissez la méthode d'inscription UPN si les machines VDI sont reliées à un domaine (AD ou Entra).

Utilisez les paramètres suivants pour déployer Netskope Client dans un environnement multi-utilisateurs à l'aide de l'UPN :

msiexec /I NSClient.msi host=addon-<tenant-FQDN> token=<OrgID> mode=peruserconfig [enrollauthtoken=<enrollment-token> enrollencryptiontoken=<encryption-token> prelogonuser=<prelogon-user> npavdimode=on userconfiglocation=<path> fail-close=<disable|no-npa> autoupdate=<on|off> /l*v <path>] /qn

IDP est une autre méthode d’inscription utilisateur où un utilisateur doit s’authentifier contre l’IDP configuré à chaque connexion sur la machine. Pour en savoir plus, consultez l’authentification et le provisionnement des utilisateurs.

Après l'authentification de l'utilisateur, le site Netskope Client d'une VDI persistante s'inscrit à l'aide des informations d'identification de l'utilisateur authentifié. Tant que le profil utilisateur existe sur la machine VDI, le système ne demande pas à l'utilisateur de s'inscrire à nouveau.

Dans un environnement non persistant, l'administrateur doit s'assurer que le profil est non persistant, sinon le système demande toujours à l'utilisateur de s'authentifier à chaque session.

Pour que les utilisateurs suivants puissent se connecter à l'aide de la méthode IDP après que le premier utilisateur se soit connecté à la VDI à l'aide de la méthode d'inscription IDP, contactez le service d'assistance de Netskope pour activer l'indicateur de fonctionnalité nécessaire.

Utilisez les paramètres suivants pour déployer Netskope Client dans un environnement multi-utilisateurs à l'aide d'IDP :

msiexec /I NSClient.msi installmode=idp tenant=<tenant-name> domain=<tenant-domain> mode=peruserconfig [enrollauthtoken=<enrollment-token> enrollencryptiontoken=<encryption-token> prelogonuser=<prelogon-user> npavdimode=on userconfiglocation=<path> fail-close=<disable|no-npa> autoupdate=<on|off> /l*v <path>] /qn

Client Deployment Parameters

Paramètres	Description
host=addon-<tenant-name>.[region.]<tenant-domain>	(Paramètre obligatoire) Requis lors de l'enrôlement d'utilisateurs à l'aide de l'UPN. Ne l'utilisez pas lorsque vous inscrivez des utilisateurs à l'aide de l'IDP. Il s'agit du nom d'hôte de l'addon de votre locataire. Par exemple, Si le nom d'hôte de votre locataire est corp.goskope.com, utilisez host=addon-corp.goskope.com. Si le nom d'hôte de votre locataire est corp.eu.goskope.com, utilisez host=addon-corp.eu.goskope.com.
token=<ID d’organisation><Organization ID>	(Paramètre obligatoire) Requis lors de l'enrôlement d'utilisateurs à l'aide de l'UPN. Ne l'utilisez pas lorsque vous enrôlez des utilisateurs à l'aide d'IdP. Pour trouver l'identifiant de votre organisation : Connectez-vous à votre console d'administration Netskope avec des identifiants administrateur. Allez dans Paramètres > Security Cloud Platform > MDM Distribution. Localisez votre identifiant d'organisation dans la section Créer une configuration VPN. L'identifiant de l'organisation est sensible à la casse.
enrollauthtoken=<Jeton d'authentification><Authentication Token>	Obligatoire lors de l’inscription d’utilisateurs utilisant UPN avec le jeton d’authentification d’inscription sécurisée activé et appliqué. Obligatoire lors de l’utilisation du Private Access Prelogon (inscription UPN et IdP) avec le jeton d’authentification d’inscription sécurisée activé et appliqué.
enrollencryptiontoken=<Encryption Token>	Requis lors de l'enrôlement d'utilisateurs à l'aide de l'UPN ou de l'IdP avec le jeton de chiffrement de l'enrôlement sécurisé activé et appliqué.
mode=peruserconfig	(Paramètre obligatoire) À utiliser lors de l'installation sur un système multi-utilisateurs. Avec ce paramètre défini, chaque utilisateur doit s'inscrire individuellement Netskope Client . Avec ce paramètre défini, chaque utilisateur doit s'inscrire individuellement Netskope Client et la même configuration de pilotage est appliquée à tous les utilisateurs. La configuration du client est appliquée en fonction des priorités. Ce paramètre est obligatoire pour les environnements VDI (si différents utilisateurs se connectent simultanément ou séparément à la même machine VDI, ils sont correctement identifiés par leur UPN).
npavdimode=on	À utiliser lors de l'installation sur un poste de travail Windows multi-utilisateurs avec des utilisateurs connectés en même temps, comme dans certains environnements Citrix VDI ou Azure Virtual Desktop. Ce paramètre ne s'applique qu'à Netskope Private Access (NPA).
userconfiglocation=<path>	Remplace le chemin d'accès par défaut pour le stockage de la configuration utilisateur. Il est recommandé de ne pas utiliser ce paramètre (et de conserver le chemin par défaut) sauf si les répertoires personnels des utilisateurs sont hébergés sur des serveurs de fichiers externes ou des partages réseau. Il est recommandé d'utiliser ce paramètre uniquement pour les systèmes multi-utilisateurs (lorsque mode=peruserconfig est inclus dans les paramètres). Chemin par défaut : %AppData%\Netskope\STAgent Le chemin personnalisé peut être un chemin absolu, un partage réseau ou un chemin ayant des variables d’environnement. Les variables d'environnement doivent être correctement échappées selon la manière dont la commande MSIEXEC est exécutée : Si l'exécution se fait depuis l'invite de commandes, ajoutez ^ avant chaque % Exemple : `>msiexec /I NSClient.msi mode=peruserconfig userconfiglocation=C:\Users\^%USERNAME^%\Netskope` Si l'exécution se fait depuis un script batch, ajoutez % avant chaque % Exemple : `>msiexec /I NSClient.msi mode=peruserconfig userconfiglocation=C:\Users\%%USERNAME%%\Netskope` Si l'exécution se fait depuis SCCM (ou un autre outil de déploiement en masse), ajoutez ^ avant chaque % et préfixez-le avec cmd /c Exemple : `>>cmd /c msiexec /I NSClient.msi mode=peruserconfig userconfiglocation=C:\Users\^%USERNAME^%\Netskope`
fail-close=disable\|no-npa	Cela remplace les paramètres d'échec de la fermeture dans la configuration du client. disable : Désactive explicitement la fermeture en cas d'échec sur ce périphérique. no-npa : Autoriser le trafic Private Access (NPA) même si le tunnel de sécurité Internet ne peut pas être établi et que Fail Close bloque le trafic Internet.
prelogonuser=<nom d’utilisateur<prelogon username>Netskopeprelogon>@prelogon..com	À utiliser lors du déploiement de la préconnexion Private Access . Pour plus d'informations, consultez la page Préconnexion.
autoupdate=on\|off	on : Valeur par défaut qui permet la mise à jour automatique de Netskope Client en fonction de la configuration du client. Si la configuration du client a désactivé la mise à jour automatique, Netskope Client ne sera pas mis à jour automatiquement sur ce système. off : Désactive la mise à jour automatique de Netskope Client. Cela remplace la configuration du client et empêchera toute mise à jour automatique de Netskope Client sur ce système.
/l*v	Définit le chemin d'accès au fichier journal de l'installation de MSIEXEC. Par exemple : `/l*v %PUBLIC%nscinstall.log`
/qn	Utilisez cette option pour une installation silencieuse.

Prise en charge de l'environnement multi-utilisateurs dans VDI

Les sections suivantes décrivent les meilleures pratiques que vous pouvez envisager dans un environnement VDI multi-utilisateurs.

Comparaison persistante ou non persistante dans un environnement multi-utilisateurs

Reportez-vous au tableau suivant pour comprendre les considérations relatives à la configuration du pilote, à la configuration du client, à l'OTP et au mot de passe principal :

Type de configuration	VDI persistante	Non-Persistent VDI	Informations complémentaires
Configuration du client	La configuration du client ayant la priorité la plus élevée* est prioritaire.	Les configurations du client ayant la priorité la plus élevée sont prioritaires	-
Configuration du pilotage	S'applique à la première configuration de pilotage de l'utilisateur connecté téléchargée par le site Netskope Client.	S'applique à la première configuration de pilotage de l'utilisateur connecté téléchargée par le site Netskope Client.	Pour un comportement cohérent dans un environnement multi-utilisateurs, assurez-vous que chaque utilisateur partage la même configuration de pilotage.
Mot de passe de désactivation unique	S'applique à la configuration du client ayant la priorité la plus élevée.	S'applique à la configuration du client ayant la priorité la plus élevée.	La désactivation de la sécurité Internet par l'utilisateur A à l'aide de l'OTP ne désactive pas les services clients de l'utilisateur B.
Mot de passe principal	S'applique à la configuration du client ayant la priorité la plus élevée.	S'applique à la configuration du client ayant la priorité la plus élevée	L'utilisateur A qui désactive les services Clients à l'aide du mot de passe principal ne désactive pas les services Clients de l'utilisateur B.

*La priorité correspond à l'ordre de configuration. Plus le profil est élevé dans la liste, plus la priorité est élevée.

Chaque fois que l'administrateur procède à une nouvelle installation ou à une mise à niveau de Netskope Client, Netskope recommande de supprimer les clés de registre : nsdeviceuid et nsdeviceuidnew de l'image principale afin d'éviter la duplication des identifiants périphériques uniques des machines virtuelles clonées.

Additional Info

Supprimez les clés nsdeviceuid et nsdeviceuidnew pour éviter la duplication de l'identifiant unique entre l'image principale et la VM clonée. Si plusieurs VM sont clonées à partir de la même infrastructure (par exemple, VMware EXSi), elles obtiennent le même identifiant de périphérique unique pour les VM clonées.
Si l'administrateur ne supprime pas les clés de registre de l'UID du périphérique, l'image maître et l'image clonée utiliseront le même ID de périphérique unique.
Les dossiers suivants sont créés après l'installation de Netskope Client et l'administrateur peut vérifier si l'image maître comprend les dossiers suivants :
- C:\N- Program Files (x86)\N- C:\N- Program Files (x86)Netskope
- C:\NProgram Files\NNetskope
- C:\NProgrammeDonnéesNetskope

Limitation

Dans un environnement multisession, le site Netskope Client présente les limitations suivantes :

Les politiques NPA pour les applications qui utilisent la "session 0" pour communiquer (comme AD ou SMB) doivent être assignées à l'utilisateur VDI "session 0" spécifié dans la configuration du client, et tout le trafic pour ces applications, quel que soit l'utilisateur réel qui l'initie, sera identifié et géré par la politique de l'utilisateur VDI "session 0".
eDLP (Endpoint DLP (Prévention des pertes de données)) n'est pas pris en charge dans les environnements multisessions utilisant un système d'exploitation Windows Desktop. Les administrateurs doivent envisager de désactiver l'eDLP dans ces environnements.
eDLP (Endpoint DLP (Prévention des pertes de données)) n'est pas activé dans les environnements multisessions utilisant un système d'exploitation Windows Server.
Lorsque le site Netskope Client est déployé/mise à niveau/reconfiguré du mode mono-utilisateur au mode multi-utilisateur en utilisant l'inscription IdP sur un périphérique Windows, le processus stAgent ne parvient pas à s'initialiser pour les utilisateurs qui passent d'un état inactif ou verrouillé à une session active.

Par exemple, deux utilisateurs, l'utilisateur A et l'utilisateur B, utilisent un système Windows.
- L'utilisateur B est actif sur le système et l'utilisateur A est connecté mais inactif.
- Netskope Client est installé/mise à niveau/reconfiguré du mode mono-utilisateur au mode multi-utilisateur et la session de l'utilisateur B est créée avec succès.
- L'utilisateur B verrouille l'écran, ce qui fait passer la session à l'état inactif.
- L'utilisateur A déverrouille l'écran mais le site Netskope Client ne s'initialise pas pour l'utilisateur A et il n'y a pas de processus stAgentUI pour l'utilisateur A. Cela perturbe la gestion du trafic pour l'utilisateur A et maintient le client inactif.
  
  Pour rétablir le processus stAgentUI et assurer une bonne gestion du trafic pour l'utilisateur A, Netskope recommande de déconnecter et de connecter l'utilisateur A afin d'éliminer tout problème lié à l'inactivité de Netskope Client.

Définir la configuration du client

Dans un environnement multi-utilisateurs, chaque configuration client comprend une valeur de priorité. La configuration ayant la priorité la plus élevée reste active jusqu'à 24 heures après son téléchargement. Si un autre utilisateur se connecte avec une configuration de priorité égale ou supérieure, cette dernière est appliquée immédiatement. Toutefois, si la priorité de la configuration New est inférieure, elle ne sera pas appliquée tant que la configuration actuelle est encore dans sa fenêtre de 24 heures. Par exemple, considérez les scénarios suivants :

Scenario 1: L'utilisateur A fait partie de la configuration client A (avec une priorité plus élevée), tandis que l'utilisateur B fait partie de la configuration client B (avec une priorité plus faible). La configuration du client ayant la priorité la plus élevée est toujours appliquée lors des deux ouvertures de session de l'utilisateur.
Scenario 2: Si l'utilisateur B se connecte en premier et applique la configuration client B (avec une priorité inférieure). Lorsque l'utilisateur A (dont la priorité est plus élevée) se connecte ensuite à la session multiple, les deux utilisateurs reçoivent la configuration client A en raison de sa priorité plus élevée.

Scenario 3: Considérons que l'utilisateur A se connecte et se déconnecte en l'espace de quelques minutes. L'utilisateur B se connecte 24 heures après la déconnexion de l'utilisateur A. L'utilisateur B utilise la configuration client B, moins prioritaire, car la configuration de l'utilisateur A, plus prioritaire, a expiré après 24 heures. L'utilisateur B reçoit la configuration client la moins prioritaire et la conserve telle quelle, même en cas de mise à jour de la configuration client.

Scenario 4: Considérons que la configuration client A (priorité plus élevée) est appliquée à l'utilisateur A et à l'utilisateur B. L'administrateur locataire modifie la configuration client B. Cela ne change pas la configuration client appliquée de A à B en raison de la priorité plus élevée de la configuration A. Cependant, si l'administrateur locataire modifie la configuration client A, les modifications New sont appliquées à l'utilisateur A et à l'utilisateur B.

Scenario 5: Si l'utilisateur B, appartenant au groupe de configuration de clients B, se connecte d'abord à la VDI, sans qu'aucun autre utilisateur ne soit actuellement connecté à la session VDI. Dans ce cas, le site Netskope Client appliquera les paramètres du groupe de configuration client B à l'utilisateur B. Toutes les éditions ou modifications apportées à d'autres groupes de configuration client n'affecteront pas la session de l'utilisateur B. Les modifications ne prendront effet que si un administrateur met à jour les paramètres du groupe de configuration du client B.

Définir la configuration du pilotage

Dans un environnement VDI multi-utilisateurs, il applique la configuration de pilotage du premier utilisateur connecté que le site Netskope Client télécharge. Le trafic de la session 0 (session de service) est dirigé vers le tunnel de l'utilisateur connecté qui contient le plus petit identifiant de session. Par exemple, considérez les scénarios suivants :

Pour un comportement cohérent dans un environnement multi-utilisateurs, assurez-vous que chaque utilisateur partage la même configuration de pilotage.

Scenario 1: L'utilisateur A (avec la configuration de pilotage A) se connecte à la session, suivi par l'utilisateur B quelques minutes plus tard. L'utilisateur A et l'utilisateur B reçoivent le même profil de configuration de pilotage (configuration de pilotage A). Maintenant, si l'utilisateur C (avec la configuration de pilotage C) se connecte, il reçoit également la même configuration de pilotage que l'utilisateur A.
Scenario 2: L'utilisateur A se connecte, suivi de l'utilisateur B. La configuration de pilotage A est appliquée aux deux utilisateurs. Maintenant, si l'administrateur du locataire modifie les paramètres de la configuration de pilotage B et met à jour la configuration du client, les utilisateurs connectés contiennent maintenant la configuration de pilotage B modifiée.
Scenario 3: Si seul l'utilisateur B se connecte et qu'aucun autre utilisateur n'a accédé à la session VDI, la configuration de pilotage de l'utilisateur B sera appliquée à l'interface utilisateur client de l'utilisateur B. Toute modification apportée à d'autres configurations de pilotage n'affectera pas l'interface utilisateur de l'utilisateur B. Les changements apportés à la configuration du pilotage ne prendront effet que lorsque l'administrateur modifiera les paramètres de pilotage spécifiques de l'utilisateur B. Ce comportement est similaire à celui d'une session mono-utilisateur.

Définir un mot de passe de désactivation unique

Dans un environnement multi-utilisateurs, la configuration du client ayant la priorité la plus élevée est prioritaire.

Par exemple, considérez le scénario suivant dans lequel l'utilisateur A se connecte et effectue les opérations suivantes :

Cliquez sur l'option Désactiver Internet Security dans l'interface utilisateur du client.
Une boîte de dialogue s'ouvre alors pour vous permettre de saisir le mot de passe à usage unique.
Saisissez le mot de passe et vérifiez si l'option Sécurité Internet est désactivée.

Ensuite, l'utilisateur B se connecte et obtient la même configuration client que l'utilisateur A. L'utilisateur B peut vérifier si l'option Internet Security est activée dans l'interface utilisateur du client.

Si l'utilisateur B se connecte en premier avec la configuration client B avec une priorité inférieure, l'administrateur doit configurer l'OTP dans la configuration client pour l'utilisateur B afin de désactiver les services de sécurité Internet dans l'interface utilisateur client.

Définir le mot de passe principal

Dans un environnement multi-utilisateurs, la configuration du client ayant la priorité la plus élevée est prioritaire.

Par exemple, considérez le scénario suivant : l'utilisateur A se connecte et effectue les opérations suivantes :

Cliquez sur l'option DisableAll Client Services dans l'interface utilisateur du client.
Une boîte de dialogue s'ouvre alors pour vous permettre de saisir le mot de passe principal.
Saisissez le mot de passe et vérifiez si l'option Tous les services clients est désactivée.

Ensuite, l'utilisateur B se connecte et obtient la même configuration client que l'utilisateur A. L'utilisateur B peut vérifier si l'option All Client Services est activée dans l'interface utilisateur du client.

Si l'utilisateur B se connecte en premier avec la configuration client B avec une priorité inférieure, l'administrateur doit configurer le mot de passe principal dans la configuration client pour l'utilisateur B afin de désactiver tous les services client dans l'interface utilisateur du client.

Définir l'échec de la fermeture

Dans un environnement multi-utilisateurs, la configuration du client ayant la priorité la plus élevée est prioritaire.

Scenario 1: Lorsque Netskope Client n'est pas joignable, il passe à l'état Fail Close pour les sessions VDI. Si l'utilisateur A se connecte et accède à l'application de pilotage, le client bloque l'accès. Si l'utilisateur A accède aux applications d'exception définies, le client doit contourner le trafic de l'application.
Scenario 2: Lorsque le périphérique est en état d'échec, il doit contourner les API MP (telles que la configuration du client, la mise à niveau automatique, l'état du client, etc.)
Scenario 3: Lorsque l'utilisateur A et l'utilisateur B se connectent tous deux à la session VDI alors que le client est en mode "fail-close", les deux utilisateurs sont empêchés d'accéder à l'application Steering et les applications d'exception définies sont contournées.
Scenario 4: Lorsque l'utilisateur C, un utilisateur non provisionné (non géré par le locataire ou l'invité Netskope ), se connecte à la session VDI alors que d'autres utilisateurs provisionnés sont actifs et que le site Netskope Client est activé, vérifiez que l'état du client de l'utilisateur C indique fail-close (fermeture en cas d'échec). L'accès de l'utilisateur C aux applications de pilotage est bloqué, tandis que les applications d'exception définies sont contournées.

Problème connu : Migration des utilisateurs

Si les utilisateurs existants migrent de l'inscription UPN à l'inscription IDP ou vice-versa dans l'image maître pour une VDI non persistante, ils peuvent rencontrer des problèmes en raison de données périmées dans leur profil d'utilisateur sauvegardé sur le chemin du réseau Fslogix/Shared. Pour contourner le problème, les administrateurs doivent supprimer le profil de l'utilisateur du chemin d'accès au profil itinérant qui inclut FSLogix ou les répertoires personnels situés sur des serveurs de fichiers externes ou des partages de réseau.

Notification de l'utilisateur pour l'application publiée

Cette section fournit des conseils sur le comportement de notification des utilisateurs pour les applications publiées via XenApp avec Netskope Client.

Les modèles de notification utilisateur permettent à l'administrateur de bloquer une action d'un utilisateur et/ou d'envoyer une alerte à ce dernier. Ces modèles peuvent être personnalisés pour fournir des informations et des options spécifiques dans une alerte ou une notification de blocage. Les administrateurs peuvent fournir une liste déroulante de justification aux utilisateurs et afficher également une zone de description pour fournir une justification (facultatif). Pour en savoir plus, consultez le modèle de notification utilisateur.
Considérez les scénarios suivants où le Netskope Client empêche l'accès à l'application en bloquant ou en alertant les utilisateurs selon les politiques de protection en temps réel pour la prévention des pertes de données (DLP) et la protection contre les menaces. Il impose des actions telles que le téléchargement ou le chargement de fichiers et la connexion ou la déconnexion des utilisateurs afin de garantir une sécurité robuste. Par exemple,

Si l'utilisateur est connecté à l'application Microsoft Teams dans XenApp et tente de se déconnecter, Netskope Client bloque l'action de l'utilisateur et lui envoie une alerte.
Netskope Client empêche le téléchargement de fichiers ou la publication de contenu dans l'application Cloud publiée. Par exemple, si l'utilisateur est connecté à l'application Microsoft Teams dans XenApp et tente de télécharger un fichier confidentiel à partir du chat Teams, Netskope Client bloque l'action de l'utilisateur et lui envoie une alerte.
Netskope Client empêche les activités de trafic web telles que le chargement ou le téléchargement par l'intermédiaire d'un navigateur. Par exemple, si l'utilisateur tente de télécharger l'application Notepad++ via le navigateur Microsoft Edge ou Google Chrome. Netskope Client bloque l'action de l'utilisateur et lui envoie une alerte.
Netskope Client empêche les activités de trafic web telles que l'accès à des domaines non autorisés par le biais d'un navigateur. Par exemple, si l'utilisateur tente d'accéder à un domaine tel que www.gambling.com via le navigateur Microsoft Edge ou Google Chrome. Le message de blocage apparaît sur le navigateur lorsque l'utilisateur saisit le nom de domaine dans l'URL du navigateur.