Управление ключами OpenAI API: правила создания, владельцы, срок действия и ротация без простоя

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

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

Сначала вывод: новые правила управляют будущими ключами, а не старыми

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

Дата	Обновление OpenAI	Что это значит для команды
10 сентября 2026 года	При создании проектного API-ключа можно задать дату истечения. Администратор может установить максимальный срок жизни ключа на уровне организации или проекта.	Новые ключи можно сделать заведомо временными, но до короткого лимита нужно подготовить повторяемую ротацию.
15 сентября 2026 года	Организация или проект может разрешить только service-account keys, только user-owned project keys либо полностью запретить создание новых API-ключей.	Для производственных сервисов, личной разработки и замороженных проектов можно установить разные правила выдачи.
15 сентября 2026 года	Ограничения организации имеют приоритет над настройками проекта.	Проект не может ослабить правило организации; он может действовать только в разрешённых ею границах.
15 сентября 2026 года	Существующие API-ключи не затрагиваются новыми ограничениями на создание.	Включение правила не отзывает старые ключи и не завершает их миграцию.

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

Разделите три решения: кто создаёт, сколько ключ живёт и как выводится

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

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

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

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

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

Выбирайте по сценарию: сервисные ключи для продакшена, пользовательские — для личной разработки

Для продакшена и общих нагрузок сначала выбирайте service-account key, для локальной и краткосрочной работы — user-owned project key, а выпуск полностью отключайте только в действительно замороженных или закрываемых проектах.

Сценарий	Обычно лучше подходит	Почему	Основной риск
Продакшен-сервис, общий backend, периодическая задача, командный агент	service-account key	Ключ связан с рабочей нагрузкой, а не с конкретным сотрудником; кадровые изменения меньше влияют на непрерывность.	Один сервисный аккаунт для множества несвязанных приложений увеличивает радиус поражения. Разделяйте по проектам или нагрузкам.
Локальная разработка, временная отладка, исследовательский скрипт	user-owned project key	Понятны владелец и персональная ответственность, а offboarding может включать его ключи.	Личный ключ не должен незаметно стать общей производственной зависимостью.
Архивный, выводимый из эксплуатации или временно замороженный проект	Запретить новые ключи	Инвентарь учётных данных перестаёт расти во время закрытия или проверки проекта.	Слишком ранняя блокировка может помешать создать замену для ротации или восстановления.

Полезный вопрос: должно ли приложение продолжать работать после ухода конкретного сотрудника? Если да, производственный ключ обычно не должен зависеть от его личной учётной записи. С другой стороны, общий сервисный ключ на ноутбуках всех разработчиков ухудшает атрибуцию и увеличивает число копий секрета.

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

Политика организации — потолок: проект может только ужесточить её

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

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

Перед изменением правила на уровне организации выполните следующую последовательность:

1. Перечислите проекты и отметьте продакшен, staging, разработку, тест, временные, архивные и выводимые из эксплуатации.
2. Для каждого проекта зафиксируйте тип ключа, который потребуется при следующей ротации, а не только уже существующие типы.
3. Определите замену для каждой активной нагрузки и убедитесь, что будущая политика разрешит её создать.
4. Отрепетируйте создание, публикацию, проверку и отзыв в проекте с низким риском.
5. Только после успешной репетиции применяйте ограничение организации.

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

Не назначайте один срок всем: начните со времени реальной ротации

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

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

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

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

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

Семь шагов для ротации без простоя

Надёжнее всего ненадолго оставить старый и новый ключ действующими одновременно и отзывать старый только после подтверждения реальным трафиком.

1. Составьте реестр текущих ключей

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

В обновлении от 4 августа 2026 года OpenAI сообщила, что дашборды Usage и Costs, а также Usage API и Costs API поддерживают фильтрацию и группировку по API-ключу. Этот разрез помогает понять, генерирует ли ключ запросы. Однако отсутствие трафика за короткий период недостаточно: редкая пакетная задача или аварийный маршрут может запускаться раз в месяц.

2. Создайте соответствующую политике замену

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

3. Сохраните замену как новую версию секрета

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

4. Переключайте постепенно

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

5. Наблюдайте и за приложением, и за использованием ключа

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

6. Ограничьте окно отката по времени

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

7. Отзовите, проверьте и назначьте следующую дату

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

Старые ключи не станут соответствовать правилам автоматически: мигрируйте их по риску

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

Создайте отдельную очередь миграции и расставьте приоритеты:

1. ключи, замеченные в коде, задачах, логах или чатах;
2. ключи с неизвестным владельцем или назначением;
3. пользовательские ключи ушедших сотрудников или людей с изменившейся ролью;
4. ключи, общие для нескольких производственных приложений;
5. ключи с широкой областью и высоким потенциальным ущербом;
6. ключи с ясным владельцем, одной нагрузкой и проверенным путём замены.

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

Во внутренней политике нужны как минимум эти 11 полей

Исполнимая политика должна фиксировать не только срок, но и владельца, доказательства переключения, окно отката и условие отзыва.

Пункт	Что зафиксировать
Область	Организация, проекты, среды и классы нагрузок
Разрешённый тип новых ключей	Только сервисные, только пользовательские проектные или запрет создания
Обоснование	Непрерывность, персональная ответственность, заморозка проекта
Максимальный срок	Потолок организации и более строгие пределы проекта
Упреждение	Когда до истечения создаётся предупреждение или задача
Хранение	Разрешённый менеджер секретов и роли доступа
Выпуск	Canary/поэтапный rollout, перезапуск и откат
Доказательства	Успешные запросы, ошибки, использование по ключу, нулевой трафик старого ключа
Условие отзыва	Новый ключ стабилен, редкие задачи проверены, окно отката закрыто
Исключение	Утверждающий, причина, компенсация и срок исключения
Аудит	Создание, изменение политики, развертывание, отзыв и смена владельца

Долгосрочную ответственность лучше связывать с нагрузкой или ролью команды, но для конкретной ротации всё равно нужен исполнитель. Фраза «отвечает platform team» недостаточна без дежурного маршрута, срока и эскалации.

До включения ограничений отрепетируйте следующую ротацию

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

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

Частые вопросы

Новое ограничение сразу сломает работающие приложения?

Нет, если речь только о новом правиле создания. В changelog от 15 сентября 2026 года сказано, что существующие API-ключи не затрагиваются. Но правило повлияет на будущую замену, поэтому выпуск нового ключа нужно отрепетировать заранее.

Максимальный срок автоматически применяется к старым ключам?

Описание от 10 сентября относится к новым ключам. Не предполагайте ретроактивного истечения: проверьте сведения о конкретном ключе и мигрируйте старые ключи отдельно.

Может ли администратор проекта ослабить правило организации?

Нет. Ограничение организации имеет приоритет над проектными настройками.

Нужно ли всей организации перейти только на сервисные ключи?

Для производственных сервисов, общих backend, scheduled jobs и командных агентов в первую очередь используйте сервисные ключи. Для локальной разработки и краткосрочных исследований — пользовательские проектные. Правило «только сервисные ключи» на всю организацию оправдано лишь тогда, когда почти все проекты относятся к первой группе, а у разработчиков уже есть рабочая альтернатива.

Когда уместно полностью запретить новые ключи?

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

Чем доказать, что старый ключ можно отозвать?

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

С чего начать прямо сейчас

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

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

Официальный источник:

• OpenAI API Changelog: обновления от 10 и 15 сентября 2026 года