Twórz i weryfikuj zasady MXC

Zasada MXC opisuje, do czego może uzyskiwać dostęp obciążenie. Zacznij od uprawnień domyślnie odmawiających dostępu, dodaj tylko zasoby wymagane dla określonego zadania i zweryfikuj wynik z reprezentatywnymi danymi wejściowymi na każdej platformie obsługiwanej przez aplikację. Każdy backend udostępnia również zasoby systemu operacyjnego potrzebne do uruchomienia zadania roboczego; domyślna odmowa nie oznacza, że proces jest uruchamiany bez środowiska systemowego.

Podejmuj decyzje dotyczące zasad w zaufanym kodzie aplikacji. Narzędzie, wtyczka, skrypt lub wygenerowane przez sztuczną inteligencję polecenie może zgłaszać, czego potrzebuje, ale nie powinno wybierać własnego modelu izolacji ani rozszerzać własnego dostępu.

Poznaj zasady i konfigurację

MXC oddziela uprawnienia zasobów od ustawień służących do uruchamiania polecenia:

  • Ustawienia zasad opisują zamierzone działanie na różnych platformach, takie jak ścieżki czytelne, ścieżki z możliwością zapisu, miejsca docelowe sieci, dostęp do interfejsu użytkownika i limit czasu.
  • Ustawienia wykonywania obejmują polecenie, katalog roboczy, środowisko i wybór izolacji.

W zestawach SDK V1 element ContainerRequest pełni obie funkcje. W .NET utwórz element ContainerRequest na podstawie polecenia, ustaw jego właściwości zasad i wykonywania oraz wywołaj MxcContainer.RunAsync lub interfejs API do uruchamiania procesów. W języku TypeScript przekaż obiekt ContainerRequest do run lub funkcję tworzącą proces. W języku Rust utwórz strukturę ContainerRequest i przekaż ją do v1::run lub funkcji spawn. Preferowana jest abstrakcyjna intencja kontenera Process, chyba że obciążenie wymaga określonego backendu.

Następujące neutralne językowo ustawienia zasad opisują zadanie o zakresie repozytorium. Używają nazw właściwości TypeScriptContainerRequest; .NET używa tej samej struktury z nazwami PascalCase, takimi jak ReadonlyPaths, i Rust używa snake_case nazw, takich jak readonly_paths. Nie są one kompletnym żądaniem: nie zawierają polecenia ani nie wybierają backendu. Utwórz katalogi i zastąp ścieżki przed ich dostosowaniem.

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

Użyj typów zestawu SDK, a nie kopiowania właściwości żądania do surowej konfiguracji wykonania. Kształty różnią się: na przykład timeoutMs żądania mapuje na process.timeout konfiguracji, ui.allowInputInjection mapuje na ui.injection, a network.runtimeConfig mapuje na sekcję najwyższego poziomu runtimeConfig. Zobacz przewodnik Szybki start dla zestawu SDK , aby zapoznać się z kompletnymi przykładami języka C#, TypeScript i Rust.

Wybieranie zgodnego schematu

Zachowaj oddzielne trzy pytania:

Oś zgodności Co należy sprawdzić?
Zestaw SDK i wydanie produktu Jakie interfejsy API i składniki środowiska uruchomieniowego zapewnia pakiet
Schemat polityki Dokładnie którą umowę konfiguracji akceptuje wydanie
Możliwości hosta Ograniczenia, które wybrane środowisko może egzekwować w czasie wykonywania

Zestawy SDK MXC 1.0 v1 używają stabilnego 1.0.0 schematu wewnętrznie, więc nie określasz wersji schematu w elemecie ContainerRequest. Wersja schematu ma zastosowanie tylko wtedy, gdy tworzysz surową konfigurację wykonywania w formacie JSON, taką jak plik dla narzędzia wiersza polecenia wxc-exec.

Nieprzetworzona konfiguracja musi deklarować dokładnie zarejestrowane version. MxC 1.0 akceptuje 1.0.0, bieżący stabilny schemat, i 0.9.0-alpha, minimalny obsługiwany schemat. MXC odrzuca brak wersji, wycofane wersje wcześniejsze niż 0.9.0-alpha, takie jak 0.8.0-alpha, i niezarejestrowane pisownie, takie jak 1.0 lub 1.0.1. Kontrakt deweloperski 1.1.0-alpha może ulec zmianie przed publikacją, więc nie używaj go do konfiguracji produkcyjnych. Wybranie tej opcji nie autoryzuje eksperymentalnych backendów.

