Creare e perfezionare i criteri MXC con la modalità di apprendimento

Le sandbox Microsoft Execution Containers (MXC) sono bloccate per impostazione predefinita, in modo che un carico di lavoro contenuto possa usare solo i file, le funzionalità e altre risorse che i criteri gli concedono.

Tuttavia, può essere difficile prevedere tutte le risorse a cui un carico di lavoro potrebbe dover accedere. La modalità di apprendimento MXC consente di creare criteri con privilegi minimi per Windows registrando le risorse a cui un carico di lavoro tenta di accedere, in modo da poter creare o perfezionare un criterio dall'evidenza anziché dalla prova e dall'errore.

Note

La modalità di apprendimento è attualmente disponibile per i carichi di lavoro eseguiti in un ProcessContainer MXC in Windows. Usare il rilevamento runtime per confermare il supporto di ProcessContainer nell'host.

Scegli un comportamento per la modalità di apprendimento

La modalità di apprendimento ha due comportamenti. Differiscono nel fatto che MXC continua ad applicare la politica mentre registra l'accesso, il che determina chi deve usare ognuno e quando.

Caratteristica	Rifiuta e registra	Consenti e registra
Accesso non autorizzato	Bloccato e registrato	Consentita e registrata
Applicazione dei criteri	Applicato, ma l'acquisizione può modificare il livello di isolamento	Allentato il criterio deny-by-default per l'esecuzione
Utenti tipici	Sviluppatori di app e autori di criteri	Amministratori IT e sviluppatori che valutano i carichi di lavoro esistenti
Quando usarlo	Durante lo sviluppo di un'app e della relativa informativa	Prima dell'esistenza di un criterio, per sapere a cosa accede un carico di lavoro attendibile
Acquisisci `mode` valore	`block` (impostazione predefinita)	`allow`

Nega e registra: sviluppa app e criteri

Usare deny e record (learningModeLogging) durante lo sviluppo di un'app o di un agente e dei relativi criteri MXC. MXC continua ad applicare il criterio mentre registra, in modo che l'accesso non autorizzato abbia esito negativo come sarebbe per gli utenti. La modalità di apprendimento aggiunge un record di ogni accesso bloccato dal criterio. In alcuni host l'acquisizione modifica il livello di isolamento selezionato da MXC. Per informazioni dettagliate, vedere Piano per i prerequisiti di acquisizione.

Gli usi comuni includono:

Capire perché un workload contenuto ha esito negativo e distinguere una concessione mancante da un errore non correlato.
Iterare una bozza di criterio fino a quando gli scenari supportati hanno esito positivo e i test negativi hanno ancora esito negativo.
Identificazione delle capacità richieste da un carico di lavoro.
Consentire agli utenti dell'app di ottimizzare la propria sandbox. L'app registra ciò che è stato bloccato, lo presenta nella propria interfaccia utente e rigenera i criteri solo dopo che l'utente approva la modifica.

Poiché MXC continua ad applicare il criterio, negare e registrare è la scelta più sicura. Usarlo ogni volta che si dispone di un criterio/policy da testare, anche se incompleto.

Consenti e registra: valuta i carichi di lavoro esistenti prima di creare un criterio

Usare consenti e registra (permissiveLearningMode) quando è necessario conoscere a quali risorse accede un carico di lavoro attendibile esistente prima di applicare un criterio MXC. Ad esempio, un amministratore IT può eseguire uno strumento line-of-business o uno script, eseguendolo nelle sue attività tipiche su un dispositivo di test, e quindi usare i risultati per creare un criterio di base prima di abilitare la modalità di imposizione. Uno sviluppatore che porta uno strumento esistente in MXC può usare lo stesso approccio per creare una prima policy.

Consenti e registra allenta l'applicazione del criterio di negazione predefinita per l'esecuzione, quindi considera il carico di lavoro come se fosse in esecuzione con le autorizzazioni complete dell'utente. MXC registra ogni accesso che il criterio avrebbe negato. Ogni volta che questa modalità è attiva, MXC restituisce anche un avviso di sicurezza con il risultato dell'esecuzione. L'host dovrebbe visualizzare l'avviso anziché ignorarlo.

Prima di usare "Consenti" e "Registra":

Eseguire solo codice attendibile, con dati rappresentativi non sensibili, su un dispositivo o account di test controllato.
Esegui le attività tipiche del carico di lavoro. L'accesso che un'esecuzione non esercita non viene visualizzato nei risultati.
Considera i risultati come un inventario di partenza. Rimuovere le autorizzazioni non necessarie e quindi verificare il criterio in bozza con Nega e Registra prima di distribuirlo.

Importante

Non esporre la modalità di apprendimento allow-and-record come strumento di produzione chiamabile da agente. Il codice host attendibile o una persona devono approvarne l'uso e qualsiasi conseguente espansione delle autorizzazioni.

