보안 | Microsoft Learn - Live Share

아티클
04/18/2023

Visual Studio Live Share의 공동 작업 세션은 많은 사용자가 세션에 참가하고 공동으로 편집, 디버그 등을 할 수 있다는 점에서 강력합니다. 하지만 이러한 액세스 수준을 고려할 때 Live Share에서 제공하는 보안 기능에 관심이 갈 것입니다. 이 문서에서는 필요에 따라 환경을 보호하기 위한 몇 가지 권장 사항 및 옵션을 제공합니다.

다른 공동 작업 도구와 마찬가지로 코드, 콘텐츠 및 애플리케이션을 신뢰할 수 있는 사용자와만 공유해야 합니다.

연결

피어 간 세션을 시작하면 Live Share가 피어 투 피어 연결을 설정하려고 시도하며 가능하지 않은 경우에만(예: 방화벽/NAT로 인해) 클라우드 릴레이 사용으로 돌아갑니다. 그러나 두 연결 형식(P2P 또는 릴레이)에서 피어 간에 전송되는 모든 데이터는 SSH 프로토콜을 사용하여 엔드투엔드 암호화됩니다. 릴레이 연결의 경우 SSH 암호화는 TLS로 암호화된 WebSocket 위의 레이어로 배치됩니다. 즉, Live Share는 보안을 위해 클라우드 릴레이 서비스에 의존하지 않습니다. 릴레이가 손상되더라도 Live Share 통신의 암호를 해독할 수 없습니다.

Live Share 서비스의 역할은 사용자 인증 및 세션 검색으로 제한됩니다. 서비스 자체는 세션의 콘텐츠를 저장하거나 액세스하지 않습니다. Live Share의 모든 사용자 콘텐츠는 SSH 세션을 통해 전송됩니다. 여기에는 코드, 터미널, 공유 서버 및 Live Share 또는 이를 기반으로 하는 확장 프로그램에서 제공하는 기타 공동 작업 기능이 포함됩니다.

이러한 동작 및 Live Share 연결 요구 사항을 변경하는 방법을 자세히 알아보려면 Live Share 연결 요구 사항을 참조하세요.

유선 암호화

SSH 프로토콜은 Diffie-Hellman 키 교환을 사용하여 세션에 대한 공유 비밀을 설정하며 AES 대칭 암호화용 키에서 파생됩니다. 암호화 키는 세션 기간 동안 주기적으로 회전됩니다. 공유 세션 비밀과 모든 암호화 키는 양쪽 모두에서 메모리 내에만 유지되며 세션 기간 동안만 유효합니다. 디스크에 기록되거나 서비스(Live Share 포함)로 전송되지 않습니다.

피어 인증

SSH 세션도 양방향으로 인증됩니다. 호스트(SSH 서버 역할)는 SSH 프로토콜 표준대로 공개/프라이빗 키 인증을 사용합니다. 호스트는 Live Share 세션을 공유할 때 세션에 대한 고유한 RSA 공개/프라이빗 키 쌍을 생성합니다. 호스트 프라이빗 키는 호스트 프로세스의 메모리 내에만 유지됩니다. 디스크에 기록되거나 Live Share 서비스를 포함한 어떤 서비스로도 전송되지 않습니다. 호스트 공개 키는 게스트가 초대 링크를 통해 액세스할 수 있는 세션 연결 정보(IP 주소 및/또는 릴레이 엔드포인트)와 함께 Live Share 서비스에 게시됩니다. 호스트의 SSH 세션에 연결하면 게스트는 SSH 호스트 인증 프로토콜을 사용하여 호스트가 게시된 공개 키에 해당하는 프라이빗 키를 보유하고 있는지 확인합니다(게스트가 실제로 프라이빗 키를 보지 않음).

게스트는 Live Share 토큰을 사용하여 호스트에 인증합니다. 토큰은 Live Share 서비스에서 발급한 서명된 JWT로, 사용자 ID(MSA, AAD 또는 GitHub 로그인을 통해 획득)에 대한 클레임이 포함되어 있습니다. 또한 토큰에는 게스트가 해당 Live Share 세션에 액세스할 수 있음을 나타내는 클레임도 있습니다(초대 링크를 갖고 있고 그리고/또는 호스트에서 특별히 초대했기 때문). 호스트는 게스트가 세션에 참가하도록 허용하기 전에 해당 토큰의 유효성을 검사하고 클레임을 확인합니다(옵션에 따라 호스트 사용자에게 메시지를 표시할 수 있음).