Zachowaj razem zestaw SDK i natywne składniki środowiska uruchomieniowego z tej samej wersji. Zobacz Wersjonowanie schematu MXC dla zarejestrowanych kontraktów.

Określ zakres dostępu do plików

Klasyfikuj każdą ścieżkę według sposobu, w jaki obciążenie z niej korzysta:

Dostęp Użyj go do
Tylko odczyt Źródło, narzędzia, biblioteki i konfiguracja, które obciążenie robocze musi sprawdzić, ale nie zmieniać
Czytaj-zapisz Dane wyjściowe, pamięć podręczna lub katalog tymczasowy specyficzne dla zadania
Odmówiony Poświadczenia, niepowiązane repozytoria, wrażliwa konfiguracja i węższe ścieżki w ramach szerszego uprawnienia

Przyznaj najmniej uprawniający praktyczny zakres. Na przykład przyznaj katalog test-results zamiast katalogu głównego repozytorium, gdy polecenie zapisuje tylko dane wyjściowe testu. Traktuj ścieżki odnalezione na podstawie zmiennych środowiskowych, menedżerów pakietów lub wyszukiwania narzędzi jako kandydatów do przeglądu, a nie automatycznych uprawnień.

Uwzględnij pliki binarne narzędzi, biblioteki, konfigurację i tymczasowe ścieżki, których obciążenie faktycznie potrzebuje. Zestawy SDK udostępniają narzędzia pomocnicze do wykrywania systemu plików, ale ich wyniki nie są zatwierdzoną polityką. Przed dodaniem należy przejrzeć każdą ścieżkę kandydującą.

Ustawienie katalogu roboczego nie udziela dostępu do tego katalogu. Dodaj ją jawnie do odpowiedniej listy systemów plików.

Unikaj polegania na nakładającej się regule ścieżki, chyba że przetestowano ją przy użyciu wybranego backendu. Backendy używają różnych mechanizmów dostępu do plików, a niektóre nie mogą reprezentować reguły odmowy wewnątrz zamapowanego lub zamontowanego katalogu.

Kontrola dostępu do sieci

Nie zezwalaj na dostęp sieciowy, chyba że zadanie tego wymaga. Wybierz model sieciowy, który wybrane zaplecze może wymusić:

Model Użyj go do
Brak dostępu zewnętrznego Analiza lub transformacja, która potrzebuje jedynie przyznanych zasobów lokalnych
Bezpośredni dostęp za pomocą reguł IP/CIDR, protokołu i portów Zadanie, które wymaga określonych połączeń bezpośrednich, takich jak TCP do znanego punktu końcowego usługi
Http(S) za pośrednictwem serwera proxy dostarczonego przez aplikację Żądania, których adresy docelowe lub uprawnienia na poziomie aplikacji kontroluje serwer proxy

Kierunkowa polityka sieciowa oddziela:

  • Egress z obciążenia do miejsc docelowych sieci.
  • Ruch przychodzący z sieci prywatnych lub lokalnych do listenerów w obciążeniu roboczym.
  • Pętla zwrotna hosta między obciążeniem a usługami na hoście, w obu kierunkach.

Reguły adresów IP/CIDR i portów nie identyfikują protokołu aplikacji ani nazwy hosta. Zezwolenie na port TCP 443 nie oznacza, że połączenie korzysta z protokołu HTTPS lub osiąga tylko jedną nazwaną usługę. Żądania DNS mogą również wymagać dostępu, gdy obciążenie robocze rozpoznaje miejsca docelowe bezpośrednio.

Obsługiwane schematy odrzucają wycofane pola sieciowe, takie jak defaultPolicy, blockedHosts, allowedHosts i network.proxy. Zamiast tego użyj pól kierunkowych egress i ingress . Zobacz przykłady zasad sieciowych.

Użyj niestandardowego serwera proxy sieciowego

Aplikacja hosta dostarcza i uruchamia serwer proxy przed uruchomieniem obciążenia roboczego. Usługa MXC nie udostępnia produkcyjnego serwera proxy ani nie zarządza nim. Serwer proxy decyduje, które żądania i adresy docelowe mają być zezwalane; usługa MXC konfiguruje obsługiwanych klientów tak, aby z niej korzystali, i stosuje ograniczenia sieci zaplecza.

