Créer et affiner des stratégies MXC avec le mode d’apprentissage

Les bacs à sable Microsoft Execution Containers (MXC) sont configurés selon un modèle de refus par défaut, afin qu’une charge de travail contenue puisse utiliser uniquement les fichiers, les fonctionnalités et les autres ressources que sa stratégie autorise.

Toutefois, il peut être difficile de prédire toutes les ressources auxquelles une charge de travail peut devoir accéder. MXC Learning Mode vous permet de créer une stratégie de moindre privilège sur Windows en enregistrant les ressources auxquelles une charge de travail tente d’accéder. Vous pouvez donc créer ou affiner une stratégie sur la base d’éléments concrets plutôt que par tâtonnements.

Note

Le mode d’apprentissage est actuellement disponible pour les workloads qui s’exécutent dans un ProcessContainer MXC sur Windows. Utilisez la découverte du runtime pour confirmer la prise en charge de ProcessContainer sur l’hôte.

Choisir un comportement du mode d’apprentissage

Le mode d’apprentissage a deux comportements. Ils diffèrent selon que MXC continue d’appliquer la politique pendant qu’elle enregistre l’accès, ce qui détermine qui doit utiliser chacun d’eux et quand.

Caractéristique	Refuser et enregistrer	Autoriser et enregistrer
Accès non accordé	Bloqué et enregistré	Autorisé et enregistré
Application de la stratégie	Appliqué, mais le mode de capture peut modifier le niveau d’isolation	Refus par défaut assoupli pour l’exécution
Utilisateurs classiques	Développeurs d’applications et auteurs de politiques	Administrateurs informatiques et développeurs qui évaluent les charges de travail existantes
Quand l′utiliser ?	Pendant que vous développez une application et sa stratégie	Avant qu’une stratégie n’existe, pour savoir à quoi une charge de travail de confiance accède
Capturer `mode` la valeur	`block` (valeur par défaut)	`allow`

Refuser et enregistrer : développer des applications et des politiques

Utilisez refuser et enregistrer (learningModeLogging) pendant le développement d’une application ou d’un agent et de sa stratégie MXC. MXC maintient l’application de la stratégie pendant qu’elle enregistre, de sorte que l’accès non autorisé échoue comme il le ferait pour vos utilisateurs. Le mode d’apprentissage ajoute un enregistrement de chaque accès bloqué par la stratégie. Sur certains hôtes, la capture modifie le niveau d’isolation sélectionné par MXC. Pour plus d’informations, consultez Prérequis pour la planification de capture.

Les utilisations courantes sont les suivantes :

Diagnostic de l’échec d’une charge de travail conteneurisée et distinction d’une autorisation manquante à partir d’une erreur non liée.
Itération sur un brouillon de stratégie jusqu’à ce que les scénarios pris en charge réussissent et que les tests négatifs échouent toujours.
Identification des capacités requises par une charge de travail.
Permettre aux utilisateurs de votre application de régler leur propre sandbox. Votre application enregistre ce qui a été bloqué, présente ce qui a été bloqué dans sa propre interface utilisateur et régénère la stratégie uniquement après l’approbation de la modification par l’utilisateur.

Étant donné que MXC continue d’appliquer la politique, refuser et enregistrer est le choix plus sûr. Utilisez-le chaque fois que vous avez une politique à tester, même une politique incomplète.

Autoriser et enregistrer : évaluer les charges de travail existantes avant de créer une politique

Utilisez Allow and record (permissiveLearningMode) quand vous devez déterminer à quoi une charge de travail existante et approuvée accède avant d’appliquer une stratégie MXC à celle-ci. Par exemple, un administrateur informatique peut exécuter un outil métier ou un script en lui faisant exécuter ses tâches habituelles sur un appareil de test, puis utiliser les résultats pour créer une stratégie de base avant d’activer la mise en application. Un développeur qui apporte un outil existant dans MXC peut utiliser la même approche pour rédiger une première politique.

