Holographic Remoting을 사용하여 보안 연결 개요
Holographic Remoting을 사용하는 경우 개요를 읽을 수 있습니다.
참고
이 지침은 Windows Mixed Reality 실행하는 HoloLens 2 및 Windows PC에서 홀로그램 원격에만 적용됩니다.
이 페이지에서는 홀로그램 원격에 대한 네트워크 보안에 대한 개요를 제공합니다. 다음에 대한 정보를 찾을 수 있습니다.
- 홀로그램 원격의 컨텍스트 및 필요한 이유의 보안
- 다양한 사용 사례에 따라 권장되는 측정값
홀로그램 원격 보안
홀로그램 원격은 네트워크를 통해 정보를 교환합니다. 보안 조치가 없는 경우 동일한 네트워크의 악의적 사용자가 통신의 무결성을 손상하거나 기밀 정보에 액세스할 수 있습니다.
Windows 스토어의 샘플 앱 및 홀로그램 원격 플레이어에는 보안이 사용하지 않도록 설정되어 있습니다. 이렇게 하면 샘플을 더 쉽게 이해할 수 있습니다. 또한 개발을 더 빠르게 시작하는 데 도움이 됩니다.
현장 테스트 또는 프로덕션의 경우 Holographic 원격 솔루션에서 보안을 사용하도록 설정하는 것이 좋습니다.
Holographic Remoting의 보안은 사용 사례에 맞게 올바르게 설정된 경우 다음과 같은 보장을 제공합니다.
- 신뢰성: 플레이어와 원격 앱 모두 상대방이 누구라고 주장하는지 확인할 수 있습니다.
- 기밀성: 어떤 타사도 플레이어와 원격 앱 간에 교환된 정보를 읽을 수 없습니다.
- 무결성: 플레이어와 원격은 통신의 전송 중 변경 내용을 검색할 수 있습니다.
중요
보안 기능을 사용하려면 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 공급자가 토큰을 생성하여 클라이언트에 보냅니다.
- 클라이언트는 홀로그램 원격을 통해 서버에 이 토큰을 보냅니다.
- 서버는 ID 공급자에 대해 클라이언트의 토큰의 유효성을 검사합니다.
ID 공급자의 한 가지 예는 Microsoft ID 플랫폼.
이전 사용 사례와 마찬가지로 이러한 토큰이 안전하지 않은 채널을 통해 전송되지 않거나 노출되지 않는지 확인합니다.