OpenAI API key: как выдать и защитить ключ

Раздел

Модели и API

Сложность

средняя

Обновлено

2026-06-01

Короткий ответ

OpenAI API key нужно выдавать как production-секрет: под конкретный project, сервис, среду и владельца. Не вставляйте ключ во frontend, мобильное приложение, README, issue, prompt, скриншот или общий чат. Минимальный рабочий контур: отдельные projects для dev/staging/production, server-side secret, budget и rate limits, usage tracking, data boundary, процедура ротации и человек, который отвечает за инциденты.

Официальная справка OpenAI по безопасности ключей отдельно говорит не делиться ключами, не размещать их в браузере или мобильных приложениях, не коммитить в репозиторий, использовать переменные окружения или key management service, смотреть usage и ротировать ключ при подозрении на утечку: Best Practices for API Key Safety. Для команды этого мало: нужно заранее определить project, роли, лимиты, логи и данные, которые вообще можно отправлять в API.

Этот материал закрывает узкий вопрос “как выдать и защитить OpenAI API key”. Для выбора модели и rollout смотрите OpenAI API для бизнеса, для сравнения провайдеров - YandexGPT, GigaChat, OpenAI, DeepSeek и Qwen, для бюджета - Стоимость LLM API.

Где живет ключ

OpenAI API использует bearer API keys. В API reference отдельно сказано: ключ является секретом, его нельзя показывать в client-side code, а загружать его нужно с сервера из environment variable или key management service: Authentication.

Практически это означает:

• пользовательский браузер не вызывает OpenAI API напрямую;
• backend получает запрос от продукта и сам добавляет Authorization;
• project и organization фиксируются в конфигурации, если у команды несколько контуров;
• логи не пишут значение ключа или полный authorization header;
• ключ можно заменить без изменения исходного кода.

Минимальный server-side контур:

product UI
  -> your backend
  -> data minimization
  -> prompt/model config
  -> OpenAI API with server-side key
  -> validation, fallback and audit log

Если прототип работает из локального ноутбука, это все равно не отменяет правило: реальное значение ключа не попадает в Git, README, .env.example, скриншоты, чат поддержки или настройки стороннего клиента.

Project и владелец

Для эксперимента можно начать с личного project key, но не превращайте его в общий командный пароль. OpenAI production best practices рекомендуют разделять staging и production projects, ограничивать доступ к production project и задавать custom rate/spend limits по project: Production best practices.

Рабочая карточка ключа:

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

Service account или пользовательский ключ

Для production-сервиса лучше не зависеть от личного ключа сотрудника. В OpenAI API reference service account описан как bot user внутри project, не привязанный к конкретному человеку; при создании service account возвращается API key: Project service accounts.

Практическое разделение:

Если используете project API keys и RBAC, проверяйте не только факт “ключ работает”, но и реальные permissions. OpenAI permissions guide рекомендует держать эксперименты, staging и production в разных projects, разделять обязанности и регулярно удалять unused roles and keys: Manage permissions.

Хранение секрета

В репозитории оставляйте только имена переменных:

# .env.example
OPENAI_API_KEY=
OPENAI_PROJECT_ID=
OPENAI_MODEL=

Реальное значение должно жить в одном из управляемых мест:

• secrets хостинга;
• CI/CD secrets;
• vault или key management service;
• runtime environment backend-сервиса;
• локальный .env, который не коммитится и не попадает в build artifact.

Не делайте “быстрый” frontend proxy, где ключ доступен через public env. В Vite, Astro, Next.js и других frontend-сборках любые public-переменные и network calls видит пользователь. Для Woghan-подобного статического сайта OpenAI API key не должен попадать в PUBLIC_* переменные вообще.

Лимиты, usage и billing

Ключ открывает расходы. До первого production-вызова настройте:

• project-level spend limit или notification threshold;
• rate limit strategy;
• отдельные keys по средам;
• usage tracking по key/project;
• алерт при резком росте запросов;
• fallback при quota или rate-limit ошибке;
• stop rule, если eval или cost выходят за границу.

OpenAI rate limits задаются на organization и project level, зависят от модели, а usage limits ограничивают общий месячный расход API: Rate limits. Поэтому “один маленький ключ” не гарантирует маленький счет. Нужны project limits, мониторинг usage и обработка ошибок без бесконечных retries.

Логируйте технические поля:

• service name и environment;
• project ID или понятный alias;
• key alias или service account name, если это доступно;
• model и endpoint;
• request ID;
• HTTP status и тип ошибки;
• latency;
• input/output token usage;
• prompt version;
• fallback route.

Не логируйте значение ключа, authorization header, платежные данные, production .env, полные prompts с персональными данными и клиентские документы без политики хранения.

