Создайте и проверьте политику MXC

Политика MXC описывает, к чему может получить доступ рабочая нагрузка. Начните с разрешений с запретом по умолчанию, добавьте только ресурсы, необходимые для конкретной задачи, и проверьте результат с помощью репрезентативных входных данных на каждой платформе, которую поддерживает ваше приложение. Каждый бэкенд также предоставляет ресурсы операционной системы, необходимые для запуска нагрузки; запрет по умолчанию не означает, что процесс выполняется без системной среды.

Храните решения политики в коде доверенного приложения. Средство, подключаемый модуль, скрипт или команда, созданная СИИ, может сообщать о необходимых возможностях, но не должна выбирать собственную модель изоляции или расширять собственный доступ.

Понимание политики и конфигурации

MXC отделяет разрешения ресурсов от параметров, используемых для выполнения команды:

  • Параметры политики описывают кроссплатформенные параметры, такие как доступные для чтения пути, доступные для записи пути, сетевые назначения, доступ к пользовательскому интерфейсу и время ожидания.
  • Параметры выполнения добавляют команду, рабочий каталог, среду и выбор контейнера.

В SDK версии 1 элемент ContainerRequest содержит оба. В .NET создайте команду ContainerRequest, задайте её свойства политики и выполнения и вызовите MxcContainer.RunAsync или API порождения процесса. В TypeScript передайте объект ContainerRequest в run или функцию spawn. В Rust создайте структуру ContainerRequest и передайте ее в v1::run или в функцию spawn. Используйте абстрактную цель containment Process, если вашей рабочей нагрузке не требуется определённый бэкенд.

В следующих языконезависимых параметрах политики описана задача с областью действия репозитория. Они используют имена свойств TypeScriptContainerRequest; .NET использует ту же структуру с именами PascalCase, такими как ReadonlyPaths, и Rust использует snake_case имена, такие какreadonly_paths. Они не являются полным запросом: они не содержат команду и не выбирают бэкенд. Создайте каталоги и замените их пути перед их адаптацией.

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

Используйте типы пакета SDK вместо копирования свойств запроса в необработанную конфигурацию выполнения. Фигуры отличаются: например, запрос timeoutMs сопоставляется с конфигурацией process.timeout, ui.allowInputInjection сопоставляется с network.runtimeConfig, а ui.injection — с разделом верхнего уровня runtimeConfig. См. краткое руководство по пакету SDK для полных примеров C#, TypeScript и Rust.

Выберите совместимую схему

Рассматривайте эти три вопроса отдельно:

Ось совместимости Что требуется проверить
SDK и релиз продукта Какие API и компоненты среды выполнения предоставляются в пакете
Схема политики Какой именно контракт конфигурации поддерживает релиз
Возможности узлов Какие ограничения выбранная среда может обеспечивать во время выполнения

Пакеты SDK MXC 1.0 версии 1 внутренне используют стабильную 1.0.0 схему, поэтому в ContainerRequest не нужно указывать версию схемы. Версия схемы применяется только при написании вручную необработанной JSON-конфигурации выполнения, например файла для средства командной строки wxc-exec.

Исходная конфигурация должна объявлять точно зарегистрированный version. MXC 1.0 принимает 1.0.0текущую стабильную схему и 0.9.0-alphaминимальную поддерживаемую схему. MXC отклоняет отсутствующую версию, снятые с поддержки версии ранее 0.9.0-alpha, например 0.8.0-alpha, и незарегистрированные варианты написания, такие как 1.0 или 1.0.1. 1.1.0-alpha Контракт для разработки может измениться перед публикацией, поэтому не используйте его для рабочих конфигураций. Выбор этого параметра не авторизует экспериментальные бэкенды.

Храните компоненты пакета SDK и собственные компоненты среды выполнения из одного и того же выпуска вместе. Сведения о зарегистрированных контрактах см. в версионировании схемы MXC.

Ограничение доступа к файлам

Классифицируйте каждый путь по тому, как нагрузка использует его:

Доступ Используйте его для
Только для чтения Источник, средства, библиотеки и конфигурация, которые рабочая нагрузка должна проверять, но не изменять
Чтение и запись Каталог вывода, кэш или временный каталог для конкретной задачи
Отклонено Учетные данные, несвязанные репозитории, конфиденциальные конфигурации и более узкие пути в рамках более широких прав доступа

Предоставьте минимально необходимый уровень доступа. Например, предоставьте каталог результатов теста вместо корневого каталога репозитория, если команда записывает только выходные данные теста. Рассматривайте пути, обнаруженные из переменных среды, диспетчеров пакетов или поиска инструментов, как кандидатов для проверки, а не как автоматически предоставляемые разрешения.

Включите двоичные файлы, библиотеки, конфигурацию и временные пути, которые действительно нужны workload. Пакеты SDK предоставляют вспомогательные средства обнаружения файловой системы, но их результаты не являются утвержденной политикой. Просмотрите каждый возможный путь перед добавлением.

Установка рабочего каталога не предоставляет доступ к этому каталогу. Добавьте его в соответствующий список файловой системы явным образом.

Избегайте использования правила перекрывающегося пути, если только вы не проверили его с выбранной серверной частью. Бэкенды используют различные механизмы доступа к файлам, и некоторые не могут задавать правило запрета в отображаемом или смонтированном каталоге.

Контролируйте доступ к сети

Не разрешайте доступ к сети, если только задача этого не требует. Выберите сетевую модель, которую может применить выбранный бэкенд:

Модель Используйте его для
Внешний доступ отсутствует Анализ или преобразование, для которых требуются только локальные ресурсы
Прямой доступ через правила IP/CIDR, протокола и порта Задача, требующая конкретных прямых подключений, например TCP к известной конечной точке службы.
HTTP(S) через прокси-сервер, предоставленный приложением Запросы, чьи назначения или разрешения на уровне приложения контролируются вашим прокси-сервером

Политика направления сети разделяет:

  • Исходящий трафик от нагрузки к сетевым узлам.
  • Входящий трафик из частных или локальных сетей к слушателям рабочей нагрузки.
  • Loopback хоста между рабочей нагрузкой и службами на хосте в обоих направлениях.

Правила IP/CIDR и портов не определяют протокол приложения или имя узла. Разрешение TCP-порта 443 не означает, что подключение использует HTTPS или достигает только одной именованной службы. DNS-запросы также могут требовать доступа, если рабочая нагрузка разрешает адреса назначения напрямую.

Поддерживаемые схемы отклоняют устаревшие сетевые поля, такие как defaultPolicy, allowedHosts, blockedHosts и network.proxy. Вместо этого используйте поля egress и ingress направления. См. примеры политики сети.

Использование пользовательского сетевого прокси-сервера

Ведущее приложение предоставляет и запускает прокси-сервер перед запуском рабочей нагрузки. MXC не предоставляет и не управляет продукционным прокси-сервером. Прокси-сервер решает, какие запросы и адреса назначения разрешать; MXC настраивает поддерживаемые клиенты для его использования и применяет сетевые ограничения серверной части.

В направленном запросе используется параметр раздела сети runtimeConfig.networkProxy для идентификации конечной точки loopback HTTP(S) с явным портом. В необработанной конфигурации выполнения этот параметр является элементом верхнего уровня runtimeConfig.networkProxy. Эта конечная точка является конфигурацией среды выполнения, а не списком разрешённых на уровне приложений. Режим прокси-сервера требует, чтобы исходящий трафик по умолчанию был запрещён, и его нельзя сочетать с правилами разрешения или запрета прямого исходящего трафика.

Клиентская маршрутизация и контроль отличаются. Переменные среды прокси-сервера или параметры платформы сообщают HTTP-клиентам, поддерживающим прокси, где отправлять запросы. Режим принудительного использования только прокси также должен предотвращать прямые подключения к Интернету; согласованная конфигурация прокси сама по себе не устанавливает это ограничение.

MXC не выполняет прозрачное перенаправление SSH, произвольного TCP/UDP или других протоколов, отличных от HTTP, через прокси-сервер HTTP(S). Поведение host-loopback и частной сети также зависит от бэкенда. Просмотрите пример конфигурации пользовательского прокси-сервера и его предварительные требования, вместо того чтобы предполагать, что один и тот же фрагмент работает везде.

Ограничить доступ к интерфейсу

По умолчанию не разрешайте фоновой рабочей нагрузке создавать окна, читать или записывать буфер обмена или эмулировать ввод с клавиатуры и указателя. Добавьте доступ к пользовательскому интерфейсу только в том случае, если он является частью предполагаемого пользовательского опыта рабочей нагрузки.

Инъекция ввода означает искусственный ввод с клавиатуры или с помощью указателя, а не произвольное внедрение кода в другой процесс.

Элементы управления пользовательского интерфейса зависят от хоста и бэкенда. Используйте сведения о поддержке среды выполнения, чтобы проверить каждое ограничение, требуемое вашей архитектурой безопасности.

Связанное выполнение

Задайте время ожидания для каждого действия агента, вызова средства или скрипта, который должен завершиться в течение заранее известного периода времени. Укажите только переменные среды, необходимые процессу, и не храните секреты ни в среде процесса, ни в доступных для чтения путях к файлам. Не предполагайте, что опущение среды создает пустую: значения по умолчанию на бэкенде и параметры наследования SDK отличаются.

Выберите жизненный цикл, соответствующий задаче. Предпочитайте однократное выполнение для независимых команд. Используйте песочницу с поддержкой состояния, только если команды должны совместно использовать установленные средства, удостоверения, файлы или состояние операционной системы.

Проверьте действующую политику

Перед отправкой полиса:

  1. Используйте обнаружение среды выполнения пакета SDK и проверьте предварительные требования выбранного бэкенда.
  2. Создайте конфигурацию и обработайте ошибки проверки политики или недоступности серверной части, не ослабляя политику.
  3. Запустите репрезентативные успешные сценарии с ресурсами, которые должна использовать рабочая нагрузка.
  4. Запустите отрицательные случаи, которые пытаются считывать секреты, записывать вне выходного каталога, использовать неутвержденный сетевой путь или получать доступ к запрещенному пользовательскому интерфейсу.
  5. Используйте Режим обучения, чтобы выявить случаи отсутствия доступа и просмотреть каждый результат перед изменением политики.
  6. Удалите все параметры обучения или аудита и выполните одну заключительную проверку в режиме принудительного применения.

Завершать с ошибкой, если узел не может применить обязательный контроль. Не выбирайте без уведомления бэкенд с более широким доступом и не удаляйте поле политики для выполнения рабочей нагрузки. Успешный анализ или запуск не является свидетельством того, что каждое предполагаемое ограничение соблюдается.

Связанные материалы

  • Последнее обновление: