MXC 정책 작성 및 검증

MXC 정책은 워크로드가 무엇에 액세스할 수 있는지 설명합니다. 기본 거부(deny-by-default) 권한 설정으로 시작하고, 특정 작업에 필요한 리소스만 추가하고, 앱이 지원하는 모든 플랫폼에서 대표 입력으로 결과의 유효성을 검사합니다. 각 백엔드는 워크로드를 시작하는 데 필요한 운영 체제 리소스도 제공합니다. 기본 거부(deny-by-default)는 프로세스가 시스템 환경 없이 실행됨을 의미하지는 않습니다.

신뢰할 수 있는 앱 코드에서 정책 결정을 처리합니다. 도구, 플러그인, 스크립트 또는 AI 생성 명령은 필요한 항목을 보고할 수 있지만 자체 격리 모델을 선택하거나 자체 액세스를 확장해서는 안 됩니다.

정책 및 구성 이해

MXC는 명령을 실행하는 설정과 리소스 권한을 구분합니다.

정책 설정은 읽기 가능한 경로, 쓰기 가능한 경로, 네트워크 대상, UI 액세스 및 시간 제한과 같은 크로스 플랫폼 동작 의도를 설명합니다.
실행 설정은 명령, 작업 디렉터리, 환경 및 컨테이너 선택을 추가합니다.

V1 SDK ContainerRequest에서는 둘 다 포함합니다. .NET에서 명령으로 ContainerRequest를 만들고, 해당 정책 및 실행 속성을 설정한 다음 MxcContainer.RunAsync 또는 spawn API를 호출합니다. TypeScript에서 ContainerRequest 개체를 run 또는 spawn 함수에 전달합니다. Rust에서 ContainerRequest 구조체를 빌드하고 이를 v1::run 또는 spawn 함수에 전달합니다. 워크로드에 특정 백엔드가 필요한 경우가 아니면 추상 Process 포함 의도를 선호합니다.

다음 언어 중립적 정책 설정은 리포지토리 범위 작업을 설명합니다. TypeScript ContainerRequest 속성 이름을 사용합니다. .NET은 ReadonlyPaths와 같은 PascalCase 이름으로 동일한 구조를 사용하며 Rust는 readonly_paths와 같은 snake_case 이름을 사용합니다. 완전한 요청이 아닙니다. 명령을 포함하지 않거나 백엔드를 선택하지 않습니다. 디렉터리를 만들고 적용하기 전에 경로를 바꿉니다.

{
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app"],
    "readwritePaths": ["C:\\src\\mxc-output"],
    "deniedPaths": ["C:\\src\\my-app\\.env"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "allowInputInjection": false
  },
  "timeoutMs": 30000
}

요청 속성을 원시 실행 구성으로 복사하는 대신 SDK 형식을 사용합니다. 형태가 다릅니다. 예를 들어 요청의 timeoutMs는 구성의 process.timeout에 매핑되고, ui.allowInputInjection는 ui.injection에 매핑되며, network.runtimeConfig는 최상위 runtimeConfig 섹션에 매핑됩니다. 전체 C#, TypeScript 및 Rust 예제는 SDK 빠른 시작을 참조하세요.

호환되는 스키마 선택

다음 세 가지 질문을 별도로 유지하세요:

호환성 축	확인할 사항
SDK 및 제품 릴리스	패키지가 제공하는 API 및 런타임 구성 요소
정책 스키마	릴리스가 허용하는 정확한 구성 계약
호스트 기능	선택한 환경이 런타임에 적용할 수 있는 제한 사항은 무엇입니까?

MXC 1.0 V1 SDK는 내부적으로 안정적인 1.0.0 스키마를 사용하므로 스키마 버전을 ContainerRequest지정하지 않습니다. 스키마 버전은 예를 들어 wxc-exec 명령줄 도구용 파일과 같은 원시 JSON 실행 구성을 작성하는 경우에만 적용됩니다.

원시 구성은 정확히 등록된 version을 지정해야 합니다. MXC 1.0은 0.9.0-alpha, 현재 안정적인 스키마, 및 1.0.0, 지원되는 최소 스키마를 허용합니다. MXC는 누락된 버전, 0.9.0-alpha보다 이전의 사용 중지된 버전(예: 0.8.0-alpha) 및 등록되지 않은 맞춤법(예: 1.0 또는 1.0.1)을 거부합니다. 1.1.0-alpha 개발용 계약은 게시하기 전에 변경될 수 있으므로 프로덕션 구성에 사용하지 마세요. 이 옵션을 선택해도 실험적 백엔드를 사용하도록 허용하지 않습니다.

