Rédiger et valider une stratégie MXC

Une stratégie MXC décrit à quoi une charge de travail peut accéder. Commencez par refuser toutes les autorisations par défaut, ajoutez uniquement les ressources nécessaires à une tâche spécifique et validez le résultat à l’aide d’entrées représentatives sur chaque plateforme prise en charge par votre application. Chaque back-end fournit également les ressources du système d’exploitation nécessaires pour démarrer une charge de travail ; le refus par défaut ne signifie pas que le processus s’exécute sans environnement système.

Conservez les décisions relatives aux stratégies dans le code de l’application approuvé. Un outil, un plug-in, un script ou une commande générée par l’IA peut signaler ce dont il a besoin, mais il ne doit pas sélectionner son propre modèle de confinement ou étendre son propre accès.

Comprendre la stratégie et la configuration

MXC sépare les autorisations de ressource des paramètres utilisés pour exécuter une commande :

• Les paramètres de stratégie décrivent l’intention multiplateforme, telles que les chemins lisibles, les chemins accessibles en écriture, les destinations réseau, l’accès à l’interface utilisateur et un délai d’expiration.
• Les paramètres d’exécution définissent la commande, le répertoire de travail, l’environnement et le choix du mécanisme de confinement.

Dans les kits SDK V1, un ContainerRequest porte les deux. Dans .NET, créez une ContainerRequest à partir de la commande, définissez ses propriétés de stratégie et d’exécution, puis appelez MxcContainer.RunAsync ou une API de spawn. En TypeScript, transmettez un objet ContainerRequest à run ou à une fonction de création de processus. En Rust, créez une structure ContainerRequest et transmettez-la à v1::run ou à une fonction de création de processus. Préférez l’intention de confinement abstraite Process , sauf si votre charge de travail a besoin d’un back-end particulier.

Les paramètres de stratégie indépendants du langage suivants décrivent une tâche limitée à un dépôt. Ils utilisent les noms de propriétés TypeScript ContainerRequest ; .NET utilise la même structure avec des noms PascalCase tels que ReadonlyPaths, et Rust utilise des noms snake_case tels que readonly_paths. Ils ne constituent pas une demande complète : ils ne contiennent ni commande ni sélection de back-end. Créez les répertoires et remplacez les chemins avant de les adapter.

{
  "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
}

Utilisez les types sdk plutôt que de copier des propriétés de requête dans une configuration d’exécution brute. Les formes diffèrent : par exemple, le timeoutMs de la requête correspond au process.timeout de la configuration, ui.allowInputInjection correspond à ui.injection, et network.runtimeConfig correspond à la section runtimeConfig de niveau supérieur. Consultez le guide de démarrage rapide du Kit de développement logiciel (SDK) pour obtenir des exemples C#, TypeScript et Rust complets.

Choisir un schéma compatible

Gardez ces trois questions distinctes :

Les kits SDK MXC 1.0 V1 utilisent le schéma stable 1.0.0 en interne. Vous ne spécifiez donc pas de version de schéma dans un ContainerRequest. Une version de schéma s’applique uniquement lorsque vous créez une configuration d’exécution JSON brute, telle qu’un fichier pour l’outil wxc-exec en ligne de commande.

Une configuration brute doit déclarer un version exact et enregistré. MXC 1.0 accepte 1.0.0, le schéma stable actuel et 0.9.0-alphale schéma minimum pris en charge. MXC rejette une version manquante, les versions retirées antérieures à 0.9.0-alpha, telles que 0.8.0-alpha, ainsi que les variantes non enregistrées, telles que 1.0 ou 1.0.1. Le 1.1.0-alpha contrat de développement peut changer avant la publication. Ne l’utilisez donc pas pour les configurations de production. Sa sélection n’autorise pas les backends expérimentaux.

Conservez ensemble les composants sdk et runtime natifs de la même version. Consultez Gestion des versions du schéma MXC pour connaître les contrats enregistrés.

Délimiter l’accès aux fichiers

Classifiez chaque chemin d’accès par la façon dont la charge de travail l’utilise :

Accordez l’accès au chemin le plus restreint possible dans la pratique. Par exemple, accordez un répertoire de résultats de test au lieu de la racine du référentiel lorsqu’une commande écrit uniquement la sortie de test. Traitez les chemins découverts à partir des variables d’environnement, des gestionnaires de package ou des recherches d’outils comme éléments à examiner, et non comme des autorisations automatiques.

Incluez les fichiers binaires des outils, les bibliothèques, les fichiers de configuration et les chemins temporaires dont la charge de travail a réellement besoin. Les kits SDK fournissent des helpers de découverte de système de fichiers, mais leurs résultats ne constituent pas une politique approuvée. Passez en revue chaque chemin d’accès candidat avant de l’ajouter.

La définition d’un répertoire de travail ne donne pas accès à ce répertoire. Ajoutez-le explicitement à la liste de systèmes de fichiers appropriée.

Évitez de vous appuyer sur une règle de chemin qui se chevauche, sauf si vous l’avez testée avec le back-end sélectionné. Les back-ends utilisent différents mécanismes d’accès aux fichiers, et certains ne peuvent pas représenter une règle de refus à l’intérieur d’un répertoire mappé ou monté.

Contrôler l’accès réseau

Maintenez l’accès réseau refusé, sauf si la tâche l’exige. Choisissez un modèle réseau que le back-end sélectionné peut appliquer :

La stratégie réseau directionnelle distingue :

