Een MXC-beleid maken en valideren

Een MXC-beleid beschrijft waartoe een workload toegang heeft. Begin met machtigingen die standaard zijn geweigerd, voeg alleen de resources toe die vereist zijn voor een specifieke taak en valideer het resultaat met representatieve invoer op elk platform dat door uw app wordt ondersteund. Elke back-end biedt ook de besturingssysteemresources die nodig zijn om een workload te starten; deny-by-default betekent niet dat het proces wordt uitgevoerd zonder een systeemomgeving.

Bewaar beleidsbeslissingen in vertrouwde app-code. Een hulpprogramma, invoegtoepassing, script of door AI gegenereerde opdracht kan rapporteren wat het nodig heeft, maar het mag geen eigen insluitingsmodel selecteren of zijn eigen toegang uitbreiden.

Begrijp beleid en configuratie

MXC scheidt resourcemachtigingen van de instellingen waarmee een opdracht wordt uitgevoerd:

  • Beleidsinstellingen beschrijven platformoverschrijdende intenties, zoals leesbare paden, schrijfbare paden, netwerkbestemmingen, ui-toegang en een time-out.
  • Uitvoeringsinstellingen voegen de opdracht, werkmap, omgeving en insluitingsoptie toe.

In de V1-SDK's bevat een ContainerRequest beide. Maak in .NET een ContainerRequest op basis van de opdracht, stel de bijbehorende beleids- en uitvoeringseigenschappen in en roep MxcContainer.RunAsync of een spawn-API aan. Geef in TypeScript een ContainerRequest object door aan run of een spawn-functie. Bouw in Rust een ContainerRequest struct en geef deze door aan v1::run of een spawn-functie. Geef de voorkeur aan de abstracte Process containment intent, tenzij uw workload een bepaalde back-end nodig heeft.

In de volgende taalneutrale beleidsinstellingen wordt een taak met repositorybereik beschreven. Ze gebruiken de namen van de TypeScript-eigenschappenContainerRequest; .NET gebruikt dezelfde structuur met PascalCase-namen zoals ReadonlyPaths, en Rust gebruikt snake_case namen zoals readonly_paths. Ze zijn geen volledig verzoek: ze bevatten geen commando of selecteren een back-end. Maak de mappen en vervang de paden voordat u ze aanpast.

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

Gebruik de SDK-typen in plaats van aanvraageigenschappen te kopiëren naar een onbewerkte uitvoeringsconfiguratie. De vormen verschillen: de timeoutMs van de aanvraag wordt bijvoorbeeld toegewezen aan de process.timeout van de configuratie, ui.allowInputInjection wordt toegewezen aan ui.injection, en network.runtimeConfig wordt toegewezen aan de sectie op het hoogste niveau runtimeConfig. Zie de SDK-quickstart voor volledige voorbeelden van C#, TypeScript en Rust.

Een compatibel schema kiezen

Houd deze drie vragen gescheiden:

Compatibiliteitsas Wat u moet controleren
SDK en productrelease Welke API's en runtime-onderdelen het pakket biedt
Beleidsschema Welk configuratiecontract exact door de release wordt geaccepteerd
Hostmogelijkheden Welke beperkingen de geselecteerde omgeving tijdens runtime kan afdwingen

De MXC 1.0 V1 SDK's maken intern gebruik van het stabiele 1.0.0 schema, zodat u geen schemaversie in een ContainerRequest hoeft op te geven. Een schemaversie is alleen van toepassing wanneer u een onbewerkte JSON-uitvoeringsconfiguratie opstelt, zoals een bestand voor het wxc-exec opdrachtregelprogramma.

Een onbewerkte configuratie moet een exacte geregistreerde version declareren. MXC 1.0 accepteert 1.0.0, het huidige stabiele schema en 0.9.0-alphahet minimaal ondersteunde schema. MXC wijst een ontbrekende versie af, buiten gebruik gestelde versies ouder dan 0.9.0-alpha, zoals 0.8.0-alpha, en niet-geregistreerde spellingen zoals 1.0 of 1.0.1. Het 1.1.0-alpha ontwikkelingscontract kan vóór publicatie worden gewijzigd, dus gebruik het niet voor productieconfiguraties. Het selecteren hiervan autoriseert experimentele backends niet.

