Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurité

Cette section explique comment sécuriser les données à l'aide du chiffrement lors de l'utilisation WorkSpaces des services Amazon. Il décrit le chiffrement en transit et au repos, ainsi que l'utilisation de groupes de sécurité pour protéger l'accès réseau au WorkSpaces. Cette section fournit également des informations sur la façon de contrôler l'accès aux appareils finaux à WorkSpaces l'aide de périphériques sécurisés et de groupes de contrôle d'accès IP.

Vous trouverez des informations supplémentaires sur l'authentification (y compris le support MFA) dans le AWS Directory Service dans cette section.

Chiffrement en transit

Amazon WorkSpaces utilise la cryptographie pour protéger la confidentialité à différentes étapes de la communication (en transit) et également pour protéger les données au repos (cryptées WorkSpaces). Les processus de chaque étape du chiffrement utilisé par Amazon pendant WorkSpaces le transport sont décrits dans les sections suivantes.

Pour plus d'informations sur le chiffrement au repos, reportez-vous à la WorkSpaces section Chiffrée de ce document.

Inscription et mises à jour

L'application cliente de bureau communique avec Amazon pour les mises à jour et l'enregistrement via HTTPS.

Étape d'authentification

Le client de bureau initie l'authentification en envoyant des informations d'identification à la passerelle d'authentification. La communication entre le client de bureau et la passerelle d'authentification utilise le protocole HTTPS. À la fin de cette étape, si l'authentification réussit, la passerelle d'authentification renvoie un jeton OAuth 2.0 au client de bureau, via la même connexion HTTPS.

Après avoir reçu les informations d'identification du client, la passerelle d'authentification envoie une demande d'authentification au AWS Directory Service. La communication entre la passerelle d'authentification et le AWS Directory Service s'effectue via HTTPS, de sorte qu'aucun identifiant utilisateur n'est transmis en texte clair.

Authentification — Connecteur Active Directory (ADC)

AD Connector utilise Kerberos pour établir une communication authentifiée avec AD sur site, afin de pouvoir se lier à LDAP et exécuter les requêtes LDAP suivantes. Le support LDAPS côté client dans ADC est également disponible pour chiffrer les requêtes entre Microsoft AD et Applications. AWS Avant d'implémenter la fonctionnalité LDAPS côté client, passez en revue les conditions requises pour le LDAPS côté client.

Le AWS Directory Service prend également en charge le protocole LDAP avec TLS. Aucune information d'identification utilisateur n'est transmise en texte clair à aucun moment. Pour une sécurité accrue, il est possible de connecter un WorkSpaces VPC au réseau local (où réside AD) à l'aide d'une connexion VPN. Lorsqu'ils utilisent une connexion VPN AWS matérielle, les clients peuvent configurer le chiffrement en transit en utilisant les normes IPSEC (Internet Key Exchange (IKE) et IPSEC SaS) avec des clés de chiffrement symétriques AES-128 ou AES-256, SHA-1 ou SHA-256 pour le hachage d'intégrité et des groupes DH (2,14-18, 22, 23 et 24 pour la phase 2) en utilisant une confidentialité directe (PFS)).

Étape de courtier

Après avoir reçu le jeton OAuth 2.0 (depuis la passerelle d'authentification, si l'authentification a réussi), le client de bureau interroge les WorkSpaces services Amazon (Broker Connection Manager) via HTTPS. Le client de bureau s'authentifie en envoyant le jeton OAuth 2.0 et, par conséquent, le client reçoit les informations de point de terminaison de la passerelle de streaming. WorkSpaces

Étape de diffusion

