Holographic Remoting でのセキュリティで保護された接続の概要
Holographic Remoting を初めて使用する場合は、概要を参照してください。
Note
このガイダンスは、Windows Mixed Reality を実行している HoloLens 2 および Windows PC 上の Holographic Remoting のみを対象にしています。
このページでは、Holographic Remoting のネットワーク セキュリティの概要を示します。 以下に関する情報を提供します。
- Holographic Remoting のコンテキストでのセキュリティと、それが必要になる理由
- さまざまなユース ケースに基づく推奨される対策
Holographic Remoting のセキュリティ
Holographic Remoting は、ネットワークを介して情報を交換します。 セキュリティ対策を講じないと、同じネットワーク上の敵対者が通信の整合性を侵害する可能性や、機密情報にアクセスする可能性があります。
サンプル アプリと、Windows ストアの Holographic Remoting プレイヤーは、セキュリティが無効になっています。 これにより、サンプルが理解しやすくなります。 また、開発を迅速に開始するのにも役立ちます。
フィールド テストまたは実稼働の場合は、Holographic Remoting ソリューションでセキュリティを有効にすることを強くお勧めします。
Holographic Remoting のセキュリティを、ユース ケースに合わせて正しく設定すると、以下が保証されます。
- 信頼性: プレーヤーとリモート アプリの両方が、相手が主張している本人であるか確認できます
- 機密性: プレーヤーとリモート アプリの間で交換された情報を第三者が読み取ることはできません
- 整合性: プレーヤーとリモート アプリは、通信への転送時の変更を検出できます
重要
セキュリティ機能を使用するには、Windows Mixed Reality または OpenXR API を使用して、カスタム プレーヤーとカスタム リモート アプリの両方を実装する必要があります。
Note
バージョン 2.4.0 以降、OpenXR API を使用するリモート アプリを作成できます。 OpenXR 環境でセキュリティで保護された接続を確立する方法の概要については、こちらを参照してください。
セキュリティ実装の計画
Holographic Remoting でセキュリティを有効にすると、リモート処理ライブラリで、ネットワークを介して交換されるすべてのデータの暗号化と整合性チェックが自動的に有効になります。
ただし、適切な認証を確実に行うために、追加の作業が必要になります。 厳密に何を行う必要があるかは、ユース ケースによって決まります。このセクションの残りの部分では、必要な手順について説明します。
重要
この記事では、一般的なガイダンスしか提供できません。 不明な点がある場合、ユース ケース固有のガイダンスを提供できるセキュリティの専門家に問い合わせることを検討してください。
最初の用語: ネットワーク接続を表すとき、"クライアント" と "サーバー" という用語が使用されます。 サーバーは既知のエンドポイント アドレスで受信接続をリッスンする側であり、クライアントはサーバーのエンドポイントに接続する側です。
Note
クライアント ロールとサーバー ロールは、アプリがプレーヤーとして機能するか、リモートとして機能するかには関連付けられません。 サンプルにはサーバー ロールのプレーヤーが含まれていますが、ユース ケースに適していれば、ロールを簡単に反転できます。
サーバーからクライアントへの認証の計画
サーバーはデジタル証明書を使用して、その身元をクライアントに証明します。 クライアントは、接続ハンドシェイク フェーズ中にサーバーの証明書を検証します。 クライアントがサーバーを信頼しない場合は、この時点で接続が終了します。
クライアントがサーバー証明書を検証する方法と、使用できるサーバー証明書の種類は、ユース ケースによって異なります。
ユース ケース 1: サーバーのホスト名が解決されない、またはサーバーがホスト名でアドレス指定されていない。
このユース ケースでは、サーバーのホスト名に対して証明書を発行するのは実用的ではありません (または発行すらできません)。 代わりに、証明書のサムプリントを検証することをお勧めします。 人間の指紋と同様に、サムプリントにより証明書が一意に識別されます。
サムプリントはクライアントに帯域外で伝達することが重要です。 つまり、リモート処理に使用されるのと同じネットワーク接続を介して、これを送信することはできません。 代わりに、これをクライアントの構成に手動で入力することや、クライアントで QR コードをスキャンすることができます。
ユース ケース 2: 固有のホスト名を介してサーバーに到達できる。
このユース ケースでは、サーバーが特定のホスト名を持ち、この名前が変更される可能性が低いことが判明しています。 この場合、サーバーのホスト名に対して発行された証明書を使用できます。 信頼は、ホスト名と証明書の信頼チェーンに基づいて確立されます。
このオプションを選択した場合、クライアントはサーバーのホスト名とルート証明書を事前に認識している必要があります。
クライアントからサーバーへの認証の計画
クライアントは、自由形式のトークンを使用してサーバーに対して認証を行います。 このトークンに含める必要がある内容も、ユース ケースによって異なります。
ユース ケース 1: クライアント アプリの身元のみ検証する必要がある。
このユース ケースでは、共有シークレットで十分です。 このシークレットは、非常に複雑で推測できないものである必要があります。
適切な共有シークレットは、サーバーとクライアントの両方の構成で手動で入力されるランダムな GUID です。 これを作成するために、たとえば、PowerShell で New-Guid コマンドを使用できます。
この共有シークレットは、セキュリティで保護されていないチャネルでは送信しないでください。 リモート処理ライブラリを使用すると、共有シークレットは常に暗号化され、信頼されたピアにのみ送信されます。
ユース ケース 2: クライアント アプリのユーザーの身元も検証する必要がある。
共有シークレットでは、このユース ケースには十分に対応できません。 代わりに、ID プロバイダーによって作成されたトークンを使用できます。 ID プロバイダーを使用した認証ワークフローは次のようになります。
- クライアントは ID プロバイダーに対して認証を行い、トークンを要求します
- ID プロバイダーはトークンを生成し、クライアントに送信します
- クライアントは、Holographic Remoting を介してこのトークンをサーバーに送信します
- サーバーは、ID プロバイダーと照合してクライアントのトークンを検証します
ID プロバイダーの例の 1 つは、Microsoft ID プラットフォームです。
前のユース ケースと同様に、これらのトークンは、セキュリティで保護されていないチャネルでは送信しないでください。このようなチャネルで送信すると、トークンが漏洩します。