Microsoft가 10월 7일 Microsoft Execution Containers(MXC)를 정식 출시했다. 에이전트가 스스로 권한을 통제하게 두지 않고, 개발자나 조직이 정한 정책을 에이전트 바깥에서 집행하는 실행 경계다.
MXC에는 세 가지 모드가 있다. 집행(Enforcement) 모드는 허용되지 않은 접근을 막고, 학습(Learning) 모드는 막으면서 기록하며, 허용(Permissive) 모드는 허용하면서 기록한다.
학습·허용 모드가 남기는 JSON 활동 보고서는 Windows의 MXC 프로세스 컨테이너에서만 만들어진다.
세 모드가 답하는 서로 다른 질문
집행 모드는 정책상 이 작업이 허용되는지를 확인한다. 학습 모드는 권한을 바로 늘리지 않고 정상 작업이 왜 실패했는지 보여 준다.
허용 모드는 정책이 막지 않았다면 작업이 무엇을 시도했는지를 보여 준다. 그 기록이 있다는 사실이 해당 동작이 격리됐다는 뜻은 아니다.
코딩 작업이라면 수정할 저장소, 읽기만 필요한 설정, 접근하면 안 되는 무관한 파일을 나눠 정책을 검토할 수 있다. 의존성 내려받기, 컴파일러 호출, 하위 프로세스 실행은 각각 필요한 접근이 다르다.
주의할 점: 허용 학습 모드의 완화된 격리
MXC 저장소 문서에 따르면 허용 학습 모드(permissiveLearningMode)는 실행 동안 기본 거부를 집행하지 않는다. 그래서 보안에 민감한 기능으로 분류되고, 켜질 때마다 보안 경고가 남는다.
반면 학습 모드의 거부 기록(learningModeLogging)은 접근을 계속 막으므로 격리 수준이 바뀌지 않는다. 발표는 허용 모드도 운영체제나 조직의 다른 제한까지 우회하지는 않는다고 설명한다.
학습 모드 기능은 Windows 전용이며 AppContainer 기반 백엔드에만 적용되고, 다른 플랫폼에서는 무시된다. 이 문서는 변경될 수 있는 main 브랜치 기준으로 읽었고, 고정된 실행 파일을 시험하지는 않았다.
탐색과 실제 허용을 나누는 도입 순서
권한을 파악하는 단계에서는 신뢰할 수 있고 범위가 좁은 작업만 실행한다. 관찰된 접근을 모두 허용 목록에 옮기지 않고, 각각이 작업에 필요한지 검토한다.
예상하지 못한 접근은 권한을 줄 이유가 아니라 작업을 조사할 이유일 수 있다.
그다음 의도한 정책을 집행 모드로 돌려 양쪽을 확인한다. 확인 대상은 필요한 작업이 성공하는지, 의도적으로 금지한 동작이 계속 거부되는지다.
이는 권장하는 점검 순서이며 여기서 MXC를 시험한 결과는 아니다. 정책 버전과 백엔드를 결과와 함께 남기면 나중의 변경도 같은 경계에 비춰 검토할 수 있다.
플랫폼마다 다른 격리 백엔드
Microsoft는 프로세스 컨테이너에 Windows의 AppContainer, macOS의 Seatbelt, Linux의 Bubblewrap을 쓴다고 설명한다. Windows 11과 Linux용 MicroVM은 실험 단계이며, 백엔드마다 보안 특성이 다르다.
Entra 기반 에이전트 구분과 Intune 정책 관리는 곧 제공될 기능으로 소개됐다. 이번 발표만으로 지금 쓸 수 있다고 볼 수는 없다.
MXC의 허용 모드 기록은 필요한 권한의 후보 목록일 뿐이고, 경계는 집행 모드에서 다시 확인할 때 비로소 증명된다.