学習モードを使用して MXC ポリシーを作成および調整する

Microsoft Execution Containers (MXC) のサンドボックスは既定ですべてのアクセスを拒否する方式を採用しているため、サンドボックス内のワークロードが使用できるのは、ポリシーで許可されたファイル、機能、その他のリソースに限られます。

ただし、ワークロードがアクセスする必要がある可能性があるすべてのリソースを予測することは困難な場合があります。 MXC 学習モードを使用すると、ワークロードがアクセスしようとするリソースを記録することで、Windowsに対する最小限の特権ポリシーを作成できます。そのため、試行錯誤の代わりに証拠からポリシーを作成または調整できます。

Note

現在、学習モードは、Windows上の MXC ProcessContainer で実行されるワークロードで使用できます。ランタイム検出を使用して、ホストでの ProcessContainer のサポートを確認します。

学習モードの動作を選択する

学習モードには 2 つの動作があります。各方式では、アクセスの記録中も MXC がポリシーによる制限を適用し続けるかどうかが異なります。この違いによって、それぞれの方式を使用すべきユーザーとタイミングが決まります。

特性	拒否して記録	許可して記録する
未許可のアクセス	ブロックされ、記録されました	許可・記録済み
ポリシーの適用	制限は適用されるが、アクセス記録によって分離レベルが変わる場合がある	実行中は既定ですべてのアクセスを拒否する制限が緩和される
一般的なユーザー	アプリ開発者とポリシー作成者	既存のワークロードを評価する IT 管理者と開発者
いつ使用するか	アプリとそのポリシーを開発する際	ポリシーの作成前に、信頼できるワークロードのアクセス先を把握するため
`mode`値をキャプチャする	`block` (既定値)	`allow`

拒否して記録する: アプリとポリシーを開発する

アプリやエージェント、およびその MXC ポリシーを開発する際は、拒否して記録する方式 (learningModeLogging) を使用します。 MXC は記録中もポリシーを適用し続けるので、ユーザーの場合と同様に、許可されていないアクセスは拒否されます。学習モードでは、ポリシーがブロックした各アクセスのレコードが追加されます。一部のホストでは、アクセス記録によって MXC が選択する分離レベルが変わります。詳細については、「アクセス記録の前提条件を計画する」を参照してください。

一般的な使用方法は以下のとおりです:

包含ワークロードが失敗する理由を診断し、不足している許可と関連のないエラーを区別します。
サポートされているシナリオが成功し、負のテストが引き続き失敗するまで、ドラフトポリシーを反復修正します。
ワークロードが要求する機能の識別。
アプリのユーザーが自分のサンドボックスを調整できるようにする。アプリは、ブロックされた内容を記録し、独自の UI で表示し、ユーザーが変更を承認した後にのみポリシーを再生成します。

MXC はポリシーを適用し続けるので、拒否と記録がより安全な選択です。テストするポリシーがあれば、不完全なものであってもいつでも使用できます。

許可して記録する: ポリシーの作成前に既存のワークロードを評価する

MXC ポリシーを適用する前に、既存の信頼されたワークロードがアクセスする内容を確認する必要がある場合は、allow and record (permissiveLearningMode) を使用します。たとえば、IT 管理者は、テストデバイスで基幹業務ツールまたはスクリプトで通常のタスクを一通り実行し、その結果を使用してベースラインポリシーを作成してから、適用を有効にすることができます。既存のツールを MXC に取り込む開発者は、同じアプローチを使用して最初のポリシーを下書きできます。

許可して記録する方式では、実行中は既定ですべてのアクセスを拒否する制限が緩和されます。そのため、ワークロードがユーザーのすべてのアクセス許可を使用して実行されるものとして扱ってください。 MXC は、ポリシーが適用されていれば拒否されていたアクセスを一つずつ記録します。このモードがアクティブになると、MXC は実行結果とともにセキュリティ警告も返します。ホストは、警告を破棄するのではなく、その警告を表示する必要があります。

許可して記録する方式を使用する前に:

制御されたテストデバイスまたはアカウントで、代表的な非機密データを使って、信頼できるコードのみを実行します。
ワークロードの一般的なタスクを実際に実行します。実行中に発生しなかったアクセスは、結果に表示されません。
結果は、必要なアクセス先を洗い出すための初期リストとして扱ってください。不要なアクセス許可を削除し、デプロイ前に拒否して記録する方式でポリシー案を検証してください。

重要

