Přehled zabezpečeného připojení pomocí holografické vzdálené komunikace
Pokud s Holographic Remotingem začínáte, možná si budete chtít přečíst náš přehled.
Poznámka
Tyto pokyny jsou specifické pro holografickou vzdálenou komunikace na HoloLens 2 a počítačích s Windows, na kterých běží Windows Mixed Reality.
Na této stránce najdete přehled zabezpečení sítě pro Holographic Remoting. Najdete zde informace o:
- Zabezpečení v kontextu holografické komunikace a důvod, proč ho možná budete potřebovat
- Doporučená opatření založená na různých případech použití
Zabezpečení holografické vzdálené komunikace
Holographic Remoting vyměňuje informace přes síť. Pokud nejsou zavedena žádná bezpečnostní opatření, nežádoucí osoba ve stejné síti může ohrozit integritu komunikace nebo získat přístup k důvěrným informacím.
Ukázkové aplikace a Holographic Remoting Player ve Windows Storu se dodávají se zakázaným zabezpečením. Díky tomu budou ukázky srozumitelnější. Pomůže vám také rychleji začít s vývojem.
Pro testování v terénu nebo v produkčním prostředí důrazně doporučujeme povolit zabezpečení v řešení Holographic Remoting.
Zabezpečení v Holographic Remoting, pokud je správně nastavené pro váš případ použití, poskytuje následující záruky:
- Pravost: hráč i vzdálená aplikace si mohou být jistí, že druhá strana je tím, za koho se vydávají
- Důvěrnost: Žádná třetí strana nemůže číst informace vyměňované mezi přehrávačem a vzdálenou aplikací.
- Integrita: hráč a vzdálený ovladač můžou detekovat jakékoli změny komunikace během přenosu.
Důležité
Abyste mohli používat funkce zabezpečení, budete muset implementovat vlastní přehrávač i vlastní vzdálenou aplikaci pomocí rozhraní API Windows Mixed Reality nebo OpenXR.
Poznámka
Od verze 2.4.0 je možné vytvářet vzdálené aplikace pomocí rozhraní OpenXR API . Přehled o tom, jak navázat zabezpečené připojení v prostředí OpenXR, najdete tady.
Plánování implementace zabezpečení
Když povolíte zabezpečení v Holographic Remoting, knihovna vzdálené komunikace automaticky povolí šifrování a kontroly integrity pro všechna data vyměněná přes síť.
Zajištění správného ověřování ale vyžaduje trochu práce navíc. Co přesně musíte udělat, závisí na vašem případu použití a zbytek této části se týká zjištění potřebných kroků.
Důležité
Tento článek může poskytnout pouze obecné pokyny. Pokud si nejste jistí, zvažte konzultaci s odborníkem na zabezpečení, který vám může poskytnout pokyny specifické pro váš případ použití.
Nejprve terminologie: Při popisu síťových připojení se použijí termíny klient a server . Server je strana, která naslouchá příchozím připojením na známé adrese koncového bodu, a klient je ten, který se připojuje ke koncovému bodu serveru.
Poznámka
Role klienta a serveru nejsou vázané na to, jestli aplikace funguje jako přehrávač nebo jako vzdálená. I když mají ukázky roli hráče v roli serveru, je snadné vrátit role, pokud lépe odpovídá vašemu případu použití.
Plánování ověřování mezi servery a klienty
Server používá digitální certifikáty k prokázání své identity klientovi. Klient ověří certifikát serveru během fáze metody handshake připojení. Pokud klient nedůvěřuje serveru, připojení se v tomto okamžiku ukončí.
Způsob, jakým klient ověřuje certifikát serveru a jaké druhy certifikátů serveru je možné použít, závisí na vašem případu použití.
Případ použití 1: Název hostitele serveru není opravený nebo server není vůbec adresován názvem hostitele.
V tomto případě použití není praktické (nebo dokonce možné) vydat certifikát pro název hostitele serveru. Doporučujeme místo toho ověřit kryptografický otisk certifikátu. Podobně jako otisk prstu člověka i kryptografický otisk jednoznačně identifikuje certifikát.
Je důležité předat kryptografický otisk klientovi mimo pásmo. To znamená, že ho nemůžete odeslat přes stejné síťové připojení, které se používá pro vzdálené komunikace. Místo toho byste ho mohli ručně zadat do konfigurace klienta nebo nechat klienta naskenovat kód QR.
Případ použití 2: Server je dostupný přes stabilní název hostitele.
V tomto případě má server konkrétní název hostitele a víte, že se tento název pravděpodobně nezmění. Pak můžete použít certifikát vystavený pro název hostitele serveru. Vztah důvěryhodnosti se vytvoří na základě názvu hostitele a řetězu důvěryhodnosti certifikátu.
Pokud zvolíte tuto možnost, klient musí předem znát název hostitele serveru a kořenový certifikát.
Plánování ověřování klient-server
Klienti se na serveru ověřují pomocí tokenu volného tvaru. Co by měl tento token obsahovat, bude opět záviset na vašem případu použití:
Případ použití 1: Stačí jenom ověřit identitu klientské aplikace.
V tomto případě může stačit sdílený tajný klíč. Tento tajný kód musí být dostatečně složitý, aby ho nebylo možné uhodnout.
Dobrý sdílený tajný klíč je náhodný identifikátor GUID, který se ručně zadá v konfiguraci serveru i klienta. K jeho vytvoření můžete použít například příkaz v PowerShellu New-Guid .
Ujistěte se, že se tento sdílený tajný klíč nikdy nesděluje přes nezabezpečené kanály. Knihovna vzdálené komunikace zajišťuje, aby se sdílený tajný klíč vždy odesílal zašifrovaný a pouze důvěryhodným partnerským partnerům.
Případ použití 2: Musíte také ověřit identitu uživatele klientské aplikace.
Sdílený tajný klíč nebude stačit k pokrytí tohoto případu použití. Místo toho můžete použít tokeny vytvořené zprostředkovatelem identity. Pracovní postup ověřování pomocí zprostředkovatele identity by vypadal takto:
- Klient se autorizuje vůči zprostředkovateli identity a požádá o token.
- Zprostředkovatel identity vygeneruje token a odešle ho klientovi.
- Klient odešle tento token na server prostřednictvím holografické vzdálené komunikace.
- Server ověří token klienta vůči zprostředkovateli identity.
Jedním z příkladů zprostředkovatele identity je Microsoft identity platform.
Stejně jako v předchozím případě použití se ujistěte, že se tyto tokeny neodesílají prostřednictvím nezabezpečených kanálů nebo nejsou jinak vystavené.