작업 영역 신뢰

2021년 7월 6일, Chris Dias 작성, @chrisdias

나 자신을 믿을 수 있을까? 이것은 많은 Visual Studio Code 사용자들이 1.57 업데이트 이후 직면한 실존적 질문입니다.

이 질문에 대한 답을 드릴 수는 없지만, 워크스페이스 신뢰(Workspace Trust)라는 개념을 도입한 이유에 대해 더 자세히 알려드릴 수 있습니다.

하지만 먼저, 약간의 배경 설명을 드리겠습니다.

고양이와 키보드, 그리고 나쁜 사과

인터넷에는 키보드를 치는 고양이 영상과 같이 즐거운 것들로 가득합니다.

개발자들에게도 역시 좋은 사람들이 만든 도구, 패키지, 오픈 소스 등으로 가득합니다. 이들은 몇 시간 동안 작업해 온 문제를 해결하는 데 도움을 주고자 합니다. VS Code와 같은 개발 도구는 패키지 관리자, 코드 린터, 태스크 러너, 번들러 등을 통합하여 끊임없이 진화하는 커뮤니티의 최신 기술 발전을 활용하는 즐거운 경험을 제공합니다.

그러나 이러한 풍부한 생태계가 제공하는 생산성은 개발 머신에 대한 광범위한 접근 권한으로 인해 종종 발생합니다. 여기에 빠른 진화와 바이럴 공유 및 소비가 결합되면, 개발 도구는 특히 공격자가 인증 토큰 저장 또는 개발자가 작성한 소프트웨어를 통해 공격을 확산시킬 수 있다는 점을 고려할 때 악용의 매력적인 대상이 됩니다.

개발자가 되는 것은 보람 있지만 위험한 사업이기도 합니다. 프로젝트에 기여하려면 본질적으로 해당 프로젝트의 작성자를 신뢰해야 합니다. `npm install` 또는 `make`를 실행하거나, Java 또는 C# 프로젝트를 빌드하거나, 자동화된 테스트 또는 디버깅과 같은 활동은 모두 해당 프로젝트의 코드가 컴퓨터에서 실행됨을 의미하기 때문입니다.

저희의 목표는 워크스페이스 신뢰(Workspace Trust) 기능을 통해 올바른 균형을 찾는 것입니다. 모두를 망치려는 소수의 "나쁜 사과"로부터 안전을 지키면서 개발을 즐겁게 만드는 모든 좋은 기능들을 계속 보장하는 것입니다.

그냥 편집기일 뿐인데, 맞나요?

네, VS Code는 편집기입니다. 하지만 대부분의 최신 편집기와 마찬가지로, 더 풍부한 개발 경험을 제공하기 위해 워크스페이스의 코드를 대신 실행할 수 있는 기능을 갖추고 있습니다.

코드를 실행하고 디버깅하는 것은 분명한 예입니다. 코드 실행이 그렇게 분명하지 않을 수도 있는데, 앱 시작 전에 실행되어 빌드와 관련 없는 임의의 코드를 실행하는 빌드를 수행할 수 있는 `preLaunchTask`가 있습니다. 암호화폐 지갑 개인 키를 훔치는 npm 모듈은 어떻습니까? 간단한 편집으로 전역으로 설치된 것이 아닌 `node_modules` 폴더에서 악성 린터가 로드될 수 있습니다. 코드를 읽는 것조차 속일 수 있습니다. 공격자는 유니코드 해킹을 사용하여 악성 코드를 눈에 띄게 숨길 수 있습니다. 심지어 소스 코드를 열지 않고도 공격을 받을 수 있습니다.

여기서의 의도는 여러분을 모든 훌륭한 도구(VS Code 포함)에서 멀어지게 하거나 직업을 바꾸게 하려는 것이 아닙니다. 여러분이 전혀 신뢰 관계가 없는 사람이나 조직이 작성한 코드를 인터넷에서 다운로드할 때 많은 공격 기회가 있다는 것을 인식시키는 것입니다.

두더지 잡기

위의 모든 시나리오에서 도구는 의도한 대로 작동하며, 악의적이지 않은 코드 베이스에서는 매우 생산적입니다. 디버깅하기 전에 앱을 빌드하기 위해 `preLaunchTask`를 설정하면 변경할 때마다 터미널에서 수동으로 빌드할 필요가 없어 시간을 절약할 수 있습니다. 린터는 모든 팀의 선호하는 코딩 지침 및 스타일(예, 탭 대 공백)을 지원하도록 고도로 사용자 정의할 수 있습니다. 커밋 전 훅을 사용하면 무언가를 잊었는지 확인하거나 커밋 전에 테스트가 실행되도록 할 수 있습니다.

