홀로그램 원격을 사용하여 보안 연결 개요

Holographic Remoting을 접하는 경우 개요를 읽을 수 있습니다.

참고

이 지침은 Windows Mixed Reality 실행 중인 HoloLens 2 및 Windows PC의 홀로그램 원격에만 적용됩니다.

이 페이지에서는 홀로그램 원격에 대한 네트워크 보안에 대한 개요를 제공합니다. 다음에 대한 정보를 찾을 수 있습니다.

  • 홀로그램 원격의 컨텍스트 및 필요한 이유의 보안
  • 다양한 사용 사례에 따라 권장되는 측정값

홀로그램 원격 보안

홀로그램 원격은 네트워크를 통해 정보를 교환합니다. 보안 조치가 없으면 동일한 네트워크의 악의적 사용자가 통신의 무결성을 손상하거나 기밀 정보에 액세스할 수 있습니다.

샘플 앱과 Windows 스토어의 홀로그램 원격 플레이어에는 보안이 비활성화되어 있습니다. 이렇게 하면 샘플을 더 쉽게 이해할 수 있습니다. 또한 개발을 더 빠르게 시작하는 데 도움이 됩니다.

현장 테스트 또는 프로덕션의 경우 Holographic Remoting 솔루션에서 보안을 사용하도록 설정하는 것이 좋습니다.

Holographic Remoting의 보안은 사용 사례에 맞게 올바르게 설정된 경우 다음과 같은 보장을 제공합니다.

  • 신뢰성: 플레이어와 원격 앱 모두 상대방이 누구라고 주장하는지 확신할 수 있습니다.
  • 기밀성: 제3자도 플레이어와 원격 앱 간에 교환된 정보를 읽을 수 없습니다.
  • 무결성: 플레이어 및 원격은 전송 중 통신 변경 내용을 감지할 수 있습니다.

중요

보안 기능을 사용하려면 Windows Mixed Reality 또는 OpenXR API를 사용하여 사용자 지정 플레이어와 사용자 지정 원격 앱을 모두 구현해야 합니다.

참고

버전 2.4.0 부터 OpenXR API 를 사용하는 원격 앱을 만들 수 있습니다. OpenXR 환경에서 보안 연결을 설정하는 방법에 대한 개요는 여기에서 찾을 수 있습니다.

보안 구현 계획

Holographic Remoting에서 보안을 사용하도록 설정하면 원격 라이브러리는 네트워크를 통해 교환되는 모든 데이터에 대한 암호화 및 무결성 검사를 자동으로 사용하도록 설정합니다.

적절한 인증을 보장하려면 몇 가지 추가 작업이 필요합니다. 정확히 수행해야 하는 작업은 사용 사례에 따라 달라지고, 이 섹션의 나머지 부분은 필요한 단계를 파악하는 것입니다.

중요

이 문서에서는 일반적인 지침만 제공할 수 있습니다. 확실하지 않은 경우 사용 사례와 관련된 지침을 제공할 수 있는 보안 전문가에게 문의하는 것이 좋습니다.

먼저 몇 가지 용어: 네트워크 연결을 설명할 때 클라이언트서버 라는 용어가 사용됩니다. 서버는 알려진 엔드포인트 주소에서 들어오는 연결을 수신 대기하는 쪽이며 클라이언트는 서버의 엔드포인트에 연결하는 쪽입니다.

참고

클라이언트 및 서버 역할은 앱이 플레이어 역할을 하는지 아니면 원격 역할을 하는지와 관련이 없습니다. 샘플에는 서버 역할의 플레이어가 있지만 사용 사례에 더 잘 맞으면 역할을 쉽게 되돌릴 수 있습니다.

서버-클라이언트 인증 계획

서버는 디지털 인증서를 사용하여 클라이언트에 대한 ID를 증명합니다. 클라이언트는 연결 핸드셰이크 단계에서 서버 인증서의 유효성을 검사합니다. 클라이언트가 서버를 신뢰하지 않으면 이 시점에서 연결이 종료됩니다.

클라이언트가 서버 인증서의 유효성을 검사하는 방법과 사용할 수 있는 서버 인증서의 종류는 사용 사례에 따라 달라집니다.

사용 사례 1: 서버 호스트 이름이 고정되지 않았거나 서버가 호스트 이름으로 전혀 주소가 지정되지 않습니다.

이 사용 사례에서는 서버의 호스트 이름에 대한 인증서를 발급하는 것이 실용적이지 않습니다(또는 가능). 대신 인증서의 지문의 유효성을 검사하는 것이 좋습니다. 사람의 지문과 마찬가지로 지문은 인증서를 고유하게 식별합니다.

지문을 대역 외 클라이언트에 전달하는 것이 중요합니다. 즉, 원격에 사용되는 동일한 네트워크 연결을 통해 보낼 수 없습니다. 대신 클라이언트의 구성에 수동으로 입력하거나 클라이언트가 QR 코드를 검사하도록 할 수 있습니다.

사용 사례 2: 안정적인 호스트 이름을 통해 서버에 연결할 수 있습니다.

이 사용 사례에서 서버에는 특정 호스트 이름이 있으며 이 이름은 변경되지 않을 수 있습니다. 그런 다음 서버의 호스트 이름에 발급된 인증서를 사용할 수 있습니다. 트러스트는 호스트 이름 및 인증서의 신뢰 체인에 따라 설정됩니다.

이 옵션을 선택하는 경우 클라이언트는 서버의 호스트 이름 및 루트 인증서를 미리 알고 있어야 합니다.

클라이언트-서버 인증 계획

클라이언트는 자유 형식 토큰을 사용하여 서버에 대해 인증합니다. 이 토큰에 포함해야 하는 항목은 사용 사례에 따라 다시 달라집니다.

사용 사례 1: 클라이언트 앱의 ID만 확인하면 됩니다.

이 사용 사례에서는 공유 암호로 충분할 수 있습니다. 이 비밀은 추측할 수 없을 정도로 복잡해야 합니다.

좋은 공유 비밀은 서버와 클라이언트의 구성 모두에 수동으로 입력되는 임의 GUID입니다. 예를 들어 만들려면 PowerShell에서 New-Guid 명령을 사용합니다.

이 공유 비밀이 안전하지 않은 채널을 통해 전달되지 않는지 확인합니다. 원격 라이브러리는 공유 비밀이 항상 암호화되고 신뢰할 수 있는 피어에만 전송되도록 합니다.

사용 사례 2: 클라이언트 앱 사용자의 ID도 확인해야 합니다.

공유 비밀만으로는 이 사용 사례를 처리할 수 없습니다. 대신 ID 공급자가 만든 토큰을 사용할 수 있습니다. ID 공급자를 사용하는 인증 워크플로는 다음과 같습니다.

  • 클라이언트는 ID 공급자에 대해 권한을 부여하고 토큰을 요청합니다.
  • ID 공급자가 토큰을 생성하여 클라이언트에 보냅니다.
  • 클라이언트는 Holographic Remoting을 통해 서버에 이 토큰을 보냅니다.
  • 서버는 ID 공급자에 대해 클라이언트의 토큰의 유효성을 검사합니다.

ID 공급자의 한 가지 예는 Microsoft ID 플랫폼.

이전 사용 사례와 마찬가지로 이러한 토큰이 안전하지 않은 채널을 통해 전송되거나 노출되지 않는지 확인합니다.

참고 항목