<b>API-ключи в self-hosted: 5 мест, где секреты чаще всего утекают</b>

<b>API-ключи в self-hosted: 5 мест, где секреты чаще всего утекают</b>

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

— .env в репозитории, бэкапе или CI-логе. Секрет должен жить только в хранилище секретов или переменных окружения на хосте.
— Конфиги в Docker Compose и systemd с правами “для всех”. Проверь owner, chmod, и что файлы не попадают в образ.
— Логи приложений и reverse proxy. Маскируй Authorization, токены, cookies, webhook-подписи.
— Образы и снапшоты. Если ключ был в контейнере при сборке, считай его уже опубликованным.
— Долгоживущие ключи без ротации. Для внешних API лучше отдельный ключ на сервис, а не один “на всё”.

Минимальный набор гигиены: короткоживущие токены, отдельные ключи для прод/тест, ограничение прав по scope, и запрет на секреты в переменных, которые печатаются в shell history или CI output.

Если секрет всё же засветился — не “подождать и посмотреть”, а сразу отозвать, пересоздать и проверить логи на следы использования. Владей своим софтом, а не арендуй его.

—
Хочешь больше keitaro vs bemob vs voluum? @tracker_stack_ubt