이제, 동시에 모든 공격에 노출될 가능성은 낮습니다. 사실, (아직까지) VS Code를 통한 익스플로잇은 없었습니다. 왜냐하면 새로운 기회가 발생할 때마다 우리에게 알려주는 훌륭한 전문가 커뮤니티가 있기 때문입니다. 워크스페이스 신뢰 이전의 우리의 접근 방식은 각 시나리오를 취약점 발생 지점에서 국지적인 권한 프롬프트로 처리하는 것이었습니다.

예를 들어, Jupyter 확장 프로그램은 Notebook의 시각화 도구를 열 때 포함된 JavaScript가 실행될 수 있음을 사용자에게 경고했습니다.

ESLint 취약점은 워크스페이스가 로드될 때 실행되기 때문에 매우 까다로웠습니다 (이것이 우리의 첫 번째 모달 대화 상자였습니다).

이는 결국 패배하는 싸움임이 밝혀졌습니다. 사용자는 전체 워크스페이스에 적용되지 않는 여러 (그리고 약간 다른) 권한 프롬프트로 인해 중단됩니다. *나는 너, 너, 너, 너를 신뢰하지만, 너와 너는 화요일에만 신뢰한다.* 우리에게는 노출되는 각 취약점을 또 다른 프롬프트로 해결하는 끊임없는 두더지 잡기 게임입니다.

따라서 VS Code를 구축할 때 저희가 따르는 패턴 중 하나는 도구와 확장 프로그램 전반에 걸쳐 유사하지만 일관되지 않게 구현되는 경험을 살펴보고 핵심 기능으로 가져올 수 있는지 확인하는 것입니다. 신뢰 프롬프트도 이 패턴을 따랐기 때문에 (희망적으로) 더 명확한 사용자 경험을 가진, 도구와 확장 프로그램 모두가 활용할 수 있는 경험과 API를 구축하기로 결정했습니다.

신뢰

이제 코드가 여러분도 모르게 실행될 수 있는 다양한 방법을 이해했으므로, 왜 이 질문을 미리 묻는지 더 잘 이해하셨기를 바랍니다.

VS Code는 코드가 악의적인지 여부를 알 수 없기 때문에(네, 저희는 1과 0만 알아요), 코드가 어디서 왔는지, 프로젝트에 기여할 의도가 있는지 등을 알 수 없으므로 이 워크스페이스 작성자를 신뢰하는지 여부를 구체적으로 묻습니다.

반면에 여러분은 똑똑하고 코드의 출처를 알고 있습니다: 여러분 자신(괜찮음), 여러분의 회사(아마 괜찮음), 친구 카이(글쎄요), 또는 인터넷의 무작위 사람(절대 안 됨).

그 지식이 도구를 더 똑똑하게 만드는 데 도움이 됩니다. 작성자를 신뢰한다면 좋습니다! 도구와 확장 프로그램은 모든 작업을 수행하고 마법 같은 경험을 제공할 수 있는 녹색 신호를 받고, 더 이상 여러분을 괴롭히지 않을 것입니다.

그렇지 않다면, 여러분은 저희에게 **VS Code, 코드를 실행하지 마세요**라고 말하는 것입니다. 이것을 저희는 **제한 모드(Restricted Mode)**라고 부르며, 잠재적으로 유해한 기능이 비활성화되어 코드를 더 안전하게 탐색하고 궁극적으로 정보에 입각한 결정을 내릴 수 있습니다.

하지만 그 대화 상자!

여러분의 의견을 듣고 있습니다. 모달 대화 상자가 상당히 크고, 여러분이 조치를 취하여 구성하지 않는 한 폴더를 열 때마다 계속 나타납니다.

저희는 이 디자인으로 시작한 것이 아닙니다. 저희는 ESLint 모달 대화 상자 사건을 살펴보고 시각적 단서와 가능한 한 가장 늦게 지연된 단일 알림 프롬프트를 사용하여 블로킹되지 않는 경험을 제공할 수 있는지 자문했습니다. 저희는 방해가 되지 않고, 제한 모드에서 시작하며 (여러분이 눈치채지 못하게) 마지막 순간에 신뢰를 요청하고 싶었습니다.

저희는 워크스페이스를 신뢰하는지 여부를 알릴 수 있는 "수동" 신뢰 알림을 도입했습니다. 설정을 기어 아이콘과 새로운 보안 아이콘을 보강하는 것을 포함하여 워크스페이스가 신뢰되지 않았음을 나타내는 다양한 UI 처리를 거쳤습니다.

