Песочница для ИИ-модели: почему одного контейнера недостаточно
Чтобы безопасно изолировать оценивание ИИ-модели или агента, запускайте каждое задание в одноразовом исполнителе и отдельно ограничивайте его файловую систему, сеть, учётные данные, ресурсы и доступ к журналам. Контейнер подходит как один из слоёв, но его безопасность зависит от подключённых каталогов, сокетов, прав процесса и внешней инфраструктуры.
После настройки проверьте не манифест, а поведение развёрнутой среды: попробуйте прочитать файлы узла, обратиться к управляющему сокету и облачным метаданным, выйти на запрещённый адрес, повторно использовать секрет и превысить лимиты. Песочницу можно принимать, только если запреты срабатывают, попытки видны во внешнем журнале, а временное состояние исчезает после задания.
Почему граница контейнера недостаточна
Контейнер разделяет процессы, сеть и ресурсы средствами общего ядра, однако конфигурация способна открыть пути за эту границу. Подключённый каталог узла предоставляет контейнеру права на доступные в нём файлы, а управление демоном позволяет создавать новые нагрузки с другими полномочиями.
Документация Docker по безопасности указывает, что контейнер с подключённым корневым каталогом способен изменять файловую систему узла, а доступный из контейнера API демона может привести к повышению привилегий. Поэтому исполнителю нельзя передавать управляющие сокеты, привилегированный режим, пространство процессов узла или ненужные системные возможности.
Для высокочувствительных данных и активного исследования агентных возможностей рассмотрите более сильную границу: микро-ВМ, отдельную виртуальную машину или одноразовый узел. Конкретный вариант выбирают по модели угроз, но среду оценивания в любом случае отделяют от разработки, обучения и промышленной эксплуатации.
Опишите разрешённые возможности до запуска
Составьте контракт задания: какие файлы разрешено читать и записывать, к каким адресам обращаться, какие инструменты и устройства использовать, сколько ресурсов потреблять и какие результаты возвращать. Всё, чего нет в списке, должно блокироваться по умолчанию.
Памятка OWASP по эксплуатации ИИ-моделей рекомендует разделять обучение, оценивание и промышленную обработку по границам доверия, ограничивать исходящий трафик недоверенных заданий и закрывать им пути узла, контейнерные сокеты, облачные метаданные и ненужные устройства. Она также предусматривает отдельные лимиты процессора, памяти, GPU, диска, процессов и сети.
Практическая архитектура состоит из управляющего сервиса, одноразового исполнителя и независимого контура наблюдения. Исполнитель получает только необходимые входы, не может изменять эталонные ответы и отправляет события наружу без обратного административного доступа из песочницы.
Изолируйте файлы и ограничьте ресурсы
Сделайте корневую файловую систему доступной только для чтения, а для результатов выделяйте пустой временный том с квотой. Эталонные тесты храните отдельно или подключайте без права записи. Не передавайте домашние каталоги, историю команд, конфигурацию Git, ключи SSH и каталоги оркестратора.
- Запускайте процесс от непривилегированного пользователя и удаляйте ненужные системные возможности.
- Применяйте профиль системных вызовов и политику AppArmor или SELinux, соответствующую операциям задания.
- Не подключайте сокеты узла, блочные устройства и ускорители без подтверждённой необходимости.
- Ограничьте память, процессорное время, число процессов, временный диск, длительность запуска и количество вызовов инструментов.
После выполнения уничтожайте исполнитель и рабочий том. Если несколько недоверенных заданий используют один GPU, сначала подтвердите, что платформа обеспечивает требуемое аппаратное разделение и очистку памяти; иначе разводите нагрузки по устройствам или узлам.
Заприте сеть и выдавайте временные секреты
Исходящие соединения блокируйте за пределами исполнителя. Если интернет необходим, направляйте запросы через контролируемый посредник со списком разрешённых доменов и портов, проверкой результатов DNS, ограничением перенаправлений и журналированием. Настройки самого приложения недостаточно: агент может воспользоваться другой библиотекой или доступным инструментом.
Отдельно запретите внутренние диапазоны, локальные служебные адреса и конечные точки облачных метаданных. Проверьте обращения по имени и прямому IP: разрешённый домен не должен после разрешения имени или перенаправления вести во внутреннюю сеть.
Не помещайте постоянные ключи в образ или общий файл конвейера. Для каждого запуска выдавайте отдельный короткоживущий токен с минимальными правами на конкретную операцию. Отзывайте его при завершении задания и маскируйте значение в журналах, диагностике и ответах модели.
Храните журналы вне песочницы
Передавайте наружу сведения о запуске процессов, вызовах инструментов, сетевых попытках, отказах политик и превышении лимитов непосредственно во время выполнения. Локальный файл не является надёжным доказательством: исполнитель способен удалить, переполнить или изменить его.
Практики NIST для оценивания агентов предусматривают документирование допустимого интернет-доступа, его блокировку или ограничение списком доменов на сетевом уровне и анализ журналов с последующей проверкой обнаружений человеком. Такой просмотр помогает выявлять не только обход правил, но и ошибки интеграции модели, инструментов и самого задания.
Не превращайте журнал в канал утечки: исключайте секреты и ненужные чувствительные входы, ограничивайте срок хранения и отделяйте права на просмотр от прав на запуск оценивания.
Примите песочницу через отрицательные тесты
Запускайте проверки через тот же образ, сетевой маршрут, механизм секретов и политики, что используются в реальном оценивании. Для каждого теста заранее задайте ожидаемый отказ и событие, которое должно появиться во внешнем журнале.
- Попробуйте прочитать каталог узла, домашний каталог и файлы соседнего задания. Ожидайте отсутствия пути или отказа в доступе.
- Проверьте управляющие сокеты, пространство процессов узла, API оркестратора и ненужные устройства. Все служебные интерфейсы должны быть недоступны.
- Обратитесь к разрешённому ресурсу, запрещённому домену, прямому внешнему IP, внутреннему адресу и облачным метаданным. Успешным должен остаться только разрешённый сценарий.
- Попробуйте применить токен к другому ресурсу и повторно использовать его после завершения запуска. Затем убедитесь, что токена нет в образе, файлах и журнале.
- Превысьте ограничения памяти, времени, процессов и временного диска. Исполнитель должен завершиться, не нарушив работу управляющего контура и соседних заданий.
- После остановки проверьте удаление тома, кэша и контрольных точек, а также сохранение причины завершения во внешнем журнале.
Критерий приёмки — согласованная цепочка доказательств: операция заблокирована на нужной границе, попытка зарегистрирована, секрет не раскрыт, соседние нагрузки не затронуты, временная среда удалена. Сохраняйте протокол вместе с версией конфигурации и повторяйте проверки после изменений ядра, среды исполнения, сетевой политики или оркестратора.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.