Autoriser et consigner assouplit l’application du refus par défaut pour l’exécution. Traitez la charge de travail comme si elle s’exécutait avec l’ensemble des autorisations de l’utilisateur. MXC enregistre chaque accès que la stratégie aurait refusé. Chaque fois que ce mode est actif, MXC retourne également un avertissement de sécurité avec le résultat de l’exécution. Votre hôte doit faire apparaître cet avertissement plutôt que de le rejeter.

Avant d’autoriser et d’enregistrer :

Exécutez uniquement du code approuvé, avec des données représentatives non sensibles, sur un appareil ou un compte de test contrôlé.
Effectuez les tâches typiques de la charge de travail. L’accès qu’une exécution ne couvre pas n’apparaît pas dans les résultats.
Traitez les résultats comme un inventaire de départ. Supprimez les autorisations inutiles, puis vérifiez le brouillon de stratégie avec les actions Refuser et Enregistrer avant de le déployer.

Important

N’exposez pas le mode d’apprentissage allow-and-record en tant qu’outil de production pouvant être appelé par agent. Un code hôte de confiance ou une personne doit approuver son utilisation et toute extension résultante des autorisations.

Prérequis pour la planification de capture

MXC collecte les résultats du mode d’apprentissage via l’un des deux chemins de capture. Il sélectionne le chemin d’accès au moment de l’exécution, en fonction de l’hôte et de la stratégie demandée. Cela s’applique à captureDenials dans l’un ou l’autre des modes et au flux de travail wxc-exec.exe --audit.

Chemin de capture	Quand MXC l’utilise	Niveau d’isolement	Elevation
Capture intégrée	Windows fournit l’environnement de sécurité du processus et les API en mode Apprentissage dont MXC a besoin et qui peuvent représenter la stratégie demandée	BaseContainer	None
Capture protégée	La capture native n’est pas disponible ou ne peut pas représenter la stratégie demandée	Niveau AppContainer compatible	MXC démarre un assistant signé, `plm.exe`avec élévation pour enregistrer une trace WPR (Windows Performance Recorder). L’utilisateur doit approuver une invite UAC ou fournir des informations d’identification d’administrateur.

La capture native ne peut pas représenter certaines stratégies, telles que processContainer.leastPrivilege, certaines configurations de proxy réseau et les chemins refusés sur les hôtes qui ne les prennent pas en charge en mode natif. Ces demandes utilisent la capture protégée même sur les hôtes qui prennent en charge la capture native. Si aucun chemin d’accès ne peut conserver la politique complète, MXC retourne une erreur au lieu d’affaiblir la politique ou d’ignorer la capture.

Pour déterminer le chemin d’accès qu’une requête utilisera, sondez la requête avec la capture activée avant de la lancer. La sonde ne crée pas de conteneur.

SDK	Call	Résultats à vérifier
.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 niveau BaseContainer signifie une capture native. Un niveau AppContainer se traduit par une capture protégée et une invite d’élévation. Le « native capture fact » décrit l’hôte, et non votre demande, donc vérifiez également le niveau.

Prévoyez ces différences :

Dans une application, sondez avant de commencer la capture et indiquez aux utilisateurs quand la capture nécessite l’approbation de l’administrateur. Ne supposez pas que la capture s’exécute sans affichage sur chaque hôte.
Lorsqu’un administrateur informatique évalue les charges de travail, vérifiez que les appareils de test prennent en charge la capture native ou qu’un administrateur peut approuver l’invite de capture protégée. Le niveau AppContainer peut également nécessiter la préparation de l’hôte.
Traitez les résultats de capture comme des preuves pour la rédaction de politiques. Étant donné que la capture protégée peut exécuter la charge de travail sur un niveau de service différent de celui de la production, confirmez la stratégie finale avec une exécution qui n’utilise pas la capture.

Exemple : activation de la capture via un SDK MXC

