Руководство по развертыванию для администраторов

Руководство по развертыванию для администраторов

Планирование, настройка и проверка развертывания ChatGPT Enterprise в рабочем пространстве и инструментах разработчика

Используйте это руководство, чтобы спланировать развертывание ChatGPT Enterprise с учетом следующих границ администрирования:

  • Доступ к рабочему пространству.
  • Локальная политика среды выполнения для охватываемых возможностей в настольном приложении ChatGPT, Codex CLI и расширении IDE.
  • Codex cloud.
  • Доступ к Platform API.
  • Доступ к плагинам и коннекторам.
  • Разрешения в подключенных системах.

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

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

В настройках рабочего пространства раздел Codex and Work Local объединяет локальный доступ к Codex и Work под параметром Allow members to use Codex and Work Locally. В некоторых рабочих пространствах вместо него предусмотрены отдельные разделы Codex Local и Work Local. При такой конфигурации параметр Allow members to use Codex locally управляет доступом к Codex, а Use Work locally — доступом к Work. Включение одного из них не включает другой. Эти названия обозначают разрешения рабочего пространства, а не отдельные продукты или клиенты. Разрешения для токенов и ограничения срока действия учётных данных находятся либо в разделе Access tokens, либо в разделе локального доступа — в зависимости от рабочего пространства. Управляемая конфигурация представляет собой отдельный уровень политик, который может ограничивать поддерживаемое поведение среды выполнения для охватываемых возможностей этих клиентов. В этом руководстве указывается конкретный интерфейс, если поведение или доступность различаются.

Обзор средств контроля доступа см. в разделе Роли и разрешения рабочего пространства. Актуальные процедуры для рабочего пространства ChatGPT приведены в справочном центре, а сведения о поведении локальных и размещённых сред выполнения — в документации для разработчиков по ссылкам.

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

Шаг 1. Назначьте ответственных и выберите схему развертывания

Назначьте ответственного за каждую часть развертывания:

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

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

Шаг 2. Настройте доступ к рабочему пространству и управление удостоверениями

Используйте управление участниками, рабочими местами и группами рабочего пространства ChatGPT, а также поддерживаемые разрешения RBAC, чтобы предоставить целевым аудиториям доступ к поддерживаемым функциям рабочего пространства. Проверяйте доступ к локальным клиентам и Codex cloud по актуальным рекомендациям для рабочего пространства, не предполагая, что одна и та же роль управляет всеми инструментами. Предоставляйте встроенные административные роли только тем, кто администрирует рабочее пространство.

Элементы управления и их названия в рабочем пространстве со временем меняются. Актуальные процедуры приведены в следующих источниках:

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

Настройка доступа к локальному компьютеру через Work Cloud

Если ваше внедрение включает доступ к локальному компьютеру для Work или dots, перед внедрением ознакомьтесь с политиками в Agent Security. Перенос политик и доступ к функциям — отдельные изменения; процедура подтверждения не требует создания политики для включения доступа. Поддерживаемая политика Global регулирует облачную оркестрацию, когда включена управляемая политика. Требования к локальному выполнению и средства контроля устройств регулируют работу подключённого компьютера. Облачные контейнеры Work и облачные компьютеры dots используют собственные настройки и требования к выполнению. Следуйте руководству Доступ к локальному компьютеру для Work Cloud и dots, где отдельно описаны настройка и условия доступности.

Используйте API политик для управления настройками Global. Для управления настройками Local или Codex Cloud используйте интерфейс Agent Security. Существующие процессы работы с API Global остаются доступными после миграции. Проверьте свои скрипты и интеграции с Terraform и убедитесь, что назначения политик и их порядок не изменились.

Проверьте совместимость перед включением синхронизации:

Сетевая политика. Если доступны переопределения на уровне среды, проверьте исключения experimental_network, описанные в разделе Управляемая конфигурация. Глобальное ограничение может оставаться в силе, даже если доступ разрешён на уровне среды.

  • Корпоративные хуки. Если эта возможность включена для вашего рабочего пространства, доступ к локальному компьютеру через Work Cloud поддерживает заданные администратором MCP-хуки, которые выполняются на облачном координаторе (оркестраторе) для поддерживаемых событий жизненного цикла и инструментов. При облачной оркестрации хуки команд и хуки из локальной конфигурации или плагинов не поддерживаются, даже если инструменты выполняются локально.

  • Неподдерживаемые хуки. При облачной оркестрации хуки команд и хуки из локальной конфигурации или плагинов не поддерживаются, даже если инструменты выполняются локально. Если и оркестрация, и выполнение происходят локально, существующие поддерживаемые хуки продолжают работать в исключительно локальных диалогах Work и Codex. Администраторы по-прежнему могут настраивать поддерживаемые управляемые хуки в Agent Security для этих процессов.

  • Аудит. Прежде чем полагаться на эти хуки, проверьте соединение для обратных вызовов, убедитесь, какие события через него поступают, и проверьте, как сбои влияют на задачу. MCP-хуки не обеспечивают полный журнал аудита Compliance API.

  • Требования к данным. Доступ к локальному компьютеру через Work Cloud не обеспечивает строгое соблюдение режима нулевого хранения данных. Требования к размещению данных и месту выполнения инференса распространяются только на соответствующий условиям контент и поддерживаемые нагрузки, регионы и конфигурации. Enterprise Key Management (EKM) охватывает поддерживаемый хранимый контент в рабочих пространствах, соответствующих условиям. Work не поддерживается при размещении инференса в ОАЭ. Если enforce_residency включён в любой облачной политике, параметр Разрешить доступ к локальному компьютеру отключается и для Work, и для dots. Эта защитная мера не настраивает регион размещения рабочего пространства и сама по себе не отключает Work Cloud или dots. Если вашей организации требуется ZDR, не включайте эту функцию.

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

