학습 모드를 사용하여 MXC 정책 만들기 및 구체화

Microsoft MXC(실행 컨테이너) 샌드박스는 기본 거부(deny-by-default) 방식이므로 포함된 워크로드는 정책에서 부여하는 파일, 기능 및 기타 리소스만 사용할 수 있습니다.

그러나 워크로드가 액세스해야 하는 모든 리소스를 예측하기 어려울 수 있습니다. MXC 학습 모드를 사용하면 워크로드가 액세스하려는 리소스를 기록하여 Windows에서 최소 권한 정책을 만들 수 있으므로 시행착오 대신 증거를 바탕으로 정책을 만들거나 구체화할 수 있습니다.

비고

학습 모드는 현재 Windows의 MXC ProcessContainer에서 실행되는 워크로드에 사용할 수 있습니다. 런타임 탐지를 사용하여 호스트에서 ProcessContainer 지원을 확인합니다.

학습 모드 동작 선택

학습 모드에는 두 가지 동작이 있습니다. MXC가 액세스를 기록하는 동안 정책을 계속 적용할지 여부에 따라 각 항목을 사용해야 하는 사용자와 시기가 결정됩니다.

특성 거부 및 기록하기 허용 및 기록하기
권한이 부여되지 않은 액세스 차단 및 기록됨 허용 및 기록됨
정책 적용 적용되지만 캡처는 격리 계층을 변경할 수 있습니다. 실행에 대해 기본 거부가 완화됨
일반 사용자 앱 개발자 및 정책 작성자 기존 워크로드를 평가하는 IT 관리자 및 개발자
사용 시기 앱 및 해당 정책을 개발하는 동안 정책이 존재하기 전에 신뢰할 수 있는 워크로드가 액세스하는 내용 알아보기
캡처 mode 값 block(기본값) allow

거부 및 기록: 앱 및 정책 개발하기

앱 또는 에이전트와 해당 MXC 정책을 개발하는 동안 deny and record(learningModeLogging)를 사용합니다. MXC는 기록하는 동안 정책을 계속 적용하므로 사용자와 마찬가지로 권한이 부여되지 않은 액세스가 실패합니다. 학습 모드는 정책이 차단한 각 액세스에 대한 기록을 추가합니다. 일부 호스트에서 캡처는 MXC가 선택하는 격리 계층을 변경합니다. 자세한 내용은 캡처 필수 구성 요소에 대한 계획을 참조하세요.

일반적인 용도는 다음과 같습니다.

  • 포함된 워크로드가 실패하는 이유를 진단하고 권한 누락을 관련 없는 오류와 구분합니다.
  • 지원되는 시나리오가 성공하고 부정적인 테스트가 계속 실패할 때까지 초안 정책을 수정해 갑니다.
  • 워크로드가 요청하는 기능을 식별합니다.
  • 앱 사용자가 자신의 샌드박스를 조정하도록 합니다. 앱은 차단된 내용을 기록하고, 자체 UI에 표시하고, 사용자가 변경 내용을 승인한 후에만 정책을 다시 생성합니다.

MXC는 정책을 계속 적용하기 때문에 거부 및 기록이 더 안전한 선택입니다. 테스트할 정책이 있을 때마다, 불완전한 정책이라도 그것을 사용하세요.

허용 및 기록: 정책을 만들기 전에 기존 워크로드를 평가하세요

MXC 정책을 적용하기 전에 신뢰할 수 있는 기존 워크로드가 액세스하는 항목을 알아야 하는 경우 허용 및 기록(permissiveLearningMode)을 사용하세요. 예를 들어 IT 관리자는 테스트 디바이스에서 일반적인 작업을 통해 업무용 도구 또는 스크립트를 실행한 다음, 결과를 사용하여 적용을 켜기 전에 기준 정책을 만들 수 있습니다. 기존 도구를 MXC로 가져오는 개발자는 동일한 접근 방식을 사용하여 첫 번째 정책 초안을 작성할 수 있습니다.

허용 및 기록은 실행에 대한 기본 거부 적용을 완화하므로 워크로드가 사용자의 전체 권한으로 실행되는 것처럼 처리합니다. MXC는 정책에 의해 거부되었을 각 액세스를 기록합니다. 이 모드가 활성화될 때마다 MXC는 실행 결과와 함께 보안 경고도 반환합니다. 호스트는 삭제하지 않고 해당 경고를 표시해야 합니다.