Le client de bureau demande l'ouverture d'une session PCoIP avec la passerelle de streaming (à l'aide du jeton OAuth 2.0). Cette session est cryptée en AES-256 et utilise le port PCoIP pour le contrôle des communications (4172/TCP).

À l'aide du jeton OAuth2.0, la passerelle de streaming demande les WorkSpaces informations spécifiques à l'utilisateur au WorkSpaces service Amazon, via HTTPS.

La passerelle de streaming reçoit également le TGT du client (qui est chiffré à l'aide du mot de passe de l'utilisateur du client) et, en utilisant le transfert Kerberos TGT, la passerelle initie une connexion Windows sur le, en utilisant le TGT Kerberos récupéré par l' WorkSpaceutilisateur.

Il lance WorkSpace ensuite une demande d'authentification auprès du AWS Directory Service configuré, en utilisant l'authentification Kerberos standard.

Une fois WorkSpace connecté avec succès, le streaming PCoIP démarre. La connexion est initiée par le client sur le port TCP 4172 avec le trafic de retour sur le port UDP 4172. De plus, la connexion initiale entre la passerelle de streaming et un WorkSpaces poste de travail via l'interface de gestion se fait via le protocole UDP 55002. (Reportez-vous à la documentation pour connaître les exigences en matière d'adresse IP et de port pour Amazon WorkSpaces. Le port UDP sortant initial est 55002.) La connexion de streaming, utilisant les ports 4172 (TCP et UDP), est cryptée à l'aide de chiffrements AES 128 et 256 bits, mais par défaut, 128 bits. Les clients peuvent modifier activement ce paramètre en 256 bits, soit en utilisant les paramètres de stratégie de groupe AD spécifiques à PCoIP pour Windows WorkSpaces, soit avec le fichier pcoip-agent.conf pour Amazon Linux. WorkSpaces Pour plus d'informations sur l'administration des politiques de groupe pour Amazon WorkSpaces, consultez la documentation.

Interfaces réseau

Chaque Amazon WorkSpace possède deux interfaces réseau, appelées interface réseau principale et interface réseau de gestion.

L'interface réseau principale fournit la connectivité aux ressources du VPC du client, telles que l'accès au AWS Directory Service, à Internet et au réseau d'entreprise du client. Il est possible d'associer des groupes de sécurité à cette interface réseau principale. Conceptuellement, les groupes de sécurité attachés à cette ENI sont différenciés en fonction de l'étendue du déploiement : groupe de WorkSpaces sécurité et groupes de sécurité ENI.

Interface réseau de gestion

L'interface réseau de gestion ne peut pas être contrôlée par le biais de groupes de sécurité ; toutefois, les clients peuvent utiliser un pare-feu basé sur l'hôte WorkSpaces pour bloquer les ports ou contrôler l'accès. Nous ne recommandons pas d'appliquer des restrictions à l'interface du réseau de gestion. Si un client décide d'ajouter des règles de pare-feu basées sur l'hôte pour gérer cette interface, quelques ports doivent être ouverts afin que le WorkSpaces service Amazon puisse gérer l'état et l'accessibilité du. WorkSpace Pour plus d'informations, reportez-vous à la section Interfaces réseau du guide d'administration d'Amazon Workspaces.

WorkSpaces groupes de sécurité

Un groupe de sécurité par défaut est créé par AWS Directory Service et est automatiquement attaché à tous WorkSpaces ceux qui appartiennent à ce répertoire spécifique.

Amazon WorkSpaces, comme de nombreux autres AWS services, utilise des groupes de sécurité. Amazon WorkSpaces crée deux groupes AWS de sécurité lorsque vous enregistrez un annuaire auprès du WorkSpaces service. Un pour les contrôleurs de répertoire DirectoryID_Controllers et un pour WorkSpaces le répertoire DirectoryID_WorkspacesMembers. Ne supprimez aucun de ces groupes de sécurité, sinon vous WorkSpaces serez affaibli. Par défaut, la sortie du groupe de sécurité WorkSpaces Membres est ouverte à 0.0.0.0/0. Vous pouvez ajouter un groupe WorkSpaces de sécurité par défaut à un répertoire. Une fois que vous avez associé un nouveau groupe de sécurité à un WorkSpaces répertoire, le nouveau groupe de sécurité sera associé au nouveau groupe de sécurité WorkSpaces WorkSpaces que vous lancez ou que vous reconstruisez. Vous pouvez également ajouter ce nouveau groupe de sécurité par défaut à un groupe existant WorkSpaces sans le reconstruire. Lorsque vous associez plusieurs groupes de sécurité à un WorkSpaces annuaire, WorkSpaces regroupez les règles de chaque groupe de sécurité en un seul ensemble de règles. Nous vous recommandons de condenser le plus possible vos règles de groupe de sécurité. Pour plus d'informations sur les groupes de sécurité, reportez-vous à la section Groupes de sécurité pour votre VPC dans le guide de l'utilisateur Amazon VPC.

Pour plus d'informations sur l'ajout d'un groupe de sécurité à un WorkSpaces répertoire ou à un répertoire existant WorkSpace, consultez le guide de l'WorkSpaces administrateur.

