Политика изоляции времени выполнения

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

Почему изоляция важна

Агенты мощные — они могут читать файлы, выполнять команды и делать сетевые запросы. Без изоляции:

• Утечки данных — агент может прочитать ключи SSH, учётные данные AWS или другие конфиденциальные файлы
• Повреждение системы — агент может удалить важные файлы или выполнить опасные команды
• Атаки цепочки поставок — взломанный навык может экспортировать данные или перейти к другим системам
• Нарушения нормативных требований — некоторые рамки соответствия требуют изоляции рабочей нагрузки

Политики изоляции предотвращают эти риски путём применения границ.

Компоненты политики изоляции

Политика изоляции контролирует четыре аспекта:

Доступ к файловой системе

Список разрешений — пути (и подпути), которые агенты могут читать и писать:

/home/user/workspace
/tmp
/var/tmp

Список запретов — пути, которые всегда блокированы, даже если находятся в списке разрешений:

~/.ssh
~/.aws
~/.gnupg
/etc

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

Выполнение команд

Список разрешений — если установлен, могут выполняться только эти команды. Пусто = нет ограничений.

git
grep
python

Список запретов — команды/шаблоны, которые всегда блокированы:

rm -rf /
chmod 777
curl | sh

Запрещённые команды терпят неудачу немедленно с записью аудита.

Доступ в сеть

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

github.com
api.openai.com
10.0.0.0/8

Список запретов — всегда блокированные хосты и шаблоны:

169.254.169.254  (метаданные AWS)
127.0.0.1:22  (локальный SSH)

Поведение по умолчанию зависит от политики сети вашей среды выполнения.

Тип исполнителя

• Local — агент работает непосредственно на ОС демона (по умолчанию, легковесный)
• Container — агент работает в изолированном контейнере без привилегий (более безопасно, требует Docker/Podman)

Создание политики изоляции

Политики изоляции настраиваются на уровне рабочего пространства, а не для каждого агента.

1. Перейдите на Параметры → Безопасность → Политика изоляции
2. Посмотрите политику по умолчанию (уже установлена, показывает запреты для директорий учётных данных)
3. Добавьте список разрешений файловой системы — пути, к которым ваши агенты должны получать доступ
4. Добавьте запреты файловой системы — пути для явной блокировки (помимо стандартов)
5. Добавьте ограничения команд (опционально) — список разрешений или запретов
6. Добавьте ограничения сети (опционально) — список разрешений или запретов
7. Выберите тип исполнителя — локальный или контейнерный
8. Нажмите Сохранить

Разрешения файловой системы в деталях

Список разрешений (что агенты могут получать доступ)

Агенты могут читать и писать пути, соответствующие записи списка разрешений:

FilesystemAllow:
  - /home/user/workspace    # Агенты могут получить доступ к этой директории и поддиректориям
  - /tmp                     # Агенты могут использовать /tmp
  - /var/data               # Агенты могут получить доступ к /var/data

Директория рабочего пространства для каждой задачи всегда разрешена, независимо от политики.

Список запретов (что агенты не могут получать доступ)

Записи запретов всегда блокируют, даже если более широкая запись разрешений их включает:

FilesystemDeny:
  - ~/.ssh                  # Запретить ключи SSH
  - ~/.aws                  # Запретить учётные данные AWS
  - ~/.gnupg               # Запретить приватные ключи GPG
  - /etc                    # Запретить конфигурацию системы (встроенный стандарт)

Встроенные запреты (не могут быть удалены):

• ~/.ssh — ключи SSH
• ~/.aws — учётные данные AWS
• ~/.gnupg — приватные ключи GPG
• ~/.config/gh — конфигурация GitHub CLI
• /etc — конфигурация системы
• Директория конфигурации демона AACWorkflow

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

Ограничения команд в деталях

Список разрешений (белый список команд)

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

CommandAllow:
  - git          # Агенты могут запустить 'git'
  - grep         # Агенты могут запустить 'grep'
  - python       # Агенты могут запустить 'python'
  - python3      # Агенты могут запустить 'python3'

Любая другая команда терпит неудачу с ошибкой.

Если список разрешений пуст, все команды разрешены (если не заблокированы списком запретов).

Список запретов (чёрный список команд)

Команды в списке запретов никогда не выполняются:

CommandDeny:
  - rm -rf /         # Блокировать деструктивные удаления
  - chmod 777        # Блокировать изменения разрешений
  - curl | sh        # Блокировать загрузку и выполнение
  - sudo             # Блокировать повышение привилегий
  - :(){ :|:& };:    # Блокировать fork-bombs

Когда попытка запрещённой команды:

• Выполнение терпит неудачу с чёткой ошибкой
• Запись аудита регистрируется
• Агент уведомляется и может попробовать другой подход

Встроенные шаблоны запретов

AACWorkflow включает встроенные шаблоны запретов для известных опасных команд:

• Удаление файлов: rm -rf, dd if=/dev/zero
• Изменения привилегий: chmod 777, chown, sudo
• Tampering с историей Git: git push --force в main/master
• Shell-бомбы: :(){ :|:& };:
• Удалённое выполнение кода: curl | sh, wget -qO- | sh
• Reverse-shells: Netcat, reverse-shell сигнатуры

Вы можете добавить больше шаблонов без удаления встроенных.

Ограничения сети в деталях

Список разрешений (одобренные назначения)

Агенты могут подключаться к имён хостов и сетей в списке разрешений:

NetworkAllow:
  - github.com              # Агенты могут подключиться к GitHub
  - api.openai.com          # Агенты могут вызвать OpenAI
  - 10.0.0.0/8              # Агенты могут достичь 10.x.x.x
  - "*.internal.example.com" # Агенты могут достичь *.internal

Список запретов (заблокированные назначения)

Агенты не могут подключаться к этим именам хостов/сетям:

NetworkDeny:
  - 169.254.169.254  # Сервис метаданных AWS EC2
  - 127.0.0.1:22     # Локальный SSH
  - 0.0.0.0/0        # Блокировать все (если объединено со списком разрешений)

Запрещённые соединения блокируются на уровне сокета и аудируются.

Исполнитель контейнера (продвинутый)

Для максимальной изоляции вы можете запустить агентов внутри контейнеров без привилегий:

1. Перейдите на Параметры → Безопасность → Политика изоляции
2. В разделе Исполнитель выберите Контейнер
3. Опционально настройте параметры, специфичные для контейнера:
   • Лимит памяти (например, 2 GB)
   • Лимит CPU (например, 2 ядра)
   • Сетевой режим (изолирован по умолчанию)
4. Нажмите Сохранить

Требования:

• Docker или Podman должны быть установлены на демоне
• Процесс демона должен иметь разрешение на создание контейнеров
• Режим без привилегий рекомендуется (безопаснее, чем работа с корнем)

Что происходит:

• Задача агента выполняется внутри контейнера
• Директория рабочего пространства для каждой задачи привязывается к монтированию
• Разрешения файлов из политики изоляции применяются
• Сеть изолирована за NetworkAllow
• Каждый контейнер удаляется после завершения задачи

Компромиссы:

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

Просмотр эффективной политики

На странице параметров вы можете увидеть:

• Встроенные стандарты — что AACWorkflow применяет по умолчанию
• Ваши переопределения — что вы добавили или настроили
• Эффективная политика — слитый результат

Пример:

Built-in deny:  ~/.ssh, ~/.aws, /etc
Your additions: /root/.kube, ~/confidential
Effective deny: ~/.ssh, ~/.aws, /etc, /root/.kube, ~/confidential

Аудит нарушений изоляции

Все нарушения политики изоляции регистрируются:

• Отказы в доступе к пути
• Сбои выполнения команд
• Блокировки сетевого соединения

Посмотрите журнал аудита в Параметры → Журналы аудита и отфильтруйте по «Изоляция» или «Безопасность», чтобы увидеть:

• Когда и какой агент попытался получить доступ к запрещённому пути
• Какие команды были заблокированы и почему
• Какие сетевые соединения были запрещены

Используйте эти журналы для:

• Корректировки политик, если агентам законно нужен доступ
• Расследования подозрительного поведения
• Соответствия требованиям аудита

Лучшие практики

• Начните ограничительно — запретить по умолчанию, разрешить то, что нужно
• Используйте исполнитель контейнера — для ненадёжных или высокорискованных задач
• Проверяйте отказы регулярно — если агенты попадают в правила запретов, расследуйте
• Парные обнаружение угроз — политика изоляции + обнаружение угроз вместе
• Документируйте ваши списки разрешений — поделитесь с вашей командой, почему нужны определённые пути/команды
• Тестируйте перед продакшеном — включите политики на тестовой среде выполнения сначала

Ограничения

• Локальный режим — лучшее усилие — изоляция на ОС хоста полагается на защиту на уровне ОС, которую иногда можно обойти
• Не может удалить встроенные запреты — директории учётных данных всегда защищены
• Режим контейнера требует среды выполнения — вам нужны Docker или Podman установлены
• Список разрешений сети точен — шаблоны подстановочных символов имеют ограниченную поддержку; используйте диапазоны IP для широких целей

Следующие шаги

• Threat detection checks — активное сканирование подозрительного поведения
• Secrets isolation (Enterprise) — управление учётными данными безопасно
• Approval policies — требуйте проверки для конфиденциальных изменений