Рекомендуемая конфигурация

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

Для большинства рабочих процессов Daybreak Blue может быть достаточно существующих в вашей организации практик безопасности, таких как контроль доступа, защита учетных данных и проверка чувствительных действий.

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

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

Изолируйте среду

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

Для работ повышенного риска или с ослабленными защитными механизмами используйте для каждой попытки новую, надежно изолированную среду. Разделяйте вычислительные ресурсы, хранилища, сети и удостоверения, а после завершения уничтожайте среду вместо ее сброса или повторного использования.

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

Определите и обеспечьте соблюдение одобренных границ

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

• Одобренные целевые системы, хосты и среды.
• Исключенные системы, включая производственную и несвязанную инфраструктуру.
• Одобренные инструменты и подключенные сервисы.
• Разрешенные и запрещенные действия.
• Одобренное время начала и окончания, а также требования к обработке данных.
• Раскрытие уязвимостей, одобрение исправлений и координацию с сопровождающими.
• Условия остановки и действия, требующие явного одобрения человеком.

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

Используйте профили разрешений Codex, чтобы создать границу по принципу минимальных привилегий. Выберите :read-only, если задача не требует изменений, или расширьте :workspace, если необходимо редактировать рабочую область. Например:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"

[features]
network_proxy = true

[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"

[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3

[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"

[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true

[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"

Функция network_proxy обеспечивает соблюдение ограничений одобренного домена. Без нее network.enabled = true разрешает прямой доступ к сети, а список разрешений лаборатории не ограничивает адреса назначения. Веб-поиск, приложения, коннекторы, серверы MCP, действия браузера и облако Codex используют отдельные средства контроля; ограничьте или отключите каждую поверхность, не требующуюся для одобренного рабочего процесса.

Замените lab.example.com одобренной целью. Ограниченное сканирование файловой системы предназначено для того, чтобы не выполнять поиск по всей рабочей области в Linux, WSL и Windows; увеличьте глубину или укажите точные запрещенные пути, если конфиденциальные файлы находятся глубже. Не объединяйте профили разрешений с устаревшими настройками sandbox_mode; следуйте рекомендациям по настройке профилей разрешений.

Если одобренный лабораторный хост разрешается в частный адрес, Codex по умолчанию блокирует его, даже когда хост находится в списке разрешений. Устанавливайте allow_local_binding = true только для явно одобренной работы в частной сети, сохраняйте узкий список разрешенных адресов назначения и ознакомьтесь с рекомендациями по локальным и частным сетям. Также можно внести в список разрешений точный одобренный частный IP-адрес.

По умолчанию блокируйте доступ к открытому интернету и производственной сети. Если внешний доступ необходим, направляйте его через независимо контролируемый шлюз или прокси с узкими списками разрешений, проверкой запросов и журналированием. Применяйте те же ограничения к косвенным подключениям через менеджеры пакетов, вебхуки, сервисы получения данных по URL, перенаправления, облачные API и подключенные инструменты. Загружайте зависимости до запуска или используйте зависимости, одобренные администратором.

Защитите учетные данные и конфиденциальные данные

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

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

Не используйте :danger-full-access и --yolo в рабочих процессах кибербезопасности. Full Access устраняет контролируемую границу песочницы, от которой зависит автоматическая проверка. Управляемые организации могут исключить :danger-full-access и --yolo, ограничить допустимые политики одобрения и потребовать автоматическую проверку с помощью конфигурации, управляемой на уровне организации.

Перед включением Full Access для одобренной модели безопасности настольное приложение ChatGPT отображает предупреждение для конкретной модели об опасных действиях. В нем рекомендуется вместо этого использовать Approve for me и приводится ссылка на настройку политики проверяющего. Это предупреждение не восстанавливает границу песочницы и не отменяет политику организации.

Защитные правила добавляют проверку на основе политик в контролируемый рабочий процесс кибербезопасности. Они не заменяют изоляцию среды, разрешения по принципу минимальных привилегий, четко определенные границы, мониторинг или контроль со стороны человека.

Проверяйте чувствительные действия Codex

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

Требуйте явного одобрения человеком для действий, затрагивающих производственную среду, внешние системы, конфиденциальные данные, повышение привилегий, постоянный доступ или необратимые изменения. Считайте недоверенными инструкции, встроенные в веб-сайты, репозитории, документы и результаты работы инструментов: они не могут расширять разрешенную область или отменять средства контроля доступа.

При выборе одобренной модели Daybreak в настольном приложении ChatGPT режим разрешений автоматически переключается на Approve for me, если он доступен для вашей учетной записи и разрешен политикой организации. Это также относится к использованию команды /model настольного приложения. Если этот режим недоступен, текущий режим разрешений не изменяется. Выбор модели никогда не отменяет управляемые требования организации.

Чтобы автоматическая проверка выполнялась, сохраните все три средства контроля:

1. Используйте интерактивную политику одобрения, например approval_policy = "on-request".
2. Установите approvals_reviewer = "auto_review".
3. Сохраняйте принудительно применяемую границу песочницы или профиля разрешений.

Запросы к цели из сетевого списка разрешений остаются внутри сетевой границы и не запускают Auto-review автоматически. Чтобы проверять чувствительную команду, даже если адрес назначения находится в списке разрешений, создайте явное правило команды в ~/.codex/rules/:

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

После добавления правила перезапустите Codex. При использовании approvals_reviewer = "auto_review" соответствующие команды перед выполнением направляются проверяющему. Добавьте соответствующие правила запросов для каждой чувствительной команды или используйте approval_mode = "prompt" для отдельных инструментов MCP. Действия, требующие решения человека, по-прежнему нуждаются в его явном одобрении.

Auto-review не проверяет обычные действия, уже разрешенные внутри песочницы. При использовании approval_policy = "never" или Full Access чувствительное действие может не создавать запрос на одобрение, доступный для проверки. Автоматическая проверка может ошибаться и не заменяет изоляцию, четко определенные границы, мониторинг или явный контроль со стороны человека.

Сведения об ограниченной политике и принудительном применении на уровне организации см. в разделе Настройка санкционированного рабочего процесса кибербезопасности.

Ведите независимый мониторинг и используйте безопасный отказ

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

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

Добавьте защитные правила в собственные рабочие процессы агентов

Если вы используете Responses API, Agents SDK или другую управляющую среду, добавьте проверку на границе выполнения инструментов. До выполнения сверяйте чувствительные предлагаемые действия с одобренными системами, действиями и временными ограничениями, направляйте неоднозначные действия и действия повышенного риска человеку, применяйте независимые ограничения файловой системы и сети, ведите журналы аудита и используйте безопасный отказ, если проверяющий или политика недоступны.

Codex Auto-review не защищает автоматически собственные инструменты или внешние управляющие среды. Используйте Защитные правила и проверку человеком как шаблон для Agents SDK, а политику проверяющего с открытым исходным кодом — как справочный материал.

Песочница и проверка на стороне продукта Codex работают отдельно от проверок кибербезопасности API. Защитные механизмы API могут возвращать ошибки cyber_policy, а значения safety_identifier для отдельных пользователей помогают ограничить последствия срабатывания защитного механизма.

Выполните очистку и проверьте результаты

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

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

Перед началом работы

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