Conexión segura con Holographic Remoting Overview

Si no está de acuerdo con la comunicación remota holográfica, puede leer nuestra información general.

Nota

Esta guía es específica de la comunicación remota holográfica en HoloLens 2 y Windows equipos que ejecutan Windows Mixed Reality.

En esta página se proporciona información general sobre la seguridad de red para la comunicación remota holográfica. Encontrará información sobre:

  • Seguridad en el contexto de la comunicación remota holográfica y por qué podría necesitarla
  • Medidas recomendadas basadas en distintos casos de uso

Seguridad de comunicación remota holográfica

Holographic Remoting intercambia información a través de una red. Si no hay medidas de seguridad, los adversarios de la misma red pueden poner en peligro la integridad de la comunicación o acceder a información confidencial.

Las aplicaciones de ejemplo y Holographic Remoting Player de Windows Store incluyen seguridad deshabilitada. Si lo hace, los ejemplos son más fáciles de entender. También le ayuda a empezar a trabajar más rápidamente con el desarrollo.

Para pruebas de campo o producción, se recomienda encarecidamente habilitar la seguridad en la solución de comunicación remota holográfica.

La seguridad en la comunicación remota holográfica, cuando se configura correctamente para su caso de uso, le ofrece las siguientes garantías:

  • Autenticidad: tanto el reproductor como la aplicación remota pueden estar seguros de que el otro lado es quien dice ser.
  • Confidencialidad: ningún tercero puede leer la información intercambiada entre el reproductor y la aplicación remota.
  • Integridad: el reproductor y el remoto pueden detectar cualquier cambio en tránsito en su comunicación

Importante

Para poder usar características de seguridad, deberá implementar un reproductor personalizado y una aplicación remota personalizada mediante Windows Mixed Reality API deOpenXR.

Nota

A partir de la versión 2.4.0, se pueden crear aplicaciones remotas mediante la API de OpenXR . Puede encontrar información general sobre cómo establecer una conexión segura en un entorno de OpenXR aquí.

Planeamiento de la implementación de seguridad

Al habilitar la seguridad en la comunicación remota holográfica, la biblioteca de comunicación remota habilitará automáticamente las comprobaciones de cifrado e integridad de todos los datos intercambiados a través de la red.

Sin embargo, para garantizar la autenticación adecuada es necesario realizar algún trabajo adicional. Lo que debe hacer exactamente depende de su caso de uso y el resto de esta sección trata de averiguar los pasos necesarios.

Importante

Este artículo solo puede proporcionar instrucciones generales. Si no está seguro, considere la posibilidad de consultar a un experto en seguridad que pueda proporcionar instrucciones específicas para su caso de uso.

En primer lugar, alguna terminología: al describir las conexiones de red, se usarán los términos cliente y servidor. El servidor es el lado que escucha las conexiones entrantes en una dirección de punto de conexión conocida y el cliente es el que se conecta al punto de conexión del servidor.

Nota

Los roles de cliente y servidor no están vinculados a si una aplicación actúa como reproductor o como remota. Aunque los ejemplos tienen el reproductor en el rol de servidor, es fácil invertir los roles si se ajusta mejor a su caso de uso.

Planeamiento de la autenticación de servidor a cliente

El servidor usa certificados digitales para demostrar su identidad al cliente. El cliente valida el certificado del servidor durante la fase de protocolo de enlace de conexión. Si el cliente no confía en el servidor, finalizará la conexión en este momento.

La forma en que el cliente valida el certificado de servidor y qué tipos de certificados de servidor se pueden usar, depende de su caso de uso.

Caso de uso 1: El nombre de host del servidor no es fijo o el servidor no se dirige por nombre de host en absoluto.

En este caso de uso, no es práctico (ni siquiera posible) emitir un certificado para el nombre de host del servidor. En su lugar, se recomienda validar la huella digital del certificado. Al igual que una huella digital humana, la huella digital identifica de forma única un certificado.

Es importante comunicar la huella digital al cliente fuera de banda. Esto significa que no se puede enviar a través de la misma conexión de red que se usa para la comunicación remota. En su lugar, podría escribirlo manualmente en la configuración del cliente o hacer que el cliente digitalizara un código QR.

Caso de uso 2: Se puede acceder al servidor a través de un nombre de host estable.

En este caso de uso, el servidor tiene un nombre de host específico y sabe que es probable que este nombre no cambie. A continuación, puede usar un certificado emitido para el nombre de host del servidor. La confianza se establecerá en función del nombre de host y la cadena de confianza del certificado.

Si elige esta opción, el cliente debe conocer de antemano el nombre de host del servidor y el certificado raíz.

Planeamiento de la autenticación de cliente a servidor

Los clientes se autentican en el servidor mediante un token de forma libre. Lo que este token debe contener dependerá de nuevo del caso de uso:

Caso de uso 1: Solo tiene que comprobar la identidad de la aplicación cliente.

En este caso de uso, un secreto compartido puede ser suficiente. Este secreto debe ser lo suficientemente complejo como para que no se pueda adivinar.

Un buen secreto compartido es un GUID aleatorio, que se introduce manualmente en la configuración del servidor y del cliente. Para crear uno, puede, por ejemplo, usar el New-Guid comando en PowerShell.

Asegúrese de que este secreto compartido nunca se comunica a través de canales no seguros. La biblioteca de comunicación remota garantiza que el secreto compartido siempre se envía cifrado y solo a los pares de confianza.

Caso de uso 2: También debe comprobar la identidad del usuario de la aplicación cliente.

Un secreto compartido no será suficiente para cubrir este caso de uso. En su lugar, puede usar tokens creados por un proveedor de identidades. Un flujo de trabajo de autenticación mediante un proveedor de identidades tendría el siguiente aspecto:

  • El cliente autoriza contra el proveedor de identidades y solicita un token
  • El proveedor de identidades genera un token y lo envía al cliente.
  • El cliente envía este token al servidor a través de Holographic Remoting
  • El servidor valida el token del cliente con el proveedor de identidades.

Un ejemplo de un proveedor de identidades es el Plataforma de identidad de Microsoft.

Al igual que en el caso de uso anterior, asegúrese de que estos tokens no se envían a través de canales no seguros ni se exponen de otro modo.

Consulte también