API-ключи в self-hosted: 5 мест, где секреты текут в прод без шума

API-ключи в self-hosted: 5 мест, где секреты текут в прод без шума

Чаще всего утечка начинается не с взлома, а с удобства: ключ кладут в .env рядом с кодом, коммитят в репозиторий или размазывают по docker-compose. Дальше этот файл уезжает в бэкапы, логи и CI-пайплайны. Владей своим софтом, а не арендуй его — и не храни секреты как попало.

Рабочая схема простая:
— секреты только через переменные окружения на рантайме;
— для продакшена — отдельное хранилище секретов или хотя бы зашифрованный файл вне git;
— ротация ключей при каждом подозрении на утечку, а не «когда будет время»;
— права на ключи минимальные: один сервис, один токен, один scope.

Отдельно проверь Docker и shell-скрипты. Команда docker inspect, история bash, echo $TOKEN в логах и crash-report’ы часто раскрывают больше, чем сам код. Если секрет нужен внутри контейнера, не пеки его в образ и не передавай через аргументы запуска: они светятся в ps и в оркестраторе.

Еще один типовой провал — общий ключ на все сервисы. Упал один воркер, утекли доступы ко всему стеку. Разделяй токены по функциям: API для платежей, API для аналитики, API для уведомлений. Тогда инцидент не превращается в тотальную пересборку инфраструктуры.

Контроль над стеком — это контроль над прибылью. Если секрет можно увидеть в git, логах или переменных окружения без защиты, это не self-hosted, а самообслуживаемая утечка.