Vue d’ensemble de la connexion sécurisée avec communication à distance holographique
Si vous débutez avec la communication à distance holographique, vous pouvez lire notre vue d’ensemble.
Notes
Ce guide est spécifique à la communication à distance holographique sur les PC HoloLens 2 et Windows exécutant Windows Mixed Reality.
Cette page vous donne une vue d’ensemble de la sécurité réseau pour la communication à distance holographique. Vous trouverez des informations sur :
- Sécurité dans le contexte de la communication à distance holographique et pourquoi vous pouvez en avoir besoin
- Mesures recommandées en fonction de différents cas d’usage
Sécurité de communication à distance holographique
La communication à distance holographique échange des informations sur un réseau. Si aucune mesure de sécurité n’est en place, les adversaires sur le même réseau peuvent compromettre l’intégrité de la communication ou accéder à des informations confidentielles.
Les exemples d’applications et le lecteur de communication à distance holographique dans le Windows Store sont fournis avec la sécurité désactivée. Cela facilite la compréhension des exemples. Il vous aide également à démarrer plus rapidement avec le développement.
Pour les tests sur le terrain ou la production, nous vous recommandons vivement d’activer la sécurité dans votre solution de communication à distance holographique.
La sécurité dans la communication à distance holographique, lorsqu’elle est configurée correctement pour votre cas d’usage, vous offre les garanties suivantes :
- Authenticité : le joueur et l’application distante peuvent être sûrs que l’autre côté est ce qu’ils prétendent être
- Confidentialité : aucun tiers ne peut lire les informations échangées entre le joueur et l’application distante
- Intégrité : les joueurs et les utilisateurs distants peuvent détecter toutes les modifications apportées à leur communication en transit
Important
Pour pouvoir utiliser les fonctionnalités de sécurité, vous devez implémenter un lecteur personnalisé et une application distante personnalisée à l’aide des API Windows Mixed Reality ou OpenXR.
Notes
À partir de la version 2.4.0, vous pouvez créer des applications distantes à l’aide de l’API OpenXR . Vous trouverez ici une vue d’ensemble de la façon d’établir une connexion sécurisée dans un environnement OpenXR.
Planification de l’implémentation de la sécurité
Lorsque vous activez la sécurité dans la communication à distance holographique, la bibliothèque de communication à distance active automatiquement le chiffrement et les vérifications d’intégrité pour toutes les données échangées sur le réseau.
Toutefois, la garantie d’une authentification correcte nécessite un travail supplémentaire. Ce que vous devez faire exactement dépend de votre cas d’usage, et le reste de cette section concerne la définition des étapes nécessaires.
Important
Cet article ne peut fournir que des conseils généraux. Si vous vous sentez incertain, envisagez de consulter un expert en sécurité qui peut vous donner des conseils spécifiques à votre cas d’usage.
Tout d’abord, une certaine terminologie : lors de la description des connexions réseau, les termes client et serveur seront utilisés. Le serveur est le côté à l’écoute des connexions entrantes sur une adresse de point de terminaison connue, et le client est celui qui se connecte au point de terminaison du serveur.
Notes
Les rôles client et serveur ne sont pas liés à l’action d’une application en tant que joueur ou en tant que distante. Bien que les exemples aient le rôle de joueur dans le rôle serveur, il est facile d’inverser les rôles s’il convient mieux à votre cas d’usage.
Planification de l’authentification de serveur à client
Le serveur utilise des certificats numériques pour prouver son identité au client. Le client valide le certificat du serveur pendant la phase d’établissement d’une liaison de connexion. Si le client n’approuve pas le serveur, il met fin à la connexion à ce stade.
La façon dont le client valide le certificat de serveur et les types de certificats de serveur qui peuvent être utilisés dépendent de votre cas d’usage.
Cas d’usage 1 : Le nom d’hôte du serveur n’est pas fixe ou le serveur n’est pas du tout traité par le nom d’hôte.
Dans ce cas d’usage, il n’est pas pratique (ou même possible) d’émettre un certificat pour le nom d’hôte du serveur. Nous vous recommandons de valider l’empreinte numérique du certificat à la place. Comme une empreinte digitale humaine, l’empreinte numérique identifie de façon unique un certificat.
Il est important de communiquer l’empreinte numérique au client hors bande. Cela signifie que vous ne pouvez pas l’envoyer via la même connexion réseau que celle utilisée pour la communication à distance. Au lieu de cela, vous pouvez l’entrer manuellement dans la configuration du client, ou pour que le client scanne un code QR.
Cas d’usage 2 : Le serveur est accessible via un nom d’hôte stable.
Dans ce cas d’usage, le serveur a un nom d’hôte spécifique, et vous savez que ce nom n’est pas susceptible de changer. Vous pouvez ensuite utiliser un certificat émis pour le nom d’hôte du serveur. L’approbation est établie en fonction du nom d’hôte et de la chaîne d’approbation du certificat.
Si vous choisissez cette option, le client doit connaître à l’avance le nom d’hôte du serveur et le certificat racine.
Planification de l’authentification client à serveur
Les clients s’authentifient auprès du serveur à l’aide d’un jeton de forme libre. Ce que ce jeton doit contenir dépend à nouveau de votre cas d’usage :
Cas d’usage 1 : Il vous suffit de vérifier l’identité de l’application cliente.
Dans ce cas d’usage, un secret partagé peut suffire. Ce secret doit être suffisamment complexe pour ne pas être deviné.
Un bon secret partagé est un GUID aléatoire, qui est entré manuellement dans la configuration du serveur et du client. Pour en créer un, vous pouvez, par exemple, utiliser la New-Guid commande dans PowerShell.
Assurez-vous que ce secret partagé n’est jamais communiqué via des canaux non sécurisés. La bibliothèque de communication à distance garantit que le secret partagé est toujours envoyé chiffré, et uniquement aux homologues approuvés.
Cas d’usage 2 : Vous devez également vérifier l’identité de l’utilisateur de l’application cliente.
Un secret partagé ne sera pas suffisant pour couvrir ce cas d’usage. Au lieu de cela, vous pouvez utiliser des jetons créés par un fournisseur d’identité. Un flux de travail d’authentification utilisant un fournisseur d’identité se présente comme suit :
- Le client autorise le fournisseur d’identité et demande un jeton
- Le fournisseur d’identité génère un jeton et l’envoie au client
- Le client envoie ce jeton au serveur via la communication à distance holographique
- Le serveur valide le jeton du client par rapport au fournisseur d’identité
Un exemple de fournisseur d’identité est le Plateforme d'identités Microsoft.
Comme dans le cas d’usage précédent, assurez-vous que ces jetons ne sont pas envoyés via des canaux non sécurisés ou exposés.