Windows Sandbox 설정 파일, 네트워크·공유 폴더를 안전하게 나누는 법

AI를 활용하여 생성한 이미지입니다.

Windows Sandbox는 설치한 프로그램과 파일을 버리고 다시 시작할 수 있는 가벼운 격리 환경이에요. 그래서 출처가 불분명한 설치 파일이나 새 도구를 시험할 때 유용하지만, 기본값을 그대로 믿고 쓰면 호스트와 네트워크에 불필요하게 노출될 수 있어요.[3] 특히 네트워크, 클립보드, 공유 폴더는 서로 다른 경로라서 하나만 끈다고 전체가 닫히지는 않아요.

중급 사용자가 .wsb 파일을 직접 만드는 이유도 여기에 있어요. 테스트 목적에 맞춰 네트워크를 끄고, 필요한 폴더만 읽기 전용으로 연결하고, 시작 명령을 최소화하면 재현 가능한 실험 공간을 만들 수 있어요.[1][2]

기본값부터 확인해요

Microsoft 문서 기준으로 Windows Sandbox는 네트워크와 vGPU가 기본 활성화되고, 오디오 입력은 켜져 있으며 비디오는 꺼져 있어요.[1] 네트워크는 Hyper-V 기본 스위치를 사용하므로 Sandbox 안의 프로그램이 내부 네트워크에 접근할 가능성이 생겨요.[1] 악성 파일을 열어 보는 목적이라면 네트워크를 켠 채로 시작하지 않는 편이 안전해요.

Sandbox는 완전한 보안 제품이 아니에요. 호스트에서 복사한 비밀값을 붙여 넣거나, 쓰기 가능한 공유 폴더를 연결하거나, 테스트 파일을 네트워크에서 다시 내려받으면 격리의 이점이 줄어들어요. 실험 전에 무엇을 관찰하려는지부터 정하고, 필요한 통로만 여는 방식이 맞아요.

가장 보수적인 .wsb 파일 만들기

Sandbox 설정 파일은 XML 형식의 텍스트 파일이고 확장명을 .wsb로 저장해 실행해요. 먼저 네트워크와 vGPU를 끄고, 호스트 폴더 한 곳만 읽기 전용으로 연결하는 구성을 사용해 보세요.[2]

<Configuration>
  <VGpu>Disable</VGpu>
  <Networking>Disable</Networking>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\Public\Downloads</HostFolder>
      <SandboxFolder>C:	emp</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>explorer.exe C:	emp</Command>
  </LogonCommand>
</Configuration>

위 예시는 Microsoft가 제공하는 샘플의 구조를 바탕으로 했어요. 호스트 경로는 실제로 시험할 파일이 있는 폴더로 바꾸되, 문서·사진 전체가 들어 있는 개인 폴더를 그대로 연결하지 않는 게 좋아요.[2] Sandbox 안의 경로는 짧고 분명한 위치로 정하면 실수도 줄어들어요.

공유 폴더의 읽기 전용을 먼저 보는 이유

ReadOnly를 true로 두면 Sandbox가 호스트 폴더를 읽을 수는 있지만, 그 폴더에 결과를 다시 쓰는 흐름은 막을 수 있어요.[2] 다운로드한 파일을 복사해 열어 보는 목적이라면 원본을 보호하는 데 도움이 돼요. 다만 Sandbox 안에서 파일을 열었다는 사실만으로 악성 동작이 모두 차단되는 것은 아니므로, 호스트로 결과물을 가져오기 전에 별도 검사를 거쳐야 해요.

반대로 테스트 프로그램이 파일을 생성해야 한다면 호스트 폴더를 쓰기 가능하게 바꾸기보다 Sandbox 내부의 임시 경로에 먼저 저장하세요. 꼭 내보내야 하는 결과만 종료 전에 확인하고, 새 결과 폴더를 읽기 전용으로 다시 연결하는 흐름이 더 안전해요.

네트워크를 켜야 할 때의 순서

1. 네트워크 없이 파일의 기본 동작을 먼저 확인해요.
2. 프로그램이 실제로 네트워크를 요구하는지 로그나 오류 메시지로 확인해요.
3. 필요한 테스트용 Sandbox 설정 파일을 별도로 복사해요.
4. 네트워크를 켠 구성에서는 개인 계정과 비밀값을 입력하지 않아요.
5. 테스트가 끝나면 Sandbox를 닫고, 결과 파일을 호스트에서 다시 검사해요.

네트워크가 기본 활성화라는 점은 편리함보다 노출 범위를 먼저 계산해야 한다는 뜻이에요.[1][3] 웹사이트나 패키지 저장소를 꼭 이용해야 하는 개발 테스트라면 연결을 허용할 수 있지만, 출처가 불분명한 실행 파일을 관찰하는 실험과 같은 설정 파일을 쓰면 안 돼요.

클립보드와 시작 명령도 별도 통로예요

공유 폴더만 끄고 클립보드는 그대로 두면 호스트에서 복사한 텍스트나 토큰이 Sandbox로 들어갈 수 있어요. 반대로 클립보드를 사용해야 하는 테스트라면 비밀번호나 API 키를 복사하지 않는 원칙을 먼저 세워야 해요. 설정 파일에서 자동으로 실행하는 LogonCommand도 편리하지만, 출처를 확인하지 않은 스크립트를 시작 명령으로 넣는 방식은 피하세요.[1]

작업을 반복한다면 용도별로 파일을 나누세요. 오프라인 파일 검사, 네트워크가 필요한 설치 테스트, 개발 도구 재현용 설정을 각각 별도 .wsb 파일로 두면 어떤 통로가 열려 있는지 파일 이름만 보고도 알 수 있어요. 설정 파일 자체도 실행 전에 메모장으로 읽어 보세요.

실패했을 때 되돌리는 법

• Sandbox가 네트워크에 접근하면 Networking 값을 Disable로 바꾸고 다시 실행해요.
• 호스트 파일이 수정됐다면 공유 폴더의 ReadOnly가 true인지 확인해요.
• Sandbox 안에서 만든 파일은 종료 전에 검사하고, 필요 없는 결과는 복사하지 않아요.
• 설정이 꼬였으면 새 .wsb 파일을 만들고 자동 시작 명령을 빼고 다시 시험해요.
• Windows Home에서는 Windows Sandbox가 지원되지 않으므로 에디션 요구사항을 먼저 확인해요.[3]

Windows 이벤트 로그를 함께 봐야 하는 문제라면 PowerShell과 wevtutil로 이벤트 로그 원인을 좁히는 글을 이어서 참고할 수 있어요. 가상 네트워크 구조 자체가 헷갈리면 Hyper-V 가상 스위치 비교가 도움이 돼요.

출처

1. Use and configure Windows Sandbox | Microsoft Learn [1]
2. Windows Sandbox sample configuration files | Microsoft Learn [2]
3. Windows Sandbox | Microsoft Learn [3]