# Где хранить ключи и пароли своего продукта

Ключ в коде уезжает вместе с кодом и тратит твои деньги молча. Разбираю, что такое файл настроек, три частые утечки и что делать, если ключ уже утёк.

URL: https://posts.danashkin.ru/guides/gde-hranit-klyuchi-svoego-produkta
Обновлено: 2026-09-11

---

## Коротко

**Главное**

- Ключ доступа - это пароль, по которому чужой сервис узнаёт твою программу и списывает деньги с твоего счёта. Утёкший ключ тратит твои деньги молча.
- Ключи не пишутся внутри кода. Они живут в отдельном файле настроек, который остаётся на твоём компьютере и на сервере, но никогда не уезжает в хранилище кода.
- Три частых утечки: ключ попал в код, ключ мелькнул в тексте ошибки, ключ записался в служебный журнал программы.
- Ключ утёк - его не прячут, а отзывают и выпускают новый. Это занимает минуту и всегда дешевле, чем надеяться, что никто не заметил.
- Агенту эти правила задают один раз в файле-памяти проекта, иначе он будет каждый раз решать заново.

## Что вообще такое переменные окружения?

**Главное**

Это настройки, которые лежат рядом с программой, а не внутри неё. Программа при запуске читает их из отдельного файла: адрес базы, ключ платёжного сервиса, пароль почты. Меняются настройки - код не трогаем.

Слово, которое [агент](/concepts/ai-agent) произносит на второй неделе работы, а объяснить забывает. На обучении у меня был показательный случай: участница ещё в первом модуле настроила запрет на чтение таких файлов, а через два месяца спросила, что это вообще за файлы. Настройку сделала, смысл не осел, и это нормально: ей никто его не объяснил в тот момент, когда он понадобился.

Разберём простым языком. У программы есть код - то, что она делает. И есть настройки - с чем именно она это делает: на какой базе, каким ключом, от чьего имени.

Настройки лежат отдельно по двум причинам:

- **Они разные в разных местах.** На твоём компьютере база учебная, на сервере боевая. Код при этом один и тот же.
- **Среди них есть секреты.** Ключи и пароли нельзя показывать никому, а код ты вполне можешь кому-то показать.

Выглядит такой файл как простой список строк вида «имя = значение». Программа при старте его читает и дальше пользуется значениями. Никакой магии.

## Почему ключ нельзя писать прямо в коде?

**Главное**

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

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

Что происходит, когда ключ вписан в код:

1. **Код уезжает в хранилище.** Даже приватное хранилище - это уже не только твой компьютер. Права доступа меняются, люди приходят и уходят.
2. **История хранит всё.** Ты потом заметишь ключ и уберёшь. Но старая версия останется в истории изменений, и достать её оттуда несложно.
3. **Кусок кода попадает в переписку.** Скинул фрагмент коллеге, вставил в чат с агентом, приложил к вопросу на форуме - ключ поехал вместе с ним.

И главное: платёжный ключ или ключ доступа к нейросети - это доступ к твоим деньгам. Утёкший ключ не ломает программу, он тихо тратит твой баланс. Узнаёшь ты об этом из счёта.

**Отдельно про боевую базу**

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

## Три места, где ключ утекает незаметно

**Главное**

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

**Первое: код с ключом уехал в хранилище.** Классика. Лечится файлом-списком исключений: в нём перечисляешь, что в хранилище не отправлять. Файл с настройками - первая строка этого списка. Площадки хранения кода умеют сами искать похожие на ключи строки и предупреждать, но полагаться только на это не стоит.

**Второе: ключ мелькнул в тексте ошибки.** Ты копируешь агенту сообщение об ошибке, а в нём - строка подключения к базе целиком, вместе с паролем. Правило простое: перед отправкой пробеги текст глазами и замени всё похожее на ключ словом-заглушкой. Подробнее про то, как вообще правильно приносить агенту ошибку, писал в отдельном материале - [как принести агенту ошибку](/guides/kak-prinesti-agentu-oshibku).

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