허용 및 기록을 사용하기 전에 다음을 수행합니다.

  • 제어된 테스트 디바이스 또는 계정에서 대표성이 있는 비민감 데이터로 신뢰할 수 있는 코드만 실행합니다.
  • 워크로드의 일반적인 작업을 수행해 봅니다. 실행에서 사용되지 않은 액세스는 결과에 표시되지 않습니다.
  • 결과를 초기 인벤토리로 처리합니다. 불필요한 권한 부여를 제거한 다음 배포하기 전에 거부 및 기록 모드에서 초안 정책을 확인합니다.

중요합니다

허용 및 기록 학습 모드를 에이전트 호출 가능 프로덕션 도구로 노출하지 마세요. 신뢰할 수 있는 호스트 코드 또는 개인은 해당 사용 및 그로 인한 사용 권한 확장을 승인해야 합니다.

캡처를 위한 사전 요구 사항 계획

MXC는 두 캡처 경로 중 하나를 통해 학습 모드 결과를 수집합니다. 호스트 및 요청된 정책에 따라 런타임에 경로를 선택합니다. 이는 어느 모드에서든 wxc-exec.exe --audit 및 captureDenials 워크플로에 적용됩니다.

캡처 경로 MXC가 이를 사용할 때 격리 계층 고도
네이티브 캡처 Windows는 MXC에 필요한 프로세스 보안 환경 및 학습 모드 API를 제공하며 요청된 정책을 나타낼 수 있습니다. BaseContainer None
보호된 캡처 네이티브 캡처를 사용할 수 없거나 요청된 정책을 나타낼 수 없습니다. 호환되는 AppContainer 계층 MXC는 서명된 도우미plm.exe를 시작하고 권한 상승으로 WPR(Windows 성능 레코더) 추적을 기록합니다. 사용자는 UAC 프롬프트를 승인하거나 관리자 자격 증명을 제공해야 합니다.

네이티브 캡처는 processContainer.leastPrivilege, 일부 네트워크 프록시 구성, 그리고 기본적으로 지원하지 않는 호스트의 거부된 경로와 같은 일부 정책을 나타낼 수 없습니다. 이러한 요청은 네이티브 캡처를 지원하는 호스트에서도 보호된 캡처를 사용합니다. 두 경로 모두 전체 정책을 유지할 수 없는 경우 MXC는 정책을 약화시키거나 캡처를 건너뛰는 대신 오류를 반환합니다.

요청이 사용할 경로를 확인하려면 시작하기 전에 캡처를 사용하도록 설정한 상태에서 요청을 프로브합니다. 프로브는 컨테이너를 만들지 않습니다.

SDK Call 확인할 결과
.NET MxcContainer.Probe(request) Tier, Probes.NativeCaptureAvailable, Probes.GuardedCaptureAvailable
TypeScript probe(request) tier, probes.nativeCaptureAvailable, probes.guardedCaptureAvailable
러스트 v1::probe(Some(&request)) tier, probes.native_capture_available, probes.guarded_capture_available

BaseContainer 계층은 네이티브 캡처를 의미합니다. AppContainer 계층은 보호된 캡처 및 권한 상승 프롬프트를 의미합니다. 네이티브 캡처 팩트에서는 요청이 아닌 호스트를 설명하므로 티어도 확인하세요.

이러한 차이점을 고려하세요:

  • 앱에서 캡처를 시작하기 전에 프로브하고, 캡처 시 관리자 승인이 필요한 경우 사용자에게 알리세요. 캡처가 모든 호스트에서 백그라운드로 실행된다고 가정하지 마세요.
  • IT 관리자가 워크로드를 평가할 때 테스트 디바이스가 네이티브 캡처를 지원하거나 관리자가 보호된 캡처 프롬프트를 승인할 수 있음을 확인하세요. AppContainer 계층에는 호스트 준비도 필요할 수 있습니다.
  • 캡처 결과를 정책 작성의 증거로 처리합니다. 보호된 캡처는 프로덕션과 다른 계층에서 워크로드를 실행할 수 있으므로 캡처를 사용하지 않는 실행으로 최종 정책을 확인하십시오.

예: MXC SDK를 통한 캡처 활성화

