Información general sobre la conexión segura con la comunicación remota holográfica
Si no está familiarizado con la comunicación remota holográfica, puede que quiera leer nuestra información general.
Nota
Esta guía es específica de la comunicación remota holográfica en HoloLens 2 y equipos Windows 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é es posible que lo necesite
- Medidas recomendadas basadas en distintos casos de uso
Seguridad de comunicación remota holográfica
La comunicación remota holográfica intercambia información a través de una red. Si no hay ninguna medida de seguridad, los adversarios de la misma red pueden poner en peligro la integridad de la comunicación o acceder a la información confidencial.
Las aplicaciones de ejemplo y el Reproductor de comunicación remota holográfica en la Tienda Windows incluyen la seguridad deshabilitada. Al hacerlo, los ejemplos son más fáciles de entender. También le ayuda a empezar a trabajar con mayor rapidez 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, ofrece las siguientes garantías:
- Autenticidad: tanto el jugador como la aplicación remota pueden estar seguros de que el otro lado es quien dicen ser
- Confidencialidad: ningún tercero puede leer la información intercambiada entre el reproductor y la aplicación remota
- Integridad: el jugador 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 o api de OpenXR.
Nota
A partir de la versión 2.4.0 , se pueden crear aplicaciones remotas mediante la API de OpenXR . Aquí puede encontrar información general sobre cómo establecer una conexión segura en un entorno de OpenXR.
Planeación de la implementación de seguridad
Al habilitar la seguridad en Holographic Remoting, 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, garantizar la autenticación adecuada requiere un trabajo adicional. Lo que debe hacer exactamente depende de su caso de uso y el resto de esta sección consiste en 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 proporcionarle instrucciones específicas para su caso de uso.
En primer lugar, algunos términos: 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 un jugador o como un remoto. Aunque los ejemplos tienen el reproductor en el rol de servidor, es fácil revertir los roles si se ajusta mejor a su caso de uso.
Planeación 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 se ha corregido o el servidor no se dirige por nombre de host en absoluto.
En este caso de uso, no es práctico (o incluso posible) emitir un certificado para el nombre de host del servidor. Le recomendamos que valide la huella digital del certificado en su lugar. 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, puede escribirlo manualmente en la configuración del cliente o hacer que el cliente examine 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 este nombre no es probable que 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 de la cadena de confianza del certificado.
Si elige esta opción, el cliente debe conocer el nombre de host del servidor y el certificado raíz de antemano.
Planeación de la autenticación de cliente a servidor
Los clientes se autentican en el servidor mediante un token de forma libre. Lo que debe contener este token 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 escribe manualmente en la configuración del servidor y del cliente. Para crear uno, por ejemplo, use 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íe cifrado y solo a elementos del mismo nivel 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 con un proveedor de identidades tendría este aspecto:
- El cliente autoriza en 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 la comunicación remota holográfica.
- El servidor valida el token del cliente con el proveedor de identidades.
Un ejemplo de 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 expuestos de otro modo.