Коротко
Храните API-ключ в переменной окружения или в защищённом хранилище, а не в коде. Так его не увидят посторонние и он не попадёт в репозиторий.
Ключ это пароль к вашему аккаунту и счёту. Если он утечёт, им смогут пользоваться чужие люди и тратить ваши деньги. Здесь мы покажем, как хранить ключ правильно, разберём короткий пример на Python и свяжем это с темой защиты чувствительных данных.
Почему ключ нельзя класть в код
Если ключ написан прямо в файле, он легко попадёт в репозиторий или в чужие руки. Один случайный коммит, и секрет уже в открытом доступе.
Удалить его из истории git бывает сложно, поэтому проще не допускать утечки.
Держите секрет отдельно от кода
Когда ключ лежит отдельно, вы можете делиться программой, не делясь секретом. Чтобы понимать, где именно подставляется ключ, полезно знать, что такое API.
Совет. Относитесь к ключу как к паролю от банка. Его не показывают, не пересылают и не оставляют в общем доступе.
Переменные окружения
Переменная окружения это значение, которое живёт в системе, а не в файле кода. Программа читает его при запуске. Безопасный пример как обычный текст выглядит так:
import os
apikey = os.environ.get("OPENAIAPI_KEY")
В коде остаётся только имя переменной, а сам ключ хранится в системе. Это безопаснее, потому что секрет не виден в исходниках и не попадает в репозиторий.
- Задайте переменную, например OPENAIAPIKEY.
- В коде читайте её через os.environ.get.
- Никогда не печатайте ключ в логах.
Файл .env и gitignore
Для локальной работы удобно держать секреты в файле .env. Главное, добавьте этот файл в .gitignore, чтобы он не попал в репозиторий. Тогда ключ останется только на вашей машине.
Перед стартом полезно понять основы запроса в материале про устройство запроса к API, чтобы знать, где именно подставляется ключ. Это поможет не запутаться при первой настройке.
Зачем нужен gitignore
Файл .gitignore говорит git, какие файлы не сохранять в репозиторий. Добавьте туда .env сразу, и секрет не уедет вместе с кодом.
Шаги безопасной настройки
Чтобы не забыть важное, идите по короткому списку. Он подходит и для одного скрипта, и для небольшого проекта в команде.
Если работаете не одни, лучше у каждого свой ключ. Так при утечке можно отозвать только один ключ, не трогая остальных.
- Создайте ключ в личном кабинете на платформе.
- Сохраните его в переменную окружения.
- Добавьте .env в .gitignore сразу.
- Проверьте, что ключ не виден в логах и в ответах.
- Заведите отдельный ключ для каждого человека или сервиса.
Что делать при утечке
Если ключ мог утечь, сразу удалите его и создайте новый в личном кабинете. Старый ключ перестанет работать, и им больше нельзя будет пользоваться.
Проверьте расход после утечки
Загляните в расход, чтобы заметить лишние запросы. Если видите чужую активность, обновите ключ ещё раз и проверьте, где он мог засветиться. Вернуться к обзору темы можно через раздел про API.
Типичные ошибки
Самая частая ошибка это ключ прямо в коде или в публичном репозитории. Вторая по частоте это пересылка ключа в чат или письмо, откуда он легко расходится дальше.
Бывает и так, что ключ печатают в логах при отладке и забывают убрать. Чтобы избежать этого, относитесь к ключу как к паролю и нигде его не показывайте. Те же принципы важны и в команде, об этом есть материал про безопасную работу с AI на работе.
- Не коммитьте ключ в репозиторий.
- Не пересылайте ключ в чат или письмо.
- Не печатайте ключ в логах при отладке.
- Не используйте один ключ годами без замены.
- Не показывайте ключ на скриншотах.
Где хранить ключ
| Способ | Безопасно? | Когда подходит |
|---|---|---|
| Прямо в коде | Нет | Никогда |
| Переменная окружения | Да | Большинство случаев |
| Файл .env вне репозитория | Да | Локальная разработка |
| Хранилище секретов | Да | Командные проекты |
Риск разных способов хранения (простая иллюстрация)
Как безопасно подключить ключ
Создаёте ключ
В личном кабинете на платформе.
Кладёте в окружение
Задаёте переменную в системе.
Читаете из кода
Берёте значение по имени переменной.
Закрываете доступ
Добавляете .env в gitignore.
Чеклист
- Не писать ключ прямо в коде.
- Хранить ключ в переменной окружения.
- Добавить .env в gitignore.
- Не печатать ключ в логах.
- Сменить ключ при подозрении на утечку.
- Завести отдельный ключ для каждого сервиса.
- Регулярно проверять расход по аккаунту.
Частые ошибки
- Коммитить ключ в репозиторий.
- Отправлять ключ в чат или письмо.
- Хранить один ключ годами без замены.
- Показывать ключ на скриншотах.
- Печатать ключ в логах при отладке.
Частые вопросы
Это значение, которое хранится в системе, а не в коде. Программа читает его при запуске, поэтому секрет не виден в исходниках.
Да, для локальной работы это удобно. Но обязательно добавьте .env в gitignore, чтобы файл не попал в репозиторий.
Сразу удалите старый ключ и создайте новый в личном кабинете. Затем проверьте расход на лишние запросы.
Нет смысла его возвращать. Безопаснее создать новый ключ, а старый отозвать, чтобы им больше нельзя было пользоваться.
Это хорошая практика. При утечке вы отзываете только один ключ и не ломаете работу остальных сервисов.
Следите за расходом в личном кабинете. Резкий рост запросов без вашей активности это повод сменить ключ.
Источники
Мы опираемся на официальную документацию. Цены и состав моделей могут меняться, проверяйте важные факты по первоисточникам.