앱이 워크로드를 호스트할 때 SDK 캡처를 사용합니다. 호스트 코드를 작성하지 않고 워크로드를 평가하려면 명령줄에서 학습 모드 사용을 참조하세요.

거부된 쓰기 사례를 포함한 SDK 빠른 시작부터 먼저 살펴보세요. 다음 조각은 해당 예제를 확장하고 동일한 워크로드 및 리소스 부여를 사용합니다. SDK가 워크로드를 시작하기 직전에 선택한 조각을 삽입합니다.

이 예제에서는 MXC 1.0 V1 SDK API를 사용합니다. 각 SDK에서 빠른 시작의 추상 프로세스 의도를 대체하는 명시적 ProcessContainer containment 선택에 대한 캡처를 구성합니다.

캡처에 대한 호스트 소유 출력 디렉터리를 만듭니다. 포함된 워크로드에 쓰기 가능할 필요는 없습니다.

요청에 명시적으로 포함된 ProcessContainer에 대한 캡처 옵션을 설정합니다.

string captureDirectory = Path.GetFullPath("captures");
Directory.CreateDirectory(captureDirectory);

request.Containment = new Containment.ProcessContainer
{
    CaptureDenials = new CaptureDenialsPolicy
    {
        Mode = CaptureDenialsMode.Block,
        OutputPath = Path.Combine(captureDirectory, "denials.json"),
    },
};

block 모드에서는 거부된 쓰기 사례가 여전히 실패합니다. 거부를 캡처해도 쓰기가 부여되지 않습니다. 승인된 허용 및 기록 실행의 경우 모드만 C#에서는 CaptureDenialsMode.Allow, TypeScript에서는 'allow', Rust에서는 CaptureDenialsMode::Allow로 변경합니다.

기존 통합을 조정할 때는 다른 컨테인먼트 설정을 유지합니다. 예약된 내부 learningModeLogging 또는 permissiveLearningMode 기능 이름이 아닌 전용 캡처 옵션을 사용합니다.

완료된 캡처 찾기

결과를 읽기 전에 실행과 캡처 완료를 기다립니다. MXC는 구성된 파일 이름에 고유한 실행 식별자를 삽입하므로 denials.json은(는) denials.<run-id>.json과 같은 파일 이름이 됩니다. 추측하거나 가장 최근 파일을 검색하지 말고 보고된 경로를 사용합니다.

result.Warnings이 완료되고 MxcContainer.RunAsync(request)을(를) 보고한 후 결과 메타데이터를 검사합니다.

if (result.OutputMetadata?.CaptureDenialsError is { } captureError)
{
    Console.Error.WriteLine($"Denial capture failed: {captureError.Message}");
    return 1;
}

if (result.OutputMetadata?.CaptureDenials is not { } capture)
{
    Console.Error.WriteLine("The run did not produce denial capture metadata.");
    return 1;
}

Console.WriteLine($"Denial document: {capture.OutputPath}");
Console.WriteLine($"Unique denials: {capture.TotalDenials}");
if (capture.DeniedResourcesTruncated)
{
    Console.Error.WriteLine("The capture is incomplete; don't generate a policy from this run.");
    return 1;
}

빠른 시작의 종료 상태, 시간 제한 및 result.Warnings 처리를 유지하세요. 특히 .NET SDK는 터미널에 자동으로 쓰는 대신 허용 Learning Mode에 대한 경고를 표시합니다.

스트리밍 실행을 사용하는 경우 MxcProcess.OutputMetadata를 검사하기 전에 터미널 대기가 끝날 때까지 기다리세요. 대기하지 않고 프로세스를 종료하는 것은 캡처 종료를 대체하는 것이 아닙니다.

거부 결과 읽기

조치 가능한 JSON 문서는 리소스, 액세스 시도 및 요약을 식별합니다. 빠른 시작의 거부된 쓰기 사례의 경우 대표 항목은 다음과 같습니다.

{
  "denials": [
    {
      "resource": "C:\\src\\MxcQuickstart\\workspace\\input\\blocked.txt",
      "resourceType": "file",
      "accessType": "write",
      "pid": 1234,
      "filetime": "132847890123456789"
    }
  ],
  "summary": {
    "exitCode": 1,
    "totalDenials": 1,
    "deniedResourcesTruncated": false
  }
}

