Partilhar via


Descrição Geral da Ligação Segura com Remoting Holográfico

Se não estiver familiarizado com o Holographic Remoting, poderá querer ler a nossa descrição geral.

Nota

Esta documentação de orientação é específica do Holographic Remoting em PCs HoloLens 2 e Windows em execução Windows Mixed Reality.

Esta página fornece-lhe uma descrição geral da segurança de rede do Holographic Remoting. Encontrará informações sobre:

  • Segurança no contexto do Holographic Remoting e por que motivo poderá precisar da mesma
  • Medidas recomendadas com base em casos de utilização diferentes

Segurança de Remoting Holográfico

O Holographic Remoting troca informações através de uma rede. Se não existirem medidas de segurança, os adversários na mesma rede poderão comprometer a integridade da comunicação ou aceder a informações confidenciais.

As aplicações de exemplo e o Holographic Remoting Player na Loja Windows são fornecidos com segurança desativada. Fazê-lo facilita a compreensão dos exemplos. Também o ajuda a começar mais rapidamente com o desenvolvimento.

Para testes de campos ou produção, recomendamos vivamente que ative a segurança na sua solução Holographic Remoting.

A segurança no Holographic Remoting, quando configurada corretamente para o seu caso de utilização, dá-lhe as seguintes garantias:

  • Autenticidade: tanto o leitor como a aplicação remota podem ter a certeza de que o outro lado é quem afirmam ser
  • Confidencialidade: nenhum terceiro pode ler as informações trocadas entre o leitor e a aplicação remota
  • Integridade: o leitor e o remoto podem detetar quaisquer alterações em trânsito na comunicação

Importante

Para poder utilizar funcionalidades de segurança, terá de implementar um leitor personalizado e uma aplicação remota personalizada com Windows Mixed Reality ou APIs OpenXR.

Nota

A partir da versão 2.4.0 , podem ser criadas aplicações remotas com a API OpenXR . Pode encontrar uma descrição geral sobre como estabelecer uma ligação segura num ambiente OpenXR aqui.

Planear a implementação de segurança

Quando ativa a segurança no Holographic Remoting, a biblioteca remota ativará automaticamente as verificações de encriptação e integridade para todos os dados trocados através da rede.

No entanto, garantir a autenticação adequada requer algum trabalho adicional. O que precisa exatamente de fazer depende do seu caso de utilização e o resto desta secção consiste em descobrir os passos necessários.

Importante

Este artigo só pode fornecer orientações gerais. Se não tiver a certeza, considere consultar um especialista em segurança que lhe possa fornecer orientações específicas para o seu caso de utilização.

Primeiro, alguma terminologia: ao descrever as ligações de rede, os termos cliente e servidor serão utilizados. O servidor é o lado a escutar as ligações recebidas num endereço de ponto final conhecido e o cliente é o que está a ligar ao ponto final do servidor.

Nota

As funções de cliente e servidor não estão ligadas ao facto de uma aplicação estar a agir como um jogador ou como um remoto. Embora os exemplos tenham o leitor na função de servidor, é fácil reverter as funções se se ajustar melhor ao seu caso de utilização.

Planear a autenticação servidor a cliente

O servidor utiliza certificados digitais para provar a sua identidade ao cliente. O cliente valida o certificado do servidor durante a fase de handshake de ligação. Se o cliente não confiar no servidor, terminará a ligação neste momento.

A forma como o cliente valida o certificado de servidor e que tipos de certificados de servidor podem ser utilizados depende do seu caso de utilização.

Caso de utilização 1: O nome do anfitrião do servidor não foi corrigido ou o servidor não é abordado pelo nome do anfitrião.

Neste caso de utilização, não é prático (ou mesmo possível) emitir um certificado para o nome do anfitrião do servidor. Recomendamos que valide o thumbprint do certificado. Tal como uma impressão digital humana, o thumbprint identifica exclusivamente um certificado.

É importante comunicar o thumbprint ao cliente fora de banda. Isto significa que não pode enviá-lo através da mesma ligação de rede que é utilizada para remoting. Em vez disso, pode introduzi-lo manualmente na configuração do cliente ou fazer com que o cliente analise um código QR.

Caso de utilização 2: O servidor pode ser contactado através de um nome de anfitrião estável.

Neste caso de utilização, o servidor tem um nome de anfitrião específico e sabe que este nome não é susceptível de ser alterado. Em seguida, pode utilizar um certificado emitido para o nome do anfitrião do servidor. A confiança será estabelecida com base no nome do anfitrião e na cadeia de fidedignidade do certificado.

Se escolher esta opção, o cliente tem de saber antecipadamente o nome do anfitrião do servidor e o certificado de raiz.

Planear a autenticação cliente a servidor

Os clientes autenticam-se no servidor com um token de forma livre. O que este token deve conter dependerá novamente do seu caso de utilização:

Caso de utilização 1: Só precisa de verificar a identidade da aplicação cliente.

Neste caso de utilização, um segredo partilhado pode ser suficiente. Este segredo deve ser complexo o suficiente para que não possa ser adivinhado.

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

Certifique-se de que este segredo partilhado nunca é comunicado através de canais inseguros. A biblioteca remota garante que o segredo partilhado é sempre enviado encriptado e apenas para elementos fidedignos.

Caso de utilização 2: Também tem de verificar a identidade do utilizador da aplicação cliente.

Um segredo partilhado não será suficiente para cobrir este caso de utilização. Em vez disso, pode utilizar tokens criados por um fornecedor de identidade. Um fluxo de trabalho de autenticação com um fornecedor de identidade teria o seguinte aspeto:

  • O cliente autoriza o fornecedor de identidade e pede um token
  • O fornecedor de identidade gera um token e envia-o para o cliente
  • O cliente envia este token para o servidor através da Comunicação Remota Holográfica
  • O servidor valida o token do cliente relativamente ao fornecedor de identidade

Um exemplo de um fornecedor de identidade é o plataforma de identidades da Microsoft.

Tal como no caso de utilização anterior, certifique-se de que estes tokens não são enviados através de canais inseguros ou expostos de outra forma.

Consulte também