Piano per i prerequisiti di acquisizione

MXC raccoglie i risultati della modalità di apprendimento tramite uno dei due percorsi di acquisizione. Seleziona il percorso in fase di esecuzione, in base all'host e al criterio richiesto. Questo vale per captureDenials in entrambe le modalità e per il wxc-exec.exe --audit flusso di lavoro.

Percorso di acquisizione	Quando MXC lo usa	Livello di isolamento	Elevation
Acquisizione nativa	Windows fornisce l'ambiente di sicurezza dei processi e le API della modalità di apprendimento di cui MXC ha bisogno, e possono rappresentare i criteri richiesti	BaseContainer	None
Cattura protetta	L'acquisizione nativa non è disponibile o non può rappresentare il criterio richiesto	Un livello AppContainer compatibile	MXC avvia un helper firmato, `plm.exe`, con elevazione per registrare una traccia WPR (Performance Recorder) Windows. L'utente deve approvare un prompt UAC o fornire le credenziali di amministratore.

L'acquisizione nativa non può rappresentare alcuni criteri, ad esempio processContainer.leastPrivilege, alcune configurazioni proxy di rete e percorsi negati sugli host che non li supportano in modo nativo. Queste richieste usano l'acquisizione sorvegliata anche in host che supportano l'acquisizione nativa. Se nessuno dei due percorsi può mantenere il criterio completo, MXC restituisce un errore anziché indebolire il criterio o ignorare l'acquisizione.

Per scoprire quale percorso userà una richiesta, eseguire il probe della richiesta con l'acquisizione abilitata prima di avviarla. Il probe non crea un contenitore.