Certains clients souhaitent restreindre les ports et les destinations par lesquels le WorkSpaces trafic peut sortir. Pour limiter le trafic sortant du WorkSpaces, vous devez vous assurer de laisser les ports spécifiques nécessaires aux communications de service ; sinon, vos utilisateurs ne pourront pas se connecter à leur WorkSpaces.

WorkSpaces utiliser l'Elastic Network Interface (ENI) dans le VPC du client pour communiquer avec les contrôleurs de domaine lors de la WorkSpace connexion. Pour permettre à vos utilisateurs de s'y connecter WorkSpaces correctement, vous devez autoriser les ports suivants à accéder à vos contrôleurs de domaine ou aux plages d'adresses CIDR qui incluent vos contrôleurs de domaine dans le groupe de sécurité _WorkspacesMembers.

Si vous WorkSpaces devez accéder à d'autres applications, à Internet ou à d'autres emplacements, vous devez autoriser ces ports et destinations en notation CIDR au sein du groupe de sécurité _WorkspacesMembers. Si vous n'ajoutez pas ces ports et destinations, ils n'atteindront rien d'autre que les ports listés ci-dessus. WorkSpaces Enfin, par défaut, un nouveau groupe de sécurité n'a aucune règle de trafic entrant. Par conséquent, aucun trafic entrant issu d'un autre hôte de votre instance n'est autorisé tant que vous n'avez pas ajouté des règles entrantes au groupe de sécurité. Les étapes ci-dessus ne sont requises que si vous souhaitez limiter la sortie WorkSpaces ou verrouiller les règles d'entrée uniquement aux ressources ou aux plages d'adresses CIDR qui devraient y avoir accès.

Groupes de sécurité ENI

L'interface réseau principale étant une ENI classique, elle peut être gérée à l'aide AWS des différents outils de gestion. Pour plus d'informations, reportez-vous à Elastic Network Interfaces. Accédez à l'adresse WorkSpace IP ( WorkSpaces sur la page de la WorkSpaces console Amazon), puis utilisez cette adresse IP comme filtre pour trouver l'ENI correspondant (dans la section Interfaces réseau de la console Amazon EC2).

Une fois l'ENI localisé, il peut être géré directement par les groupes de sécurité. Lorsque vous attribuez manuellement des groupes de sécurité à l'interface réseau principale, tenez compte des exigences en matière de port d'Amazon WorkSpaces. Pour plus d'informations, reportez-vous à la section Interfaces réseau du guide d'administration d'Amazon Workspaces.

Listes de contrôle d'accès réseau (ACL)

En raison de la complexité accrue de la gestion d'un autre pare-feu, les ACL réseau sont couramment utilisées dans des déploiements très complexes et ne constituent généralement pas une bonne pratique. Comme les ACL réseau sont attachées aux sous-réseaux du VPC, leur fonction se concentre sur la couche 3 (réseau) du modèle OSI. Amazon WorkSpaces étant conçu sur les services d'annuaire, deux sous-réseaux doivent être définis. Les ACL réseau sont gérées séparément des services d'annuaire, et il est fort probable qu'une ACL réseau soit attribuée à un seul des sous-réseaux WorkSpaces « assignés ».

Lorsqu'un pare-feu sans état est requis, les listes de contrôle d'accès réseau constituent une bonne pratique en matière de sécurité. Assurez-vous que toutes les modifications apportées aux ACL réseau au-delà des paramètres par défaut sont validées par sous-réseau, conformément à la meilleure pratique. Si les ACL réseau ne fonctionnent pas comme prévu, pensez à utiliser les journaux de flux VPC pour analyser le trafic.

AWS Network Firewall

AWS Network Firewall offre des fonctionnalités allant au-delà de celles proposées par les groupes de sécurité natifs et les ACL réseau, mais moyennant un coût. Lorsque les clients ont demandé la possibilité de renforcer la sécurité des connexions réseau, telles que l'inspection des noms de serveur (SNI) pour les sites Web basés sur HTTPS, la détection et la prévention des intrusions et une liste d'autorisation et de refus pour les noms de domaine, ils ont dû trouver d'autres pare-feux sur le. AWS Marketplace La complexité du déploiement de ces pare-feux présentait des défis qui dépassaient les compétences des administrateurs EUC standard. AWS Network Firewall offre une AWS expérience native tout en activant les protections des couches 3 à 7. L'utilisation de AWS Network Firewall en conjonction avec NAT Gateway est une bonne pratique lorsque les entreprises ne disposent d'aucun autre moyen (licences sur site existantes pour les pare-feux tiers pouvant être transférés vers le cloud ou équipes distinctes qui gèrent les pare-feux exclues) pour couvrir toutes les protections du réseau EUC. NAT Gateway est également gratuit avec AWS Network Firewall.

