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

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

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

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

На self-hosted инстансе нормальная схема выглядит так: секреты лежат в менеджере вроде Vault или хотя бы в зашифрованном хранилище, приложение получает их на старте, а в контейнеры и логи они не попадают. Если секрет нужен для интеграции с рекламным API, ограничь его по IP, scope и типу операций. Контроль над стеком — это контроль над прибылью.

Отдельно проверь бэкапы, дампы БД и мониторинг: там любят всплывать токены, webhook URL и SMTP-пароли. Маскируй значения в логах, отключай вывод переменных окружения в debug и не давай админам привычку «временно положить секрет в заметку».

Дисциплина тут скучная, зато надежная: секрет должен жить в одном месте, иметь узкие права и короткий срок жизни. Владей своим софтом, а не арендуй его.