Żądanie przekierowania używa ustawienia sekcji sieciowej runtimeConfig.networkProxy do identyfikowania punktu końcowego sprzężenia zwrotnego HTTP(S) z jawnym portem. W konfiguracji surowego wykonania to ustawienie jest elementem najwyższego poziomu runtimeConfig.networkProxy. Ten punkt końcowy to konfiguracja środowiska uruchomieniowego, a nie lista dozwolonych elementów na poziomie warstwy aplikacji. Tryb proxy wymaga domyślnie blokowanego ruchu wychodzącego i nie można go łączyć z bezpośrednimi regułami zezwalania lub blokowania ruchu wychodzącego.

Routing klienta i wymuszanie po stronie klienta różnią się. Zmienne środowiskowe serwera proxy lub ustawienia platformy informują współpracujących klientów HTTP, gdzie wysyłać żądania. Ścieżka wymuszania tylko do serwera proxy musi również uniemożliwiać bezpośrednie połączenia internetowe; sama współpracująca konfiguracja serwera proxy nie ustanawia tego ograniczenia.

Usługa MXC nie przekierowuje w sposób przezroczysty protokołu SSH, dowolnego protokołu TCP/UDP ani innych protokołów innych niż HTTP za pośrednictwem serwera proxy HTTP(S). Zachowanie pętli zwrotnej hosta i sieci prywatnej różni się również w zależności od backendu. Zapoznaj się z przykładem konfiguracji niestandardowego serwera proxy i jego wymaganiami wstępnymi zamiast zakładać, że ten sam fragment działa wszędzie.

Ogranicz dostęp do interfejsu użytkownika

Domyślnie nie zezwalaj obciążeniu w tle na tworzenie okien, odczytywanie ani zapisywanie schowka albo wstrzykiwanie danych wejściowych z klawiatury i wskaźnika. Dodaj dostęp do interfejsu użytkownika tylko wtedy, gdy jest on częścią zamierzonego doświadczenia użytkownika obciążenia.

Wstrzykiwanie danych wejściowych oznacza syntetyczne dane wejściowe z klawiatury lub wskaźnika, a nie dowolne wstrzyknięcie kodu do innego procesu.

Kontrolki interfejsu użytkownika zależą od hosta i backendu. Użyj informacji o obsłudze w czasie wykonywania, aby sprawdzić każde ograniczenie wymagane przez projekt zabezpieczeń.

Wiązane wykonanie

Ustaw limit czasu dla każdej akcji agenta, wywołania narzędzia lub skryptu, które powinny zostać zakończone w określonym czasie. Podaj tylko zmienne środowiskowe, których potrzebuje proces, i nie przechowuj sekretów ani w środowisku procesu, ani w czytelnych ścieżkach plików. Nie zakładaj, że pominięcie środowiska powoduje utworzenie pustego: domyślne ustawienia backendu i opcje dziedziczenia zestawu SDK różnią się.

Wybierz cykl życia odpowiedni do zadania. Preferuj jednorazowe uruchamianie dla niezależnych poleceń. Użyj piaskownicy obsługującej stan tylko wtedy, gdy polecenia muszą udostępniać zainstalowane narzędzia, tożsamość, pliki lub stan systemu operacyjnego.

Zweryfikuj obowiązującą politykę

Przed wysłaniem zasady:

  1. Użyj odnajdywania środowiska uruchomieniowego zestawu SDK i sprawdź wymagania wstępne wybranego backendu.
  2. Utwórz konfigurację i obsłuż błędy sprawdzania poprawności zasad lub niedostępności zaplecza bez osłabienia zasad.
  3. Uruchom reprezentatywne udane scenariusze z zasobami, których powinno używać obciążenie.
  4. Uruchamiaj negatywne przypadki, które próbują odczytać sekrety, zapisać poza katalogiem wyjściowym, użyć niezatwierdzonej ścieżki sieciowej lub uzyskać dostęp do niedozwolonego interfejsu użytkownika.
  5. Użyj Learning Mode, aby zbadać brakujący dostęp i przejrzeć każdy wynik przed zmianą polityki.
  6. Usuń wszystkie ustawienia uczenia lub audytu i uruchom jeden ostatni test wymuszający.

Zgłoś błąd, gdy host nie może wymusić wymaganej kontroli. Nie wybieraj po cichu backendu z szerszym dostępem ani nie usuwaj pola zasad, aby uruchomić obciążenie robocze. Pomyślna analiza lub uruchomienie nie jest dowodem na to, że każde zamierzone ograniczenie obowiązuje.

Treści powiązane

  • Ostatnia aktualizacja o