• Trafic sortant de la charge de travail vers les destinations réseau.
• Trafic entrant des réseaux privés ou locaux vers les écouteurs de la charge de travail.
• Boucle locale de l’hôte entre la charge de travail et les services exécutés sur l’hôte, dans les deux sens.

Les règles d’adresse IP/CIDR et de port n’identifient pas de protocole d’application ou de nom d’hôte. L’autorisation du port TCP 443 n’établit pas que la connexion utilise HTTPS ou qu’elle atteint uniquement un service nommé. Les requêtes DNS peuvent également nécessiter un accès lorsque la charge de travail résout directement les destinations.

Les schémas pris en charge rejettent les champs réseau retirés, tels que defaultPolicy, allowedHosts, blockedHosts et network.proxy. Utilisez plutôt les champs directionnels ingress et egress. Consultez les exemples de stratégie réseau.

Utiliser un proxy réseau personnalisé

Votre application hôte fournit et démarre le proxy avant de démarrer la charge de travail. MXC ne fournit pas ou ne gère pas de proxy de production. Le proxy décide quelles demandes et destinations autoriser ; MXC configure les clients pris en charge pour l’utiliser et applique les restrictions réseau du serveur principal.

La requête directionnelle utilise le paramètre runtimeConfig.networkProxy de la section réseau pour identifier un point de terminaison de bouclage HTTP(S) avec un port explicite. Dans une configuration d’exécution brute, ce paramètre correspond à l’élément de premier niveau runtimeConfig.networkProxy. Ce point de terminaison relève de la configuration d’exécution, et non d’une liste d’autorisation au niveau de la couche application. Le mode proxy nécessite un trafic sortant refusé par défaut et ne peut pas être combiné avec des règles d’autorisation ou de refus du trafic sortant direct.

Le routage du client et l’application des règles sont deux choses différentes. Les variables d’environnement du proxy ou les paramètres de la plateforme indiquent aux clients HTTP compatibles où envoyer les requêtes. Un mécanisme d’application via proxy uniquement doit également empêcher les connexions Internet directes ; une configuration proxy coopérative seule n’établit pas cette restriction.

MXC ne redirige pas en toute transparence SSH, TCP/UDP arbitraire ou d’autres protocoles non HTTP via le proxy HTTP(S). Le comportement de la boucle locale de l’hôte et des réseaux privés varie également selon le backend. Passez en revue l’exemple de configuration de proxy personnalisé et ses prérequis au lieu de supposer que le même fragment fonctionne partout.

Restreindre l’accès à l’interface utilisateur

Par défaut, n’autorisez pas une tâche en arrière-plan à créer des fenêtres, lire ou écrire dans le Presse-papiers, ou injecter une entrée de clavier et de pointeur. Ajoutez l’accès à l’interface utilisateur uniquement lorsqu’il fait partie de l’expérience utilisateur prévue de la charge de travail.

L’injection d’entrée signifie une entrée de clavier ou de pointeur synthétique, et non une injection de code arbitraire dans un autre processus.

Les contrôles de l’interface utilisateur dépendent de l’hôte et du backend. Utilisez les informations de prise en charge du runtime pour vérifier chaque restriction requise par votre conception de sécurité.

Exécution contrôlée

Définissez un délai d’expiration pour chaque action de l’agent, appel d’outil ou script qui doit se terminer dans une période connue. Fournissez uniquement les variables d’environnement dont le processus a besoin et conservez les secrets hors de l’environnement du processus et des chemins de fichiers lisibles. Ne partez pas du principe que l’omission de l’environnement crée un environnement vide : les valeurs par défaut du back-end et les options d’héritage du SDK diffèrent.

Choisissez un cycle de vie qui correspond à la tâche. Préférez l’exécution en une seule fois pour les commandes indépendantes. Utilisez un environnement sandbox tenant compte de l’état uniquement lorsque les commandes doivent partager les outils installés, l’identité, les fichiers ou l’état du système d’exploitation.

Valider la stratégie effective

Avant de déployer une stratégie :

1. Utilisez la découverte du runtime de votre Kit de développement logiciel (SDK) et vérifiez les prérequis du back-end sélectionné.
2. Créez la configuration et gérez les erreurs de validation de la stratégie ou d’indisponibilité du backend sans assouplir la stratégie.
3. Exécutez des scénarios de réussite représentatifs avec les ressources que la charge de travail doit utiliser.
4. Exécutez des cas négatifs qui tentent de lire des secrets, d’écrire en dehors du répertoire de sortie, d’utiliser un chemin réseau non approuvé ou d’accéder à l’interface utilisateur non autorisée.
5. Utilisez le Learning Mode pour rechercher les causes d’un accès manquant et passez en revue chaque résultat avant de modifier la politique.
6. Supprimez tous les paramètres d’apprentissage ou d’audit et exécutez un dernier test avec application effective de la stratégie.

Échoue lorsque l’hôte ne peut pas appliquer un contrôle requis. Ne sélectionnez pas silencieusement un back-end avec un accès plus large et ne supprimez pas un champ de stratégie afin de permettre à une charge de travail de s’exécuter. Une analyse ou un lancement réussi n’est pas une preuve que chaque restriction prévue est respectée.

Contenu connexe

• Vue d’ensemble des conteneurs d’exécution Microsoft
• Options de confinement MXC et prise en charge de la plateforme
• Créer et affiner des stratégies MXC avec le mode d’apprentissage
• Exemples de stratégies MXC