API-ключи в self-hosted: где их прячут, а потом удивляются утечке

В self-hosted инстансах секреты чаще всего текут не «из-за хакеров», а из-за привычек: кладут ключи в .env рядом с кодом, суют в compose-файлы, оставляют в логах и бэкапах. Один компрометированный сервер — и у тебя открыта не только интеграция, но и весь контур.

Рабочая схема проста:
— хранить секреты вне репозитория: переменные окружения, менеджер секретов, файловые ACL
— выдавать каждому сервису свой ключ, а не общий на всё
— ограничивать права ключа по API: только нужные методы, только нужные IP, только нужный срок жизни
— ротировать ключи по расписанию и сразу после инцидента
— не печатать секреты в stdout, алерты и trace-логи

Отдельно проверь типовые дыры: volume с /etc/containers или /var/lib/docker, доступ к shell у лишних пользователей, CI/CD с правами «на всё», резервные копии без шифрования. Если секрет лежит там, куда может добраться приложение или оператор, это уже не секрет, а отложенная проблема.

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