Utilisez la capture SDK lorsque votre application héberge la charge de travail. Pour évaluer une charge de travail sans écrire de code hôte, consultez Utiliser le mode d’apprentissage à partir de la ligne de commande.

Démarrez avec le guide de démarrage rapide du Kit de développement logiciel (SDK), y compris son cas d’écriture refusée. Les fragments suivants étendent cet exemple et utilisent la même charge de travail et les mêmes allocations de ressources. Insérez le fragment sélectionné juste avant que le Kit de développement logiciel (SDK) ne lance la charge de travail.

Les exemples utilisent les API du SDK MXC 1.0 V1. Dans chaque SDK, vous configurez la capture sur une sélection explicite de confinement ProcessContainer, qui remplace l’intention de processus abstraite du guide de démarrage rapide.

Créez un répertoire de sortie appartenant à l’hôte pour la capture. Il n’a pas besoin d’être accessible en écriture par la charge de travail contenue.

Définissez les options de capture sur le conteneur ProcessContainer explicite de la requête :

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

Définissez les options de capture sur le conteneur ProcessContainer explicite de la requête :

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

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

Ajoutez use mxc_sdk::v1::configs::{CaptureDenials, CaptureDenialsMode, ProcessContainerConfig}; aux imports. Définissez ensuite les options de capture sur la contenance ProcessContainer explicite de la requête :

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

En mode block, le cas d’écriture refusée continue d’échouer. La capture du déni n’accorde pas le droit d’écriture. Pour une exécution d’autorisation et d’enregistrement approuvée, modifiez uniquement le mode en CaptureDenialsMode.Allow en C#, 'allow' en TypeScript ou CaptureDenialsMode::Allow en Rust.

Lors de l’adaptation d’une intégration existante, conservez ses autres paramètres de conteneur. Utilisez des options de capture dédiées, et non les noms de capacité internes réservés learningModeLogging ou permissiveLearningMode.

Trouver la capture terminée

Attendez la finalisation de l’exécution et de la capture avant de lire le résultat. MXC insère un identificateur d’exécution unique dans le nom de fichier configuré, de sorte que denials.json devient un nom tel que denials.<run-id>.json. Utilisez le chemin signalé au lieu de le deviner ou de rechercher le fichier le plus récent.

Une fois l’opération MxcContainer.RunAsync(request) terminée et que vous signalez result.Warnings, inspectez les métadonnées du résultat :

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

Conservez la gestion du guide de démarrage rapide de l’état de sortie, des délais d’expiration et de result.Warnings. En particulier, le sdk .NET retourne des avertissements sur le mode d’apprentissage permissif plutôt que de les écrire automatiquement dans votre terminal.

Si vous utilisez l’exécution en streaming, attendez la fin de l’exécution du terminal avant d’inspecter MxcProcess.OutputMetadata. La libération du processus sans attendre n’est pas un substitut à la finalisation de la capture.

Une fois l’opération run(request) terminée et que vous signalez result.warnings, inspectez les métadonnées du résultat :

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

Conservez la gestion du guide de démarrage rapide de l’état de sortie, des délais d’expiration et de result.warnings.

Si vous utilisez spawn, attendez que le processus se termine avant d’inspecter outputMetadata sur le processus renvoyé. La libération du processus sans attendre n’est pas un substitut à la finalisation de la capture. N’interprétez pas une capture manquante ou incomplète comme zéro refus et n’utilisez pas de texte arbitraire imprimé par la charge applicative comme approbation pour étendre sa politique.

Une fois que v1::run est renvoyé et que vous signalez result.warnings, inspectez les métadonnées du résultat :

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

Conservez la gestion du guide de démarrage rapide de l’état de sortie, des délais d’expiration et de result.warnings.

Si vous utilisez v1::spawn, appelez wait sur le MxcProcess renvoyé avant d’inspecter son output_metadata(). L’arrêt du processus sans attendre n’est pas un substitut à la finalisation de la capture. N’interprétez pas une capture manquante ou incomplète comme zéro refus et n’utilisez pas de texte arbitraire imprimé par la charge de travail comme approbation pour développer sa politique.