이 문서는 워크로드가 한 모든 작업의 철저한 로그가 아니라 정책 작성에 대한 증거입니다. resourceType 값은 resource를 읽는 방법을 결정합니다. 예를 들어 file 항목에는 절대 경로가 포함되고 capability 항목에는 internetClient와 같은 기능 이름이 포함됩니다. 일부 관찰은 정책 권한 부여로 표현할 수 없으며 단일 입력이 모든 코드 경로를 실행하지는 않습니다.

허용 모드에서 문서에는 현재 capability 요청이 포함되지 않습니다. deny 및 record 모드로 워크로드를 실행하여 필요한 기능을 식별합니다.

만약 true이 deniedResourcesTruncated이면, 해당 실행에서 정책을 생성하지 마세요. 빈 문서는 워크로드가 안전하거나 의도한 모든 제한이 적용되었음을 증명하지도 않습니다.

MXC는 실행 가능한 문서 옆에 상세 로그 파일도 작성합니다. 예를 들어 denials.<run-id>.json는 denials.<run-id>.verbose.json을 생성합니다. 자세한 정보 표시 파일은 레지스트리 쓰기와 같이 MXC 정책이 수행할 수 없는 관찰을 포함하는 제한된 편집 처리된 진단 레코드입니다. 출력 메타데이터는 해당 경로를 보고하지 않으므로 실행 가능한 문서의 경로에서 파생하세요. 상세 로그 파일은 실행 가능한 문서에서 설명하지 않는 실패를 조사하는 데 사용하고, 권한 목록으로 사용하지 마십시오.

다른 실패와 거부를 구분하세요

결과 무엇을 해야 할지
MXC가 구성을 거부합니다. 스키마, 필드 조합 및 선택한 백 엔드를 확인합니다. 잘못된 요청을 해결하기 위해 더 많은 액세스 권한을 부여하지 마세요.
백엔드 또는 캡처 기능을 사용할 수 없습니다 지원 정보를 검사하고 사전 요구 사항을 확인합니다. 필요한 제한을 알림 없이 사용하지 않도록 설정하지 마세요.
강제 적용 중 워크로드가 실패합니다 종료 상태, 오류 출력 및 완료된 거부 기록을 검토합니다. 워크로드 실패가 반드시 리소스 거부를 의미하는 것은 아닙니다.
캡처가 실패하거나 불완전함 워크로드가 성공적으로 종료된 경우에도 증거를 사용할 수 없거나 불완전한 것으로 처리합니다.

구조적 캡처는 조치 가능한 문서를 수집합니다. 하위 수준 ProcessContainer learningMode 설정을 사용하면 거부 및 기록 이벤트를 기록할 수 있지만 자체적으로 이 문서를 수집하지는 않습니다. 호스트가 증거를 수집해야 하는 경우 캡처를 사용합니다.

감지된 액세스 검토

정책을 변경하기 전에 각 결과를 분류하세요. 다음은 그 예입니다.

찾는 중 잠재적인 조치
필수 입력 파일 이를 포함하는 가장 좁은 읽기 전용 경로를 추가합니다.
필요한 출력 또는 캐시 작업별 읽기-쓰기 경로 추가
자격 증명 또는 관련이 없는 사용자 파일 거부된 상태로 유지하고 필요한 경우 워크로드를 변경하세요.
상위 범위의 부모 디렉터리 부모에게 권한을 부여하는 대신 필요한 자식 경로를 식별합니다.
예기치 않은 네트워크, UI 또는 기능 요청 액세스 권한을 부여하기 전에 워크로드에 왜 그것이 필요한지 확인
MXC가 정책에서 표현할 수 없는 리소스 워크로드를 변경하거나 요구 사항을 강제할 수 있는 백엔드를 선택합니다.

관찰된 액세스는 시작, 디스커버리, 선택적 기능, 오류 처리 또는 한 번의 실행에서 사용되는 특정 입력에서 발생할 수 있습니다. 모든 요청이 필요하다고 가정하지 마세요. 빠른 시작의 부정 테스트에서 거부된 쓰기는 누락된 권한이 아니라 의도한 결과입니다.

예: 명령줄에서 학습 모드 사용