Les déploiements de AWS Network Firewall sont conçus sur la base de la conception EUC existante. Les conceptions à VPC unique permettent d'obtenir une architecture simplifiée avec des sous-réseaux pour les points de terminaison du pare-feu et des considérations distinctes relatives au routage des sorties Internet, tandis que les conceptions à VPC multiples tirent parti d'un VPC d'inspection consolidé avec points de terminaison pare-feu et passerelles de transit.

Scénarios de conception

Scénario 1 : verrouillage de base de l'instance

Le groupe WorkSpaces de sécurité par défaut n'autorise aucun trafic entrant, car les groupes de sécurité sont refusés par défaut et dotés d'un état. Cela signifie qu'aucune configuration supplémentaire ne doit être configurée pour sécuriser davantage les WorkSpaces instances elles-mêmes. Tenez compte des règles sortantes qui autorisent tout le trafic, et déterminez si cela correspond au cas d'utilisation. Par exemple, il peut être préférable de refuser tout le trafic sortant vers le port 443, quelle que soit l'adresse, ainsi que les plages d'adresses IP spécifiques adaptées aux cas d'utilisation des ports, telles que 389 pour LDAP, 636 pour LDAPS, 445 pour SMB, entre autres ; notez toutefois que la complexité de l'environnement peut nécessiter plusieurs règles et qu'il est donc préférable de le faire via des ACL réseau ou un dispositif de pare-feu.

Scénario 2 : Exceptions entrantes

Bien qu'il ne s'agisse pas d'une exigence constante, il peut arriver que le trafic réseau soit initié en provenance de WorkSpaces. Par exemple, le triage des instances lorsque le WorkSpaces client ne peut pas se connecter nécessite une autre connectivité à distance. Dans ces cas, il est préférable d'activer temporairement le protocole TCP 3389 entrant pour le groupe de sécurité du client ENI WorkSpace du client.

Un autre scénario est celui des scripts organisationnels qui exécutent des commandes pour les fonctions d'inventaire ou d'automatisation, initiées par une instance centralisée. La sécurisation du trafic sur ce port à partir de ces instances centralisées spécifiques sur le trafic entrant peut être configurée de manière permanente. Toutefois, il est recommandé de le faire sur le groupe de sécurité supplémentaire attaché à la configuration du répertoire, car il peut être appliqué à plusieurs déploiements dans le AWS compte.

Enfin, certains trafics réseau ne sont pas basés sur l'état et nécessiteront que des ports éphémères soient spécifiés dans les exceptions entrantes. Si les requêtes et les scripts échouent, il est recommandé d'autoriser les ports éphémères, au moins temporairement, tout en déterminant la cause première de la panne de connectivité.

Scénario 3 : inspection d'un seul VPC

