Что произошло
10 сентября 2026 года OpenAI опубликовала обновление в API changelog, вводящее новую функциональность для управления проектными ключами. Администраторы организаций и проектов получили возможность задавать максимальный срок жизни (maximum key lifetime) для любых создаваемых API-ключей. Новые ключи не могут быть созданы с бесконечным сроком действия и обязаны истекать в пределах, установленных на уровне организации или проекта. Это изменение позиционируется как шаг к повышению безопасности по умолчанию (security-by-default) для корпоративных клиентов.
Инициатива является прямым ответом на растущее число инцидентов, связанных с компрометацией API-ключей. Как следует из отчёта METR, в марте 2026 года один украденный ключ позволил злоумышленникам в течение трёх недель расходовать средства на публичные модели, нанеся ущерб примерно на $600 000. Аналитики Cloud Security Alliance (CSA) и CloudSEK также отмечают серию атак на IDE-плагины и CI/CD-пайплайны в период с октября 2025 по июнь 2026 года, где API-ключи ИИ-провайдеров становились первоочередной целью. Максимальный срок жизни ключа напрямую ограничивает «окно компрометации», снижая потенциальный финансовый и репутационный ущерб.
Одновременно с этим обновлением OpenAI анонсировала публичную бета-версию Agents API и запуск модели GPT-6 Astra, ориентированных на сложные корпоративные сценарии. Усиление контроля над ключами происходит на фоне активного продвижения агентных решений, что требует от компаний выстраивания более зрелой архитектуры безопасности. Для российского бизнеса, который активно осваивает фронтир-модели, в том числе через шлюзы и агрегаторы, это изменение становится обязательным к рассмотрению в рамках обновления внутренних политик и процедур.
Как это устроено
Механика контроля: двухуровневая иерархия
Новая политика реализована как иерархическая система ограничений. Администратор на уровне всей организации в настройках платформы (Platform settings) устанавливает верхний предел срока жизни ключа. Далее руководители отдельных проектов могут задавать более строгие ограничения в рамках своего проекта, но они не могут превысить лимит, установленный на уровне организации. Такая модель обеспечивает централизованное управление рисками и позволяет делегировать операционную ответственность без нарушения общих стандартов безопасности. По нашему опыту проектов, подобная двухуровневая система эффективно работает в крупных холдингах с децентризованной структурой ИТ-команд.
Технологическая реализация: policy enforcement
Технически функция представляет собой встроенный механизм принудительного применения политик (policy enforcement) на стороне платформы OpenAI. При попытке создать новый ключ без указания срока истечения или со сроком, превышающим установленный лимит, система вернёт ошибку. Это отличается от предыдущей модели, где безопасность полностью зависела от дисциплины разработчиков и внешних инструментов, таких как секрет-менеджеры или скрипты ротации. Теперь платформа сама выступает гарантом соблюдения базового правила безопасности, что снижает вероятность человеческой ошибки. В типовом сценарии это исключает создание «вечных» ключей для тестовых или временных задач, которые часто забывают отозвать.
Экономика безопасности: снижение потенциального ущерба
Основной экономический эффект от нововведения заключается в уменьшении максимального ущерба от утечки ключа. Если ранее скомпрометированный ключ мог использоваться месяцами, то теперь его время жизни жёстко ограничено. В случае с инцидентом METR, где ущерб составил $600 000, наличие ограничения в 30 дней сократило бы потенциальные потери как минимум на две трети. Экономика атаки на ИИ-сервисы меняется: для злоумышленника повышается стоимость эксплуатации украденного ключа, так как требуется чаще находить новые векторы для его получения. Это делает такие атаки менее привлекательными с точки зрения рентабельности.
Ограничения и границы политики
Несмотря на очевидную пользу, новая политика не является панацеей. Она не вводит одноразовые ключи (one-time tokens) для сессий, не интегрируется напрямую с корпоративными IAM-системами для федерации идентификации и не предоставляет рекомендаций по оптимальному значению срока жизни. OpenAI оставляет выбор конкретного лимита за клиентом. Кроме того, политика распространяется только на ключи, создаваемые через платформу OpenAI, и не контролирует ключи от сторонних шлюзов (например, Polza или ProxyAPI), если они не используют механизм управления ключами самого OpenAI. Поэтому комплексная безопасность по-прежнему требует многослойного подхода.
Как это выглядит на практике
В финансовой компании, использующей фронтенд-модели для анализа транзакций через российский шлюз, проксирующий запросы к OpenAI, CISO устанавливает максимальный срок жизни ключей в 30 дней на уровне организации. Команда разработки, работающая над сервисом скоринга, создаёт проектный ключ со сроком в 7 дней для CI/CD-пайплайна. При компрометации учетной записи одного из разработчиков злоумышленник получает доступ к ключу, но через 7 дней он становится неактивным, автоматически блокируя дальнейшие несанкционированные вызовы и ограничивая финансовые потери. Инцидент выявляется по аномальному всплеску активности в первые сутки, но ущерб оказывается минимальным.
В компаниях-разработчиках ПО, интегрирующих GPT-6 Astra в свои SaaS-продукты, новая политика меняет процесс онбординга клиентов. Вместо предоставления постоянного API-ключа, клиент через личный кабинет генерирует ключ с заданным сроком жизни, например, 90 дней. За неделю до истечения система автоматически уведомляет клиента о необходимости обновления ключа. Такой подход снижает количество обращений в поддержку из-за «сломавшейся» интеграции и одновременно защищает клиента от последствий утечки ключа из его собственной системы, так как даже украденный ключ будет действовать ограниченное время.
Для системного интегратора, внедряющего ИИ-решения для госзаказчика, наличие функции maximum key lifetime становится аргументом в пользу соответствия требованиям 243-ФЗ. В контракте прописывается, что все ключи доступа к внешним моделям должны иметь срок жизни не более 60 дней. Интегратор настраивает соответствующий лимит в проекте на платформе OpenAI. Это позволяет заказчику быть уверенным, что по окончании проекта или при смене подрядчика все выданные ключи автоматически станут недействительными, что является частью процедуры вывода ИИ-сервиса из эксплуатации.
Что это значит для российской компании
Для российского бизнеса прямое взаимодействие с API OpenAI осложняется инфраструктурными ограничениями, поэтому большинство компаний используют специализированные шлюзы (ProxyAPI, VseGPT, Neurly, RockAPI) или резидентные решения (Polza). Новая политика OpenAI напрямую влияет на тех, кто использует шлюзы с транзакционной моделью оплаты, так как конечный ключ к API OpenAI остаётся у провайдера шлюза. Однако принцип короткоживущих ключей становится отраслевой практикой безопасности, и российские компании должны применять его и в своей архитектуре, управляя ключами доступа к самим шлюзам.
С точки зрения законодательства, 243-ФЗ «Об экспериментальных правовых режимах…» от 26.07.2026 даёт оператору больших фундаментальных моделей право определять правила их эксплуатации, обновления и вывода из эксплуатации. Хотя закон напрямую не регламентирует срок жизни API-ключей, внедрение политики maximum key lifetime является технической реализацией принципа контролируемого жизненного цикла ИИ-активов, что соответствует духу и букве закона. Это особенно актуально для компаний, которые создают собственные ИИ-сервисы на базе fronter-моделей и должны демонстрировать регуляторам зрелость процессов управления.
Экономически переход к короткоживущим ключам может потребовать первоначальных инвестиций в автоматизацию (секрет-менеджеры, CI/CD-скрипты), но в долгосрочной перспективе он снижает стоимость владения за счёт предотвращения дорогостоящих инцидентов. Бюджеты на информационную безопасность должны быть пересмотрены в сторону увеличения расходов на проактивные меры управления доступом, а не только на реагирование.
| Аспект | Старый подход (без ограничений) | Новый подход с Maximum Key Lifetime |
|---|---|---|
| Управление жизненным циклом | Ручная ротация по необходимости, риск «забытых» ключей. | Автоматическое принудительное истечение по заданному расписанию. |
| Модель рисков | Высокий потенциальный ущерб при утечке, окно компрометации не ограничено. | Снижённый и предсказуемый ущерб, окно компрометации ограничено днями/неделями. |
| Операционная нагрузка | Нерегулярные, но трудоёмкие процедуры ревока и перевыпуска ключей. | Интеграция ротации в регулярные процессы CI/CD и IDM. |
| Соответствие комплаенсу | Сложно доказать соблюдение политик безопасности при аудите. | Наличие технического контроля, упрощающего прохождение аудитов и соответствие 243-ФЗ. |
Что делать: пошагово
- Проведите полную инвентаризацию всех существующих API-ключей OpenAI и ключей к шлюзам в ваших системах, включая репозитории кода, CI/CD-конфигурации и секрет-менеджеры.
- Определите и зафиксируйте во внутренней политике безопасности максимальные сроки жизни ключей для различных сред (например, 90 дней для production, 30 дней для staging, 7 дней для dev).
- Зайдите в настройки платформы OpenAI (Platform settings) и установите organisational limit в соответствии с утверждённой политикой.
- Настройте автоматическую ротацию ключей с использованием ваших секрет-менеджеров (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) или внутренних скриптов, которые будут обновлять ключи до их истечения.
- Модифицируйте все CI/CD-пайплайны так, чтобы они динамически получали короткоживущие ключи из секрет-менеджера на время сборки или развёртывания, а не использовали вшитые в код константы.
- Интегрируйте логирование использования API-ключей в вашу SIEM-систему для мониторинга аномальной активности и оперативного реагирования на потенциальные компрометации.
- Обновите стандарты безопасной разработки и проведите обучение для разработчиков, разъяснив новые правила работы с API-ключами и процедуру их получения.
Типичные ошибки
- Установка слишком долгого срока жизни. Выбор лимита в 365 или более дней практически обесценивает всю инициативу, сохраняя высокое окно компрометации и не меняя модель рисков.
- Игнорирование ключей от шлюзов. Фокусировка только на ключах от api.openai.com в то время, как ключи для доступа к Polza или ProxyAPI остаются бессрочными, создаёт ложное чувство безопасности.
- Отсутствие автоматизации ротации. Расчёт на то, что разработчики будут вручную обновлять ключи раз в месяц, неизбежно приводит к простоям сервисов и человеческим ошибкам.
- Хранение ключей в коде. Несмотря на новую политику, разработчики продолжают хранить ключи в git-репозиториях или config-файлах, что делает их уязвимыми для утечки при компрометации репозитория.
- Отсутствие мониторинга использования. Невозможность отследить, какой ключ, из какого сервиса и с какой интенсивностью используется, не позволяет выявить компрометацию на ранней стадии.
Как понять, что вы на верном пути
- В вашей системе не существует ни одного API-ключа старше установленного лимита, что подтверждается автоматическими сканерами.
- Процесс создания и ротации ключей полностью автоматизирован и интегрирован в CI/CD-цикл, разработчик не взаимодействует с ключами напрямую.
- Внутренние и внешние аудиты безопасности показывают полное отсутствие хардкодинга секретов в исходном коде и конфигурационных файлах.
- Существует чёткий и документированный процесс эскалации и отзыва ключей в случае инцидента, а все команды его знают.
- Бюджет на информационную безопасность включает статьи на поддержку и развитие инструментов управления секретами и доступом.
Вопросы, которые нам задают
### Стоит ли нам теперь полностью отказаться от OpenAI в пользу российских моделей?
Нет, данное изменение не является причиной для отказа от использования fronter-моделей OpenAI. Оно наоборот, повышает безопасность их применения. Решение о переходе на российские аналоги должно базироваться на оценке функциональности, стоимости, производительности и общей стратегии технологического суверенитета, а не на отдельной функции безопасности.
### Какой оптимальный срок жизни ключа выбрать для нашей компании?
Не существует единого правильного значения. Выбор зависит от баланса между безопасностью и операционными издержками. По нашему опыту, для большинства production-сервисов хорошей отправной точкой является 30-90 дней. Для сред разработки и тестирования стоит использовать более короткие сроки — от 7 до 14 дней.
### Решает ли эта проблема все риски, связанные с утечками ключей?
Нет, это лишь один, хотя и важный, слой защиты. Полноценная безопасность требует комплексного подхода, включающего использование секрет-менеджеров, мониторинг аномальной активности, сегрегацию доступа по принципу минимума привилегий и регулярные аудиты. Maximum key lifetime — это mitigation, а не silver bullet.