Visão geral da conexão segura com comunicação remota holográfica

Se você não estiver familiarizado com a Comunicação Remota Holográfica, talvez queira ler nossa visão geral.

Esta página fornece uma visão geral da segurança de rede para Comunicação Remota Holográfica. Você encontrará informações sobre:

• Segurança no contexto da Comunicação Remota Holográfica e por que você pode precisar dela
• Medidas recomendadas com base em diferentes casos de uso

Segurança de comunicação remota holográfica

A Comunicação Remota Holográfica troca informações por uma rede. Se nenhuma medida de segurança estiver em vigor, os adversários na mesma rede poderão comprometer a integridade da comunicação ou acessar informações confidenciais.

Os aplicativos de exemplo e o Player de Comunicação Remota Holográfica na Windows Store vêm com a segurança desabilitada. Fazer isso torna as amostras mais fáceis de entender. Ele também ajuda você a começar mais rapidamente com o desenvolvimento.

Para teste de campo ou produção, é altamente recomendável habilitar a segurança em sua solução de Comunicação Remota Holográfica.

A segurança na Comunicação Remota Holográfica, quando configurada corretamente para seu caso de uso, oferece as seguintes garantias:

• Autenticidade: o jogador e o aplicativo remoto podem ter certeza de que o outro lado é quem eles afirmam ser
• Confidencialidade: nenhum terceiro pode ler as informações trocadas entre o player e o aplicativo remoto
• Integridade: o player e o remoto podem detectar alterações em trânsito em sua comunicação

Planejando a implementação de segurança

Quando você habilita a segurança na Comunicação Remota Holográfica, a biblioteca de comunicação remota habilitará automaticamente as verificações de criptografia e integridade de todos os dados trocados pela rede.

No entanto, garantir a autenticação adequada requer algum trabalho extra. O que exatamente você precisa fazer depende do seu caso de uso, e o restante desta seção é sobre descobrir as etapas necessárias.

Primeiro, algumas terminologias: ao descrever conexões de rede, os termos cliente e servidor serão usados. O servidor é o lado escutando conexões de entrada em um endereço de ponto de extremidade conhecido e o cliente é aquele que se conecta ao ponto de extremidade do servidor.

Planejando a autenticação de servidor para cliente

O servidor usa certificados digitais para provar sua identidade para o cliente. O cliente valida o certificado do servidor durante a fase de handshake de conexão. Se o cliente não confiar no servidor, ele encerrará a conexão neste ponto.

A forma como o cliente valida o certificado do servidor e quais tipos de certificados de servidor podem ser usados depende do caso de uso.

Caso de uso 1: O nome do host do servidor não foi corrigido ou o servidor não é endereçado pelo nome do host.

Nesse caso de uso, não é prático (ou mesmo possível) emitir um certificado para o nome do host do servidor. Recomendamos que você valide a impressão digital do certificado. Como uma impressão digital humana, a impressão digital identifica exclusivamente um certificado.

É importante comunicar a impressão digital para o cliente fora de banda. Isso significa que você não pode enviá-lo pela mesma conexão de rede usada para comunicação remota. Em vez disso, você pode inseri-lo manualmente na configuração do cliente ou fazer com que o cliente examine um código QR.

Caso de uso 2: O servidor pode ser acessado por um nome de host estável.

Nesse caso de uso, o servidor tem um nome de host específico e você sabe que esse nome provavelmente não será alterado. Em seguida, você pode usar um certificado emitido para o nome do host do servidor. A confiança será estabelecida com base no nome do host e na cadeia de confiança do certificado.

Se você escolher essa opção, o cliente precisará saber o nome do host do servidor e o certificado raiz com antecedência.

Planejando a autenticação de cliente para servidor

Os clientes se autenticam no servidor usando um token de forma livre. O que esse token deve conter dependerá novamente do seu caso de uso:

Caso de uso 1: Você só precisa verificar a identidade do aplicativo cliente.

Nesse caso de uso, um segredo compartilhado pode ser suficiente. Esse segredo deve ser complexo o suficiente para não ser adivinhado.

Um bom segredo compartilhado é um GUID aleatório, que é inserido manualmente na configuração do servidor e do cliente. Para criar um, você pode, por exemplo, usar o New-Guid comando no PowerShell.

Verifique se esse segredo compartilhado nunca é comunicado por canais inseguros. A biblioteca de comunicação remota garante que o segredo compartilhado sempre seja enviado criptografado e somente para pares confiáveis.

Caso de uso 2: Você também precisa verificar a identidade do usuário do aplicativo cliente.

Um segredo compartilhado não será suficiente para cobrir esse caso de uso. Em vez disso, você pode usar tokens criados por um provedor de identidade. Um fluxo de trabalho de autenticação usando um provedor de identidade teria esta aparência:

• O cliente autoriza no provedor de identidade e solicita um token
• O provedor de identidade gera um token e o envia ao cliente
• O cliente envia esse token para o servidor por meio da Comunicação Remota Holográfica
• O servidor valida o token do cliente em relação ao provedor de identidade

Um exemplo de um provedor de identidade é o plataforma de identidade da Microsoft.

Como no caso de uso anterior, verifique se esses tokens não são enviados por canais inseguros ou expostos de outra forma.

Consulte Também

• Visão geral da Comunicação remota holográfica
• Conexão segura com a API do OpenXR
• Conexão segura com a API de Windows Mixed Reality