초대 및 참가 액세스

새 공동 작업 세션을 시작할 때마다 Live Share는 초대 링크에 배치되는 새 고유 식별자를 생성합니다. 이러한 링크는 신뢰할 수 있는 사람을 초대하는 견고한 보안 기반을 제공합니다. 링크 식별자는 “추측 불가능”하며 단일 공동 작업 세션 동안만 유효하기 때문입니다.

예상하지 않은 게스트 제거

호스트는 게스트가 공동 작업 세션에 참가할 때마다 자동으로 알림을 받습니다.

Visual Studio Code:

Visual Studio Code join notification

Visual Studio에서:

Visual Studio join notification

게다가 어떤 이유로 모르는 게스트가 참가한 경우 해당 게스트를 제거할 수 있는 기능이 알림에 제공됩니다. (예를 들어 실수로 회사 차원의 채팅 시스템에 링크를 게시하고 임의 직원이 가입한 경우) 표시되는 알림에서 "제거" 단추를 클릭하면 공동 작업 세션에서 제거됩니다.

VS Code에서는 참가 알림을 해제한 이후에도 참가자를 제거할 수 있습니다. 탐색기 또는 VS Code 작업 표시줄의 사용자 지정 탭에서 Live Share 보기를 열면 참가자 이름을 마우스로 가리키거나 마우스 오른쪽 단추로 클릭하고 "참가자 제거" 아이콘 또는 옵션을 선택할 수 있습니다.

Remove participant in VS Code

게스트 승인 필요

일반적으로 공동 작업 세션에 참가하는 참가자는 Microsoft 회사 또는 학교 계정(AAD), 개인 Microsoft 계정 또는 GitHub 계정을 사용하여 Live Share에 로그인됩니다. 로그인한 사용자에 대한 "알림 + 제거" 기본값은 이러한 게스트에게 적절한 속도와 제어를 제공하지만 중요한 작업을 수행하는 경우 좀 더 잠가야 할 수 있습니다.

또한 일부 상황에서는 모든 게스트가 로그인하여 공동 작업 세션에 참가하도록 강제하는 것은 문제가 될 수 있습니다. 예를 들면 Live Share를 잘 모르는 사람에게 게스트로 참가하도록 요청하거나, 학급/학습 시나리오, 또는 지원되는 계정 유형이 하나도 없는 사람과 공동 작업하는 경우가 포함됩니다. 이러한 이유로 Live Share는 로그인하지 않은 사용자가 공동 작업 세션에 읽기 전용 게스트로 참가하는 것을 허용할 수 있습니다. 호스트는 기본적으로 게스트가 참가하기 전에 게스트를 승인해야 하지만 이러한 "익명" 게스트를 거부 또는 항상 승인해야 할 수도 있습니다.

로그인한 사용자에 대한 게스트 승인 요구

로그인한 게스트가 "승인"될 때까지 공동 작업 세션에 참가하지 못하게 하려면 다음 설정을 변경합니다.

VS Code에서 settings.json(파일 > 기본 설정 > 설정)에 다음 코드를 추가합니다.
```
"liveshare.guestApprovalRequired": true
```
Visual Studio에서 도구 > 옵션 > Live Share > "게스트 승인 필요"를 True로 설정합니다.

이 시점부터는 참가하는 각 게스트를 승인하라는 메시지가 표시됩니다.

Visual Studio Code:

Visual Studio Code join approval request

Visual Studio에서:

Visual Studio join approval request

호스트가 이 설정을 사용하도록 설정한 세션에 참가하는 게스트는 상태 표시줄 또는 참가 대화 상자에 Live Share가 호스트의 승인을 기다리고 있다는 알림이 표시됩니다.

로그인하지 않은(익명) 사용자 자동 거부 또는 수락

