Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Als u geen gebruik hebt van Holographic Remoting, kunt u ons overzicht lezen.
Opmerking
Deze richtlijnen zijn specifiek voor holografische externe communicatie op HoloLens 2- en Windows-pc's met Windows Mixed Reality.
Op deze pagina vindt u een overzicht van netwerkbeveiliging voor Holographic Remoting. U vindt informatie over:
- Beveiliging in de context van Holographic Remoting en waarom u deze mogelijk nodig hebt
- Aanbevolen maatregelen op basis van verschillende use cases
Holographic Remoting-beveiliging
Holographic Remoting wisselt informatie uit via een netwerk. Als er geen beveiligingsmaatregelen zijn genomen, kunnen kwaadwillenden op hetzelfde netwerk de integriteit van de communicatie in gevaar komen of toegang krijgen tot vertrouwelijke informatie.
Voor de voorbeeld-apps en de Holographic Remoting Player in de Windows Store is beveiliging uitgeschakeld. Hierdoor zijn de voorbeelden beter te begrijpen. Het helpt u ook om sneller aan de slag te gaan met ontwikkeling.
Voor veldtesten 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 gebruiksscenario:
- Authenticiteit: zowel de speler als de externe app kan er zeker van zijn dat de andere kant is wie ze beweren te zijn
- Vertrouwelijkheid: geen enkele derde partij kan de informatie lezen die wordt uitgewisseld tussen speler en externe app
- Integriteit: de speler en de externe speler kunnen alle wijzigingen in de communicatie in de overdracht 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.
Opmerking
Vanaf versie 2.4.0 kunnen externe apps met de OpenXR-API worden gemaakt. Hier vindt u een overzicht van het tot stand brengen van een beveiligde verbinding in een OpenXR-omgeving.
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 use-case en de rest van deze sectie gaat over het uitzoeken van de benodigde stappen.
Belangrijk
Dit artikel bevat alleen algemene richtlijnen. 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 zijde die luistert naar binnenkomende verbindingen op een bekend eindpuntadres en de client is degene die verbinding maakt met het eindpunt van de server.
Opmerking
De client- en serverfuncties zijn niet gekoppeld aan het feit of een app fungeert als een speler of als een externe app. 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-clientverificatie 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 punt beëindigd.
Hoe de client het servercertificaat valideert en welke soorten servercertificaten kunnen worden gebruikt, is afhankelijk van uw gebruiksscenario.
Use case 1: De hostnaam van de server is niet opgelost of de server is helemaal niet geadresseerd met de hostnaam.
In dit geval 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 op unieke wijze.
Het is belangrijk om de vingerafdruk out-of-band door te geven aan de client. Dat betekent dat u deze 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.
Use case 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.
Client-naar-serververificatie plannen
Clients worden geverifieerd op de server met behulp van een token in vrije vorm. Wat dit token weer moet bevatten, is afhankelijk van uw use-case:
Use case 1: U hoeft alleen de identiteit van de client-app te verifiëren.
In dit geval 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.
Use case 2: U moet ook de identiteit van de gebruiker van de client-app controleren.
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 het vorige gebruiksvoorbeeld moet u ervoor zorgen dat deze tokens niet worden verzonden via onveilige kanalen of op een andere manier worden weergegeven.