Как мы защищаем облачных агентов: аппаратная изоляция, файрвол «только веб», сетевой журнал и аудит

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

Отдельная машина с аппаратной изоляцией

Каждая сессия получает собственную виртуальную машину, и после сессии она уничтожается. Это аппаратная виртуализация, а не контейнер. Контейнеры делят одно ядро с сервером и друг с другом, и ошибка в этом ядре — уже выход наружу. У нашей машины своё ядро, а границу между ней и сервером держит сам процессор — технологии Intel VT-x и AMD-V. Машины на нашем железе работают под Firecracker: на этом гипервизоре AWS разделяет функции Lambda разных клиентов. Это самая надёжная изоляция, какая бывает у машин на общем сервере. Выбраться из такой машины можно только через уязвимость в самом гипервизоре, и на практике это почти нереально.

Но даже это не был бы выход на сервер. Гипервизор работает от непривилегированного пользователя, а каждая машина — в своём сетевом пространстве, так что за стенкой — ещё одна клетка. Сессии на арендованных облачных машинах получают такую же отдельную виртуальную машину у облачного провайдера.

Права администратора у агента есть только внутри его машины.

Доступы, которые вы даёте агенту, — токен репозитория, ключи S3, токен Яндекс Диска — нигде не записываются. Они ждут в памяти, пока машина заберёт их один раз по TLS, и сразу стираются. Даже одноразовый пароль, по которому машина знакомится с платформой, срабатывает только один раз, и агенту он не достаётся. Ключ, с которым агент обращается к моделям, привязан к сессии и ограничен её бюджетом: потратить больше, чем вы разрешили, он не может.

Файрвол: только веб

Машина агента выходит в интернет только по HTTP и HTTPS — портам 80 и 443 — и разрешает имена только через заданные DNS-серверы. Всё остальное закрыто:

• Другие порты и протоколы — SSH, почта, базы данных, торренты — получают отказ сразу.
• Внутренние сети недоступны: частные адреса, адрес метаданных облака, сервер, на котором работает машина, и соседние машины.
• Новых соединений — не больше 20 в секунду, с запасом на всплеск в 100. Обычная установка зависимостей укладывается в этот лимит или просто повторяет попытку, а флуд не проходит.
• Подделать адрес отправителя нельзя: такие пакеты отбрасываются на выходе из машины.

На практике это значит одно: git — по HTTPS. Платформа и сама клонирует репозитории по HTTPS, а агент знает об этом ограничении и не пытается его обойти.

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

Сетевой журнал

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

Для каждого соединения в журнале есть:

• время начала и длительность;
• адрес, порт и имя сайта, которое агент запрашивал;
• сколько данных ушло и пришло;
• наш внешний адрес и порт, с которых соединение увидел сервер на той стороне.

Для отклонённых попыток записаны адрес, порт и сколько раз агент пытался.

Всё это видно на вкладке «Сеть» на странице сессии: куда обращался агент (отклонённые направления — первыми), сколько соединений и трафика, полный список с фильтром. Журнал честен о своих пропусках: если сборщик на сервере какое-то время не работал, вкладка так и скажет — с точными интервалами, — а не покажет тишину.

Журнал хранится 90 дней. Если на наш адрес придёт жалоба, мы найдём соединение по адресу, порту и времени и точно скажем, какая сессия его открыла — или что ни одна.

Журнал аудита

В консоли, в разделе «Журнал аудита», видно, кто и что делал в вашей организации:

• входы и регистрация, смена пароля и настроек;
• приглашения, удаление участников и смена ролей;
• создание, изменение и отзыв API-ключей, платежи;
• запуск и остановка сессий агентов, подключение MCP-серверов и Telegram-чатов.

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

Где это работает

Файрвол «только веб» и сетевой журнал действуют на быстрых сессиях — на машинах на нашем железе. Сессии на арендованных облачных машинах изолированы у облачного провайдера, но фильтра «только веб» и сетевого журнала у них нет: они выходят в интернет со своих адресов.

И две оговорки о журнале. Имя сайта — подсказка из DNS-ответов: если агент обратится по IP или через DNS-over-HTTPS, в журнале будет только адрес. А отклонённые попытки сверх 20 в секунду блокируются, но по отдельности не записываются.

Если вам нужен отчёт по сессии или есть вопросы о безопасности, напишите в поддержку.

Удачной разработки!