EMZETT.
Войти

Emzett Wiki

Управление секретами: безопасное хранение паролей и ключей в проектах

Properties1
tagsglossar, devops, sicherheit

время чтения ~2 мин.

Управление секретами: безопасное хранение паролей и ключей в проектах

Коротко: API-ключи, пароли и сертификаты не должны находиться в репозитории Git; храните их в переменных окружения или менеджерах секретов и регулярно ротируйте.

Подробнее: Секрет (secret) — любая информация, дающая доступ: пароль базы данных, API-ключ, токен, закрытый ключ. Почти ежедневно ключи собираются из публичных репозиториев (боты сканируют GitHub за секунды) и используются для злоупотреблений (счета за облако, вывод данных).

Подробности

Что не работает

  • Секреты в исходном коде или в файлах конфигурации в репозитории.
  • В образах Docker или во фронтенд-коде (видит каждый пользователь).
  • В чате, электронной почте, тикетах, скриншотах.
  • Одни и те же ключи для разработки и production, для всех сервисов.
  • Бессрочно действующие, слишком мощные ключи.

Как сделать лучше

  1. Переменные окружения (файл .env локально, в .gitignore), секреты CI (GitHub Actions secrets), настройки хостинга (Vercel, Netlify).
  2. Менеджеры секретов: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password/Bitwarden Secrets, Doppler, SOPS (зашифрованные файлы в репозитории).
  3. Наименьшие привилегии: ключи с минимальными правами, раздельные для окружений и сервисов.
  4. Ротация: регулярное обновление, короткоживущие токены, немедленный отзыв при подозрении.
  5. Журналируйте и отслеживайте доступ.
  6. Два уровня доступа (не один ключ на всё).

Защита от утечек

  • Хуки pre-commit и сканеры: gitleaks, trufflehog, secret scanning GitHub и защита push.
  • При случайном коммите: немедленно отозвать/обновить ключ (удаления из истории недостаточно, данные уже скопированы); последующая очистка истории (git filter-repo) — только как дополнительная мера.
  • Проверяйте журналы, чтобы в них не выводились секреты; не делайте сообщения об ошибках слишком подробными.
  • Предоставляйте файлы-примеры (.env.example) без реальных значений.

Практика для небольших проектов

Используйте .env локально и настройки платформы хостинга для production. Создавайте отдельные ключи на каждый сервис, записывайте их в менеджер паролей (не в файлы), задавайте оповещения о бюджете в облачных сервисах и по возможности ограничения по IP или привязку к домену для API-ключей. Публичный ключ браузера (например, для карт) должен быть ограничен вашим доменом.

См. также: Файлы env, Наименьшие привилегии, Менеджер паролей

Обратные ссылки