Allow-and-Record Learning Mode をエージェント呼び出し可能な運用ツールとして公開しないでください。この方式の使用と、それに伴うアクセス許可の拡大については、信頼できるホスト側のコードまたは担当者による承認が必要です。

アクセス記録の前提条件を計画する

MXC は、2 つのキャプチャパスのいずれかを使用して学習モードの結果を収集します。ホストと要求されたポリシーに基づいて、実行時にパスが選択されます。これは、いずれかのモードの captureDenials と、wxc-exec.exe --audit ワークフローに適用されます。

アクセス記録の方法	MXC がそれを使用する場合	分離層	Elevation
ネイティブキャプチャ	Windows が MXC に必要なプロセスセキュリティ環境と学習モード API を提供しており、それらを使用して要求されたポリシーを表現できる	BaseContainer	None
ガード付きキャプチャ	ネイティブキャプチャが使用できないか、要求されたポリシーを表すことができない	互換性のある AppContainer 分離レベル	MXC は、Windows パフォーマンスレコーダー (WPR) トレースを記録するために、昇格された権限で署名付きヘルパー`plm.exe`を開始します。ユーザーは、UAC プロンプトを承認するか、管理者の資格情報を指定する必要があります。

ネイティブのアクセス記録では、processContainer.leastPrivilege、一部のネットワークプロキシ構成、拒否対象のパスをネイティブでサポートしていないホスト上でのパスの拒否設定など、一部のポリシーを表現できません。これらの要求では、ネイティブキャプチャをサポートするホストでも保護されたキャプチャが使用されます。どちらのパスもポリシー全体を保持できない場合、MXC はポリシーを弱めたりキャプチャをスキップしたりするのではなく、エラーを返します。

リクエストが使用するパスを調べるには、開始する前にキャプチャを有効にしてリクエストをプローブする。プローブはコンテナーを作成しません。

