«Мы смогли купить безопасное решение, а не строить его сами»: Benchling закрыла DNS-эксфильтрацию в многопользовательском Code Interpreter

Научный код от ИИ-агентов в тысячах арендаторов

Платформа Benchling для биотехнологических исследований генерирует научный код, который выполняется от имени исследователей в тысячах арендаторов. Основной сценарий — код, написанный ИИ-агентом, хотя Code Interpreter используется и для простых вычислений, и как песочница генерации кода. Сегодня эта архитектура обрабатывает больше 600 сессий выполнения кода в день для более чем 250 арендаторов в неделю и обходится без инцидентов безопасности.

Каждая сессия должна быть полностью изолирована, а доступ — только к данным своего арендатора, без взаимной видимости. При этом схема не может требовать отдельного IAM-роля на каждого арендатора: при таком масштабе это даёт неуправляемый рост числа ролей, то есть проблему не только безопасности, но и эксплуатации. Отдельным пунктом команда безопасности Benchling выделила DNS: разрешение имён часто остаётся разрешённым, а даже когда системные настройки его ограничивают, у клиента нет ни видимости, ни управления этими ограничениями.

Отдельный аккаунт для недоверенного кода

Решение начинается с разделения ответственности: код ИИ-агентов выполняется в выделенном AWS-аккаунте, отдельном от основного продакшена Benchling, поэтому при инциденте основной аккаунт с клиентскими данными и ролями доступа напрямую не затронут. В этой VPC нет ни internet gateway, ни NAT gateway, а сама песочница работает в отдельной security group с разрешённым только портом 443 — исходящего пути наружу у недоверенного кода нет вовсе.

Сетевых путей остаётся два уровня: эндпоинты VPC для разрешённого доступа к Amazon S3 и DNS-запросы, которые оценивает Route 53 Resolver DNS Firewall по политике из трёх приоритетов. Учётные данные при этом не выдаются заранее на каждого арендатора — Benchling подставляет их в каждую сессию Code Interpreter поштучно через AWS Security Token Service (AWS STS), динамически сужая права и не накапливая статические роли.

Три приоритета DNS Firewall

Первый, самый высокий приоритет блокирует разрешение известных нежелательных доменов: так отсекаются очевидные угрозы до того, как они дойдут до логики разрешений. Дополнительно это даёт наблюдаемость — запросы к явному списку запрещённых доменов логируются в DNS Firewall и служат ранним сигналом о подозрительной активности внутри песочницы.

Второй уровень — allow list: разрешение имён только для явно перечисленных доменов, на практике почти исключительно для эндпоинтов S3, нужных для доступа к данным. Список сознательно минимальный, потому что каждый разрешённый домен — потенциальный канал утечки; в отличие от системных настроек, которые могут меняться от версии к версии, это артефакт под контролем Benchling, который можно проверять, версионировать и обновлять по своему графику.

Третий уровень — catch-all: любой запрос, не разрешённый вторым приоритетом, получает ответ NODATA. Именно это делает DNS-эксфильтрацию невозможной: при типовой туннельной атаке украденные данные кодируются в поддомены, а здесь у закодированных запросов просто нет пути разрешения, и цепочка рекурсии рвётся на первом шаге.

Эксфильтрация как проверяемое свойство

Каждый слой Benchling проверила отдельно в пилотной VPC. Попытки DNS-туннелирования подтвердили, что DNS Firewall возвращает NODATA для любого домена вне явного allow list; попытки прямых IP-соединений — что маршрутизация по prefix list и NACL ограничивают трафик портом 443 и эфемерными портами, без выхода на произвольные внешние хосты; попытки API-вызовов — что политики эндпоинтов VPC отклоняют запросы к любому бакету вне разрешённого набора.

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

Отдельный слой — политики эндпоинтов: Benchling разворачивает Gateway endpoint для S3 в своём регионе и Interface endpoint для кросс-регионального доступа, у каждого с явным списком бакетов. Это защита, независимая от IAM: даже если недоверенный код получит валидные учётные данные к чужому бакету, запрос отклонит политика эндпоинта, потому что учётные данные определяют, что сессии разрешено делать, а политика — что сеть физически способна доставить. Скомпрометированная сессия может дотянуться только до того арендатора, которому она была назначена.

Купить, а не строить

До выбора AgentCore команда рассматривала собственную песочницу: это означало бы проектировать оркестрацию контейнеров, управление жизненным циклом песочниц и примитивы сетевой изоляции с нуля. Code Interpreter в режиме VPC снял этот пласт работ — AWS берёт на себя жизненный цикл песочницы, включая патчи, масштабирование и укрепление среды выполнения. «Мы смогли купить безопасное решение вместо того, чтобы строить его самим», — говорит инженер по безопасности приложений Benchling Джереми Сташевски.

Режим VPC — официально документированный вариант подключения: AgentCore создаёт сетевой интерфейс в аккаунте клиента с частным IP-адресом, публичная подсеть сама по себе интернет-доступа не даёт, а для выхода в интернет подсеть нужно размещать в частных подсетях с маршрутом на NAT Gateway. Именно поэтому отсутствие NAT gateway в схеме Benchling — не деталь, а решение: у трафика, который попытался бы обойти DNS Firewall, просто нет исходящего маршрута.

Итог с момента запуска в начале апреля 2026 года: больше 600 сессий выполнения кода в день для научных задач ИИ-агентов и более 250 отдельных арендаторов в неделю, ноль инцидентов безопасности и ноль утечек данных между арендаторами. Вывод AWS звучит без иллюзий: ни один отдельный контроль в такой архитектуре не достаточен сам по себе.