Data boundary

API key отвечает только за доступ. Он не решает, какие данные можно отправлять. OpenAI data controls page указывает, что API data не используется для обучения моделей без opt-in, а также описывает abuse monitoring logs, application state, project-level retention controls и ограничения для отдельных endpoints: Data controls.

До запуска составьте красную зону:

• passwords, tokens, private keys, recovery codes;
• платежные данные;
• персональные данные без правового основания;
• договоры целиком, если задаче нужен только фрагмент;
• коммерческие условия клиента под NDA;
• production .env и incident logs;
• исходный код клиента, если договор запрещает внешний API;
• документы без владельца и срока хранения.

Если нужен RAG или file upload, отдельно проверьте storage, deletion, retention и права на источники. Не переносите “у нас есть ключ” в “можно отправлять все документы”.

IP allowlist и сетевой контур

OpenAI Help Center описывает IP allowlisting как дополнительный слой защиты, при котором API принимает запросы только от доверенных адресов. Если эта возможность доступна в вашем аккаунте и подходит архитектуре, включайте ее для production backend. Если нет, компенсируйте:

• backend-only вызовами;
• outbound allowlist на своей стороне;
• секретным хранилищем;
• короткими лимитами бюджета;
• отдельными dev/staging/prod projects;
• журналом и алертами по usage.

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

Ротация и утечка

План ротации нужен до инцидента:

1. Создать новый key или service account key в нужном project.
2. Добавить его в secret storage под новой version.
3. Переключить staging и выполнить тестовый запрос.
4. Переключить production.
5. Проверить usage, rate-limit headers и ошибки.
6. Удалить или отозвать старый ключ.
7. Проверить Git, CI logs, issue, screenshots, chat и prompt history, если ротация связана с утечкой.

Если ключ попал в репозиторий или frontend bundle, считайте его скомпрометированным. Удаление строки из последнего commit не возвращает секрету безопасность. Нужно заменить ключ и проверить расходы за период риска.

Чего не делать

• Не покупайте и не используйте чужие “OpenAI API key” или shared gateways без владельца.
• Не путайте ChatGPT subscription и OpenAI API billing.
• Не вставляйте production key в браузер, мобильное приложение, no-code форму или расширение IDE.
• Не давайте подрядчику ключ от production project.
• Не храните ключ в .env.example.
• Не отправляйте key или .env в prompt AI-инструменту.
• Не делайте один ключ для всех сервисов.
• Не копируйте актуальные цены в статью без процедуры обновления.

Если официальный доступ, оплата, регион, договор или data controls не подходят компании, правильный вывод - не обход, а другой контур: обезличенный eval, локальная модель, другой provider или ручной процесс до нормального договора.

Чеклист

• Project соответствует среде: dev, staging или production.
• Для production есть service account или управляемый project key.
• API key хранится server-side.
• Frontend не вызывает OpenAI API напрямую.
• В репозитории есть только имена переменных, без значений.
• Настроены spend/rate limits и usage tracking.
• Логи не содержат key, authorization header и чувствительные prompts.
• Определены data boundary и retention правила.
• При необходимости включен IP allowlist.
• Есть владелец, дата пересмотра и процедура ротации.
• Подрядчики и coding tools используют отдельный dev/staging key.
• При утечке старый ключ отзывается, а расходы и логи проверяются.

FAQ

Можно ли использовать один OpenAI API key для всей команды?

Для бизнеса это плохая практика. OpenAI не поддерживает sharing API keys как командную модель. Разделяйте доступ через members, projects, service accounts, роли и отдельные ключи по средам.

Можно ли хранить OpenAI API key во frontend?

Нет. Браузерный код, network calls и sourcemap видит пользователь. Делайте backend endpoint, который проверяет пользователя, минимизирует данные и вызывает OpenAI API server-side.

Нужен ли service account?

Для production-сервиса обычно да. Личный ключ сотрудника ломается при уходе человека, смешивает ownership и усложняет ротацию. Service account лучше отражает реальный владелец: приложение внутри project.

Что делать, если ключ утек?

Создайте новый ключ, переключите сервис, отзовите старый, проверьте usage и места утечки. Не ограничивайтесь удалением ключа из README или Git history.

Как ограничить расходы?

Разделите projects, задайте spend/rate limits, включите usage tracking, поставьте alert и stop rule. В коде различайте quota/rate-limit ошибки и не делайте бесконечные retries.

Что читать дальше?

Для архитектуры интеграции откройте OpenAI API для бизнеса. Для выбора провайдера смотрите сравнение моделей, а для экономики - стоимость LLM API.