Übersicht über die sichere Verbindung mit Holographic Remoting
Wenn Sie noch nicht mit Holographic Remoting sind, sollten Sie unsere Übersicht lesen.
Hinweis
Diese Anleitung ist spezifisch für holographic Remoting auf HoloLens 2- und Windows-PCs, auf denen Windows Mixed Reality ausgeführt wird.
Auf dieser Seite erhalten Sie einen Überblick ü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 Gegner im selben Netzwerk die Integrität der Kommunikation beeinträchtigen oder auf vertrauliche Informationen zugreifen.
Die Beispiel-Apps und der Holographic Remoting Player im Windows Store verfügen über deaktivierte Sicherheit. Dadurch werden die Beispiele leichter verständlich. Es hilft Ihnen auch, schneller mit der Entwicklung zu beginnen.
Für Feldtests oder Produktionen 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 Player als auch die Remote-App können sicher sein, dass die andere Seite die ist, die sie vorgeben, zu sein.
- Vertraulichkeit: Kein Dritter kann die Informationen lesen, die zwischen Player und Remote-App ausgetauscht werden.
- Integrität: Spieler und Remote können alle Ä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 mit 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.
Für die ordnungsgemäße Authentifizierung ist jedoch zusätzliche Arbeit erforderlich. 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 sind, sollten Sie sich an einen Sicherheitsexperten wenden, der Ihnen spezifische Anleitungen für Ihren Anwendungsfall geben kann.
Zunächst einige Begrifflichkeiten: Beim Beschreiben 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 als Remote fungiert. Während die Beispiele den Player in der Serverrolle enthalten, ist es einfach, die Rollen umzukehren, wenn es 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 Servernamename ist nicht behoben, 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 ein 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 ihn manuell in die Konfiguration des Clients eingeben oder einen QR-Code vom Client überprüfen 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 dieser Name wahrscheinlich nicht geändert 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 Freiformtokens. 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 freigegebenes 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 freigegebene Geheimnis nie über unsichere Kanäle kommuniziert wird. Die Remotingbibliothek stellt sicher, dass das freigegebene 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 freigegebenes 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 für den 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 mit dem Identitätsanbieter.
Ein Beispiel für einen Identitätsanbieter ist die 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.