여러분이 Insiders 빌드를 사용하면 VS Code에서 워크스페이스 신뢰에 대해 이야기하는 것과 같은 새로운 경험의 최신 반복을 얻을 수 있습니다. Insiders는 매일 출시되며 저희는 VS Code를 빌드하는 데 사용합니다.

그 아이디어는 사용자(당신!)가 **자신의 조건**으로 워크스페이스에 대한 신뢰를 부여하거나 거부할 시점을 결정할 수 있다는 것입니다. 도구나 확장 프로그램이 정말 액세스 권한이 필요할 때만 워크스페이스를 신뢰하는지 묻는 알림을 표시할 것입니다.

이제 많은 분들이 동의하시겠지만, VS Code는 "알림 피로"(개선하기 위해 노력하고 있습니다 😊)라는 문제로 고통받고 있습니다. 저희 테스트에서 사람들은 알림을 무시한다는 것을 보았습니다. 사용자들은 기어나 새로운 보안 아이콘을 보지 못했습니다. 사용량 데이터는 수동 알림을 통해 신뢰를 부여하는 비율이 매우 낮았음을 보여주었습니다. 사용자 연구에서 사람들은 뭔가 고장 났다고 생각하며 시간을 보내고, 그런 다음 문제를 해결하고 원래 상태로 돌아가려고 시간을 보냈습니다.

저희는 방해가 되지 않고 가능한 한 지연시키려고 의도했지만, 현실은 제한 모드에서 제품이 고장난 것처럼 느껴졌고 사람들은 그것이 자신들의 잘못이라고 생각했다는 것입니다. 우리 둘 다에게 좋은 상황은 아니었습니다.

여러분을 통제권 안에 두기

폴더를 신뢰하기로 결정하는 것은 VS Code의 기능에 근본적인 영향을 미칩니다. 따라서 모든 연구 후, 폴더를 열려고 할 때 즉시 신뢰 질문을 하는 것이 올바른 일이라고 결정했습니다. 모달 대화 상자가 방해가 되기 때문에, 대화 상자를 강력하게 만들어 몇 가지 질문에 답할 수 있도록 하여 일상 업무에서 프롬프트를 훨씬 덜 보게 함으로써 균형을 맞추려고 합니다.

자체 사용 및 다른 개발자들과의 인터뷰를 통해, 사람들은 일반적으로 모든 소스를 넣는 주요 폴더를 가지고 있으며 이를 신뢰할 만하다고 생각한다는 것을 알게 되었습니다. 따라서 대화 상자에서 직접 **부모** 폴더를 신뢰할 수 있는 기능을 추가했습니다. 한 번의 클릭으로 폴더와 모든 하위 폴더를 신뢰할 수 있으며, 그러면 신뢰 프롬프트가 다시 나타나지 않습니다.

워크스페이스 신뢰 편집기

워크스페이스 신뢰 편집기는 무엇을 신뢰하는지에 대한 추가 제어 기능을 제공하며, 1.58 릴리스에서 기능을 쉽게 구성할 수 있도록 업데이트될 것입니다.

그리고 동작을 사용자 정의할 수 있기 때문에 신뢰 편집기에 도달하는 방법은 여러 가지입니다 😊. **제한 모드** 상태 표시줄 메시지, 제한 모드 배너의 **관리** 링크, 기어 메뉴를 클릭하거나 명령 팔레트(F1)를 열고 **Workspaces: Manage Workspace Trust** 명령을 사용하세요.

워크스페이스 신뢰 편집기에서 현재 폴더, 부모 폴더(및 모든 하위 폴더), 그리고 컴퓨터의 모든 폴더를 신뢰할 수 있습니다.

또한 워크스페이스 신뢰 설정으로 빠르게 이동하여 환경 설정을 미세 조정할 수 있습니다.

워크스페이스 신뢰를 사용하는 방법

아무도 치실질하는 것을 좋아하지 않지만, 올바른 일이라는 것을 알기 때문에 합니다. 아무도 보안에 대해 생각하고 싶어하지 않지만, 그것이 올바른 일이라는 것을 알기 때문에 합니다. 환경 설정을 사용자 정의함으로써 개발 경험을 즐겁게 유지하면서 개발의 고유한 위협으로부터 자신을 보호할 수 있습니다(즐거운 치실질?!?).