Sortie du déni de lecture

Le document JSON actionnable identifie les ressources, les tentatives d’accès et un résumé. Pour le cas d’écriture refusée du guide de démarrage rapide, une entrée représentative ressemble à ceci :

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

Le document est une preuve de la rédaction de stratégies, et non d’un journal exhaustif de tout ce que la charge de travail a fait. La resourceType valeur détermine comment lire resource. Par exemple, une file entrée contient un chemin absolu et une capability entrée contient un nom de fonctionnalité tel que internetClient. Certaines observations ne peuvent pas être exprimées sous forme d’autorisations de stratégie, et une seule entrée n’exercera pas chaque chemin de code.

En mode d’autorisation, le document n’inclut actuellement pas de demandes de capacité. Exécutez la charge de travail en mode deny and record pour identifier les capacités dont elle a besoin.

Si deniedResourcesTruncated c’est truele cas, ne générez pas de politique à partir de cette exécution. Un document vide ne prouve pas non plus qu’une charge de travail est sûre ou que chaque restriction prévue a été exercée.

MXC écrit également un fichier détaillé à côté du document actionnable. Par exemple, denials.<run-id>.json produit denials.<run-id>.verbose.json. Le fichier détaillé est un enregistrement de diagnostic de taille limitée et caviardé qui inclut des observations sur lesquelles la stratégie MXC ne peut pas agir, comme les écritures de Registre. Les métadonnées de sortie ne signalent pas son chemin d’accès, donc déduisez-le du chemin d’accès du document actionnable. Utilisez le fichier détaillé pour examiner un échec que le document exploitable n’explique pas, et non comme une liste d’autorisations.

Distinguer un refus d’autres échecs

Résultat	Procédure à suivre
MXC rejette la configuration	Vérifiez le schéma, les combinaisons de champs et le back-end sélectionné. N’accordez pas plus d’accès pour contourner une demande non valide.
La fonctionnalité de back-end ou de capture n’est pas disponible	Inspectez les informations de support et les conditions préalables de capture. Ne désactivez pas silencieusement une restriction requise.
La charge de travail ne fonctionne pas lorsque l’application est activée	Passez en revue son état de sortie, la sortie d’erreur et la capture des refus effectuée. L’échec d’une charge de travail n’est pas nécessairement un refus de ressource.
La capture échoue ou est incomplète	Traitez les éléments probants comme indisponibles ou incomplets, même si la charge de travail s’est terminée avec succès.

La capture structurée capture le document exploitable. Le paramètre ProcessContainer learningMode de niveau inférieur active l’enregistrement des événements deny-and-record, mais ne collecte pas lui-même ce document. Utilisez la collecte lorsque l’hôte doit exploiter les éléments de preuve.

Vérifier les accès observés

Classifiez chaque résultat avant de modifier la stratégie. Par exemple:

Résultat	Action potentielle
Un fichier d’entrée obligatoire	Ajouter le chemin d’accès en lecture seule le plus étroit qui le couvre
Une sortie requise ou un cache requis	Ajouter un chemin d’accès en lecture-écriture propre à la tâche
Un justificatif d’identité ou un fichier utilisateur sans rapport	Conservez l’état Refusé et modifiez la charge de travail si nécessaire
Répertoire parent large	Identifiez les chemins d’accès enfants requis au lieu d’accorder le parent
Une requête inattendue liée au réseau, à l’interface utilisateur ou aux fonctionnalités	Vérifier pourquoi le workload en a besoin avant d’accorder l’accès
Ressource que MXC ne peut pas exprimer dans la politique	Modifier la charge de travail ou choisir un back-end qui peut faire respecter l’exigence

