Vytvořte a ověřte zásadu MXC

Zásady MXC popisují, k čemu má úloha přístup. Začněte s ve výchozím nastavení zakázanými oprávněními, přidejte pouze prostředky potřebné pro konkrétní úkol a ověřte výsledek reprezentativními vstupy na každé platformě, kterou vaše aplikace podporuje. Každý back-end také poskytuje prostředky operačního systému potřebné ke spuštění úlohy; implicitní zákaz neznamená, že proces běží bez systémového prostředí.

Udržujte rozhodnutí o zásadách v kódu důvěryhodné aplikace. Nástroj, modul plug-in, skript nebo příkaz vygenerovaný AI může hlásit, co potřebuje, ale neměl by vybrat vlastní model omezení ani rozšířit svá vlastní oprávnění.

Porozumět zásadám a konfiguraci

MXC odděluje oprávnění k prostředkům od nastavení pro spuštění příkazu:

  • Nastavení zásad popisují záměr pro různé platformy, jako jsou čitelné cesty, zapisovatelné cesty, cíle sítě, přístup k uživatelskému rozhraní a časový limit.
  • Nastavení spuštění přidávají příkaz, pracovní adresář, prostředí a výběr izolace.

V sadách SDK V1 nese ContainerRequest obojí. V .NET vytvořte ContainerRequest z příkazu, nastavte jeho zásady a vlastnosti spuštění a volejte MxcContainer.RunAsync nebo API pro spuštění procesu. V TypeScriptu předejte objekt ContainerRequest do run nebo do funkce spawn. V Rustu ContainerRequest vytvořte strukturu a předejte ji do v1::run nebo funkce spawn. Pokud vaše úloha nepotřebuje konkrétní back-end, upřednostňujte abstraktní záměr omezení Process.

Následující jazykově neutrální nastavení zásad popisují úlohu v rámci úložiště. Používají názvy vlastností TypeScriptu ContainerRequest; .NET používá stejnou strukturu s názvy PascalCase, jako je ReadonlyPaths, a Rust používá názvy snake_case, jako je readonly_paths. Nejsou to úplné požadavky: neobsahují příkaz ani nevybírejí back-end. Vytvořte adresáře a nahraďte cesty před jejich přizpůsobením.

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

Místo kopírování vlastností požadavku do raw execution configuration použijte typy sady SDK. Struktury se liší: například timeoutMs požadavku se mapuje na process.timeout konfigurace, ui.allowInputInjection se mapuje na ui.injection a network.runtimeConfig se mapuje na oddíl nejvyšší úrovně runtimeConfig. Kompletní příklady jazyka C#, TypeScript a Rust najdete v rychlém startu sady SDK .

Vyberte kompatibilní schéma

Mějte tyto tři otázky oddělené:

Osa slučitelnosti Co zkontrolovat
SDK a vydání produktu Jaká rozhraní API a komponenty modulu runtime balíček poskytuje
Schéma zásady Který přesný konfigurační kontrakt release přijímá
Možnosti hostitele Která omezení může vybrané prostředí vynutit za běhu

Sady SDK MXC 1.0 V1 interně používají stabilní schéma 1.0.0, takže v ContainerRequest nezadáváte verzi schématu. Verze schématu platí jenom v případě, že vytvoříte nezpracovanou konfiguraci spuštění ve formátu JSON, například soubor pro nástroj příkazového řádku wxc-exec.

Nezpracovaná konfigurace musí deklarovat přesný registrovaný version. MXC 1.0 přijímá 1.0.0, aktuální stabilní schéma a 0.9.0-alphaminimální podporované schéma. MXC odmítne chybějící verzi, vyřazené verze starší než 0.9.0-alpha, například 0.8.0-alpha, a neregistrované zápisy, například 1.0 nebo 1.0.1. Vývojová 1.1.0-alpha smlouva se může před publikováním změnit, takže ji nepoužívejte pro produkční konfigurace. Jeho výběr neopravňuje k použití experimentálních back-endů.

