Что даёт связка ChatGPT Desktop, Codex и Amazon Bedrock в AWS GovCloud
ChatGPT Desktop и Codex можно развернуть в контролируемом режиме так, чтобы инференс моделей OpenAI шёл через Amazon Bedrock в AWS GovCloud (US-West, регион us-gov-west-1). Приложение работает на управляемом организацией компьютере: десктопный клиент или CLI берёт настроенные учётные данные AWS и отправляет запросы на эндпоинт Amazon Bedrock Mantle в us-gov-west-1. Сам инференс проходит через Responses API на Amazon Bedrock, а доступ регулируют AWS Identity and Access Management (IAM) и существующие сетевые контроли AWS GovCloud (US).
Обработка остаётся в выбранном регионе Amazon Bedrock, если у организации есть требования к резидентности данных. Оплата идёт за токены: лицензий на места и обязательств на разработчика нет. Поддерживается режим нулевого хранения данных (ZDR), в котором промпты и ответы обрабатываются без записи в долговременное хранилище со стороны AWS и без передачи провайдерам моделей. Официальное руководство AWS по этой конфигурации описывает её целиком, включая оговорки по авторизации.
Дальше начинается часть, от которой зависит всё остальное. Использование AWS GovCloud (US) и следование любому гайду сами по себе нагрузку не авторизуют. Организация сверяет выбранную модель, сервисы AWS, регион, эндпоинт, средства управления рабочей станцией, репозитории, учётные данные и потоки данных со своим планом безопасности и процессом авторизации. Этот текст - разбор конфигурации и порядка её проверки, а не разрешение на эксплуатацию.
Кому подходит и кому нет
Схема нужна организациям, чья архитектура безопасности требует, чтобы инференс моделей использовал идентичности, эндпоинты и региональные контроли AWS GovCloud (US). Второй адресат - команды безопасности: они проверяют и документируют конфигурацию до того, как разрешить более широкое использование.
- Подходит: разработка и ревью кода в регулируемой среде, работа с чувствительными репозиториями, сценарии, где аудит и сетевой контроль важнее удобства.
- Не подходит: как способ сэкономить на обычном ChatGPT или как замена рабочему пространству ChatGPT для команды без требований к резидентности и формальной авторизации.
Опора на админку ChatGPT здесь не работает. Установка использует AWS напрямую, поэтому правила рабочего пространства ChatGPT и роли пользователей её не контролируют: основные средства контроля безопасности находятся на компьютере. Практический вывод простой: политику рабочей станции и сеть настраивают до первого запуска, иначе первый же старт пройдёт в конфигурации по умолчанию.
Два компонента: Work и Codex
Доступ к моделям OpenAI идёт через два компонента. Work выполняет сложные многошаговые задачи и выдаёт результаты, готовые к проверке. Codex работает как агент для разработки, тестирования и проверки ПО. Других функций этим компонентам приписывать не нужно: всё, что выходит за рамки описания, проверяется по документации вендора.
Клиентов три: десктопное приложение ChatGPT, Codex CLI и IDE-интеграции с Visual Studio Code, JetBrains и Xcode. Набор важен для проверки: конфигурацию подтверждают в каждом клиенте, который реально используется в команде.
Архитектура и потоки данных: что куда уходит
Цепочка запроса выглядит так:
- Пользователь работает на управляемом организацией компьютере в десктопном приложении ChatGPT, Codex CLI или IDE-интеграции.
- Клиент берёт учётные данные из заранее заданного именованного AWS-профиля. Это либо ключ Amazon Bedrock API, либо временные креденшелы из цепочки AWS SDK, включая SSO-сессию IAM Identity Center.
- Запрос уходит по HTTPS на эндпоинт Amazon Bedrock Mantle в
us-gov-west-1. Сетевые ограничения пропускают только этот адрес. - Bedrock передаёт запрос в Responses API и выбранную модель. Обработка остаётся в регионе Bedrock.
- Ответ возвращается в клиент. При включённом ZDR промпты и ответы не записываются в долговременное хранилище на стороне AWS и не передаются провайдерам моделей.
Управление доступом идёт через IAM и сетевые контроли AWS GovCloud (US). Периметр вокруг рабочей станции и периметр вокруг AWS-аккаунта настраиваются отдельно, и оба нужно подтвердить до запуска. Ниже список объектов, которые стоит зафиксировать в документе проверки.
| Объект проверки | Что подтвердить |
|---|---|
| Модель | Конкретная модель OpenAI одобрена для этой нагрузки и этого региона |
| Сервисы AWS | Перечень задействованных сервисов совпадает с согласованным |
| Регион | us-gov-west-1 подтверждён как регион обработки |
| Эндпоинт | Разрешён именно эндпоинт Amazon Bedrock Mantle, других сетевых выходов у клиентов нет |
| Рабочая станция | Политика устройства применяется и не отключается локальным администратором |
| Репозитории | Список доступных репозиториев ограничен и зафиксирован |
| Учётные данные | Тип (ключ или SSO), срок жизни, порядок ротации и отзыва |
| Потоки данных | Соответствие плану безопасности, включая режим хранения и ZDR |
Почему правила ChatGPT workspace здесь не работают
Организации привыкли управлять доступом через рабочее пространство ChatGPT: роли, участники, настройки функций. В этой схеме такой слой отсутствует, потому что запросы идут в AWS под учётными данными AWS, а клиент живёт на машине пользователя. Значит, ограничения описываются там, где они реально применяются: в файле политики устройства и в сетевых правилах.
Отсюда и требования к процессу: конфигурация должна накатываться централизованно, а не руками пользователя, иначе один локальный администратор сведёт на нет весь пилот. Как выглядят такие многослойные ограничения в близком сценарии, мы разбирали в материале про изоляцию AI-агентов на Amazon Bedrock AgentCore: там роль играют отдельный аккаунт, DNS Firewall и политики VPC-эндпоинтов.
Подготовка до первого запуска: порядок действий
Последовательность важнее скорости. Если запустить клиент до того, как закрыты политика и сеть, ограничения придётся накатывать на уже работающую установку, и часть проверок станет бессмысленной.
- Определить рабочую станцию и политику устройства. Выбрать машину, на которой будет пилот, и зафиксировать, какие возможности выключены. Пользователь не должен иметь возможности изменить этот набор.
- Закрыть сеть. Разрешить только одобренный эндпоинт Amazon Bedrock, отключить прочие внешние соединения и сетевые возможности. Изоляция от openai.com и других внешних доменов входит сюда же.
- Подготовить именованный AWS-профиль и выбрать ветку аутентификации: ключ Amazon Bedrock API или цепочка AWS SDK со SSO через IAM Identity Center.
- Записать
config.tomlиrequirements.tomlдо первого запуска. Первый файл задаёт параметры подключения, второй фиксирует политику устройства. - Выполнить вход в API-режиме. Интерактивный вход через обычную учётную запись ChatGPT в этой схеме не используется.
- Запустить десктопное приложение и Codex CLI. Если в команде есть IDE-интеграции, их проверяют отдельно.
- Проверить провайдера модели через
/statusв Codex CLI и в настройках приложения. - Задокументировать результат для процесса авторизации: версии клиентов, имя профиля, регион, эндпоинт, лог или скриншот проверки, дата.
Вся конфигурация держится на четырёх элементах: вход в API-режиме, управляемая политика устройства, именованный AWS-профиль и сетевые ограничения, разрешающие доступ только к одобренному эндпоинту Amazon Bedrock при отключении других внешних соединений и сетевых возможностей. Выпал любой из них - схема перестаёт быть контролируемой.
Аутентификация: ключ Amazon Bedrock API или цепочка AWS SDK с SSO
Ветку выбирают один раз, до записи config.toml: от неё зависит содержимое профиля, порядок проверки и план отзыва доступов.
Когда выбирать ключ Amazon Bedrock API
Путь удобен прозрачностью: один явный секрет, минимум зависимостей от IdP и SSO-сессий. Для короткого пилота на пару машин этого хватает.
- Плюсы: простая настройка, понятная диагностика при ошибках, не зависит от доступности провайдера идентичности.
- Минусы: ключ ведёт себя как долгоживущий секрет, его нужно хранить вне репозиториев и ротировать по регламенту; к SSO-сессии он не привязан, поэтому отзыв при инциденте критичен.
Если проверка не прошла, ключ отзывают в первую очередь. Это часть плана отката, а не отдельное пожелание.
Когда выбирать цепочку AWS SDK и SSO через IAM Identity Center
Этот вариант ближе организациям с корпоративным IdP и практикой временных креденшелов. Приложение берёт учётные данные из цепочки AWS SDK, а SSO-профиль IAM Identity Center выдаёт их после входа сотрудника.
- Плюсы: временные креденшелы вместо статического секрета, централизованное управление доступом через IAM, отзыв доступа не требует обхода всех машин.
- Минусы: зависимость от доступности SSO и корректности профиля; истёкшая сессия ломает запуск, и клиент уходит в ошибку аутентификации вместо работы.
Общее правило для обеих ветвей: именованный AWS-профиль - это то, на что ссылается конфигурация приложения. При SSO профиль должен быть валиден на момент запуска. Публичное описание конфигурации не приводит полного синтаксиса команд и точных имён полей, поэтому перед настройкой сверяйтесь с официальной документацией AWS и OpenAI, а не с фрагментами из сторонних блогов.
config.toml и requirements.toml: что где задаётся
Разделение ответственности простое. config.toml содержит параметры подключения: провайдер, регион, имя AWS-профиля, режим входа. requirements.toml задаёт управляемую политику устройства: набор ограничений, который фиксируется централизованно и не должен обходиться пользователем.
В политике должны найти отражение вход в API-режиме, именованный AWS-профиль, одобренный эндпоинт Amazon Bedrock, отключённые браузер, генерация изображений, память и телеметрия, изоляция от openai.com и прочих внешних доменов. Имена конкретных полей зависят от версии клиента. Проверяйте их по официальной документации и фиксируйте версию, для которой составлен файл: политика, написанная под другую сборку, может молча не примениться.
Сетевые ограничения: только одобренный эндпоинт Bedrock
Правило одно: разрешён только одобренный эндпоинт Amazon Bedrock, остальное закрыто. Изоляция от openai.com и прочих внешних доменов нужна по двум причинам. Первая: клиент не должен иметь технической возможности уйти в обходной маршрут и отправить данные мимо Bedrock. Вторая: каждый лишний разрешённый адрес расширяет поверхность атаки и добавляет строку в сверку с планом безопасности.
Конкретные IP-адреса и FQDN в публичном описании не приводятся. Список формируется по документации AWS для региона us-gov-west-1, проверяется на актуальность и фиксируется в сетевой политике. Если в логах появляются обращения к доменам вне списка, это сигнал, что клиент или его компонент обновления настроен не так, как предполагалось.
Отключение браузера, генерации изображений, памяти и телеметрии
Каждая из этих возможностей создаёт дополнительный поток данных или внешнее соединение. Браузер подтягивает веб-контент, генерация изображений обращается к отдельному сервису, память хранит контекст между сессиями, телеметрия отправляет диагностику. При инференсе через Bedrock ни один из этих потоков не нужен для работы, а каждый добавляет вопрос в процесс авторизации.
Практический эффект отключения: меньше данных покидает машину, проще обосновать конфигурацию перед безопасниками, меньше зависимостей от внешних сервисов при проверке. Обратная сторона тоже есть: пользователи теряют привычные функции, и это стоит проговорить с командой заранее, чтобы пилот не превратился в спор о удобстве.
Проверка после запуска: убедиться, что провайдер - Bedrock
Проверка не должна опираться на предположения. В Codex CLI выбранный провайдер модели смотрится через /status, в десктопном приложении - в настройках. Если используются оба клиента, проверять нужно оба: конфигурация могла примениться к одному и не примениться к другому, особенно когда версии клиентов различаются.
Формат вывода /status зависит от версии клиента, поэтому оценивайте не внешний вид, а факт: провайдер - Amazon Bedrock, регион us-gov-west-1, профиль тот самый, что заведён для пилота. Если в статусе виден другой провайдер или другой регион, останавливайтесь и возвращайтесь к requirements.toml и сетевой политике.
Результат проверки фиксируется для процесса авторизации: скриншот или лог со статусом, дата, версии клиентов, имя профиля, регион. Без этой записи разговор с безопасниками снова начнётся с нуля.
Границы авторизации: что нужно сверить с планом безопасности
Использование AWS GovCloud (US) и следование руководству сами по себе нагрузку не авторизуют. Организация отвечает за проверку выбранной модели, сервисов AWS, региона, эндпоинта, средств управления рабочей станцией, репозиториев, учётных данных и потоков данных на соответствие system security plan и своему процессу авторизации. Источник AWS формулирует это прямо, без оговорок.
- Какая модель одобрена и покрывает ли она задачи пилота?
- Какие сервисы AWS задействованы и все ли они есть в согласованном перечне?
- Подтверждён ли регион
us-gov-west-1как регион обработки? - Тот ли это эндпоинт Bedrock Mantle, и нет ли у клиентов альтернативных маршрутов?
- Какие средства управления рабочей станцией применяются и как проверяется их работоспособность?
- Какие репозитории доступны агенту и кто подтвердил этот список?
- Какие учётные данные выданы, на какой срок и как отзываются?
- Какие потоки данных остаются и как они соотносятся с режимом хранения и ZDR?
Как такой чек-лист выглядит на практике для регулируемой компании, мы разбирали в материале про защищённую self-service аналитику в Amazon SageMaker: там тоже речь про IAM, шифрование, сетевые ограничения и аудит, и тоже без автоматического одобрения нагрузки.
План отката, если проверка не прошла
Откат готовят до пилота, иначе в момент провала времени на его согласование не будет.
- Остановить использование клиентов на управляемых машинах.
- Вернуть предыдущую версию политики устройства вместо пилотного
requirements.toml. - Отозвать временные ключи и учётные данные, выданные для проверки.
- Закрыть сетевые исключения, добавленные специально для пилота.
- Зафиксировать причину провала и результаты проверки в том же документе, где планировалась авторизация.
Отзыв ключей - обязательный шаг, а не опция. Учётные данные, выданные для проверки и оставшиеся активными, продолжают работать после того, как политику откатили и про пилот забыли. Почему это не теоретический риск, видно по разбору несанкционированных действий GPT-5.6 Sol: там отдельно разобраны кэш учётных данных и цена изоляции.
Итог: когда схема оправдана, а когда избыточна
Схема оправдана, когда архитектура безопасности требует идентичностей, эндпоинтов и региональных контролей AWS GovCloud (US) для инференса моделей, и когда есть процесс авторизации, готовый принять документированную конфигурацию. Она избыточна, когда команде достаточно обычного рабочего пространства ChatGPT, нет требований к резидентности данных и нет формальной процедуры одобрения: управляемая политика, сетевые ограничения и отзыв ключей добавят работы без выигрыша.
На решение влияют два фактора. Оплата за токены без лицензий на места и обязательств на разработчика упрощает пилот на несколько человек. Поддержка ZDR снимает часть вопросов о хранении промптов, но не заменяет сверку потоков данных с планом безопасности.
Следующий шаг после прочтения: выписать по чек-листу, что уже подтверждено, отметить пробелы и назначить дату проверки провайдера через /status в каждом клиенте, который будет использоваться. Если хотя бы один пункт закрыть не удаётся, разворачивать конфигурацию рано.