L’accès observé peut provenir du démarrage, de la découverte, des fonctionnalités facultatives, de la gestion des erreurs ou de l’entrée particulière utilisée lors d’une exécution. Ne supposez pas que chaque demande est nécessaire. Dans le test négatif du guide de démarrage rapide, l’écriture refusée est le résultat prévu, pas une autorisation manquante.

Exemple : utiliser le mode d’apprentissage à partir de la ligne de commande

Pour évaluer une charge de travail sans écrire de code hôte, exécutez-la avec l’outil wxc-exec.exe en ligne de commande et une configuration JSON. Pour le format de configuration, consultez Rédiger et valider une stratégie MXC.

L’installation d’un package logiciel SDK MXC n’ajoute pas wxc-exec.exe à votre PATH. Téléchargez mxc-release-binaries.zip à partir de la version MXC qui correspond à votre version du Kit de développement logiciel (SDK) et exécutez l’outil par son chemin complet. Les exemples suivants supposent que vous avez extrait l’archive dans C:\Tools\Mxc et que vous utilisez le dossier x64. Sur les appareils Arm64, utilisez le dossier arm64.

Capturez avec l’un ou l’autre des comportements

Sélectionnez le confinement de ProcessContainer et ajoutez captureDenials à la section processContainer de la configuration. Par exemple, un administrateur informatique qui évalue une charge de travail qui n’a pas encore de stratégie peut utiliser le mode 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"
    }
  }
}

Créez le répertoire de sortie avant l’exécution, puis transmettez le fichier de configuration à l’outil :

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

Après l’exécution, wxc-exec écrit une ligne JSON sur la sortie d’erreur standard avec le chemin de sortie réel et un résumé :

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

Utilisez le chemin d’accès signalé pour lire le document. Pour vérifier un brouillon de stratégie en cours d’application, ajoutez vos autorisations à la configuration et modifiez le mode en block.

Proposer une configuration ajustée

Pour la création de stratégies pilotées par les développeurs, le flux de travail d’audit exécute une capture en mode autoriser et enregistrer et propose également une configuration révisée :

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

Le flux de travail d’audit génère les documents de refus, un fichier de trace, un instantané de la configuration source et un fichier Adjusted_*.json qui fusionne les accès observés dans cette configuration. La configuration ajustée est une proposition à examiner, et non une politique approuvée. MXC ne le produit pas lorsque la capture est tronquée, et la capture SDK ne le produit pas du tout.

Le flux de travail d’audit prend uniquement en charge ProcessContainer. Ne combinez --audit pas avec un paramètre explicite processContainer.captureDenials . Pour connaître les contrats CLI et SDK complets, consultez Fonctionnalités du mode apprentissage sur GitHub.

Terminer la boucle d’apprentissage

Utilisez ce flux de travail pour passer de la découverte à une stratégie d’application :

Sélectionnez le modèle de confinement avant d’activer le mode d’apprentissage.
Si la charge de travail n’a pas encore de politique et que vous ne pouvez pas écrire directement une politique étroite, exécutez-la en mode autoriser et enregistrer dans un environnement contrôlé. Effectuez ses tâches classiques.
Rédigez une politique ciblée à partir des éléments de preuve et supprimez les autorisations générales et non liées.
Exécutez la charge de travail sous la stratégie brouillon avec refus et journalisation, puis résolvez les refus restants, y compris les capacités requises.
Répétez avec les entrées représentatives de réussite, d’échec et de cas limites.
Supprimez tous les paramètres d’apprentissage, de capture et d’audit, et exécutez un dernier test avec application effective de la stratégie. La capture peut modifier le niveau d’isolation sélectionné par MXC. Cette exécution confirme donc le comportement de la stratégie en production.

Arrêtez d’étendre l’accès lorsque la charge de travail prise en charge réussit et que les tests négatifs échouent toujours comme prévu.

Un agent de codage peut vous aider à expliquer les observations, mais vérifiez et approuvez les modifications apportées aux stratégies d’accès aux ressources.

Commentaires

Cette page a-t-elle été utile ?

Dernière mise à jour : 2026-10-27