Panoramica della connessione sicura con Holographic Remoting
Se non si ha familiarità con Holographic Remoting, è possibile leggere la panoramica.
Nota
Queste indicazioni sono specifiche per Holographic Remoting su HoloLens 2 e PC Windows 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 di Holographic Remoting
Holographic Remoting scambia informazioni su una rete. Se non sono state applicate misure di sicurezza, gli antagonisti nella stessa rete possono compromettere l'integrità della comunicazione o accedere alle informazioni riservate.
Le app di esempio e Holographic Remoting Player in Windows Store sono dotate di sicurezza disabilitata. In questo modo gli esempi sono più facili da comprendere. Consente anche di iniziare più rapidamente con lo sviluppo.
Per i 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 giocatore che l'app remota possono essere sicuri che l'altro lato sia chi dichiara di essere
- Riservatezza: nessuna terza parte può leggere le informazioni scambiate tra il lettore e l'app remota
- Integrità: il lettore e il telecomando 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 api Windows Mixed Reality o 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 scambiati in rete.
Per garantire l'autenticazione corretta è tuttavia necessario eseguire alcune operazioni aggiuntive. Ciò che è necessario fare dipende dal caso d'uso e la parte restante di questa sezione riguarda la definizione dei passaggi necessari.
Importante
Questo articolo può fornire solo indicazioni generali. In caso di dubbi, è consigliabile consultare un esperto di sicurezza che possa fornire indicazioni specifiche per il caso d'uso.
Prima di tutto una terminologia: quando si descrivono le connessioni di rete, verranno usati i termini client e server . Il server è il lato in ascolto delle connessioni in ingresso in un indirizzo endpoint noto e il client è quello che si connette all'endpoint del server.
Nota
I ruoli client e server non sono legati al fatto che un'app agisca come lettore o come remoto. Anche se gli esempi hanno il giocatore nel ruolo del server, è facile invertire i ruoli se meglio si adatta al caso d'uso.
Pianificazione dell'autenticazione da server a client
Il server usa 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, la connessione verrà terminata a questo punto.
Il modo in cui il client convalida il certificato del 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 è corretto o il server non è affatto indirizzato dal nome host.
In questo caso d'uso, non è pratico (o anche 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 per fare in modo che il client analizzi un codice a matrice.
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 questo nome non è probabile che venga modificato. È quindi possibile usare un certificato emesso per il 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 sul server usando un token in formato libero. Il token che deve contenere di nuovo dipenderà dal caso d'uso:
Caso d'uso 1: È sufficiente verificare l'identità dell'app client.
In questo caso d'uso, un segreto condiviso può essere sufficiente. Questo segreto deve essere abbastanza 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, ad esempio, usare il New-Guid comando in PowerShell.
Assicurarsi che questo segreto condiviso non venga mai comunicato tramite canali non sicuri. La libreria remota garantisce che il segreto condiviso venga sempre inviato crittografato e solo ai 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 vengano inviati tramite canali non sicuri o altrimenti esposti.