Übersicht über die sichere Verbindung mit Holographic Remoting
Wenn Sie noch keine Erfahrung mit Holographic Remoting haben, sollten Sie unsere Übersicht lesen.
Hinweis
Dieser Leitfaden gilt speziell für Holographic Remoting auf HoloLens 2- und Windows-PCs, auf denen Windows Mixed Reality ausgeführt werden.
Auf dieser Seite erhalten Sie eine Übersicht über die Netzwerksicherheit für Holographic Remoting. Hier finden Sie Informationen zu:
- Sicherheit im Kontext von Holographic Remoting und warum Sie es möglicherweise benötigen
- Empfohlene Maßnahmen basierend auf verschiedenen Anwendungsfällen
Holographic Remoting-Sicherheit
Holographic Remoting tauscht Informationen über ein Netzwerk aus. Wenn keine Sicherheitsmaßnahmen vorhanden sind, können Angreifer im selben Netzwerk die Integrität der Kommunikation gefährden oder auf vertrauliche Informationen zugreifen.
Für die Beispiel-Apps und den Holographic Remoting Player im Windows Store ist die Sicherheit deaktiviert. Dies erleichtert das Verständnis der Beispiele. Es hilft Ihnen auch, schneller mit der Entwicklung zu beginnen.
Für Feldtests oder die Produktion empfehlen wir dringend, die Sicherheit in Ihrer Holographic Remoting-Lösung zu aktivieren.
Die Sicherheit in Holographic Remoting bietet Ihnen bei richtiger Einrichtung für Ihren Anwendungsfall die folgenden Garantien:
- Authentizität: Sowohl der Spieler als auch die Remote-App können sicher sein, dass die andere Seite die ist, die sie zu sein behaupten.
- Vertraulichkeit: Kein Dritter kann die informationen lesen, die zwischen Spieler und Remote-App ausgetauscht werden.
- Integrität: Spieler und Remote können änderungen an ihrer Kommunikation während der Übertragung erkennen.
Wichtig
Um Sicherheitsfeatures verwenden zu können, müssen Sie sowohl einen benutzerdefinierten Player als auch eine benutzerdefinierte Remote-App mithilfe von Windows Mixed Reality- oder OpenXR-APIs implementieren.
Hinweis
Ab Version 2.4.0 können Remote-Apps mit der OpenXR-API erstellt werden. Eine Übersicht zum Herstellen einer sicheren Verbindung in einer OpenXR-Umgebung finden Sie hier.
Planen der Sicherheitsimplementierung
Wenn Sie die Sicherheit in Holographic Remoting aktivieren, aktiviert die Remotingbibliothek automatisch Verschlüsselungs- und Integritätsprüfungen für alle daten, die über das Netzwerk ausgetauscht werden.
Das Sicherstellen einer ordnungsgemäßen Authentifizierung erfordert jedoch zusätzlichen Aufwand. Was genau Sie tun müssen, hängt von Ihrem Anwendungsfall ab, und im rest dieses Abschnitts geht es darum, die erforderlichen Schritte zu ermitteln.
Wichtig
Dieser Artikel kann nur allgemeine Anleitungen enthalten. Wenn Sie sich unsicher fühlen, sollten Sie sich an einen Sicherheitsexperten wenden, der Ihnen spezifische Anleitungen für Ihren Anwendungsfall geben kann.
Zunächst etwas Terminologie: Bei der Beschreibung von Netzwerkverbindungen werden die Begriffe Client und Server verwendet. Der Server ist die Seite, die auf eingehende Verbindungen an einer bekannten Endpunktadresse lauscht, und der Client ist derjenige, der eine Verbindung mit dem Endpunkt des Servers herstellt.
Hinweis
Die Client- und Serverrollen sind nicht daran gebunden, ob eine App als Player oder remote fungiert. Während die Beispiele den Spieler in der Serverrolle enthalten, ist es einfach, die Rollen umzukehren, wenn dies besser zu Ihrem Anwendungsfall passt.
Planen der Server-zu-Client-Authentifizierung
Der Server verwendet digitale Zertifikate, um seine Identität gegenüber dem Client nachzuweisen. Der Client überprüft das Zertifikat des Servers während der Handshakephase der Verbindung. Wenn der Client dem Server nicht vertraut, wird die Verbindung an diesem Punkt beendet.
Wie der Client das Serverzertifikat überprüft und welche Arten von Serverzertifikaten verwendet werden können, hängt von Ihrem Anwendungsfall ab.
Anwendungsfall 1: Der Serverhostname ist nicht festgelegt, oder der Server wird überhaupt nicht mit dem Hostnamen adressiert.
In diesem Anwendungsfall ist es nicht praktikabel (oder sogar möglich), ein Zertifikat für den Hostnamen des Servers ausstellen. Es wird empfohlen, stattdessen den Fingerabdruck des Zertifikats zu überprüfen. Wie bei einem menschlichen Fingerabdruck identifiziert der Fingerabdruck ein Zertifikat eindeutig.
Es ist wichtig, den Fingerabdruck out-of-band an den Client zu kommunizieren. Das bedeutet, dass Sie es nicht über dieselbe Netzwerkverbindung senden können, die für Remoting verwendet wird. Stattdessen können Sie es manuell in die Konfiguration des Clients eingeben oder den Client einen QR-Code scannen lassen.
Anwendungsfall 2: Der Server kann über einen stabilen Hostnamen erreicht werden.
In diesem Anwendungsfall hat der Server einen bestimmten Hostnamen, und Sie wissen, dass sich dieser Name wahrscheinlich nicht ändern wird. Anschließend können Sie ein Zertifikat verwenden, das für den Hostnamen des Servers ausgestellt wurde. Die Vertrauensstellung wird basierend auf dem Hostnamen und der Vertrauenskette des Zertifikats eingerichtet.
Wenn Sie diese Option auswählen, muss der Client den Hostnamen des Servers und das Stammzertifikat im Voraus kennen.
Planen der Client-zu-Server-Authentifizierung
Clients authentifizieren sich beim Server mithilfe eines Freihandtokens. Was dieses Token enthalten soll, hängt wiederum von Ihrem Anwendungsfall ab:
Anwendungsfall 1: Sie müssen nur die Identität der Client-App überprüfen.
In diesem Anwendungsfall kann ein gemeinsam genutztes Geheimnis ausreichend sein. Dieses Geheimnis muss so komplex sein, dass es nicht erraten werden kann.
Ein gutes gemeinsames Geheimnis ist eine zufällige GUID, die manuell in die Konfiguration des Servers und des Clients eingegeben wird. Um eine zu erstellen, können Sie z. B. den New-Guid Befehl in PowerShell verwenden.
Stellen Sie sicher, dass dieses gemeinsame Geheimnis niemals über unsichere Kanäle kommuniziert wird. Die Remotingbibliothek stellt sicher, dass das gemeinsame Geheimnis immer verschlüsselt und nur an vertrauenswürdige Peers gesendet wird.
Anwendungsfall 2: Außerdem müssen Sie die Identität des Benutzers der Client-App überprüfen.
Ein gemeinsam genutztes Geheimnis reicht nicht aus, um diesen Anwendungsfall abzudecken. Stattdessen können Sie Token verwenden, die von einem Identitätsanbieter erstellt wurden. Ein Authentifizierungsworkflow mit einem Identitätsanbieter würde wie folgt aussehen:
- Der Client autorisiert sich beim Identitätsanbieter und fordert ein Token an.
- Der Identitätsanbieter generiert ein Token und sendet es an den Client.
- Der Client sendet dieses Token über Holographic Remoting an den Server.
- Der Server überprüft das Clienttoken gegen den Identitätsanbieter.
Ein Beispiel für einen Identitätsanbieter ist der Microsoft Identity Platform.
Stellen Sie wie im vorherigen Anwendungsfall sicher, dass diese Token nicht über unsichere Kanäle gesendet oder anderweitig verfügbar gemacht werden.