호스트 코드를 작성하지 않고 워크로드를 평가하려면 wxc-exec.exe 명령줄 도구와 JSON 구성을 사용하여 워크로드를 실행합니다. 구성 형식은 MXC 정책 작성 및 유효성 검사를 참조하세요.

MXC SDK 패키지를 설치해도 PATH이(가) wxc-exec.exe에 추가되지는 않습니다. SDK 버전과 일치하는 mxc-release-binaries.zip에서 를 다운로드하고 전체 경로로 도구를 실행합니다. 다음 예제에서는 C:\Tools\Mxc에 보관 파일을 추출하고 x64 폴더를 사용한다고 가정합니다. Arm64 디바이스에서 arm64 폴더를 사용합니다.

두 동작 방식 중 하나를 사용하여 캡처

ProcessContainer 포함 관계를 선택하고 구성의 captureDenials 섹션에 processContainer를 추가합니다. 예를 들어 정책이 없는 워크로드를 평가하는 IT 관리자는 모드 allow:를 사용할 수 있습니다.

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "processcontainer",
  "process": {
    "commandLine": "C:\\Tools\\Contoso\\ReportTool.exe"
  },
  "processContainer": {
    "captureDenials": {
      "mode": "allow",
      "outputPath": "C:\\MxcAudit\\denials.json"
    }
  }
}

실행하기 전에 출력 디렉터리를 만든 다음, 구성 파일을 도구에 전달합니다.

C:\Tools\Mxc\x64\wxc-exec.exe audit-config.json

실행 후 wxc-exec는 실제 출력 경로와 요약이 포함된 JSON 한 줄을 표준 오류에 씁니다.

{"type":"captureDenials","outputPath":"C:\\MxcAudit\\denials.<run-id>.json","exitCode":0,"totalDenials":2,"deniedResourcesTruncated":false}

보고된 경로를 사용하여 문서를 읽습니다. 적용 중인 초안 정책을 확인하려면 구성에 권한 부여를 추가하고 모드를 block로 변경합니다.

조정된 구성을 제안

개발자 기반 정책 작성의 경우 감사 워크플로는 허용 및 기록 캡처를 실행하고 수정된 구성을 제안합니다.

C:\Tools\Mxc\x64\wxc-exec.exe --audit --config <path-to-config>

감사 워크플로는 거부 문서, 추적 파일, 원본 구성의 스냅샷 및 관찰된 액세스를 해당 구성에 병합하는 Adjusted_*.json 파일을 씁니다. 조정된 구성은 승인된 정책이 아니라 검토를 위한 제안입니다. MXC는 캡처가 잘리면 생성되지 않으며 SDK 캡처는 전혀 생성하지 않습니다.

감사 워크플로는 ProcessContainer만 지원합니다. processContainer.captureDenials를 명시적 --audit 설정과 결합하지 마세요. 전체 CLI 및 SDK 사양은 GitHub의 학습 모드 기능을 참조하세요.

학습 루프를 완료하세요

이 워크플로를 사용하여 탐지에서 강제 적용 정책으로 이동합니다.

  1. 학습 모드를 사용하도록 설정하기 전에 격리 모델을 선택합니다.
  2. 워크로드에 아직 정책이 없고 좁은 정책을 직접 작성할 수 없는 경우 제어된 환경에서 allow and record 모드를 사용하여 실행합니다. 기본 작업을 수행합니다.
  3. 증거를 바탕으로 좁은 정책 초안을 작성하고 광범위하고 관련이 없는 권한 부여를 제거합니다.
  4. 거부 및 기록을 사용하여 초안 정책에 따라 워크로드를 실행하고 필요한 기능을 포함하여 나머지 거부를 해결합니다.
  5. 대표적인 성공, 실패 및 경계 사례 입력으로 반복합니다.
  6. 모든 학습, 캡처 및 감사 설정을 제거하고 최종 강제 적용 테스트를 실행합니다. 캡처는 MXC가 선택하는 격리 계층을 변경할 수 있으므로 이 실행은 프로덕션 환경에서 정책이 작동하는 방식을 확인합니다.

지원되는 워크로드가 성공하고 부정적인 테스트가 의도한 대로 계속 실패하는 경우 액세스를 더 이상 확장하지 마세요.

코딩 에이전트는 관찰을 설명하는 데 도움이 될 수 있지만 리소스 액세스 정책의 변경 내용을 검토하고 승인해야 합니다.