앞서 설명한 대로 로그인하지 않은 사용자가 공동 작업 세션에 읽기 전용 게스트로 참가하는 것을 허용하도록 Live Share를 구성할 수 있습니다. 이러한 "익명" 게스트는 참가할 때 이름을 입력해야 하지만 단순한 이름은 실제 로그인과 동일한 수준의 보증을 제공하지 않습니다. 따라서 위에서 설명한 "게스트 승인 필요" 설정에 관계없이 기본적으로 호스트에게 모든 익명 게스트를 승인하라는 메시지가 표시됩니다.

다음과 같이 익명 사용자를 항상 거부하거나(익명 게스트 사용 안 함) 익명 사용자를 항상 수락할 수 있습니다.

VS Code에서 settings.json(파일 > 기본 설정 > 설정)의 liveshare.anonymousGuestApproval을 accept, reject 또는 prompt(기본값)로 적절히 설정합니다.
Visual Studio에서 도구 > 옵션 > Live Share > "익명 게스트 승인"을 수락, 거부 또는 프롬프트(기본값)로 적절히 설정합니다.

그럼에도 불구하고 신뢰할 수 있는 사람에게만 Live Share 초대 링크를 보내야 합니다.

게스트 명령 제어 허용

VS Code: The host doesn't allowing running this command.

게스트가 코드 작업("빠른 수정")을 통해 임의의 명령을 실행할 수 있도록 허용하고 CodeLens는 다음 설정을 지정합니다.

VS Code에서 settings.json(파일 > 기본 설정 > 설정)을 설정하거나 false 기본값으로 true 설정합니다liveshare.languages.allowGuestCommandControl.

파일 액세스 및 표시 유형 제어

Live Share의 원격 모델은 게스트가 프로젝트의 전체 콘텐츠를 동기화하지 않고 호스트가 공유한 파일 및 폴더를 확인할 수 있는 빠른 읽기/쓰기 액세스를 제공합니다. 따라서 게스트는 전체 공유 파일 트리에서 독립적으로 파일을 탐색하고 편집할 수 있습니다. 그러나 이러한 자유로 인해 호스트에게 몇 가지 위험이 있습니다. 개념적으로 보면 개발자는 호스트 모르게 소스 코드로 이동하여 소스 코드를 수정하거나 공유 파일 트리의 어딘가에 있는 중요한 소스 코드 또는 "비밀"을 볼 수 있습니다. 따라서 호스트로서 항상 게스트가 공유 중인 프로젝트 전체에 액세스할 수 있기를 원하지 않을 수 있습니다. 다행스럽게도 이 원격 모델의 부가적 장점 하나는 기능은 훼손하지 않으면서 다른 사용자와 공유하지 않으려는 파일을 "제외"할 수 있다는 점입니다. 게스트는 일반적으로 자체적으로 수행하려는 경우 이러한 파일에 액세스해야 하는 디버깅 세션과 같은 작업에 계속 참가할 수 있습니다.

공유 중인 폴더 또는 프로젝트에 .vsls.json 파일을 추가하여 이 작업을 수행할 수 있습니다. 이 json 형식 파일에 추가하는 모든 설정은 Live Share가 파일을 처리하는 방법을 변경합니다. 직접 제어를 제공하는 것 외에도, 프로젝트를 복제하는 모든 사용자가 추가 노력 없이 해당 규칙을 활용할 수 있도록 이러한 파일을 소스 제어에 커밋할 수도 있습니다.

다음은 예제 .vsls.json 파일입니다.

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none",
    "excludeFiles":[
        "*.p12",
        "*.cer",
        "token",
        ".gitignore"
    ],
    "hideFiles": [
        "bin",
        "obj"
    ]
}

참고 항목

공동 작업 세션을 시작할 때 공유하는 모든 파일/폴더를 읽기 전용으로 만들 수도 있습니다. 자세한 내용은 다음을 참조하세요.

이러한 속성이 게스트가 수행할 수 있는 작업을 어떻게 변경하는지 살펴보겠습니다.

속성

