Vue d’ensemble de la connexion sécurisée avec accès distant holographique

Si vous ne connaissez pas la communication à distance holographique, vous souhaiterez peut-être lire notre vue d’ensemble.

Notes

ce guide est spécifique à la communication à distance holographique sur les ordinateurs 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 y trouverez des informations sur les éléments suivants :

  • La sécurité dans le contexte de la communication à distance holographique et la raison pour laquelle vous pouvez en avoir besoin
  • Mesures recommandées en fonction de différents cas d’utilisation

Sécurité de la 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 aux informations confidentielles.

la sécurité est désactivée pour les exemples d’applications et le lecteur de communication à distance holographique dans le magasin de Windows. Cela rend les exemples plus faciles à comprendre. Il vous aide également à commencer plus rapidement avec le développement.

Pour les tests de champ 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’utilisation, vous offre les garanties suivantes :

  • Authenticité : le joueur et l’application distante peuvent vérifier que l’autre côté est bien celui qu’ils revendiquent
  • Confidentialité : aucun tiers ne peut lire les informations échangées entre le joueur et l’application distante
  • Intégrité : Player et Remote peuvent détecter toute modification en transit de leur communication

Important

pour pouvoir utiliser les fonctionnalités de sécurité, vous devez implémenter à la fois 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 iciune vue d’ensemble de l’établissement d’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 contrôles d’intégrité de toutes les données échangées sur le réseau.

Le fait de garantir une authentification appropriée nécessite néanmoins des tâches supplémentaires. Ce que vous devez faire exactement dépend de votre cas d’utilisation, et le reste de cette section concerne la procédure à suivre.

Important

Cet article ne peut fournir que des conseils généraux. Si vous n’êtes pas sûr, pensez à consulter un expert en sécurité qui peut vous fournir des conseils spécifiques à votre cas d’utilisation.

Tout d’abord : lorsque vous décrivez des connexions réseau, les termes client et serveur sont utilisés. Le serveur est le côté qui écoute les 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 au fait qu’une application joue le rôle d’un lecteur ou d’un serveur distant. Tandis que les exemples ont le joueur dans le rôle de serveur, il est facile d’inverser les rôles si cela s’avère mieux adapté à votre cas d’utilisation.

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 au cours de la phase de négociation de connexion. Si le client n’approuve pas le serveur, il met fin à la connexion à ce stade.

La manière dont le client valide le certificat de serveur, ainsi que les types de certificats de serveur qui peuvent être utilisés, dépendent de votre cas d’utilisation.

Cas d’utilisation 1 : Le nom d’hôte du serveur n’est pas fixe, ou le serveur n’est pas traité par le nom d’hôte.

Dans ce cas d’utilisation, il n’est pas pratique (voire 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 pour une empreinte 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 sur 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 demander au client d’analyser un code QR.

Cas d’utilisation 2 : Le serveur peut être atteint sur un nom d’hôte stable.

Dans ce cas d’utilisation, 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 le nom d’hôte du serveur et le certificat racine à l’avance.

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’utilisation :

Cas d’utilisation 1 : Il vous suffit de vérifier l’identité de l’application cliente.

Dans ce cas d’utilisation, un secret partagé peut suffire. Ce secret doit être suffisamment complexe pour qu’il ne puisse pas être deviné.

Un secret partagé correct est un GUID aléatoire, qui est entré manuellement à la fois 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’utilisation 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’utilisation. Au lieu de cela, vous pouvez utiliser des jetons créés par un fournisseur d’identité. Un flux de travail d’authentification à l’aide d’un fournisseur d’identité ressemble à ceci :

  • 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é

le Plateforme d’identités Microsoftest un exemple de fournisseur d’identité.

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 qu’ils sont exposés autrement.

Voir aussi