Panoramica della connessione sicura con Holographic Remoting

Se non si ha una nuova versione di Holographic Remoting, è possibile leggere la panoramica.

Nota

Queste linee guida sono specifiche di Holographic Remoting HoloLens 2 e Windows PC che eseguono Windows Mixed Reality.

Questa pagina offre una panoramica della sicurezza di rete per Holographic Remoting. Sono disponibili informazioni su:

  • Sicurezza nel contesto di Holographic Remoting e perché potrebbe essere necessaria
  • Misure consigliate in base a casi d'uso diversi

Sicurezza della comunicazione remota olografica

Holographic Remoting scambia informazioni su una rete. Se non sono presenti misure di sicurezza, gli avversari nella stessa rete possono compromettere l'integrità della comunicazione o accedere a informazioni riservate.

Le app di esempio e Holographic Remoting Player in Windows Store sono con sicurezza disabilitata. In questo modo, gli esempi sono più facili da comprendere. Consente anche di iniziare più rapidamente a usare lo sviluppo.

Per il test sul campo o la produzione, è consigliabile abilitare la sicurezza nella soluzione Holographic Remoting.

La sicurezza in Holographic Remoting, se configurata correttamente per il caso d'uso, offre le garanzie seguenti:

  • Autenticità: sia il lettore che l'app remota possono essere certi che l'altro lato sia l'utente che dichiara di essere
  • Riservatezza: nessuna terza parte può leggere le informazioni scambiate tra il lettore e l'app remota
  • Integrità: il lettore e il remoto possono rilevare eventuali modifiche in transito alla comunicazione

Importante

Per poter usare le funzionalità di sicurezza, è necessario implementare sia un lettore personalizzato che un'app remota personalizzata usando le API Windows Mixed Realityo OpenXR.

Nota

A partire dalla versione 2.4.0 è possibile creare app remote usando l'API OpenXR . Una panoramica su come stabilire una connessione sicura in un ambiente OpenXR è disponibile qui.

Pianificazione dell'implementazione della sicurezza

Quando si abilita la sicurezza in Holographic Remoting, la libreria remota abiliterà automaticamente i controlli di crittografia e integrità per tutti i dati s scambiati in rete.

Per garantire un'autenticazione appropriata, tuttavia, è necessario eseguire alcune operazioni aggiuntive. Le operazioni da eseguire dipendono dal caso d'uso e il resto di questa sezione riguarda la procedura necessaria.

Importante

Questo articolo può fornire solo indicazioni generali. In caso di dubbi, è consigliabile consultare un esperto di sicurezza in grado di fornire indicazioni specifiche per il caso d'uso.

Prima di tutto, quando si descrivono le connessioni di rete, verranno usati i termini client e server . Il server è il lato in ascolto delle connessioni in ingresso su un indirizzo endpoint noto e il client è quello che si connette all'endpoint del server.

Nota

I ruoli client e server non sono legati a se un'app funge da lettore o da remoto. Anche se gli esempi hanno il ruolo del server, è facile invertire i ruoli se si adatta meglio al caso d'uso.

Pianificazione dell'autenticazione da server a client

Il server usa i certificati digitali per dimostrare la propria identità al client. Il client convalida il certificato del server durante la fase di handshake della connessione. Se il client non considera attendibile il server, terminerà la connessione a questo punto.

Il modo in cui il client convalida il certificato server e quali tipi di certificati server possono essere usati dipende dal caso d'uso.

Caso d'uso 1: Il nome host del server non è fisso o il server non è affatto indirizzato in base al nome host.

In questo caso d'uso, non è pratico (o nemmeno possibile) rilasciare un certificato per il nome host del server. È consigliabile convalidare invece l'identificazione personale del certificato. Come un'impronta digitale umana, l'identificazione personale identifica in modo univoco un certificato.

È importante comunicare l'identificazione personale al client fuori banda. Ciò significa che non è possibile inviarlo tramite la stessa connessione di rete usata per la comunicazione remota. È invece possibile immetterlo manualmente nella configurazione del client o fare in modo che eseere il client a eseguire l'analisi di un codice a qr.

Caso d'uso 2: Il server può essere raggiunto tramite un nome host stabile.

In questo caso d'uso, il server ha un nome host specifico e si sa che non è probabile che questo nome cambi. È quindi possibile usare un certificato rilasciato al nome host del server. L'attendibilità verrà stabilita in base al nome host e alla catena di attendibilità del certificato.

Se si sceglie questa opzione, il client deve conoscere in anticipo il nome host del server e il certificato radice.

Pianificazione dell'autenticazione da client a server

I client eseguono l'autenticazione nel server usando un token in formato libero. Ciò che questo token deve contenere dipenderà di nuovo dal caso d'uso:

Caso d'uso 1: È necessario solo verificare l'identità dell'app client.

In questo caso d'uso, un segreto condiviso può essere sufficiente. Questo segreto deve essere sufficientemente complesso da non poterlo indovinare.

Un segreto condiviso valido è un GUID casuale, che viene immesso manualmente nella configurazione del server e del client. Per crearne uno è possibile, ad esempio, usare il New-Guid comando in PowerShell.

Assicurarsi che questo segreto condiviso non sia mai comunicato tramite canali non sicuri. La libreria remota garantisce che il segreto condiviso sia sempre inviato crittografato e solo a peer attendibili.

Caso d'uso 2: È anche necessario verificare l'identità dell'utente dell'app client.

Un segreto condiviso non sarà sufficiente per coprire questo caso d'uso. È invece possibile usare i token creati da un provider di identità. Un flusso di lavoro di autenticazione che usa un provider di identità sarà simile al seguente:

  • Il client autorizza il provider di identità e richiede un token
  • Il provider di identità genera un token e lo invia al client
  • Il client invia questo token al server tramite Holographic Remoting
  • Il server convalida il token del client rispetto al provider di identità

Un esempio di provider di identità è il Microsoft Identity Platform.

Come nel caso d'uso precedente, assicurarsi che questi token non siano inviati tramite canali non sicuri o esposti in altro modo.

Vedere anche