Overzicht van beveiligde verbinding met holographic remoting
Als u geen gebruik hebt van Holographic Remoting, kunt u ons overzicht lezen.
Notitie
Deze richtlijnen zijn specifiek voor externe communicatie van Holographic op HoloLens 2- en Windows-pc's met Windows Mixed Reality.
Deze pagina geeft u een overzicht van netwerkbeveiliging voor externe communicatie van Holographic. Hier vindt u informatie over:
- Beveiliging in de context van Holographic Remoting en waarom u deze mogelijk nodig hebt
- Aanbevolen metingen op basis van verschillende use cases
Holographic Remoting-beveiliging
Holographic Remoting wisselt informatie uit via een netwerk. Als er geen beveiligingsmaatregelen zijn, kunnen kwaadwillende personen op hetzelfde netwerk de integriteit van de communicatie in gevaar komen of toegang krijgen tot vertrouwelijke informatie.
De voorbeeld-apps en de Holographic Remoting Player in de Windows Store worden geleverd met uitgeschakelde beveiliging. Hierdoor zijn de voorbeelden gemakkelijker te begrijpen. Het helpt u ook om sneller aan de slag te gaan met ontwikkelen.
Voor veldtests of productie raden we u ten zeerste aan om beveiliging in te schakelen in uw Holographic Remoting-oplossing.
Beveiliging in Holographic Remoting biedt u de volgende garanties wanneer deze correct is ingesteld voor uw use-case:
- Authenticiteit: zowel de speler als de externe app kunnen er zeker van zijn dat de andere kant is wie ze beweren te zijn
- Vertrouwelijkheid: geen enkele derde partij kan de informatie lezen die is uitgewisseld tussen speler en externe app
- Integriteit: speler en externe speler kunnen eventuele wijzigingen in hun communicatie in transit detecteren
Belangrijk
Als u beveiligingsfuncties wilt gebruiken, moet u zowel een aangepaste speler als een aangepaste externe app implementeren met behulp van Windows Mixed Reality- of OpenXR-API's.
Notitie
Vanaf versie 2.4.0 kunnen externe apps met de OpenXR-API worden gemaakt. Een overzicht van het tot stand brengen van een beveiligde verbinding in een OpenXR-omgeving vindt u hier.
De beveiligings-implementatie plannen
Wanneer u beveiliging inschakelt in Holographic Remoting, schakelt de externe bibliotheek automatisch versleuteling en integriteitscontroles in voor alle gegevens die via het netwerk worden uitgewisseld.
Het garanderen van de juiste verificatie vereist echter wat extra werk. Wat u precies moet doen, is afhankelijk van uw gebruiksscenario en de rest van deze sectie gaat over het uitzoeken van de benodigde stappen.
Belangrijk
Dit artikel kan alleen algemene richtlijnen bieden. Als u twijfelt, kunt u overwegen een beveiligingsexpert te raadplegen die u richtlijnen kan geven die specifiek zijn voor uw gebruiksscenario.
Eerst wat terminologie: bij het beschrijven van netwerkverbindingen worden de termen client en server gebruikt. De server is de kant die luistert naar binnenkomende verbindingen op een bekend eindpuntadres en de client is degene die verbinding maakt met het eindpunt van de server.
Notitie
De client- en serverfuncties zijn niet gekoppeld aan het feit of een app fungeert als speler of als een externe. Hoewel de voorbeelden de speler in de serverrol hebben, is het eenvoudig om de rollen om te keren als deze beter past bij uw gebruiksscenario.
De server-naar-client-verificatie plannen
De server gebruikt digitale certificaten om de identiteit aan de client te bewijzen. De client valideert het certificaat van de server tijdens de handshakefase van de verbinding. Als de client de server niet vertrouwt, wordt de verbinding op dit moment beëindigd.
Hoe de client het servercertificaat valideert en welke soorten servercertificaten kunnen worden gebruikt, is afhankelijk van uw gebruiksscenario.
Gebruiksvoorbeeld 1: De hostnaam van de server is niet opgelost of de server wordt helemaal niet geadresseerd door de hostnaam.
In dit gebruiksvoorbeeld is het niet praktisch (of zelfs mogelijk) om een certificaat uit te geven voor de hostnaam van de server. We raden u aan in plaats daarvan de vingerafdruk van het certificaat te valideren. Net als een menselijke vingerafdruk identificeert de vingerafdruk een certificaat.
Het is belangrijk om de vingerafdruk out-of-band door te geven aan de client. Dit betekent dat u het niet kunt verzenden via dezelfde netwerkverbinding die wordt gebruikt voor externe communicatie. In plaats daarvan kunt u deze handmatig invoeren in de configuratie van de client of de client een QR-code laten scannen.
Gebruiksvoorbeeld 2: De server kan worden bereikt via een stabiele hostnaam.
In dit geval heeft de server een specifieke hostnaam en u weet dat deze naam waarschijnlijk niet zal veranderen. U kunt vervolgens een certificaat gebruiken dat is uitgegeven aan de hostnaam van de server. Vertrouwen wordt tot stand gebracht op basis van de hostnaam en de vertrouwensketen van het certificaat.
Als u deze optie kiest, moet de client de hostnaam van de server en het basiscertificaat van tevoren weten.
De client-naar-server-verificatie plannen
Clients verifiëren bij de server met behulp van een token in vrije vorm. Wat dit token moet bevatten, is weer afhankelijk van uw gebruiksscenario:
Gebruiksvoorbeeld 1: U hoeft alleen de identiteit van de client-app te verifiëren.
In dit gebruiksvoorbeeld kan een gedeeld geheim voldoende zijn. Dit geheim moet zo complex zijn dat het niet kan worden geraden.
Een goed gedeeld geheim is een willekeurige GUID, die handmatig wordt ingevoerd in zowel de configuratie van de server als de client. Als u er een wilt maken, kunt u bijvoorbeeld de New-Guid opdracht in PowerShell gebruiken.
Zorg ervoor dat dit gedeelde geheim nooit wordt gecommuniceerd via onveilige kanalen. De externe bibliotheek zorgt ervoor dat het gedeelde geheim altijd versleuteld wordt verzonden en alleen naar vertrouwde peers.
Gebruiksvoorbeeld 2: U moet ook de identiteit van de gebruiker van de client-app verifiëren.
Een gedeeld geheim is niet voldoende om deze use case te dekken. In plaats daarvan kunt u tokens gebruiken die zijn gemaakt door een id-provider. Een verificatiewerkstroom met behulp van een id-provider ziet er als volgt uit:
- De client autoriseert op basis van de id-provider en vraagt een token aan
- De id-provider genereert een token en verzendt dit naar de client
- De client verzendt dit token naar de server via Holographic Remoting
- De server valideert het token van de client op basis van de id-provider
Een voorbeeld van een id-provider is de Microsoft identity platform.
Net als in de vorige use-case moet u ervoor zorgen dat deze tokens niet worden verzonden via onveilige kanalen of op een andere manier worden weergegeven.