Zachovejte sady SDK a nativní komponenty modulu runtime ze stejného vydání společně. Viz verzování schématu MXC pro registrované kontrakty.

Vymezit rozsah přístupu k souborům

Klasifikujte jednotlivé cesty podle toho, jak je úloha používá:

Access Použijte jej pro
Read-only Zdroj, nástroje, knihovny a konfigurace, které musí úloha kontrolovat, ale nesmí je měnit
Čtení a zápis Výstup, mezipaměť nebo dočasný adresář specifický pro úlohu
Odmítnuto Přihlašovací údaje, nesouvisející úložiště, citlivá konfigurace a užší cesty v rámci širšího oprávnění

Povolte co nejužší praktický přístup. Pokud například příkaz zapíše pouze výstup testu, udělte přístup k adresáři výsledků testů místo kořenového adresáře úložiště. Považujte cesty zjištěné z proměnných prostředí, správců balíčků nebo vyhledáváním nástrojů jako kandidáty na kontrolu, nikoli automaticky schválené cesty.

Zahrňte binární soubory nástroje, knihovny, konfiguraci a dočasné cesty, které workload skutečně potřebuje. SDK poskytují pomocné nástroje pro zjišťování souborových systémů, ale jejich výsledky nejsou schválenou zásadou. Před přidáním zkontrolujte jednotlivé kandidátské cesty.

Nastavení pracovního adresáře neuděluje přístup k danému adresáři. Přidejte ho explicitně do příslušného seznamu souborových systémů.

Vyhněte se spoléhání na pravidlo překrývající se cesty, pokud jste ho netestovali s vybraným back-endem. Back-endy používají různé mechanismy přístupu k souborům a některé nemůžou reprezentovat pravidlo zamítnutí v mapovaném nebo připojeném adresáři.

Řídit přístup k síti

Pokud to úloha nevyžaduje, zachovejte odepření síťového přístupu. Zvolte síťový model, který může vybraný back-end vynutit:

Model Použijte jej pro
Bez externího přístupu Analýza nebo transformace, která potřebuje pouze přidělené místní prostředky
Přímý přístup pomocí pravidel IP/CIDR, protokolu a portů Úloha, která vyžaduje konkrétní přímá připojení, například TCP ke známému endpointu služby
HTTP(S) prostřednictvím proxy serveru poskytnutého aplikací Požadavky, jejichž cíle nebo oprávnění na úrovni aplikace řídí váš proxy server

Směrová zásada sítě odděluje:

  • Odchozí provoz dat z úlohy do cílů sítě.
  • Ingress z privátních nebo místních sítí do listenerů v úloze.
  • Zpětná smyčka hostitele mezi úlohou a službami na hostiteli v obou směrech.

Pravidla IP/CIDR a portu neidentifikují aplikační protokol ani název hostitele. Povolení portu TCP 443 neznamená, že připojení používá protokol HTTPS nebo dosáhne pouze jedné pojmenované služby. Požadavky DNS můžou také vyžadovat přístup, když úloha přímo překládá cílové adresy.

Podporovaná schémata odmítnou vyřazená síťová pole, například defaultPolicy, allowedHosts, blockedHostsa network.proxy. Místo toho použijte směrová pole egress a ingress. Podívejte se na příklady síťových zásad.

Použít vlastní síťový proxy server

Hostitelská aplikace dodává a spouští proxy server před tím, než spustí úlohu. MXC neposkytuje ani nespravuje produkční proxy server. Proxy server rozhoduje o tom, které požadavky a cíle povolí; MXC nakonfiguruje podporované klienty tak, aby ho používali, a uplatní síťová omezení backendu.