SDK	Call	Risultati da controllare
.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`

Un livello BaseContainer indica l'acquisizione nativa. Un livello AppContainer indica l'acquisizione protetta e una richiesta di elevazione dei privilegi. Il native capture fact descrive l'host, non la richiesta, quindi controlla anche il livello.

Tenere conto di queste differenze:

In un'app, eseguire una verifica prima di avviare l'acquisizione e indicare agli utenti quando l'acquisizione richiede l'approvazione dell'amministratore. Non presupporre che l'acquisizione venga eseguita silenziosamente su ogni host.
Quando un amministratore IT valuta i carichi di lavoro, verificare che i dispositivi di test supportino l'acquisizione nativa o che un amministratore possa approvare il prompt di acquisizione sorvegliato. Il livello AppContainer può anche richiedere la preparazione dell'host.
Considerare i risultati di acquisizione come evidenza per la redazione di criteri. Poiché guarded capture può eseguire il carico di lavoro in un livello diverso da quello di produzione, verificare i criteri finali con un'esecuzione che non usa guarded capture.

Esempio: abilitazione dell'acquisizione tramite MXC SDK

Usare SDK capture quando l'app ospita il carico di lavoro. Per valutare un carico di lavoro senza scrivere codice host, vedere Usare la modalità di apprendimento dalla riga di comando.

Iniziare con l'avvio rapido SDK, incluso il caso di scrittura negata. I frammenti seguenti estendono l'esempio e usano lo stesso carico di lavoro e le stesse assegnazioni di risorse. Inserire il frammento selezionato immediatamente prima che l'SDK avvii il carico di lavoro.

Gli esempi usano le API MXC 1.0 V1 SDK. In ogni SDK si configura il capture su una selezione di contenimento ProcessContainer esplicita, che sostituisce l'intent astratto del processo del quickstart.

Creare una directory di output di proprietà dell'host per l'acquisizione. Non deve essere scrivibile dal carico di lavoro contenuto.

Impostare le opzioni di acquisizione per il contenitore ProcessContainer esplicito della richiesta:

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"),
    },
};

Impostare le opzioni di acquisizione per il contenimento esplicito di ProcessContainer della richiesta:

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

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

Aggiungere use mxc_sdk::v1::configs::{CaptureDenials, CaptureDenialsMode, ProcessContainerConfig}; alle importazioni. Impostare quindi le opzioni di acquisizione per il contenimento esplicito di ProcessContainer della richiesta:

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
};

In block modalità, il caso di scrittura negata continua a fallire. La registrazione del diniego non concede l'autorizzazione di scrittura. Per un'esecuzione di tipo allow-and-record approvata, modificare solo la modalità in CaptureDenialsMode.Allow in C#, 'allow' in TypeScript o CaptureDenialsMode::Allow in Rust.

Quando si adatta un'integrazione esistente, mantenere le altre impostazioni di contenimento. Usare le opzioni di acquisizione dedicate, non i nomi di funzionalità interni riservati permissiveLearningMode o learningModeLogging.

Individua la capture completata

Attendere l'esecuzione e il completamento dell'acquisizione prima di leggere il risultato. MXC inserisce un identificatore di esecuzione univoco nel nome file configurato, quindi denials.json diventa un nome come denials.<run-id>.json. Usare il percorso segnalato invece di indovinarlo o eseguire una scansione alla ricerca del file più recente.

Dopo che MxcContainer.RunAsync(request) è stato completato e dopo aver segnalato result.Warnings, esaminare i metadati dei risultati:

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;
}

Mantenere la gestione del quickstart dello stato di uscita, dei timeout e di result.Warnings. In particolare, l'SDK di .NET restituisce avvisi sulla modalità di apprendimento permissiva anziché scriverli automaticamente nel terminale.

Se si usa l'esecuzione in streaming, attendere il completamento dell'attesa del terminale prima di esaminare MxcProcess.OutputMetadata. Chiudere il processo senza attendere non è un sostituto della finalizzazione dell'acquisizione.

Dopo che run(request) è stato completato e dopo aver segnalato result.warnings, esaminare i metadati dei risultati:

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.");
}

Mantenere la gestione della guida introduttiva dello stato di uscita, dei timeout e result.warnings.

Se si usa spawn, attendere il completamento del processo prima di esaminare outputMetadata nel processo restituito. Chiudere il processo senza attendere non è un sostituto della finalizzazione dell'acquisizione. Non interpretare un'acquisizione mancante o incompleta come nessun rifiuto e non usare testo arbitrario stampato dal carico di lavoro come approvazione per espandere la sua policy.

Dopo che v1::run restituisce e si segnala result.warnings, esaminare i metadati del risultato:

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);
}

Mantenere la gestione dello stato di uscita, dei timeout e di result.warnings.

Se si usa v1::spawn, chiamare wait sul MxcProcess restituito prima di esaminarne output_metadata(). L'interruzione del processo senza attesa non sostituisce la finalizzazione dell'acquisizione. Non interpretare un rilevamento mancante o incompleto come zero negazioni e non usare testo arbitrario stampato dal carico di lavoro come approvazione per espandere la propria policy.

Leggere l'output di rifiuto

Il documento JSON attuabile identifica le risorse, il tentativo di accesso e un riepilogo. Per il caso di scrittura negato della guida introduttiva, una voce rappresentativa è simile alla seguente:

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

Il documento è una prova della redazione di policy, non un log completo di tutto ciò che il carico di lavoro ha fatto. Il resourceType valore determina come leggere resource. Ad esempio, una file voce contiene un percorso assoluto e una capability voce contiene un nome di funzionalità, come internetClient. Alcune osservazioni non possono essere espresse come autorizzazioni dei criteri e un singolo input non esercita ogni percorso di codice.

In modalità Consenti il documento non include attualmente richieste di capacità. Eseguire il carico di lavoro con deny and record per identificare le funzionalità necessarie.

Se deniedResourcesTruncated è true, non generare un criterio da tale esecuzione. Un documento vuoto inoltre non dimostra che un carico di lavoro è sicuro o che ogni restrizione prevista è stata applicata.

MXC scrive anche un file dettagliato accanto al documento utilizzabile. Esempio: denials.<run-id>.json genera denials.<run-id>.verbose.json. Il file dettagliato è un record di diagnostica delimitato e oscurato che include osservazioni su cui i criteri MXC non possono agire, ad esempio le scritture del Registro di sistema. I metadati di output non riportano il percorso, quindi ricavalo dal percorso del documento actionable. Usare il file dettagliato per analizzare un errore che il documento operativo non spiega, non come elenco di autorizzazioni.

Distinguere un diniego da altri errori

Risultato	Cosa fare
MXC rifiuta la configurazione	Controllare lo schema, le combinazioni di campi e il back-end selezionato. Non concedere più accesso per aggirare una richiesta non valida.
La funzionalità backend o funzionalità di cattura non è disponibile	Esaminare le informazioni di supporto e registrare i prerequisiti. Non disabilitare senza avvisare l'utente una restrizione obbligatoria.
Il carico di lavoro fallisce in modalità enforcement	Esaminare lo stato di uscita, l'output di errore e l'acquisizione dei dinieghi completata. Un errore del workload non è necessariamente una negazione di risorse.
Acquisizione non riuscita o incompleta	Considera l'evidenza come non disponibile o incompleta, anche se il workload è stato chiuso correttamente.

L'acquisizione strutturata raccoglie il documento elaborabile. L'impostazione ProcessContainer learningMode di livello inferiore abilita la registrazione degli eventi deny-and-record, ma non raccoglie per sé questo documento. Usare l'acquisizione quando l'host deve elaborare le evidenze raccolte.

Rivedere l'accesso rilevato

Classificare ogni risultato prima di modificare la politica. Ad esempio:

Trovare	Potenziale azione
Un file di input obbligatorio	Aggiungere il percorso di sola lettura più stretto che lo copre
Un output o una cache necessari/a	Aggiungere un percorso di lettura/scrittura specifico dell'attività
Una credenziale o un file utente non correlato	Mantenerlo negato e modificare il carico di lavoro, se necessario
Una directory padre più ampia	Identificare i percorsi figlio necessari invece di autorizzare l'elemento padre
Una richiesta di rete, interfaccia utente o funzionalità imprevista	Verificare il motivo per cui il workload lo richiede prima di concedere l'accesso
Risorsa che MXC non può esprimere nel criterio	Modifica il carico di lavoro o scegli un back-end in grado di applicare il requisito

L'accesso osservato può provenire dall'avvio, dal rilevamento, dalle funzionalità facoltative, dalla gestione degli errori o dall'input specifico usato in una specifica esecuzione. Non presupporre che ogni richiesta sia necessaria. Nel test negativo dell'avvio rapido, la scrittura negata è il risultato previsto, non un'autorizzazione mancante.

Esempio: usare Learning Mode dalla riga di comando

Per valutare un carico di lavoro senza scrivere codice host, eseguirlo con lo wxc-exec.exe strumento da riga di comando e una configurazione JSON. Per il formato di configurazione, vedere Redigere e convalidare un criterio MXC.

L'installazione di un pacchetto MXC SDK non aggiunge wxc-exec.exe a PATH. Scaricare mxc-release-binaries.zip dalla versione MXC corrispondente alla versione dell'SDK ed eseguire lo strumento specificandone il percorso completo. Gli esempi seguenti presuppongono che l'archivio sia stato estratto in C:\Tools\Mxc e che sia stata usata la cartella x64. Nei dispositivi Arm64 usare la cartella arm64.

Acquisire con uno dei due comportamenti

Selezionare containment ProcessContainer e aggiungere captureDenials alla sezione processContainer della configurazione. Ad esempio, un amministratore IT che valuta un carico di lavoro che non dispone ancora di un criterio può usare la modalità 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"
    }
  }
}

Creare la directory di output prima dell'esecuzione e quindi passare il file di configurazione allo strumento:

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

Dopo l'esecuzione, wxc-exec scrive una riga JSON nell'output di errore standard con il percorso di output effettivo e un riepilogo:

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

Usare il percorso segnalato per leggere il documento. Per verificare una bozza di criterio in fase di applicazione, aggiungere le autorizzazioni alla configurazione e modificare la modalità in block.

Proporre una configurazione modificata

Per la creazione di criteri basati sullo sviluppatore, il flusso di lavoro di audit esegue un'acquisizione con autorizzazione e registrazione e propone anche una configurazione modificata:

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

Il flusso di lavoro di controllo scrive i documenti Denial, un file di traccia, uno snapshot della configurazione di origine e un Adjusted_*.json file che unisce l'accesso osservato a tale configurazione. La configurazione modificata è una proposta per la revisione, non un criterio/norma approvata. MXC non lo produce quando l'acquisizione viene troncata e l'acquisizione dell'SDK non la produce affatto.

Il flusso di lavoro di controllo supporta solo ProcessContainer. Non combinare --audit con un'impostazione esplicita processContainer.captureDenials . Per i contratti completi della CLI e dell'SDK, vedere Funzionalità della modalità di apprendimento in GitHub.

Completare il ciclo di apprendimento

Usare questo flusso di lavoro per passare dall'individuazione a un criterio di applicazione:

Selezionare il modello di contenimento prima di abilitare la modalità di apprendimento.
Se il carico di lavoro non ha ancora una policy e non è possibile scriverne direttamente una restrittiva, eseguilo con Allow e Record in un ambiente controllato. Esegui le sue attività tipiche.
Redigere un criterio specifico in base alle evidenze e rimuovere autorizzazioni ampie e non correlate.
Eseguire il carico di lavoro in base ai criteri in bozza con negazione e registrazione e risolvere le negazioni rimanenti, incluse le capacità richieste.
Ripetere con input rappresentativi di esito positivo, negativo e casi limite.
Rimuovere tutte le impostazioni di apprendimento, acquisizione e controllo ed eseguire un test finale di imposizione. Capture può modificare il livello di isolamento selezionato da MXC, quindi questa esecuzione conferma il comportamento del criterio nell'ambiente di produzione.

Interrompere l'espansione dell'accesso quando il carico di lavoro supportato ha esito positivo e i test negativi hanno comunque esito negativo come previsto.

Un agente di programmazione può aiutare a spiegare le osservazioni, ma assicurarsi di esaminare e approvare le modifiche apportate ai criteri di accesso alle risorse.

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-10-27