동일한 릴리스에서 SDK 및 네이티브 런타임 구성 요소를 함께 유지하세요. 등록된 계약에 대한 MXC 스키마 버전 지정 을 참조하세요.

파일 액세스 범위 지정

워크로드에서 사용하는 방식을 따라 각 경로를 분류합니다.

액세스	다음 용도로 사용
읽기 전용	워크로드가 검사해야 하지만 변경해서는 안 되는 원본, 도구, 라이브러리 및 구성
읽기/쓰기	작업별 출력, 캐시 또는 임시 디렉터리
거부됨	자격 증명, 관련이 없는 리포지토리, 민감한 구성 정보 및 더 넓은 권한 범위 내의 좁은 경로

가장 실용적인 최소 경로를 부여합니다. 예를 들어 명령이 테스트 출력만 작성할 때 리포지토리 루트 대신 테스트 결과 디렉터리를 지정합니다. 환경 변수, 패키지 관리자 또는 도구 검색에서 검색된 경로를 자동 부여가 아닌 검토 후보로 처리합니다.

워크로드에 실제로 필요한 도구 이진 파일, 라이브러리, 구성 및 임시 경로를 포함합니다. SDK들은 파일 시스템 검색/발견 헬퍼를 제공하지만 결과는 승인된 정책이 아닙니다. 추가하기 전에 각 후보 경로를 검토합니다.

작업 디렉터리를 설정해도 해당 디렉터리에 대한 액세스 권한이 부여되지 않습니다. 해당 파일 시스템 목록에 명시적으로 추가합니다.

선택한 백 엔드를 사용하여 테스트하지 않는 한 겹치는 경로 규칙에 의존하지 마십시오. 백 엔드는 다른 파일 액세스 메커니즘을 사용하며 일부는 매핑되거나 탑재된 디렉터리 내에서 거부 규칙을 나타낼 수 없습니다.

네트워크 액세스 제어

태스크에 필요한 경우가 아니면 네트워크 액세스가 거부된 상태로 유지합니다. 선택한 백엔드가 적용할 수 있는 네트워크 모델을 선택합니다.

모델	다음 용도로 사용
외부 액세스 없음	부여된 로컬 리소스만 필요한 분석 또는 변환
IP/CIDR, 프로토콜 및 포트 규칙을 통한 직접 액세스	알려진 서비스 엔드포인트에 대한 TCP와 같은 특정 직접 연결이 필요한 작업
애플리케이션에서 제공하는 프록시를 통한 HTTP(S)	대상 또는 애플리케이션 수준 권한을 프록시가 제어하는 요청

방향성 네트워크 정책은 다음을 구분합니다.

워크로드에서 네트워크 대상으로 송신
프라이빗 또는 로컬 네트워크에서 워크로드의 리스너로의 인그레스
호스트의 워크로드와 서비스 간 양방향 호스트 루프백.

IP/CIDR 및 포트 규칙은 애플리케이션 프로토콜 또는 호스트 이름을 식별하지 않습니다. TCP 포트 443을 허용해도 연결이 HTTPS를 사용하거나 하나의 지정된 서비스에만 연결된다는 것을 의미하지 않습니다. DNS 요청은 워크로드가 대상 주소를 직접 조회할 때도 액세스가 필요할 수도 있습니다.

지원되는 스키마는 사용 중지된 네트워크 필드(예: defaultPolicy, allowedHostsblockedHosts및 network.proxy)를 거부합니다. 대신 방향 egress 및 ingress 필드를 사용합니다. 네트워크 정책 예제를 참조하세요.

사용자 지정 네트워크 프록시 사용

호스트 앱은 워크로드를 시작하기 전에 프록시를 제공하고 시작합니다. MXC는 프로덕션 프록시를 제공하거나 관리하지 않습니다. 프록시는 허용할 요청 및 대상을 결정합니다. MXC는 지원되는 클라이언트가 이를 사용하도록 구성하고 백 엔드의 네트워크 제한을 적용합니다.