excludeFiles 속성을 사용하면 Live Share가 게스트에게 특정 파일 또는 폴더를 열 수 없도록 하는 GLOB 파일 패턴(찾은 .gitignore 파일과 매우 유사함)의 목록을 지정할 수 있습니다. 여기에는 호스트의 편집 위치로 팔로우 또는 이동하는 게스트, 공동 작업 디버깅 중에 파일을 한 단계씩 코드 실행, 정의로 이동과 같은 코드 탐색 기능 등의 시나리오가 포함됩니다. 이 기능은 비밀, 인증서 또는 암호를 포함하는 경우처럼 어떤 경우에도 공유하지 않으려는 파일을 위한 것입니다. 예를 들어 .vsls.json 파일은 보안을 제어하기 때문에 항상 제외됩니다.

hideFiles 속성은 비슷하지만 이처럼 엄격하지는 않습니다. 이러한 파일은 단지 파일 트리에서 숨겨집니다. 예를 들어 디버깅 도중 이러한 파일 중 하나를 한 단계씩 디버그했다면 해당 파일이 편집기에서 계속 열려 있습니다. 이 속성은 .gitignore 파일 설정이 없거나(다른 소스 제어 시스템을 사용하는 경우) 복잡성 또는 혼동을 피하기 위해 이미 포함된 항목을 보강하려는 경우에 주로 유용합니다.

gitignore 설정은 Live Share가 공유 폴더에서 .gitignore 파일의 내용을 처리하는 방법을 설정합니다. 기본적으로 .gitignore 파일에 있는 모든 GLOB는 "hideFiles" 속성에 지정된 것처럼 처리됩니다. 그러나 다음 값 중 하나를 사용하여 다른 동작을 선택할 수 있습니다.

옵션	결과
`none`	.gitignore 콘텐츠가 파일 트리에서 게스트에게 표시됩니다(게스트 편집기 설정으로 필터링되지 않은 것으로 가정).
`hide`	기본값입니다. .gitignore 내의 GLOB가 "hideFiles" 속성에 지정된 것처럼 처리됩니다.
`exclude`	.gitignore 내의 GLOB가 "excludeFiles" 속성에 지정된 것처럼 처리됩니다.

exclude 설정의 단점은 node_modules 같은 폴더의 내용이 .gitignore에 자주 있지만 디버그하는 동안 한 단계씩 실행하는 데 유용할 수 있다는 것입니다. 따라서 Live Share는 excludeFiles 속성에서 "!"를 사용하여 규칙을 되돌리는 기능을 지원합니다. 예를 들어 다음 .vsls.json 파일은 node_modules를 제외하고 ".gitignore"의 모든 것을 제외합니다.

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ]
}

숨기기 및 제외 규칙은 별도로 처리되므로 실제로는 제외하지 않고 복잡성을 줄이기 위해 node_modules를 숨기려는 경우 다음과 같이 파일을 편집하면 됩니다.

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ],
    "hideFiles":[
        "node_modules"
    ]
}

하위 폴더의 .vsls.json 파일

마지막으로 .gitignore와 마찬가지로 .vsls.json 파일을 하위 폴더에 배치할 수 있습니다. 숨기기/제외 규칙은 공유한 루트 폴더(있는 경우)의 .vsls.json 파일로 시작하여 해당 폴더의 각 하위 폴더를 탐색한 다음 처리할 .vsls.json 파일을 찾도록 지정된 파일로 넘어가는 방식으로 결정됩니다. 파일 트리에서 멀리 떨어진 폴더에 있는 .vsls.json 파일의 내용은 더 상위 수준에서 설정된 규칙을 보완(또는 재정의)합니다.

참고: 해당 파일의 부모 디렉터리가 제외된 경우 파일을 다시 포함(!)할 수 없습니다. .gitignore와 마찬가지로 파일을 다시 포함할 때 파일의 모든 부모 디렉터리도 다시 포함해야 합니다.

기본적으로 Live Share는 공유 폴더/솔루션 외부에서 호스트가 여는 모든 파일도 공유합니다. 이렇게 하면 다른 관련 파일을 다시 공유하지 않고도 간편하게 해당 파일을 빠르게 열 수 있습니다.

이 기능을 사용하지 않도록 설정하려는 경우