У меня на одном проекте вход был устроен по одноразовой ссылке на почту. Удобно и без паролей. А ссылка по недосмотру писалась ещё и в служебный журнал - то есть любой, у кого был доступ к журналу, мог войти в чужой аккаунт. Поймали до публичного запуска. Это ровно тот класс ошибок, который делается молча и обнаруживается только глазами. Про остальные проверки перед выкладыванием продукта наружу писал в материале про [прототип и деплой](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

## Как это устроено на практике?

**Главное**

Файл с настройками лежит рядом с проектом и в хранилище не уезжает. Рядом с ним - файл-образец с теми же именами, но пустыми значениями: по нему видно, что нужно заполнить, и он безопасен для публикации.

Порядок, который стоит завести на любом проекте:

1. **Заведи файл настроек**

   Один файл в корне проекта, куда складываются все ключи и пароли. Агент сделает это сам, если попросить: «вынеси все ключи в файл настроек».

2. **Добавь его в список исключений**

   Чтобы он не уехал в хранилище. Это отдельный файл-список, в нём перечисляется, что игнорировать.

3. **Сделай файл-образец**

   Копия с теми же именами и пустыми значениями. Его как раз можно и нужно хранить в проекте: по нему понятно, какие настройки нужны, а секретов в нём нет.

4. **Пропиши настройки на сервере отдельно**

   На хостинге для этого есть свой раздел. Файл с секретами туда не копируется, значения вписываются в панели управления.

5. **Проверь, что в хранилище ключей нет**

   Открой своё хранилище кода и поищи по нему характерные куски: «ключ», «пароль», «token». Пять минут, которые лучше потратить сейчас.

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

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

**Главное**

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

Порядок действий по убыванию срочности:

| Шаг | Что делаешь | Зачем |
|---|---|---|
| 1 | Отзываешь ключ в кабинете сервиса | старая копия перестаёт работать сразу |
| 2 | Выпускаешь новый и вписываешь в настройки | продукт продолжает работать |
| 3 | Проверяешь расход по счёту | понять, успели ли им воспользоваться |
| 4 | Убираешь ключ из кода и истории | чтобы не утёк повторно |
| 5 | Ставишь ограничения на новый ключ | лимит трат, разрешённые адреса, права только на нужное |

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

Про то, как вообще выдавать агенту права по принципу «нового сотрудника», писал в материале про [доступ агента к почте и серверу](/guides/dostup-agenta-k-pochte-i-serveru).

## Правила, которые задаются агенту один раз

**Главное**

Всё перечисленное стоит записать в файл-память проекта, а не повторять в каждой задаче. Тогда агент соблюдает их по умолчанию, а не решает заново при каждом запуске.

Набор правил, который я держу в проектах:

- **Ключи и пароли - только в файле настроек.** Никогда в коде, никогда в тексте задачи.
- **Файл настроек не уезжает в хранилище.** И проверяется отдельно перед каждой отправкой.
- **В журнал не пишем ничего, похожего на секрет.** Ни ссылок для входа, ни строк подключения, ни токенов.
- **Доступ к боевым данным - на чтение.** Право менять выдаётся отдельно и осознанно.
- **При выпуске ключа сразу ставим ограничения.** Лимит и минимально нужные права.

Эти пять строк живут в файле-памяти проекта - том самом, который агент читает при старте. Что вообще стоит писать в такой файл, разбирал в материале про [CLAUDE.md](/guides/chto-pisat-v-claude-md). Разница ощутимая: правило в файле работает всегда, правило в голове - до первой забывчивости.

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

**Главное**

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

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

**У меня приватное хранилище. Можно держать ключи там?**

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

**Агенту показывать ключ можно?**

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

**Мы работаем вдвоём. Как передать настройки коллеге?**

Через менеджер паролей или защищённый канал, а не сообщением в мессенджере. У каждого при этом свои ключи, где сервис это позволяет: так видно, чей ключ утёк, и отзывать можно точечно.

**Нужен ли отдельный сервис для хранения секретов?**

Для маленького проекта нет: файла настроек и панели хостинга достаточно. Такие сервисы становятся оправданы, когда людей и серверов больше, чем помещается в голове.

## Главный вывод

**Главное**

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

Главное, что стоит запомнить: секрет утекает не из-за взлома, а по бытовой невнимательности. Вписал в код, скинул в чат, оставил в журнале - три самых частых способа.

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

Открой свой текущий проект и поищи в нём слово «ключ». Сколько мест ты найдёшь, где секрет лежит прямо в коде?

### Источники

- [Environment variable - что такое переменные окружения, Википедия](https://en.wikipedia.org/wiki/Environment_variable)
- [API key - назначение и риски ключей доступа, Википедия](https://en.wikipedia.org/wiki/Application_programming_interface_key)
- [Игнорирование файлов в Git - официальная документация GitHub](https://docs.github.com/en/get-started/git-basics/ignoring-files)
- [Поиск утёкших секретов в репозиториях - документация GitHub](https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning)
- [Principle of least privilege - принцип минимально нужных прав, Википедия](https://en.wikipedia.org/wiki/Principle_of_least_privilege)