SDK	Call	確認対象の結果
.NET	`MxcContainer.Probe(request)`	`Tier`、`Probes.NativeCaptureAvailable`、`Probes.GuardedCaptureAvailable`
TypeScript	`probe(request)`	`tier`、`probes.nativeCaptureAvailable`、`probes.guardedCaptureAvailable`
Rust	`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 コンテインメントの選択に対してキャプチャを構成します。これにより、クイックスタートの抽象的な process intent が置き換えられます。

キャプチャ用のホスト所有の出力ディレクトリを作成します。含まれているワークロードによって書き込み可能である必要はありません。

要求の明示的な 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"),
    },
};

要求の明示的な ProcessContainer コンテインメントにキャプチャオプションを設定します。

const captureDirectory = resolve('captures');
mkdirSync(captureDirectory, { recursive: true });

request.containment = {
  type: 'processcontainer',
  config: {
    captureDenials: {
      mode: 'block',
      outputPath: join(captureDirectory, 'denials.json'),
    },
  },
};

インポート文に use mxc_sdk::v1::configs::{CaptureDenials, CaptureDenialsMode, ProcessContainerConfig}; を追加してください。次に、要求の明示的な ProcessContainer 包含にキャプチャオプションを設定します。

let capture_directory = env::current_dir()?.join("captures");
fs::create_dir_all(&capture_directory)?;

// The configuration types are non-exhaustive, so start from their defaults.
let mut capture_denials = CaptureDenials::default();
capture_denials.mode = CaptureDenialsMode::Block;
capture_denials.output_path = Some(capture_directory.join("denials.json").display().to_string());

let mut process_container = ProcessContainerConfig::default();
process_container.capture_denials = Some(capture_denials);

let request = ContainerRequest {
    containment: Containment::ProcessContainer(process_container),
    ..request
};

block モードでは、書き込み拒否のケースは引き続き失敗します。書き込み拒否を記録しても、その書き込みが許可されるわけではありません。承認済みの「許可して記録する」方式で実行する場合は、モードのみを変更し、C# では CaptureDenialsMode.Allow、TypeScript では 'allow'、Rust では CaptureDenialsMode::Allow に設定します。

既存の連携機能を変更する場合は、その他のコンテインメント設定を維持してください。予約された内部 learningModeLogging や permissiveLearningMode capability 名ではなく、専用のキャプチャオプションを使用します。

完了したキャプチャを見つける

実行と終了処理の完了を待ってから、結果を読み取ります。 MXC は構成されたファイル名に一意の実行識別子を挿入するため、 denials.json は denials.<run-id>.json などの名前になります。推測したり、最新のファイルをスキャンしたりする代わりに、報告されたパスを使用します。

MxcContainer.RunAsync(request)が完了し、result.Warningsを報告したら、結果メタデータを調べてください。

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 はアクセス制限を緩和する学習モードに関する警告を返しますが、ターミナルには自動的に出力しません。

ストリーミング実行を使用する場合は、MxcProcess.OutputMetadata を確認する前に、プロセスの終了を待つ処理を完了してください。待機せずにプロセスを破棄することは、キャプチャの最終処理に代わるものではありません。

run(request)が完了し、result.warningsを報告したら、結果メタデータを調べてください。

const captureError = result.outputMetadata?.captureDenialsError;
if (captureError) {
  throw new Error(`Denial capture failed: ${captureError.message}`);
}

const capture = result.outputMetadata?.captureDenials;
if (!capture) {
  throw new Error('The run did not produce denial capture metadata.');
}

console.log(`Denial document: ${capture.outputPath}`);
console.log(`Unique denials: ${capture.totalDenials}`);
if (capture.deniedResourcesTruncated) {
  throw new Error("The capture is incomplete; don't generate a policy from this run.");
}

終了状態、タイムアウト、および result.warningsに関するクイックスタートの処理を維持します。

spawnを使用する場合は、プロセスが完了するのを待ってから、返されたプロセスのoutputMetadataを検査してください。待機せずにプロセスを破棄することは、キャプチャの最終処理に代わるものではありません。欠落または不完全なキャプチャをゼロ拒否として解釈しないでください。また、ワークロードによって印刷された任意のテキストを承認として使用してポリシーを拡張しないでください。

v1::run から制御が戻り、result.warnings の内容を報告した後、結果のメタデータを確認します。

let metadata = result.output_metadata.as_ref();
if let Some(error) = metadata.and_then(|metadata| metadata.capture_denials_error.as_ref()) {
    eprintln!("Denial capture failed: {}", error.message);
    return Ok(1);
}

let Some(capture) = metadata.and_then(|metadata| metadata.capture_denials.as_ref()) else {
    eprintln!("The run did not produce denial capture metadata.");
    return Ok(1);
};

println!("Denial document: {}", capture.output_path);
println!("Unique denials: {}", capture.total_denials);
if capture.denied_resources_truncated {
    eprintln!("The capture is incomplete; don't generate a policy from this run.");
    return Ok(1);
}

終了状態、タイムアウト、および result.warningsに関するクイックスタートの処理を維持します。

v1::spawn を使用する場合は、返された MxcProcess の wait を呼び出してから、output_metadata() を確認してください。プロセスの終了を待たずに破棄しても、アクセス記録の完了処理を行ったことにはなりません。欠落または不完全なキャプチャをゼロ拒否として解釈しないでください。また、ワークロードによって出力された任意のテキストをポリシーを拡張する根拠として使用しないでください。

アクセス拒否の出力を確認する

アクション可能な 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などの機能名が含まれます。一部の観測値はポリシー許可として表現できません。また、1 つの入力ですべてのコードパスが実行されるとは限りません。

現時点では、許可モードで生成されるドキュメントに機能へのアクセス要求は含まれません。ワークロードに必要な機能を特定するには、「拒否して記録する」方式でワークロードを実行します。

deniedResourcesTruncatedがtrueの場合は、その実行からポリシーを生成しないでください。ドキュメントが空であっても、ワークロードが安全であることや、意図したすべての制限が実際にテストされたことの証明にはなりません。

MXC は、アクション可能なドキュメントと同じ場所に詳細ログファイルも出力します。たとえば、denials.<run-id>.json を使用すると、denials.<run-id>.verbose.json が生成されます。詳細ログファイルは、記録量が制限され、機密情報がマスクされた診断記録です。レジストリへの書き込みなど、MXC ポリシーでは制御できない操作の観測結果も含まれます。出力メタデータには詳細ログファイルのパスが含まれないため、アクション可能なドキュメントのパスから特定してください。詳細ログファイルは、アクション可能なドキュメントでは原因が分からない障害の調査に使用してください。アクセス許可の一覧として使用しないでください。

アクセス拒否とその他の障害を区別する

結果	何をすべきか
MXC が構成を拒否する	スキーマ、フィールドの組み合わせ、選択したバックエンドを確認します。無効な要求を回避するために、これ以上のアクセス権を付与しないでください。
バックエンドまたはキャプチャ機能が使用できない	サポート情報とアクセス記録の前提条件を確認します。必要な制限を黙って無効にしないでください。
制限が適用された状態でワークロードが失敗する	ワークロードの終了ステータス、エラー出力、記録が完了したアクセス拒否の情報を確認します。ワークロードの失敗は、必ずしもリソースへのアクセス拒否が原因とは限りません。
キャプチャが失敗するか、不完全である	ワークロードが正常に終了した場合でも、証拠を使用不可または不完全として扱います。

構造化されたアクセス記録では、アクション可能なドキュメントが収集されます。下位レベルの ProcessContainer の learningMode 設定では、「拒否して記録する」方式のイベント記録が有効になりますが、この設定だけではアクション可能なドキュメントは収集されません。ホスト側で記録された情報を利用する必要がある場合は、アクセス記録機能を使用します。

記録されたアクセスを確認する

ポリシーを変更する前に、各結果を分類してください。例:

検索中	潜在的なアクション
必要な入力ファイル	それをカバーする最も狭い読み取り専用パスを追加する
必要な出力またはキャッシュ	タスク固有の読み取り/書き込みパスを追加する
資格情報または無関係なユーザーファイル	拒否したままにし、必要に応じてワークロードを変更する
広範なアクセスを許可する親ディレクトリ	親に権限を付与する代わりに、必要な子パスを特定する
想定外のネットワーク、UI、または機能へのアクセス要求	アクセスを許可する前に、ワークロードがそのアクセスを必要とする理由を確認する
MXC がポリシーで表現できないリソース	ワークロードを変更するか、要件を適用できるバックエンドを選択する

観測されたアクセスは、スタートアップ、探索、オプションの機能、エラー処理、または 1 回の実行で使用される特定の入力に起因する可能性があります。すべての要求が必要であると想定しないでください。クイックスタートの否定テストでは、拒否された書き込みは意図した結果であり、アクセス許可の不足ではありません。

例: コマンドラインから Learning Mode を使用する

ホスト側のコードを記述せずにワークロードを評価するには、wxc-exec.exe コマンドラインツールと JSON 構成を使用してワークロードを実行します。構成形式については、「MXC ポリシーの作成と検証」を参照してください。

MXC SDK パッケージをインストールしても、wxc-exec.exe が PATH に自動的に追加されることはありません。 SDK のバージョンに一致するを mxc-release-binaries.zipからダウンロードし、ツールをフルパスを指定して実行します。次の例では、アーカイブを C:\Tools\Mxc に展開し、x64 フォルダーを使用していることを前提としています。 Arm64 デバイスでは、 arm64 フォルダーを使用します。

いずれかの動作でキャプチャする

コンテインメントとして ProcessContainer を選択し、構成の processContainer セクションに captureDenials を追加します。たとえば、ポリシーがまだないワークロードを評価する 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 は実際の出力パスと概要を含む 1 行の 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 のみがサポートされます。 --auditを明示的なprocessContainer.captureDenials設定と組み合わせないでください。完全な CLI および SDK コントラクトについては、GitHub の Learning-mode capabilitiesを参照してください。

学習ループを完了する

必要なアクセスの調査から、実際に制限を適用するポリシーの作成へ進むには、次のワークフローを使用します。

学習モードを有効にする前に、コンテインメントモデルを選択します。
ワークロードにまだポリシーがなく、必要最小限のアクセスに制限したポリシーをすぐに作成できない場合は、管理された環境で「許可して記録する」方式を使用してワークロードを実行します。ワークロードの一般的なタスクを実際に実行します。
収集した記録に基づいて、必要最小限のアクセスに制限したポリシー案を作成し、過度に広範なアクセス許可や不要なアクセス許可を削除します。
ポリシー案を適用した状態で「拒否して記録する」方式を使用してワークロードを実行し、必要な機能へのアクセスを含め、残っているアクセス拒否の問題を解決します。
正常系、異常系、境界条件を代表する入力を使用して、テストを繰り返します。
すべての学習、キャプチャ、監査の設定を削除し、最終的な強制適用テストを実行します。キャプチャによって MXC によって選択される分離層が変更される可能性があるため、この実行により、運用環境でのポリシーの動作が確認されます。

対象のワークロードが正常に動作し、ネガティブテストでも想定どおりに処理が失敗することを確認できたら、アクセス許可の拡大を終了します。

コーディングエージェントは所見を説明するのに役立ちますが、リソースアクセスポリシーに対する変更を確認して承認してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-11-02