Redigere e convalidare un criterio MXC

Un criterio MXC descrive a cosa può accedere un carico di lavoro. Iniziare con autorizzazioni con rifiuto predefinito, aggiungere solo le risorse necessarie per un'attività specifica e convalidare il risultato con input rappresentativi su ogni piattaforma supportata dall'app. Ogni back-end fornisce anche le risorse del sistema operativo necessarie per avviare un carico di lavoro; deny per impostazione predefinita non significa che il processo venga eseguito senza un ambiente di sistema.

Mantenere le decisioni relative alle policy nel codice dell'app attendibile. Uno strumento, un plug-in, uno script o un comando generato dall'intelligenza artificiale può segnalare ciò di cui ha bisogno, ma non deve selezionare il proprio modello di contenimento o espandere il proprio accesso.

Comprendere criteri e configurazione

MXC separa le autorizzazioni delle risorse dalle impostazioni per eseguire un comando:

• Le impostazioni di Policy descrivono la finalità multipiattaforma, ad esempio percorsi leggibili, percorsi scrivibili, destinazioni di rete, accesso all'interfaccia utente e timeout.
• Le impostazioni di esecuzione aggiungono il comando, la directory di lavoro, l'ambiente e la selezione di contenimento.

Negli SDK della versione 1, un ContainerRequest contiene entrambi. In .NET creare un oggetto ContainerRequest dal comando, impostarne le proprietà di esecuzione e i criteri e chiamare MxcContainer.RunAsync o un'API di spawn. In TypeScript, passa un oggetto ContainerRequest a run o a una funzione spawn. In Rust, creare una struct ContainerRequest e passarla a v1::run o a una funzione spawn. Preferisci il criterio di contenimento astratto Process a meno che il carico di lavoro non richieda un particolare back-end.

Le impostazioni dei criteri indipendenti dalla lingua seguenti descrivono un'attività con ambito repository. Usano i nomi delle proprietà TypeScriptContainerRequest; .NET usa la stessa struttura con nomi PascalCase, ReadonlyPathsad esempio e Rust usa nomi snake_case, ad esempio readonly_paths. Non sono una richiesta completa: non contengono un comando né selezionano un back-end. Creare le directory e sostituire i percorsi prima di adattarli.

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

Usare i tipi SDK anziché copiare le proprietà della richiesta in una configurazione di esecuzione non elaborata. Le forme differiscono: ad esempio, timeoutMs della richiesta corrisponde a process.timeout, ui.allowInputInjection corrisponde a ui.injection e network.runtimeConfig corrisponde alla sezione runtimeConfig di primo livello della configurazione. Vedere l'avvio rapido dell'SDK per esempi completi di C#, TypeScript e Rust.

Scegliere uno schema compatibile

Tenere separate queste tre domande:

Gli SDK MXC 1.0 V1 usano internamente lo schema stabile 1.0.0, quindi non si specifica una versione dello schema in un ContainerRequest. Una versione dello schema si applica solo quando si crea una configurazione di esecuzione in formato JSON non elaborato, ad esempio un file per lo strumento a riga di comando wxc-exec.

Una configurazione non elaborata deve dichiarare un elemento registrato esatto version. MXC 1.0 accetta 1.0.0, lo schema stabile corrente e 0.9.0-alpha, lo schema minimo supportato. MXC rifiuta una versione mancante, versioni ritirate precedenti a 0.9.0-alpha, ad esempio 1.0, e ortografie non registrate, ad esempio 0.8.0-alpha o 1.0.1. Il 1.1.0-alpha contratto di sviluppo può cambiare prima della pubblicazione, quindi non usarlo per le configurazioni di produzione. La selezione non autorizza i back-end sperimentali.

Mantieni insieme gli SDK e i componenti di runtime nativi della stessa versione. Vedere Controllo delle versioni dello schema MXC per i contratti registrati.

Definire l'ambito dell'accesso ai file

Classificare ogni percorso in base al modo in cui il carico di lavoro lo usa:

Concedi l'accesso minimo necessario. Ad esempio, concedere una directory test-results anziché la radice del repository quando un comando scrive solo l'output di test. Considera i percorsi individuati da variabili di ambiente, gestori pacchetti o ricerche di strumenti come candidati per la revisione e non come autorizzazioni automatiche.

Includi i file binari, le librerie, la configurazione e i percorsi temporanei effettivamente necessari per il carico di lavoro. Gli SDK forniscono helper per l'individuazione del file system, ma i loro risultati non costituiscono una politica approvata. Esaminare ogni percorso candidato prima di aggiungerlo.

L'impostazione di una directory di lavoro non garantisce l'accesso a tale directory. Aggiungerlo all'elenco di file system appropriato in modo esplicito.

Evitare di basarsi su una regola del percorso sovrapposto, a meno che non sia stata testata con il back-end selezionato. I back-end usano meccanismi di accesso ai file diversi e alcuni non possono rappresentare una regola di negazione all'interno di una directory mappata o montata.

Controllo dell'accesso alla rete

Mantenere negato l'accesso alla rete a meno che l'attività non lo richieda. Scegliere un modello di rete che il back-end selezionato può applicare:

La politica di rete direzionale separa:

• Traffico in uscita dal carico di lavoro alle destinazioni di rete.
• Ingress da reti private o locali ai listener nel workload.
• Loopback host tra il carico di lavoro e i servizi sull'host, in entrambe le direzioni.

Le regole IP/CIDR e porta non identificano un protocollo applicazione o un nome host. Se si consente la porta TCP 443, non garantisce che la connessione usi HTTPS o raggiunga solo un servizio con nome specifico. Le richieste DNS possono anche richiedere che l'accesso sia consentito quando il carico di lavoro risolve direttamente le destinazioni.

Gli schemi supportati rifiutano i campi di rete deprecati, ad esempio defaultPolicy, allowedHosts, blockedHosts, e network.proxy. Usare invece i campi direzionali egress e ingress . Vedere esempi di criteri di rete.

Usare un proxy di rete personalizzato

L'app host fornisce e avvia il proxy prima di avviare il carico di lavoro. MXC non fornisce o gestisce un proxy di produzione. Il proxy decide quali richieste e destinazioni consentire; MXC configura i client supportati per usarlo e applica le restrizioni di rete del back-end.

La richiesta direzionale usa l'impostazione della sezione di runtimeConfig.networkProxy rete per identificare un endpoint di loopback HTTP(S) con una porta esplicita. In una configurazione di esecuzione raw, questa impostazione è il runtimeConfig.networkProxy di livello superiore. Questo endpoint è una configurazione di runtime, non un elenco di elementi consentiti a livello di applicazione. La modalità proxy richiede il traffico in uscita con criterio predefinito di negazione e non può essere combinata con regole di autorizzazione o negazione diretta in uscita.

Il routing e l'applicazione dei client sono diversi. Le variabili di ambiente proxy o le impostazioni della piattaforma indicano ai client HTTP che collaborano dove inviare richieste. Un percorso di enforcement tramite solo proxy deve anche impedire connessioni Internet dirette; una configurazione di proxy cooperante da sola non stabilisce tale restrizione.

MXC non reindirizza in modo trasparente SSH, TCP/UDP arbitrario o altri protocolli non HTTP tramite il proxy HTTP(S). Anche il comportamento del loopback dell'host e della rete privata varia in base al back-end. Esaminare l'esempio di configurazione del proxy personalizzato e i relativi prerequisiti invece di presupporre che lo stesso frammento funzioni ovunque.

Limitare l'accesso all'interfaccia utente

Per impostazione predefinita, non consentire a un carico di lavoro in background di creare finestre, leggere o scrivere gli Appunti o inserire input da tastiera e puntatore. Aggiungere l'accesso all'interfaccia utente solo quando fa parte dell'esperienza utente prevista del carico di lavoro.

L'iniezione di input significa input sintetico da tastiera o puntatore, non l'iniezione arbitraria di codice in un altro processo.

I controlli dell'interfaccia utente sono dipendenti dall'host e dal back-end. Usare le informazioni di supporto di runtime per verificare ogni restrizione richiesta dalla progettazione della sicurezza.

Esecuzione vincolata

Impostare un timeout per ogni azione dell'agente, chiamata dello strumento o script che deve terminare entro un periodo noto. Fornire solo le variabili di ambiente necessarie al processo e mantenere i segreti fuori sia dall'ambiente del processo sia dai file o dai percorsi di file leggibili. Non presupporre che l'omissione dell'ambiente crei un ambiente vuoto: le impostazioni predefinite back-end e le opzioni di ereditarietà dell'SDK differiscono.

Scegliere un ciclo di vita adatto al task. Preferire l'esecuzione singola per i comandi indipendenti. Usare una sandbox con gestione dello stato solo quando i comandi devono condividere gli strumenti installati, l'identità, i file o lo stato del sistema operativo.

Convalidare il criterio effettivo

Prima di distribuire un criterio/policy:

1. Usare la runtime discovery dell'SDK e controllare i prerequisiti del back-end selezionato.
2. Creare la configurazione e gestire gli errori di convalida della policy o di back-end non disponibile senza indebolire la policy.
3. Eseguire casi di successo rappresentativi con le risorse che il carico di lavoro deve usare.
4. Eseguire casi negativi che tentano di leggere i segreti, scrivere all'esterno della directory di output, usare un percorso di rete non approvato o accedere all'interfaccia utente non consentita.
5. Usare Learning Mode per analizzare l'accesso mancante ed esaminare ogni risultato prima di modificare i criteri.
6. Rimuovere tutte le impostazioni di apprendimento o controllo ed eseguire un test finale in modalità di applicazione.

Non riuscire quando l'host non può applicare un controllo obbligatorio. Non selezionare senza avvisare l'utente un back-end con accesso più ampio o rimuovere un campo dei criteri per eseguire un carico di lavoro. Un parsing o un avvio riuscito non è una prova che tutte le restrizioni previste siano rispettate.

Contenuti correlati

• Panoramica dei contenitori di esecuzione di Microsoft
• Opzioni di contenimento MXC e supporto della piattaforma
• Crea e perfeziona i criteri MXC con la modalità di apprendimento
• Esempi di criteri MXC