<b>API-ключи утекать не должны: 5 правил для self-hosted инстанса</b>

<b>API-ключи утекать не должны: 5 правил для self-hosted инстанса</b>

Секреты обычно теряют не из-за взлома, а из-за удобства. Ключи лежат в .env, попадают в бэкап, светятся в логах и уезжают в git вместе с чужой привычкой «потом удалю». Под капотом всё устроено проще, чем кажется: любой секрет должен жить вне кода и вне истории деплоя.

— Храни ключи в secret manager или хотя бы в отдельном файле с правами 600, а не в репозитории.
— Не передавай секреты через переменные окружения в shell-истории и CI-логи; лучше монтируй их в контейнер как файл.
— Режь логи: маскирование токенов, запрет debug-дампа и фильтр на request/response payload.
— Для каждого сервиса делай отдельный ключ. Один сервис скомпрометирован — не падает весь стек.
— Ротируй секреты по расписанию и после любого инцидента, а не «когда-нибудь потом».

Отдельная ловушка — доступ к бэкапам и мониторингу. Если туда попали конфиги, дампы БД или трассировки запросов, считай, секрет уже не секрет. Шифруй архивы, ограничивай доступ по ролям и не давай observability читать больше, чем нужно.

Контроль над стеком — это контроль над прибылью. Владей своим софтом, а не арендуй его: секреты должны быть изолированы, минимальны и заменяемы без боли.