Mxc: Microsoft Execution Containers 버전 1.0.0
요약
Microsoft Execution Containers (MXC)는 Windows 11 25H2 업데이트를 기반으로, 관리자 권한 없이 AppContainer를 구성할 수 있게 함으로써 기업 환경의 보안 강화에 기여합니다. 이는 에이전트가 시스템을 오염시키는 것을 막고, 앱 실행 시 읽기/쓰기를 특정 디렉터리로 제한하는 등 근본적인 보안 설계가 필요함을 강조합니다.
핵심 포인트
- MXC는 관리자 권한 없이 AppContainer 구성을 가능하게 하는 큰 진전입니다.
- 에이전트의 무분별한 행동을 막으려면, 개발자나 조직이 강제하는 명확한 실행 경계가 필수적입니다.
- 기존 OS 앱들은 최소 권한 원칙 적용이 미흡하며 근본적인 보안 설계 개선이 필요합니다.
드디어 bubblewrap에 대응하는 도구가 나온 건 반갑지만, 업계의 권한 관리는 오래전부터 형편없었고 이것만으로 해결되지는 않음. 리소스를 읽기 전용으로 제공한다고 해도 JIRA에 연결하는 순간 다른 신원 체계와 리소스 모델이 끼어들며 복잡성이 폭증함. 보안 모델을 계속 복잡하게 만드는 접근은 효과가 없음. 결국 사고가 나면 “보안 설정을 제대로 하지 않았다”라고 책임을 돌릴 뿐인데, 올바른 설정을 설명하기도 어렵고 실제 구성은 더 어려움. 도구 자체는 좋아 보이지만, 통제를 벗어난 에이전트로부터 보호받으려면 보안을 근본부터 다시 설계해야 함.
Microsoft 보안은 양극단으로 나뉨. Sharepoint나 Azure의 네트워크 리소스는 권한을 정교하게 구분할지 몰라도, 소비자용 애플리케이션은 형편없음.
Excel, VSCode, Outlook 등의 권한 모델은 “Do you trust this?”라는 대화상자에서 예·아니요를 선택해 모든 권한을 한꺼번에 허용하는 수준임.
모바일 기기는 일부 측면에서 더 잘하고 있지만, 최소 권한을 기본값으로 삼는 표준화된 체계가 필요함. 지금보다 훨씬 덜 혼란스러워야 함.
백엔드별 동작 문서를 훑어보니, 프로젝트 거의 전체를 최신 세대 LLM이 만든 듯함. “용도에 맞게 깔끔하고 안전한 설계를 하라”가 아니라 “무슨 수를 써서라도 작동하게 하라”로 지시를 해석한 결과처럼 보임.
bubblewrap 통합 문서조차 의식의 흐름대로 쏟아낸 글에 가까워 결과물을 거의 신뢰할 수 없음.
거의 같은 다른 게시물에 썼던 내용을 다시 올림: https://news.ycombinator.com/item?id=50026061.
가장 크고 반가운 소식은 Windows 11 25H2의 8월 누적 업데이트부터 누구나 관리자 권한 없이 AppContainer를 구성할 수 있게 됐다는 것임. mxc는 그 위에 구축됨.
아직 불확실하고 불안정하며 개선할 부분도 많지만, 새로운 가능성을 탐색할 수 있게 하는 첫걸음임.
기업 환경에서는 엄청난 변화임. 지금은 사용자에게 ChatGPT 데스크톱의 Windows 샌드박스를 설정해 주기가 꽤 번거로움. agent365를 통한 Intune 및 신원 관리 연동도 예정되어 있다는 점이 또 다른 큰 소식임.
앱의 읽기·쓰기를 특정 디렉터리로만 제한하는 아주 간단한 방법이 필요함. 20년도 더 전에 나왔어야 할 유용한 기능인데 왜 아직 보편적으로 쓸 수 없는지 모르겠음. 사용자에게도 매우 쉬운 방식으로 보안 문제 대부분을 즉시 해결할 수 있을 것임.
MXC가 이 기능을 제공하는 것 같지는 않은데, 아니라면 알려주면 좋겠음!
MXC로 임의의 실행 파일을 실행할 수 있지만, 백엔드마다 보안 보장 수준이 다름. Windows의 LPAC 같은 백엔드에서는 PowerShell을 비롯한 여러 실행 파일이 시작 단계부터 실패함.
에이전트가 자기 자신의 보안 권한을 결정해서는 안 되고, 개발자나 조직이 정한 경계를 외부에서 강제해야 한다는 뜻이라면, 인간 사용자와 구분되는 별도의 보안 주체로 만들면 되는 것 아닌가?
실행 경계가 없으면 에이전트가 서버 설정 변경을 가장 빠른 해결책으로 판단해 운영 사이트를 망가뜨릴 수 있다고 하는데, 경계가 있어도 그런 판단은 할 수 있음. 핵심은 그 판단을 실제 행동으로 옮길 수 있느냐임. 전반적으로 발표문이 매우 허술하게 작성됨.
별도의 보안 주체를 만들자는 접근은 보안 컨텍스트의 존재를 전제로 하며, 이 제품이 바로 그것을 제공함. 그게 없다면 보안 주체를 어디에서 설정할 것인가?
이걸 일반 앱의 권한 경계로 사용할 수 있는지, 아니면 어떻게든 “에이전트”인 척해야 하는지 궁금함. 음악 플레이어가 SSH 키 등을 읽지 못하도록 제한하는 기능은 진작 필요했음.
당연히 기업 고객 전용으로 묶일 것 같음. 일반 사용자는 최상위 라이선스 비용을 내지 않으면 더 나은 보안도 얻지 못하는 셈임.
나도 주로 Linux에서 에이전트를 신뢰하지 않는 사용자 계정으로 실행해 제한하고 있음. Docker의 격리 경계도 그리 훌륭하지 않기 때문임. Firecracker는 오래된 기술이지만 유용하고, 올바른 방향으로 나아가는 도구임.
에이전트별로 구체적인 접근 권한을 부여할 수 있는 로컬 HashiCorp Vault 같은 도구가 정말 필요함. 이런 접근 경계를 검토하고 관리하는 데는 끝없이 시간이 들 수 있음.
그렇다면 Mac을 사면 될 듯함.
제한하면 좋을 작업이 많으며, npm install이 바로 떠오름. 개발 컨테이너와 통합해서 더 강한 격리 환경에서 실행할 수 있을지 궁금함.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기