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

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

В self-hosted-инстансе секреты ломаются не из-за «хакеров», а из-за бытовой небрежности. Ключ лежит в .env рядом с кодом, бэкап уехал в S3 без шифрования, а токен попал в логи после debug-печати. Потом кто-то удивляется, почему из панели улетают лимиты и лиды.

Базовый набор защиты:
— держи секреты вне репозитория и вне образа;
— монтируй их как переменные окружения или файлы с правами 600;
— не пиши ключи в docker-compose, CI-логи и shell history;
— разделяй ключи по сервисам: один токен на одну задачу;
— ротируй секрет после любого инцидента, а не «когда будет время».

Отдельно проверь точки утечки: вебхуки, error-tracking, reverse proxy, дампы БД, экспорт настроек, кэш админки. Если сервис умеет маскировать значения — включай это сразу. Если не умеет, считай, что каждое поле формы однажды окажется в логах.

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

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