Översikt över säker anslutning med holografisk fjärrkommunikation
Om du inte har använt Holographic Remoting tidigare kanske du vill läsa vår översikt.
Anteckning
Den här vägledningen är specifik för Holographic Remoting på HoloLens 2- och Windows-datorer som kör Windows Mixed Reality.
På den här sidan får du en översikt över nätverkssäkerhet för Holographic Remoting. Du hittar information om:
- Säkerhet i samband med Holographic Remoting och varför du kan behöva det
- Rekommenderade åtgärder baserat på olika användningsfall
Säkerhet för holografisk fjärrkommunikation
Holographic Remoting utbyter information över ett nätverk. Om det inte finns några säkerhetsåtgärder kan angripare i samma nätverk äventyra kommunikationens integritet eller komma åt konfidentiell information.
Exempelapparna och Holographic Remoting Player i Windows Store har inaktiverad säkerhet. På så sätt blir exemplen lättare att förstå. Det hjälper dig också att komma igång snabbare med utveckling.
För fälttestning eller produktion rekommenderar vi starkt att du aktiverar säkerhet i din Holographic Remoting-lösning.
Säkerhet i Holographic Remoting ger dig följande garantier när det är korrekt konfigurerat för ditt användningsfall:
- Äkthet: både spelare och fjärrapp kan vara säkra på att den andra sidan är den de påstår sig vara
- Konfidentialitet: ingen tredje part kan läsa informationen som utbyts mellan spelare och fjärrapp
- Integritet: Spelare och fjärranslutna kan identifiera ändringar i kommunikationen under överföring
Viktigt
För att kunna använda säkerhetsfunktioner måste du implementera både en anpassad spelare och en anpassad fjärrapp med antingen Windows Mixed Reality- eller OpenXR-API:er.
Anteckning
Från och med version 2.4.0 kan fjärrappar som använder OpenXR-API :et skapas. En översikt över hur du upprättar en säker anslutning i en OpenXR-miljö finns här.
Planera säkerhetsimplementeringen
När du aktiverar säkerhet i Holographic Remoting aktiverar fjärrkommunikationsbiblioteket automatiskt krypterings- och integritetskontroller för alla data som utbyts över nätverket.
För att säkerställa korrekt autentisering krävs dock lite extra arbete. Exakt vad du behöver göra beror på ditt användningsfall, och resten av det här avsnittet handlar om att ta reda på de nödvändiga stegen.
Viktigt
Den här artikeln kan bara ge allmän vägledning. Om du känner dig osäker kan du kontakta en säkerhetsexpert som kan ge dig vägledning som är specifik för ditt användningsfall.
Först en del terminologi: när du beskriver nätverksanslutningar används termerna klient och server . Servern är den sida som lyssnar efter inkommande anslutningar på en känd slutpunktsadress och klienten är den som ansluter till serverns slutpunkt.
Anteckning
Klient- och serverrollerna är inte knutna till om en app fungerar som en spelare eller som en fjärranslutning. Även om exemplen har spelaren i serverrollen är det enkelt att ändra rollerna om det passar ditt användningsfall bättre.
Planera server-till-klient-autentiseringen
Servern använder digitala certifikat för att bevisa sin identitet för klienten. Klienten validerar serverns certifikat under anslutningshandskakningsfasen. Om klienten inte litar på servern avslutas anslutningen nu.
Hur klienten validerar servercertifikatet och vilka typer av servercertifikat som kan användas beror på ditt användningsfall.
Användningsfall 1: Serverns värdnamn har inte åtgärdats eller så hanteras inte servern av värdnamnet alls.
I det här användningsfallet är det inte praktiskt (eller ens möjligt) att utfärda ett certifikat för serverns värdnamn. Vi rekommenderar att du validerar certifikatets tumavtryck i stället. Precis som med ett mänskligt fingeravtryck identifierar tumavtrycket ett certifikat unikt.
Det är viktigt att kommunicera tumavtrycket till klienten out-of-band. Det innebär att du inte kan skicka den över samma nätverksanslutning som används för fjärrkommunikation. I stället kan du ange den manuellt i klientens konfiguration eller låta klienten skanna en QR-kod.
Användningsfall 2: Servern kan nås via ett stabilt värdnamn.
I det här användningsfallet har servern ett specifikt värdnamn och du vet att det här namnet troligen inte kommer att ändras. Du kan sedan använda ett certifikat som utfärdats till serverns värdnamn. Förtroende upprättas baserat på värdnamnet och certifikatets förtroendekedja.
Om du väljer det här alternativet måste klienten känna till serverns värdnamn och rotcertifikatet i förväg.
Planera klient-till-server-autentiseringen
Klienter autentiserar mot servern med hjälp av en token med fritt formulär. Vad denna token ska innehålla beror på ditt användningsfall:
Användningsfall 1: Du behöver bara verifiera klientappens identitet.
I det här användningsfallet kan en delad hemlighet vara tillräcklig. Den här hemligheten måste vara så komplex att den inte kan gissas.
En bra delad hemlighet är ett slumpmässigt GUID som anges manuellt i både serverns och klientens konfiguration. Om du vill skapa en kan du till exempel använda New-Guid kommandot i PowerShell.
Kontrollera att den delade hemligheten aldrig kommuniceras över osäkra kanaler. Fjärrkommunikationsbiblioteket säkerställer att den delade hemligheten alltid skickas krypterad och endast till betrodda peer-datorer.
Användningsfall 2: Du måste också verifiera identiteten för klientappens användare.
En delad hemlighet räcker inte för att täcka det här användningsfallet. I stället kan du använda token som skapats av en identitetsprovider. Ett autentiseringsarbetsflöde som använder en identitetsprovider skulle se ut så här:
- Klienten auktoriserar mot identitetsprovidern och begär en token
- Identitetsprovidern genererar en token och skickar den till klienten
- Klienten skickar denna token till servern via Holographic Remoting
- Servern validerar klientens token mot identitetsprovidern
Ett exempel på en identitetsprovider är Microsofts identitetsplattform.
Precis som i föregående användningsfall kontrollerar du att dessa token inte skickas via osäkra kanaler eller exponeras på annat sätt.