Что именно построила Benchling и почему это нетривиально
Benchling, платформа для R&D в life sciences, выполняет научный код, сгенерированный AI-агентами, в Amazon Bedrock AgentCore Code Interpreter в режиме VPC. Сессии идут внутри изолированного AWS-аккаунта, а доступ к данным ограничен рамками того тенанта, от имени которого запущена задача. По данным Benchling, эта схема обрабатывает более 600 сессий выполнения кода в день для более чем 250 тенантов в неделю без инцидентов безопасности и утечек между тенантами (How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore).
Архитектура собрана по принципу defense-in-depth из трех слоев: изоляция на уровне AWS-аккаунта, Amazon Route 53 Resolver DNS Firewall и политики VPC-эндпоинтов. Первый слой отделяет среду исполнения от остальной инфраструктуры, второй закрывает канал эксфильтрации через DNS, третий решает, к каким данным и ресурсам сессия вообще может обратиться. Итоговая цель - не дать сгенерированному коду вынести данные наружу и при этом сохранить контроль доступа к данным для каждой задачи.
Сложность в деталях. Каждая сессия должна видеть только данные своего тенанта, без кросс-тенантной видимости. Отдельная IAM-роль на каждого тенанта при таком масштабе превращается в неуправляемое разрастание ролей (role sprawl): сотни почти одинаковых политик, которые расходятся при изменениях и усложняют аудит. Режим Sandbox в Code Interpreter ограничивает исходящий доступ операциями Amazon S3, но Benchling нужна управляемая заказчиком сетевая изоляция (customer-controlled network isolation), поэтому Sandbox как основной контур не подошел.
Модель угроз: что именно защищают и от чего
Стандартный сетевой контроль блокирует HTTP, ограничивает порты исходящего трафика и число внешних соединений. DNS-разрешение при этом часто остается открытым, а если системные настройки его и ограничивают, видимости и управления над этими ограничениями может не быть (источник). Для мультитенантной среды этого недостаточно.
Четыре класса рисков, которые закрывает архитектура:
- Кросс-тенантная видимость. Код одного клиента получает доступ к объекту или бакету другого.
- Эксфильтрация через исходящие соединения. Сгенерированный код открывает сокет и выгружает данные на внешний хост.
- Эксфильтрация через DNS-туннелирование. Данные кодируются в поддомены запросов, ответы приходят в DNS-ответах; блокировки HTTP такой поток не видят.
- Компрометация учётных данных сессии. Долгоживущие ключи внутри песочницы дают атакующему устойчивый доступ к данным тенанта.
Требование Benchling сформулировано жестко: точно определить, какие домены могут разрешаться и какие эндпоинты доступны, а затем непрерывно проверять эти контроли собственным набором интеграционных тестов (тот же разбор). Принцип «ничего, пока явно не разрешено» превращает конфигурацию сети в белый список: все, что не разрешено явно, не работает. Список угроз для агентов шире одних сетевых каналов - prompt injection, скрытые модификации моделей и побеги агентов разобраны в отдельном материале (AI-безопасность на практике).
Изоляция на уровне аккаунта и VPC-режим Code Interpreter
Первый слой защиты - отдельный AWS-аккаунт под среду выполнения. Если код внутри сессии получит лишние права или найдет ошибку в изоляции, он останется в границах аккаунта, где нет доступа к продовым данным и сервисам компании. Барьер не зависит от корректности политик внутри VPC, и именно поэтому он работает как база, а не как дополнение.
Второй элемент - режим VPC у Code Interpreter: сети и маршрутизацию контролирует заказчик, а не провайдер. В описании кейса заявлено, что в этой VPC нет интернет- и NAT-шлюзов, а исходящий трафик ограничен VPC-эндпоинтами для Amazon S3. В опубликованном разборе AWS эти детали не раскрыты, поэтому воспринимайте их как заявленную конфигурацию, а не как документированный факт: состав шлюзов, эндпоинтов и маршрутов придется проектировать и проверять под свою среду.
Code Interpreter в AgentCore применяют для разных задач: простых вычислений, генерации кода и запуска кода, написанного агентом от имени исследователя. При выборе режима команда Benchling оценивала свойства сетевой изоляции каждого режима сети Code Interpreter на соответствие своей модели угроз. Порядок действий здесь правильный: сначала модель угроз, потом режим и его настройки.
Sandbox vs VPC: критерии выбора
| Критерий | Sandbox | VPC |
|---|---|---|
| Исходящий доступ | Ограничен операциями Amazon S3 | Определяете вы: эндпоинты, политики, DNS-правила |
| Кто управляет сетевой изоляцией | Провайдер | Заказчик |
| Контроль над DNS | Нет | Есть, включая DNS Firewall |
| Кому подходит | Прототипы, один тенант, нечувствительные данные | Мультитенантный продукт с чувствительными данными и требованиями compliance |
Sandbox проще в эксплуатации: меньше инфраструктуры и меньше конфигурации, которую можно сломать. VPC дает контроль над сетью и вместе с ним обязанность поддерживать политики, DNS-правила и эндпоинты в актуальном состоянии. Для одного тенанта или внутреннего прототипа второй вариант почти всегда избыточен.
DNS Firewall: закрываем канал, который обычно забывают
DNS почти никогда не блокируют полностью: без него в VPC не резолвятся имена AWS-сервисов, и ломается почти все. Этим пользуется DNS-туннелирование. Атакующий дробит данные на фрагменты, отправляет их как поддомены в DNS-запросах к своему домену, а на своей стороне собирает фрагменты из логов resolver-а. Фильтр HTTP и ограничение портов такой поток не останавливают, потому что данные уходят в запросах на разрешение имен.
Amazon Route 53 Resolver DNS Firewall в архитектуре Benchling помогает предотвращать эксфильтрацию данных, включая утечку через DNS (разбор кейса). Правила работают на уровне resolver-а, поэтому фильтруется само разрешение имени, а не соединение после него.
Как выглядит трёхуровневая политика на практике
В описании кейса политика описана как трёхуровневая: блок-лист, allow-лист и блокировка всего остального. Конкретные домены, приоритеты правил и настройки в публичном разборе не раскрыты, так что логику придется воспроизводить под свою инфраструктуру.
- Блок-лист. Явные запреты для известных нежелательных доменов и категорий. Список дешев в поддержке, но не защищает от нового домена атакующего.
- Allow-лист. Минимум доменов, без которых работа ломается: эндпоинты AWS-сервисов, внутренние сервисы, хранилища пакетов, если они действительно нужны.
- Default deny. Все, что не попало в allow-лист, не разрешается. Без этого уровня первые два почти бесполезны: перечислить все запрещенное невозможно, а разрешенное перечислить можно.
Практический эффект: чтобы вынести данные через DNS, атакующему нужно попасть в allow-лист. Здесь кейс Benchling смыкается с требованием непрерывной валидации - список доменов нужно не только задать, но и проверять, что он не расширился случайно при очередной правке.
Доступ к данным без IAM-роли на каждого тенанта
Отдельная IAM-роль на тенанта при сотнях клиентов не масштабируется: роли множатся, права расходятся, аудит превращается в ручную сверку. По данным кейса, именно это ограничение исключило вариант с ролью на каждого тенанта, несмотря на его очевидность.
В описании кейса заявлены два других механизма: временные учётные данные AWS STS, выдаваемые на каждую задачу, и политики VPC-эндпоинтов. Первый дает сессии короткоживущий credential, второй ограничивает, куда этот credential может обратиться. Детали того, как временные креды привязываются к конкретному тенанту и задаче, в публичном разборе отсутствуют, поэтому общая логика такова: сессия получает права на данные одного тенанта и не может выйти за их пределы ни по сети, ни по API.
Политики VPC-эндпоинтов как точка контроля
VPC-эндпоинт в заявленной конфигурации - единственный разрешенный маршрут исходящего трафика, для Amazon S3. Политика на эндпоинте описывает, к каким ресурсам и при каких условиях обращение разрешено: конкретные бакеты, префиксы, вызывающая роль. Контроль живет на сетевом уровне и не требует плодить роли под каждого тенанта: одна и та же схема работает и как защита от эксфильтрации, и как per-job контроль доступа к данным.
Смежная задача в регулируемых средах решается похожим набором средств: изоляция доменов, IAM, шифрование, сетевые ограничения и аудит. Пример такой сборки есть в разборе защищенной self-service аналитики в Amazon SageMaker (изоляция, IAM и сетевые ограничения в SageMaker).
Непрерывная валидация: почему настроить один раз недостаточно
Сетевые политики дрейфуют. Появляются новые сервисы, меняются эндпоинты, кто-то расширяет allow-лист, чтобы быстро починить интеграцию, и контроль незаметно слабеет. Проверка конфигурации в IaC этого не ловит: она показывает замысел, а не фактическое поведение среды.
Benchling проверяет контроли собственным набором интеграционных тестов. Такие тесты отвечают на вопросы, которые не видны в описании инфраструктуры:
- не разрешается ли домен, которого нет в allow-листе;
- доступен ли эндпоинт, которого быть не должно;
- видит ли сессия данные чужого тенанта;
- работают ли нужные сервисы, то есть не сломала ли изоляция сам продукт.
Последний пункт забывают чаще всего. Изоляция, которая ломает легитимные сценарии, будет отключена под давлением сроков, и тогда никакие политики не помогут.
Более 600 сессий в день и более 250 тенантов в неделю без инцидентов - результат постоянной работы, а не одной удачной настройки на старте проекта.
Что из подхода Benchling стоит перенять, а что нет
Перенять стоит пять вещей:
- принцип «ничего, пока явно не разрешено» как основу конфигурации сети, а не как лозунг в описании архитектуры;
- изоляцию на уровне отдельного AWS-аккаунта: она переживет ошибку в политике внутри VPC;
- DNS Firewall как обязательный слой, потому что DNS-канал остается открытым почти всегда;
- отказ от IAM-роли на тенанта в пользу короткоживущих кредов и политик эндпоинтов;
- интеграционные тесты, которые проверяют фактическую изоляцию, а не наличие конфигурации в репозитории.
Ограничения тоже конкретные. Нужна своя инфраструктура и команда, которая умеет поддерживать VPC, DNS-правила и эндпоинты. Sandbox-режим не подходит, если есть требования compliance или клиентские данные с высокими обязательствами по изоляции. Детали трёхуровневой политики DNS Firewall и работы с временными учётными данными AWS STS в публичном материале не раскрыты, поэтому эту часть придется проектировать самим и проверять на своей модели угроз. Для одного тенанта, внутреннего инструмента или нечувствительных данных архитектура избыточна: Sandbox и внятная модель угроз закроют большую часть рисков дешевле.
Контекст Benchling объясняет строгость решений: life sciences, исследовательские данные клиентов, сотни организаций в одной среде. Если строите агентную систему с нуля, полезно сначала закрыть более общие вопросы - почему агенты проваливают пилоты из-за данных и отсутствия архитектуры безопасности, разобрано в материале про теневую сторону ИИ-агентов (разбор продакшн-безопасности агентов). Возможности AgentCore, появившиеся к августу 2026, включая временные политики и контроль расходов, собраны в отдельном обзоре (обновления Amazon Bedrock и AgentCore).