Шаг 3. Настройте требования к локальной среде выполнения

Локальные требования ограничивают поведение среды выполнения, когда пользователь запускает поддерживаемый локальный сеанс в настольном приложении ChatGPT, Codex CLI или расширении IDE. Доставляйте requirements.toml через поддерживаемый облачный канал, канал устройства или системный канал. Не смешивайте эту политику с ролями и группами рабочего пространства ChatGPT.

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

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

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

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

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

Шаг 4. Стандартизируйте конфигурацию репозитория

Используйте конфигурацию на уровне репозитория, чтобы совместно применять настройки проекта по умолчанию, правила и навыки без дублирования настройки для каждого пользователя. Добавляйте конфигурацию в систему контроля версий в .codex или .agents в соответствии с расположением, указанным в документации функции:

Тип Источник Назначение
Конфигурация Основы конфигурации Задание настроек репозитория по умолчанию для поддерживаемых локальных клиентов
Правила Правила Управление командами, требующими подтверждения за пределами песочницы
Навыки Создание навыков Предоставление рабочих процессов репозитория поддерживаемым клиентам

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

Шаг 5. Настройте Codex cloud

Codex cloud использует размещённые в облаке среды и подключённые репозитории исходного кода.

Codex Cloud по умолчанию отключён для рабочих пространств Enterprise. Существующие настройки Использовать Codex в облаке переносятся из Codex Cloud (Legacy): рабочие пространства, в которых Cloud уже был включён, сохраняют доступ, а там, где Cloud был отключён, он остаётся отключённым, пока администратор не включит его. Доступ по-прежнему зависит от этапа развёртывания и ограничений рабочего пространства.

Спланируйте каждый уровень разграничения доступа:

  1. Предоставьте целевым пользователям разрешение Использовать Codex в облаке. Отдельно предоставьте разрешение Управлять средами рабочего пространства тем, кто создаёт и редактирует общие среды рабочего пространства. См. рекомендации по ролям в рабочем пространстве.
  2. Установите и настройте поддерживаемую интеграцию с системой хранения исходного кода.
  3. Ограничьте доступ к репозиториям в системе хранения исходного кода теми репозиториями, которые нужны каждой группе пользователей.
  4. Настройте облачные среды, секреты, доступ к интернету и поддерживаемые требования, управляемые в облаке, для этих репозиториев.
  5. Настройте дополнительные облачные процессы, например проверку кода.
  6. Проверьте доступ к задачам с участием типичного пользователя, а управление средами — с участием назначенного администратора. Проверьте разрешения каждого из них для рабочего пространства, сред и репозиториев.

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

Codex cloud соблюдает разрешения и меры защиты репозиториев, предоставляемые подключённой системой хранения исходного кода. Доступ к рабочему пространству не позволяет обойти эти меры. См. Облачные среды для получения рекомендаций по настройке и выполнению задач.

Шаг 6. Настройте плагины и подключенные возможности

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

Перед включением плагина или навыка в развертывание:

  1. Подтвердите его источник, ответственного владельца, целевую аудиторию и дату проверки.
  2. Проверьте встроенные навыки, коннекторы, MCP servers, перехватчики, а также данные и действия, необходимые каждой возможности.
  3. Протестируйте его с неконфиденциальными данными и минимально необходимым уровнем доступа.
  4. Зафиксируйте, кто отвечает за повторную проверку и вывод из эксплуатации.

Плагины работают в Chat и Work в ChatGPT в веб-версии, настольном и мобильном приложениях, в Codex в настольном приложении ChatGPT, а также через браузер плагинов Codex CLI. В расширении IDE они недоступны. ChatGPT и Codex используют единый универсальный публичный каталог плагинов; средства управления рабочим пространством определяют, к каким из этих плагинов получат доступ участники.

Полное описание модели см. в разделах Управление плагинами и Управление навыками.

Шаг 7. Настройте управление и наблюдаемость

Выберите инструмент отчетности, соответствующий задаче:

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

Обеспечьте защиту границы интеграции:

  • Храните API keys и другие учетные данные интеграции в корпоративной системе управления секретами.
  • Ограничьте доступ к последующим системам и хранимым данным утвержденной аудиторией.
  • Защищайте экспортированные записи Compliance API с учетом их конфиденциальности и политики хранения организации, а рабочие процессы сбора и удаления тестируйте на соответствие актуальному контракту.

Шаг 8. Проверьте и поддерживайте развертывание

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

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

Проверьте каждую применимую границу с помощью типичных учетных записей:

  • Участие в рабочем пространстве ChatGPT, рабочее место и разрешения поддерживаемой роли.
  • Охватываемые локальные возможности в настольном приложении ChatGPT, Codex CLI и расширении IDE, включая вход и фактически действующие требования среды выполнения.
  • Доступ к Codex cloud, конфигурация среды и разрешения репозитория.
  • Доступ к организации и проекту Platform API для рабочих процессов с API key.
  • Установка плагинов, встроенные навыки, доступ к коннекторам и поддерживаемые действия.
  • Авторизация в подключенных системах и доступ к данным.
  • Доступ к аналитике и данным о соответствии требованиям для ответственных администраторов.

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

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

Если нужно отключить доступ к локальному компьютеру через Work Cloud

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