Zorg ervoor dat SDK- en native runtimeonderdelen uit dezelfde release samen komen. Zie MXC-schemaversiebeheer voor de geregistreerde contracten.

Bestandstoegang beperken

Classificeer elk pad op basis van de wijze waarop de workload dit gebruikt:

Toegang Gebruik het voor
Read-only Bron, hulpprogramma's, bibliotheken en configuratie die door de workload moeten worden gecontroleerd, maar niet moeten worden gewijzigd
Lezen-schrijven Een taakspecifieke uitvoer, cache of tijdelijke map
Geweigerd Inloggegevens, niet-gerelateerde repositories, gevoelige configuratie en smallere paden binnen een bredere machtiging

Geef het smalste praktische toegangspad. Verleen bijvoorbeeld toegang tot een map met testresultaten in plaats van de hoofdmap van de opslagplaats wanneer een opdracht alleen testuitvoer schrijft. Behandel paden die zijn gedetecteerd vanuit omgevingsvariabelen, pakketbeheerders of hulpprogramma's als kandidaten voor beoordeling, niet als automatische toekenningen.

Voeg de binaire hulpprogrammabestanden, bibliotheken, configuratie en tijdelijke paden toe die de workload daadwerkelijk nodig heeft. De SDK's bieden helpers voor bestandssysteemdetectie, maar hun resultaten vormen geen officieel beleid. Controleer elk kandidaatpad voordat u het toevoegt.

Als u een werkdirectory instelt, verleent u geen toegang tot die directory. Voeg deze expliciet toe aan de juiste bestandssysteemlijst.

Vermijd dat u vertrouwt op een overlappende padregel, tenzij u deze hebt getest met de geselecteerde back-end. Back-ends maken gebruik van verschillende mechanismen voor bestandstoegang en sommige kunnen geen weigerregel in een gekoppelde of gekoppelde map ondersteunen.

Netwerktoegang regelen

Netwerktoegang geweigerd houden, tenzij deze door de taak is vereist. Kies een netwerkmodel dat door de geselecteerde back-end kan worden afgedwongen:

Model Gebruik het voor
Geen externe toegang Analyse of transformatie waarvoor alleen toegekende lokale resources nodig zijn
Directe toegang met IP-/CIDR-, protocol- en poortregels Een taak die specifieke directe verbindingen nodig heeft, zoals TCP met een bekend service-eindpunt
HTTP(S) via een door de toepassing geleverde proxy Aanvragen waarvan uw proxy de bestemmingen of machtigingen op toepassingsniveau beheert

Gericht netwerkbeleid maakt onderscheid tussen:

  • Uitgaand verkeer van de workload naar netwerkbestemmingen.
  • Ingress van privénetwerken of lokale netwerken naar listeners in de workload.
  • Host loopback tussen de workload en services op de host, in beide richtingen.

IP-/CIDR- en poortregels identificeren geen toepassingsprotocol of hostnaam. Door TCP-poort 443 toe te staan, betekent dit niet dat de verbinding HTTPS gebruikt of slechts één benoemde service bereikt. DNS-aanvragen kunnen ook toegang nodig hebben wanneer de workload bestemmingen rechtstreeks oplost.

Ondersteunde schema's weigeren de buiten gebruik gestelde netwerkvelden, zoals defaultPolicy, allowedHosts, blockedHosts en network.proxy. Gebruik in plaats daarvan de directionele egress- en ingress-velden. Zie voorbeelden van netwerkbeleid.

Een aangepaste netwerkproxy gebruiken

Uw host-app levert en start de proxy voordat deze de workload start. MXC biedt geen productieproxy en beheert er ook geen. De proxy bepaalt welke aanvragen en bestemmingen worden toegestaan; MXC configureert ondersteunde clients om deze te gebruiken en past de netwerkbeperkingen van de back-end toe.