방향 요청은 네트워크 섹션의 runtimeConfig.networkProxy 설정을 사용하여 명시적 포트가 있는 HTTP(S) 루프백 엔드포인트를 식별합니다. 원시 실행 구성에서 이 설정은 최상위 수준 runtimeConfig.networkProxy입니다. 이 엔드포인트는 애플리케이션 계층 허용 목록이 아닌 런타임 구성입니다. 프록시 모드에는 기본 거부 송신이 필요하며 직접 송신 허용 또는 거부 규칙과 결합할 수 없습니다.

클라이언트 라우팅 및 강제 적용은 다릅니다. 프록시 환경 변수 또는 플랫폼 설정은 프록시를 지원하는 HTTP 클라이언트에게 요청을 보낼 위치를 알려줍니다. 프록시 전용 적용 경로는 직접 인터넷 연결도 차단해야 합니다. 협력형 프록시 구성만으로는 그러한 제한을 보장하지 않습니다.

MXC는 HTTP(S) 프록시를 통해 SSH, 임의 TCP/UDP 또는 기타 비 HTTP 프로토콜을 투명하게 리디렉션하지 않습니다. 호스트 루프백 및 프라이빗 네트워크 동작도 백 엔드에 따라 다릅니다. 모든 위치에서 동일한 구성 조각이 작동한다고 가정하는 대신 사용자 지정 프록시 구성 예제 및 해당 필수 구성 요소를 검토합니다.

UI 액세스 제한하기

기본적으로 백그라운드 워크로드가 창을 만들거나, 클립보드를 읽거나 쓰거나, 키보드 및 포인터 입력을 삽입하도록 허용하지 않습니다. 워크로드의 의도된 사용자 경험의 일부인 경우에만 UI 액세스를 추가합니다.

입력 주입은 다른 프로세스에 임의 코드 삽입이 아니라 합성 키보드 또는 포인터 입력을 의미합니다.

UI 컨트롤은 호스트 및 백 엔드에 종속됩니다. 런타임 지원 정보를 사용하여 보안 디자인에 필요한 각 제한을 확인하십시오.

바운드 실행

알려진 기간 내에 완료해야 하는 모든 에이전트 작업, 도구 호출 또는 스크립트에 대한 시간 제한을 설정합니다. 프로세스에 필요한 환경 변수만 제공하고, 프로세스 환경과 읽을 수 있는 파일 경로 모두에 비밀 정보를 두지 않습니다. 환경을 생략한다고 해서 빈 환경이 생성된다고 가정하지 마세요. 백엔드 기본값과 SDK 상속 옵션은 서로 다릅니다.

작업과 일치하는 수명 주기를 선택합니다. 독립 명령에 대해 원샷 실행을 선호합니다. 명령이 설치된 도구, ID, 파일 또는 운영 체제 상태를 공유해야 하는 경우에만 상태 인식 샌드박스를 사용합니다.

유효 정책 검사

정책을 게시하기 전에 다음을 수행합니다.

SDK의 런타임 검색 을 사용하고 선택한 백 엔드의 필수 구성 요소를 확인합니다.
정책을 약화시키지 않고 구성을 만들고 정책 유효성 검사 또는 백엔드 사용 불가 오류를 처리합니다.
워크로드에서 사용해야 하는 리소스를 사용하여 대표적인 정상 동작 사례를 실행합니다.
비밀을 읽거나, 출력 디렉터리 외부에서 쓰거나, 승인되지 않은 네트워크 경로를 사용하거나, 허용되지 않는 UI에 액세스하려고 시도하는 부정 사례를 실행합니다.
학습 모드를 사용하여 누락된 액세스를 조사하고 정책을 변경하기 전에 각 결과를 검토합니다.
모든 학습 또는 감사 설정을 제거하고 최종 강제 적용 테스트를 실행합니다.

호스트가 필요한 컨트롤을 적용할 수 없는 경우 실패합니다. 더 광범위한 액세스 권한이 있는 백 엔드를 자동으로 선택하거나 정책 필드를 제거하여 워크로드를 실행하지 마세요. 구문 분석이나 실행이 성공했다고 해서 모든 의도된 제한이 적용된다는 증거는 아닙니다.

피드백

이 페이지가 도움이 되었나요?

2026-10-27 에 마지막으로 업데이트됨