VS Code에서 settings.json에 다음 코드를 추가합니다.
```
"liveshare.shareExternalFiles": false
```
Visual Studio에서 도구 > 옵션 > Live Share > "외부 파일 공유"를 False로 설정합니다.

읽기 전용 모드

호스트로 코드를 공유할 때 게스트가 편집하지 않도록 하려는 경우가 있습니다. 게스트가 코드 중 일부를 검토해야 하거나 프로젝트를 다수의 게스트에게 표시하지만 불필요하게 또는 실수로 편집하는 것을 원하지 않을 수 있습니다. Live Share는 읽기 전용 모드에서 프로젝트를 공유하는 기능을 제공합니다.

호스트는 공유할 때 공동 작업 세션에 읽기 전용 모드를 설정할 수 있습니다. 세션에 참가하는 게스트는 코드를 편집할 수 없지만, 서로의 커서 및 강조 표시를 볼 수 있을 뿐만 아니라 프로젝트를 탐색할 수도 있습니다.

읽기 전용 모드에서도 게스트와 함께 디버그할 수 있습니다. 게스트는 디버깅 프로세스를 단계별로 진행할 수 없지만 중단점을 추가 또는 제거하고 변수를 검사할 수 있습니다. 또한 여전히 게스트와 서버 및 터미널(읽기 전용)을 공유할 수 있습니다.

읽기 전용 공동 작업 세션을 시작하는 방법에 대해 자세히 알아볼 수 있습니다.

공동 디버깅

까다로운 코딩 문제 또는 버그를 디버그하는 경우 여러 사람이 디버깅에 참가하면 정말 유용할 수 있습니다. Visual Studio Live Share에서는 호스트가 디버깅을 시작할 때마다 모든 게스트와 디버깅 세션을 공유하여 "공동 작업 디버깅" 또는 "공동 디버깅"을 설정할 수 있습니다.

호스트가 디버깅 세션을 시작 또는 중지하는 시기를 완전히 제어할 수 있지만, 신뢰하지 않는 사람과 공유하는 경우 공동 디버깅으로 인해 몇 가지 위험이 발생합니다. Live Share에서는 초대하는 게스트가 콘솔/REPL 명령을 실행할 수 있으므로 악의적인 행위자가 원치 않는 명령을 실행할 위험이 있습니다.

따라서 신뢰하는 사람과만 공동 디버그해야 합니다.

자세한 정보:

공동 디버깅 시 호스트가 디버깅 세션을 위해 제공하는 애플리케이션의 서로 다른 부분을 액세스하는 것은 정말 유용할 수 있습니다. 브라우저에서 앱에 액세스하거나 로컬 데이터베이스에 액세스하거나 도구에서 REST 엔드포인트에 도달할 수 있습니다. Live Share를 사용하면 “서버를 공유”할 수 있으므로 호스트 머신의 로컬 포트를 게스트 머신의 정확히 동일한 포트에 매핑합니다. 게스트는 마치 머신에서 로컬로 실행 중인 것처럼 애플리케이션을 정확하게 조작할 수 있습니다(예를 들어 호스트와 게스트 모두 http://localhost:3000).에서 실행 중인 웹앱에 액세스할 수 있음).

그러나 호스트는 게스트와 공유하는 포트를 매우 신중하게 선택해야 하며 시스템 포트가 아닌 애플리케이션 포트를 공유해야 합니다. 게스트의 경우 공유 포트는 서버/서비스를 자신의 머신에서 실행하는 것처럼 정확하게 작동합니다. 이 공유 포트는 매우 유용하지만 잘못된 포트를 공유하는 경우 위험할 수도 있습니다. 이러한 이유로 Live Share는 구성 설정 및 호스트에 의한 작업 없이는 공유해야 하는 것과 공유해서는 안 되는 것에 대해 어떠한 가정도 하지 않습니다.

Visual Studio에서는 ASP.NET 프로젝트에 지정된 웹 애플리케이션 포트는 게스트가 실행 중인 웹앱에 용이하게 액세스할 수 있도록 디버깅 중에 자동으로 공유됩니다. 그러나 원하는 경우 도구 > 옵션 > Live Share > "디버그 시 웹앱 공유"를 "False"로 설정하여 이 자동화를 해제할 수 있습니다.

Visual Studio Code에서는 Live Share가 적절한 애플리케이션 포트를 검색하고 공유하려고 시도합니다. 그러나 settings.json에 다음 코드를 추가하여 이 동작을 해제할 수 있습니다.

"liveshare.autoShareServers": false

두 경우 모두 추가 포트를 공유할 때는 주의해야 합니다.

기능 구성에 대한 자세한 내용은 다음을 참조하세요.

최신 개발 환경에서는 다양한 명령줄 도구를 자주 사용합니다. 다행스럽게도 Live Share는 호스트에게 필요에 따라 게스트와 “터미널을 공유”할 수 있는 기능을 제공합니다. 공유 터미널은 읽기 전용이거나 완전하게 공동 작업이 가능하므로 호스트와 게스트는 모두 명령을 실행하고 그 결과를 볼 수 있습니다. 호스트는 다른 공동 작업자가 출력을 보거나 원하는 수의 명령줄 도구를 사용하여 테스트를 실행하거나, 빌드하거나, 심지어 환경 관련 문제를 심사하도록 허용할 수 있습니다.

호스트만 공유 터미널을 시작하여 게스트가 한 터미널을 시작하거나, 호스트가 예측 또는 감시하지 못하는 작업을 수행하지 못하게 할 수 있습니다. 호스트는 공유 터미널을 시작할 때 읽기 전용인지 아니면 읽기/쓰기인지를 지정할 수 있습니다. 터미널이 읽기/쓰기인 경우 호스트를 포함하여 누구나 터미널에 입력할 수 있습니다. 그러면 게스트가 호스트의 마음에 들지 않는 작업을 수행하는 경우 개입하기가 쉬워집니다. 그러나 안전하려면 호스트는 게스트가 실제로 필요하다는 것을 아는 경우 게스트에게 읽기/쓰기 액세스 권한만 부여하고, 호스트가 실행하는 모든 명령의 출력을 게스트가 참조하기를 원하는 경우에 읽기 전용 터미널을 계속 사용해야 합니다.

Visual Studio에서 터미널은 기본적으로 공유되지 않습니다. VS Code에서는 기본적으로 터미널이 자동으로 읽기 전용으로 공유됩니다. 그러나 settings.json에 다음 코드를 추가하여 이 동작을 해제할 수 있습니다.

"liveshare.autoShareTerminals": false

자세한 정보:

Microsoft에서 제공하는 회사 또는 학교 이메일 주소를 사용하여 로그인할 때 “관리자 승인 필요”라는 메시지가 표시될 수 있습니다. Live Share는 보안 기능의 사용자 정보에 대한 읽기 권한을 요구하고 Azure AD 테넌트는 디렉터리의 내용에 액세스하는 새 애플리케이션에 대해 "관리자 동의"를 요구하도록 설정되어 있기 때문입니다.

AD 관리자는 다음 정보를 사용하여 이 문제를 해결해야 합니다.

애플리케이션 이름: Visual Studio Live Share(참가자)
애플리케이션 유형: 웹앱
애플리케이션 상태: 프로덕션
위임된 권한: User.Read
애플리케이션 URL: https://visualstudio.microsoft.com/services/live-share/
회신 URL: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

이 작업은 Live Share를 사용하는 사용자에 대해 한 번만 수행하면 됩니다. 자세한 내용은 여기 및 여기를 참조하세요.

참고 항목

문제가 있으신가요? 문제 해결을 참조하거나 피드백을 제공해 주세요.

Live Share의 보안 기능

연결

유선 암호화

피어 인증

초대 및 참가 액세스

예상하지 않은 게스트 제거

게스트 승인 필요

로그인한 사용자에 대한 게스트 승인 요구

로그인하지 않은(익명) 사용자 자동 거부 또는 수락

게스트 명령 제어 허용

파일 액세스 및 표시 유형 제어

속성

하위 폴더의 .vsls.json 파일

외부 파일 공유 비활성화

읽기 전용 모드

공동 디버깅

로컬 서버 공유

터미널 공유

AAD 관리자 동의

참고 항목

피드백

피드백

추가 리소스