Les déploiements simplifiés WorkSpaces (tels qu'un VPC unique sans plan de dimensionnement) ne nécessitent pas de VPC distinct pour l'inspection. La connexion à d'autres VPC peut donc être simplifiée grâce au peering VPC. Cependant, des sous-réseaux distincts pour les points de terminaison du pare-feu doivent être créés avec le routage configuré vers ces points de terminaison ainsi que le routage de sortie Internet Gateway (IGW), qui n'aurait pas besoin d'être configuré autrement. Les déploiements existants peuvent ne pas disposer de l'espace IP disponible si tous les sous-réseaux utilisent l'intégralité du bloc d'adresse CIDR VPC. Dans ces cas, le scénario 4 peut être plus efficace car le déploiement a déjà dépassé sa conception initiale.

Scénario 4 : Inspection centralisée

Souvent préféré dans le cadre de plusieurs déploiements EUC dans une même AWS région, ce qui simplifie l'administration des règles statiques et apatrides du pare-feu AWS réseau. Les homologues VPC existants seront remplacés par des passerelles de transit, car cette conception nécessite l'utilisation de pièces jointes Transit Gateway ainsi que le routage d'inspection qui ne peut être configuré que via ces pièces jointes. Un plus grand contrôle est également exercé sur cette configuration, ce qui permet une sécurité allant au-delà de l' WorkSpaces expérience par défaut.

Chiffré WorkSpaces

Chaque Amazon WorkSpace est approvisionné avec un volume racine (C : lecteur pour Windows WorkSpaces, racine pour Amazon Linux WorkSpaces) et un volume utilisateur (D : lecteur pour Windows WorkSpaces, /home pour Amazon Linux WorkSpaces). La WorkSpaces fonction cryptée permet de chiffrer un ou les deux volumes.

Qu'est-ce qui est chiffré ?

Les données stockées au repos, les entrées/sorties (E/S) du disque vers le volume et les instantanés créés à partir de volumes chiffrés sont tous chiffrés.

Quand le chiffrement a-t-il lieu ?

Le chiffrement d'un WorkSpace doit être spécifié lors du lancement (création) du WorkSpace. WorkSpaces les volumes ne peuvent être chiffrés qu'au moment du lancement : après le lancement, l'état de chiffrement des volumes ne peut pas être modifié. La figure suivante montre la page de WorkSpaces console Amazon permettant de choisir le chiffrement lors du lancement d'un nouveau système WorkSpace.

Comment est WorkSpace crypté un nouveau produit ?

Un client peut choisir l' WorkSpaces option Encrypted depuis la WorkSpaces console Amazon ou en utilisant l' WorkSpaces API Amazon lorsqu'il lance une nouvelle application WorkSpace. AWS CLI

Pour chiffrer les volumes, Amazon WorkSpaces utilise une clé CMK provenant de AWS Key Management Service ()AWS KMS. Une clé AWS KMS CMK par défaut est créée la première fois qu'une clé WorkSpace est lancée dans une région. (Les CMK ont une portée régionale.)

Un client peut également créer une clé CMK gérée par le client à utiliser avec le chiffrement. WorkSpaces Le CMK est utilisé pour chiffrer les clés de données utilisées par le WorkSpaces service Amazon pour chiffrer chacun des volumes. WorkSpace (Au sens strict, c'est Amazon EBS qui chiffrera les volumes). Pour connaître les limites CMK actuelles, reportez-vous à la section Quotas de AWS KMS ressources.

Pour une description détaillée du processus de WorkSpaces chiffrement, reportez-vous à la section Comment Amazon l' WorkSpaces utilise AWS KMS. Réfléchissez à la manière dont l'utilisation de CMK sera surveillée pour garantir qu'une demande de chiffrement WorkSpace est traitée correctement. Pour plus d'informations sur AWS KMS les clés et les clés de données, consultez la AWS KMS page.

Options de contrôle d'accès et appareils fiables

Amazon WorkSpaces propose aux clients des options leur permettant de gérer les appareils clients auxquels ils peuvent accéder WorkSpaces. Les clients peuvent limiter WorkSpaces l'accès aux appareils fiables uniquement. L'accès à WorkSpaces peut être autorisé à partir de macOS et de PC Microsoft Windows à l'aide de certificats numériques. Il peut également autoriser ou bloquer l'accès pour les clients iOS, Android, Chrome OS, Linux et Zero, ainsi que pour le client WorkSpaces Web Access. Grâce à ces fonctionnalités, il peut encore améliorer la posture de sécurité.

Les options de contrôle d'accès sont activées pour les nouveaux déploiements afin que les utilisateurs puissent y accéder WorkSpaces depuis des clients sous Windows, macOS, iOS, Android, ChromeOS et Zero Clients. L'accès via Web Access ou un WorkSpaces client Linux n'est pas activé par défaut pour un nouveau WorkSpaces déploiement et devra être activé.

Si l'accès aux données d'entreprise à partir d'appareils sécurisés (également appelés appareils administrés) est limité, WorkSpaces l'accès peut être limité aux appareils sécurisés dotés de certificats valides. Lorsque cette fonctionnalité est activée, Amazon WorkSpaces utilise une authentification basée sur des certificats pour déterminer si un appareil est fiable. Si l'application WorkSpaces cliente ne parvient pas à vérifier qu'un appareil est fiable, elle bloque les tentatives de connexion ou de reconnexion depuis l'appareil.

Un support fiable pour les appareils est disponible pour les clients suivants :

Pour plus d'informations sur le contrôle des appareils autorisés à accéder WorkSpaces, reportez-vous à la section Restreindre WorkSpaces l'accès aux appareils fiables.

Groupes de contrôle d'accès IP

À l'aide de groupes de contrôle basés sur les adresses IP, les clients peuvent définir et gérer des groupes d'adresses IP fiables, et autoriser les utilisateurs à accéder à leurs adresses WorkSpaces uniquement lorsqu'ils sont connectés à un réseau fiable. Cette fonctionnalité permet aux clients de mieux contrôler leur niveau de sécurité.

Des groupes de contrôle d'accès IP peuvent être ajoutés au niveau du WorkSpaces répertoire. Il existe deux manières de commencer à utiliser les groupes de contrôle d'accès IP.

Pour une description détaillée de l'utilisation des groupes de contrôle d'accès IP dans le cadre du processus de WorkSpaces chiffrement Amazon, reportez-vous à la section Groupes de contrôle d'accès IP pour vous WorkSpaces.

Surveillance ou journalisation à l'aide d'Amazon CloudWatch

La surveillance du réseau, des serveurs et des journaux fait partie intégrante de toute infrastructure. Les clients qui déploient Amazon WorkSpaces doivent surveiller leurs déploiements, en particulier l'état de santé général et l'état de connexion de chacun WorkSpaces.

CloudWatch Métriques Amazon pour WorkSpaces

CloudWatch metrics for WorkSpaces est conçu pour fournir aux administrateurs des informations supplémentaires sur l'état de santé général et l'état de connexion d'un individu WorkSpaces. Les métriques sont disponibles par WorkSpace ou agrégées pour tous les membres WorkSpaces d'une organisation au sein d'un annuaire donné.

Ces métriques, comme toutes les CloudWatch métriques, peuvent être consultées dans le AWS Management Console (illustré dans la figure suivante), accessibles via les CloudWatch API et surveillées par des CloudWatch alarmes et des outils tiers.

Par défaut, les mesures suivantes sont activées et sont disponibles sans frais supplémentaires :

En outre, des alarmes peuvent être créées, comme le montre la figure suivante.

Amazon CloudWatch Events pour WorkSpaces

Les événements d'Amazon CloudWatch Events peuvent être utilisés pour afficher, rechercher, télécharger, archiver, analyser et répondre aux connexions réussies à WorkSpaces. Le service peut surveiller les adresses IP WAN des clients, le système d'exploitation, l' WorkSpaces identifiant et les informations d'identifiant de répertoire auxquelles les utilisateurs se WorkSpaces connectent. Par exemple, il peut utiliser des événements aux fins suivantes :

Pour plus d'informations sur l'utilisation d' CloudWatch Events, consultez le guide de l'utilisateur Amazon CloudWatch Events. Pour en savoir plus sur les CloudWatch événements pour WorkSpaces, reportez-vous à la section Surveiller votre WorkSpaces utilisation de Cloudwatch Events.

YubiKey support pour Amazon WorkSpaces

Afin d'ajouter une couche de sécurité supplémentaire, les clients choisissent souvent de sécuriser les outils et les sites avec une authentification multifactorielle. Certains clients choisissent de le faire avec un Yubico YubiKey. Amazon WorkSpaces prend en charge à la fois les codes d'accès à usage unique (OTP) et le protocole d'authentification FIDO U2F avec. YubiKeys

Amazon prend WorkSpaces actuellement en charge le mode OTP, et aucune étape supplémentaire n'est requise de la part d'un administrateur ou d'un utilisateur final pour utiliser un YubiKey avec OTP. L'utilisateur peut le connecter YubiKey à son ordinateur, s'assurer que le clavier est focalisé dans le WorkSpace (en particulier dans le champ où l'OTP doit être saisi) et toucher le contact doré duYubiKey. L'OTP YubiKey sera automatiquement saisi dans le champ sélectionné.

Pour utiliser le mode FIDO U2F avec YubiKey et WorkSpaces, des étapes supplémentaires sont nécessaires. Assurez-vous que vos utilisateurs disposent de l'un de ces YubiKey modèles pris en charge afin d'utiliser la redirection U2F avec : WorkSpaces

Pour activer la redirection USB pour YubiKey U2F

Par défaut, la redirection USB est désactivée pour PCoIP WorkSpaces ; pour utiliser le mode U2F avec YubiKeys, vous devez l'activer.

Une fois que vous avez activé la redirection USB pour YubiKey U2F, vous pouvez utiliser le mode Fido U2F. YubiKey