Směrový požadavek používá nastavení sekce sítě runtimeConfig.networkProxy k identifikaci koncového bodu zpětné smyčky HTTP(S) s explicitním portem. V konfiguraci nezpracovaného spuštění je toto nastavení položkou nejvyšší úrovně runtimeConfig.networkProxy. Tento koncový bod je konfigurace modulu runtime, nikoli seznam povolených položek aplikační vrstvy. Režim proxy vyžaduje výchozí zákaz odchozí komunikace a nedá se kombinovat s pravidly přímého povolení nebo odepření odchozí komunikace.

Směrování klientů a vynucování se liší. Proměnné prostředí proxy serveru nebo nastavení platformy sdělují spolupracujícím klientům HTTP, kam mají odesílat požadavky. Cesta vynucení pouze proxy serveru musí také bránit přímému připojení k internetu; samotná kooperativní konfigurace proxy toto omezení nezřídí.

MXC transparentně nepřesměrovává SSH, libovolné TCP/UDP ani jiné protokoly jiné než HTTP prostřednictvím proxy serveru HTTP(S). Chování zpětné smyčky hostitele a privátní sítě se také liší podle back-endu. Projděte si příklad konfigurace vlastního proxy serveru a jeho předpoklady místo toho, abyste předpokládali, že stejný fragment funguje všude.

Omezit přístup k uživatelskému rozhraní

Ve výchozím nastavení nepovolujte úloze na pozadí vytvářet okna, číst nebo zapisovat schránku nebo simulovat vstup z klávesnice a ukazatele. Přidat přístup k uživatelskému rozhraní pouze v případech, kdy je součástí zamýšlené uživatelské zkušenosti úlohy.

Injektování vstupu znamená syntetický vstup z klávesnice nebo ukazovacího zařízení, nikoli vkládání libovolného kódu do jiného procesu.

Ovládací prvky uživatelského rozhraní jsou závislé na hostiteli a back-endu. Pomocí informací o podpoře modulu runtime ověřte každé omezení, které váš bezpečnostní návrh vyžaduje.

Vázané provádění

Nastavte časový limit pro každou akci agenta, volání nástroje nebo skript, který by se měl dokončit ve známé lhůtě. Poskytněte pouze proměnné prostředí, které proces potřebuje, a tajné údaje uchovávejte mimo prostředí procesu i čitelné cesty k souborům. Nepředpokládejte, že vynechání prostředí vytvoří prázdné prostředí: výchozí nastavení back-endu a možnosti dědičnosti sady SDK se liší.

Zvolte životní cyklus, který odpovídá úkolu. Upřednostněte jednorázové spuštění pro nezávislé příkazy. Sandbox s podporou stavu používejte jenom v případě, že příkazy musí sdílet nainstalované nástroje, identitu, soubory nebo stav operačního systému.

Ověřte platné zásady

Před odesláním zásady:

  1. Použijte v sadě SDK funkci runtime discovery a zkontrolujte požadavky vybraného back-endu.
  2. Vytvořte konfiguraci a zpracujte chyby ověření zásad nebo chyby způsobené nedostupností backendu, aniž byste oslabili zásadu.
  3. Spusťte reprezentativní úspěšné scénáře s prostředky, které by měla úloha používat.
  4. Spusťte negativní případy, které se pokoušejí číst tajemství, zapisovat mimo výstupní adresář, používat neschválené síťové cesty nebo přistupovat k nepovolenému uživatelskému rozhraní.
  5. Pomocí výukového režimu můžete prošetřit chybějící přístup a před změnou zásad zkontrolovat jednotlivé výsledky.
  6. Odeberte všechna nastavení učení nebo auditování a spusťte jeden závěrečný test vynucení.

Selže, pokud hostitel nemůže vynutit požadované opatření. Nevybírejte automaticky back-end s širším přístupem ani neodebírejte pole zásad, aby se úloha spustila. Úspěšná analýza nebo spuštění není důkazem, že každé zamýšlené omezení platí.

Související obsah

  • Poslední aktualizace v