VS Code 팀의 대부분의 사람들은 신뢰하는 소스를 작업하는 최상위 폴더로 시작합니다. 예를 들어, 제 Mac에서는 GitHub에서 Microsoft 조직에서 가져온 모든 소스를 `~/src` 폴더에 넣습니다. `~/src`를 신뢰하는 폴더로 지정하면 그 아래의 모든 것이 본질적으로 신뢰됩니다. `~/src/vscode` 또는 `~src/vscode-docker` 등을 열 때, 저희 조직이 작성하고 사용하는 코드를 신뢰하기 때문에 전체 신뢰로 열립니다.

저는 `~/scratch`(여기서는 "임시 저장소"를 의미하며, 물론 원하는 대로 만들 수 있습니다)이라는 별도의 폴더를 가지고 있으며, 여기에 나머지 모든 것을 넣고 기본적으로 신뢰하지 않는다고 가정합니다. 그런 다음 폴더별로 신뢰 결정을 내립니다.

작업 흐름을 원활하게 하기 위해 `"security.workspace.trust.startupPrompt"` 설정을 ` "never"`로 설정했습니다.

이 설정으로 모달 대화 상자에 의해 프롬프트되지 않고 워크스페이스가 제한 모드로 직접 열립니다. 저는 이미 `~src/scratch` 폴더를 신뢰하지 않는다고 결정했으므로, 하위 폴더를 열 때마다 프롬프트할 필요가 없습니다. 읽거나 쓰는 코드를 신뢰한다고 결정하면, 두 번의 빠른 클릭(VS Code 상단에 있는 제한 모드 알림, 그런 다음 신뢰 버튼)으로 해당 폴더에서 활성화할 수 있습니다.

제 Windows 컴퓨터에서는 상황이 조금 더 흥미롭습니다. 저는 일반적으로 Windows Subsystem for Linux(WSL)에서 실행되는 Ubuntu 이미지에서 작업하며, WSL 확장 프로그램을 사용합니다. Linux의 `~/src` 폴더를 신뢰하고 Windows 쪽의 `d:\src` 폴더를 신뢰합니다.

팀원 중 일부는 한 걸음 더 나아가 제한 모드 배너를 완전히 끄기도 합니다 (`"security.workspace.trust.banner": "never"`). 상태 표시줄 알림만 남겨둡니다. 저에게는 이것이 너무 과한 것 같습니다. 상단의 배너는 저를 정직하게 유지하고 인터넷에서 코드를 가져올 때 주의하도록 상기시켜 줍니다.

오픈 소스는 훌륭합니다

저희는 VS Code가 여러분의 "실제" 작업을 완료하는 데 사용하는 도구이며, 저희가 도입하는 모든 장애물이나 걸림돌은 다음 유니콘을 구축하고 출시하는 데 속도를 늦출 뿐이라는 것을 알고 있습니다. 많은 분들이 트위터, 레딧, 이슈 트래커를 통해 의견을 주셨고, 솔직한 피드백에 감사드립니다. 여러분의 의견을 바탕으로 1.58 릴리스에 포함될 여러 수정 및 개선 사항을 만들었으며, 계속해서 대화를 이어가기를 기대합니다.

향후에는 확장 프로그램 작성자가 임의 코드 실행을 피하고 제한 모드에서 실행될 때 더 많은 기능을 제공하도록 돕고 싶습니다. 저희 로드맵은 확장 프로그램 생태계에 추가적인 보안 기능을 제공하기 위해 Visual Studio Marketplace 팀과 협력하는 작업을 설명합니다 (이를 "신뢰된 확장 프로그램"이라고 부릅니다). 여기에는 검증된 게시자, 서명, 플랫폼별 확장이 포함됩니다. 요컨대, 워크스페이스 신뢰는 좋은 확장 프로그램이 좋은 결정을 내리도록 돕는다고 생각할 수 있습니다. 신뢰된 확장 프로그램은 나쁜 확장 프로그램으로부터 여러분을 보호할 것입니다.

VS Code를 공개적으로 구축하는 것의 이점 중 하나는 커뮤니티가 최고의 경험을 만드는 데 도움을 줄 수 있다는 것입니다. 따라서 가능한 한 방해가 되지 않도록 하면서 여러분을 안전하게 보호하는 데 도움이 되는 흐름을 어떻게 개선할 수 있는지 알려주십시오. 기존 이슈에 (정중하게!) 댓글을 달거나, 새로운 이슈를 제출하거나, 트위터 @code로 메시지를 보내주시면 경청하겠습니다!

감사합니다.

Chris와 VS Code 팀

(안전하게) 행복한 코딩 되세요!