De gerichte aanvraag maakt gebruik van de instelling runtimeConfig.networkProxy van de netwerksectie om een HTTP(S)-loopback-eindpunt te identificeren met een expliciete poort. In een onbewerkte uitvoeringsconfiguratie is deze instelling het element op het hoogste niveau runtimeConfig.networkProxy. Dit eindpunt is runtimeconfiguratie, niet een toelatingslijst op toepassingsniveau. De proxymodus vereist een standaard-weigering voor uitgaand verkeer en kan niet worden gecombineerd met regels voor het toestaan of weigeren van directe uitgaande verbindingen.

Clientrouting en afdwinging zijn verschillend. Proxyomgevingsvariabelen of platforminstellingen vertellen HTTP-clients die proxy's ondersteunen waar aanvragen moeten worden verzonden. Een proxy-only afdwingingspad moet ook directe internetverbindingen voorkomen; alleen een meewerkende proxyconfiguratie stelt die beperking niet vast.

MXC leidt SSH, willekeurige TCP/UDP of andere niet-HTTP-protocollen niet transparant om via de HTTP(S)-proxy. Het gedrag van host-loopback en privénetwerk verschilt ook per back-end. Bekijk het voorbeeld van de aangepaste proxyconfiguratie en de bijbehorende vereisten in plaats van ervan uit te gaan dat hetzelfde fragment overal werkt.

UI-toegang beperken

Standaard is het niet toegestaan dat een achtergrondworkload vensters maakt, het klembord leest of schrijft, of toetsenbord- en aanwijzerinvoer injecteert. Voeg alleen gebruikersinterfacetoegang toe als deze deel uitmaakt van de beoogde gebruikerservaring van de workload.

Inputinjectie betekent synthetische toetsenbord- of aanwijzerinvoer, geen willekeurige code-injectie in een ander proces.

UI-elementen zijn afhankelijk van host en back-end. Gebruik runtime-ondersteuningsinformatie om elke beperking te verifiëren die uw beveiligingsontwerp vereist.

Gebonden uitvoering

Stel een time-out in voor elke agentactie, hulpprogramma-aanroep of script dat binnen een bekende periode moet worden voltooid. Geef alleen de omgevingsvariabelen op die het proces nodig heeft en houd geheimen buiten zowel de procesomgeving als leesbare bestandspaden. Stel niet dat het weglaten van de omgeving een lege omgeving maakt: de standaardinstellingen van de back-end en sdk-overnameopties verschillen.

Kies een levenscyclus die overeenkomt met de taak. Geef bij onafhankelijke opdrachten de voorkeur aan eenmalige uitvoering. Gebruik een toestandbewuste sandbox alleen wanneer opdrachten geïnstalleerde hulpprogramma's, identiteit, bestanden of de toestand van het besturingssysteem moeten delen.

Het effectieve beleidselement valideren

Voordat u een polis verzendt:

  1. Gebruik de runtimedetectie van uw SDK en controleer de vereisten van de geselecteerde back-end.
  2. Maak de configuratie en verwerk beleidsvalidatie- of fouten door een niet-beschikbare back-end zonder het beleid te verzwakken.
  3. Voer representatieve succescases uit met de resources die de workload moet gebruiken.
  4. Voer negatieve gevallen uit die proberen geheimen te lezen, buiten de uitvoermap te schrijven, een niet-goedgekeurd netwerkpad te gebruiken of toegang te krijgen tot de gebruikersinterface die niet is toegestaan.
  5. Gebruik Learning Mode om ontbrekende toegang te onderzoeken en bekijk elk resultaat voordat u het beleid wijzigt.
  6. Verwijder alle leer- of controle-instellingen en voer één laatste handhavingstest uit.

Mislukken wanneer de host geen vereist besturingselement kan afdwingen. Selecteer niet stilzwijgend een back-end met bredere toegang en verwijder geen beleidsveld om een werkbelasting uit te voeren. Succesvol parsen of starten is geen bewijs dat elke beoogde beperking geldt.

Verwante onderwerpen

  • Laatst bijgewerkt om