Управление секретами: не хардкодить и не коммитить

Самый частый «взлом» — это найденный в коде ключ, который никто не собирался прятать.

Секрет — любая строка, дающая доступ: пароль БД, API-ключ, приватный ключ, токен. Управление секретами — то, как их хранят, выдают и меняют, не раскрывая.

Почему хардкод опасен

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

Опасность не ограничивается публичным GitHub. Представьте внутренний приватный репозиторий: к нему имеют доступ десятки сотрудников, подрядчиков и сервисных аккаунтов CI. Любой из них при увольнении уносит полный клон со всей историей, а значит и с тем боевым ключом платёжного шлюза, который кто-то когда-то «временно» закоммитил. Приватность репозитория создаёт ложное чувство защищённости: круг доступа гораздо шире, чем кажется, и контролировать его задним числом невозможно.

Ещё один сценарий — образы контейнеров. Если секрет попал в исходники на этапе сборки, он застывает в слое Docker-образа, который потом раздаётся в реестр и подтягивается на множество узлов. Даже если в финальном слое файл удалён, промежуточный слой с секретом остаётся в истории образа, и его легко извлечь командой осмотра слоёв. Так секрет «протекает» туда, где его никто не ожидает увидеть.

// Уязвимо: ключ прямо в коде
const apiKey = "sk_live_8a72bf...";          // утечёт вместе с репозиторием
const db = connect("postgres://user:Pa$$w0rd@host/db");

// Безопасно: значение приходит из окружения, в коде — только имя переменной
const apiKey = env("PAYMENT_API_KEY");
const db = connect(env("DATABASE_URL"));

Куда выносить: переменные окружения и хранилища

Базовый приём — переменные окружения: код читает env("..."), а сами значения задаются в среде выполнения и в .env-файле, который не коммитится. В репозиторий кладут лишь шаблон без значений.

# .gitignore
.env

# .env.example (в репозитории, БЕЗ реальных значений)
PAYMENT_API_KEY=
DATABASE_URL=

Для зрелых систем переменных мало: используют секрет-менеджеры (Vault, облачные Secret Manager, KMS). Они хранят секреты зашифрованными, выдают по запросу с аудитом и контролем доступа, поддерживают версии и автоматическую ротацию. Принципиальное отличие от переменных окружения — централизация и наблюдаемость: вы в любой момент видите, какой сервис когда запрашивал какой секрет, можете отозвать доступ одной командой и не разносите копии секрета по десяткам конфигов. Переменная окружения хороша как способ доставки секрета в процесс, но сама по себе она не решает задачу безопасного хранения и аудита — для этого и нужен менеджер.

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

Если секрет уже утёк в git

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

Секрет попал в git:
 1. ОТОЗВАТЬ старый секрет / выпустить новый  (главное!)
 2. обновить секрет в окружении/хранилище
 3. (опционально) переписать историю репозитория

Ротация и минимум доступа

Секреты — расходный материал: их периодически меняют (ротация), чтобы старая утечка теряла ценность. Доступ к секрету выдают по least privilege: каждому сервису — только его секреты, и желательно с ограниченными правами (например, ключ только на чтение очереди).

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

Как работает под капотом: short-lived credentials

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

Под капотом это обычно работает так: у сервиса есть устойчивая «личность» (machine identity), подтверждаемая платформой — например, ролью облака или подписанным токеном среды исполнения. Эту личность сервис предъявляет хранилищу, а взамен получает временный секрет под конкретную задачу. Заметьте: сам долгоживущий корень доверия при этом никогда не передаётся по сети и не лежит в конфиге приложения — приложение лишь доказывает, «кто оно», а не «что оно знает». Это смещает модель от «секрет как пароль, который надо прятать» к «секрет как краткий пропуск, который не страшно потерять».

Долгоживущий ключ                Короткоживущие креды
-----------------                ---------------------
лежит у каждого сервиса      =>   мастер-секрет только в хранилище
утёк = беда навсегда         =>   утёк = беда на пару часов
ротация = ручной аврал       =>   ротация = автоматически по TTL

Частые ошибки

Ключ в коде или в git-истории. Считайте его раскрытым; ротируйте.
Секреты в логах и в сообщениях об ошибках. Маскируйте при выводе.
Один ключ на всё и навсегда. Нарушает least privilege и мешает ротации.
Секреты в URL/query. URL попадает в логи, историю, Referer.
Секрет в файле сборки или в Dockerfile через ARG. Оседает в слоях образа; передавайте секреты сборки специальными механизмами, а не аргументами.
Один .env на все окружения. Боевые ключи не должны лежать рядом с тестовыми; разделяйте dev/stage/prod и доступ к ним.

Итоги

Не хардкодьте и не коммитьте секреты; код читает имя переменной, не значение.
Базово — переменные окружения и неотслеживаемый .env; зрело — секрет-менеджер.
Утёкший секрет ротируйте немедленно; чистка истории вторична.
Ограничивайте доступ и срок жизни секретов.