Secure Connection with Holographic Remoting Overview

Wenn Sie noch nicht mit Holographic Remoting sind, können 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 wird.

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 gründe für deren Notwendigkeit
  • 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 Dies die Integrität der Kommunikation beeinträchtigen oder auf vertrauliche Informationen zugreifen.

Die Beispiel-Apps und der Holographic Remoting Player im Windows Store mit deaktivierter Sicherheit. Dies erleichtert das Verständnis der Beispiele. Außerdem können Sie schneller mit der Entwicklung beginnen.

Für Feldtests oder Die Produktion wird dringend empfohlen, die Sicherheit in Ihrer Holographic Remoting-Lösung zu aktivieren.

Die Sicherheit in Holographic Remoting bietet Ihnen bei ordnungsgemäßer Einrichtung für Ihren Anwendungsfall die folgenden Garantien:

  • Authentizität: Sowohl die Player- als auch die Remote-App können sicher sein, dass die andere Seite die ist, die sie als
  • Vertraulichkeit: Keine Drittanbieter können die Informationen lesen, die zwischen Player und Remote-App ausgetauscht werden.
  • Integrität: Player und Remote können während der Übertragung Änderungen an der Kommunikation 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 mithilfe der OpenXR-API erstellt werden. Eine Übersicht über das 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.

Die Sicherstellung einer ordnungsgemäßen Authentifizierung erfordert jedoch zusätzlichen Aufwand. Was Genau Sie tun müssen, hängt von Ihrem Anwendungsfall ab, und im restlichen Teil dieses Abschnitts geht es darum, die erforderlichen Schritte zu finden.

Wichtig

Dieser Artikel kann nur allgemeine Anleitungen enthalten. Wenn Sie unsicher sind, ziehen Sie in Betracht, einen Sicherheitsexperten zu konsultieren, der Ihnen spezifische Anleitungen für Ihren Anwendungsfall geben kann.

Zunächst einige 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 der Client, 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 Player in der Serverrolle haben, ist es einfach, die Rollen umzukehren, wenn sie besser zu Ihrem Anwendungsfall passen.

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 Serverzertifikat während der Verbindungshandshakephase. Wenn der Client dem Server nicht vertraut, wird die Verbindung zu diesem Zeitpunkt 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 anhand des Hostnamens adressiert.

In diesem Anwendungsfall ist es nicht praktikabel (oder sogar möglich), ein Zertifikat für den Hostnamen des Servers auszustellen. Es wird empfohlen, stattdessen den Fingerabdruck des Zertifikats zu überprüfen. Wie ein menschlicher Fingerabdruck identifiziert der Fingerabdruck ein Zertifikat eindeutig.

Es ist wichtig, den Fingerabdruck out-of-band an den Client zu übermitteln. Das bedeutet, dass Sie sie nicht über dieselbe Netzwerkverbindung senden können, die für Remoting verwendet wird. Stattdessen können Sie ihn manuell in die Clientkonfiguration eingeben oder den 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 mithilfe eines Freiformtokens beim Server. Was dieses Token enthalten sollte, hängt wieder von Ihrem Anwendungsfall ab:

Anwendungsfall 1: Sie müssen nur die Identität der Client-App überprüfen.

In diesem Anwendungsfall kann ein gemeinsames Geheimnis ausreichen. Dieses Geheimnis muss so komplex sein, dass es nicht erraten werden kann.

Ein gutes gemeinsames Geheimnis ist eine zufällige GUID, die sowohl in der Konfiguration des Servers als auch des Clients manuell eingegeben wird. Sie können z. B. den New-Guid Befehl in PowerShell verwenden, um einen zu erstellen.

Stellen Sie sicher, dass dieses gemeinsame Geheimnis nie ü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: Sie müssen auch die Identität des Benutzers der Client-App überprüfen.

Ein gemeinsames 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 anhand des Identitätsanbieters.

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.

Weitere Informationen