Содержание

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

Разберём, почему секреты утекают, где их хранить, как работать с ними в CI/CD и что делать при утечке.

Почему секреты нельзя хранить в коде?

Секреты в коде утекают вместе с кодом: репозиторий копируется на ноутбуки разработчиков, попадает к подрядчикам, в CI и иногда — случайно — в открытый доступ. Даже если удалить файл, ключ остаётся в истории коммитов, а боты непрерывно сканируют публичные репозитории в поисках таких ключей.

Как секреты утекают на практике:

  • файл .env закоммичен в репозиторий;
  • ключ вставлен прямо в код «временно» и забыт;
  • секреты отправлены в общий чат или по почте;
  • ключи видны в логах сборки или в ошибках приложения;
  • ключ встроен во фронтенд или мобильное приложение, откуда его легко достать.

Про другие типичные уязвимости — статья OWASP Top 10 простыми словами.

Где хранить секреты?

Секреты хранят вне кода — в переменных окружения сервера, в защищённых настройках CI/CD или в специализированном менеджере секретов. Выбор зависит от размера команды и количества сервисов.

Способ Подходит для Плюсы Минусы
Файл .env на сервере Небольшой проект, один сервер Просто Ручное управление, нет журнала доступа
Секреты CI/CD Деплой и сборка Встроено в платформу Привязка к одной платформе
Облачный менеджер секретов Проекты в облаке Права, аудит, ротация Зависимость от провайдера
Self-hosted хранилище (Vault и аналоги) Много сервисов, свои серверы Гибкость, динамические секреты Нужно поддерживать
Менеджер паролей команды Доступы людей к сервисам Удобно, есть разграничение Не для машинных секретов

Старинный ключ на светлом фоне Фото: Unsplash

Как работать с секретами в разработке и CI/CD?

В разработке у каждого программиста свои тестовые ключи, а в репозитории лежит только шаблон без значений. В CI/CD секреты подставляются платформой во время сборки и деплоя и никогда не выводятся в логи.

# .env.example — в репозитории, без значений
DB_PASSWORD=
PAYMENT_API_KEY=
S3_SECRET=

# .gitignore
.env

Правила:

  1. Разные ключи для окружений. Тестовые ключи платёжной системы — в разработке, боевые — только на продакшене.
  2. Минимальные права. Ключ для загрузки файлов не должен давать доступ ко всему облачному аккаунту.
  3. Проверка перед коммитом. Сканер секретов в pre-commit и CI ловит ключи до того, как они попадут в историю.
  4. Маскирование в логах. Платформа CI и приложение не выводят значения секретов.
  5. Ничего секретного на клиенте. Всё, что попадает во фронтенд или мобильное приложение, считается публичным.

Как настроить пайплайн, мы разбирали в статье CI/CD на GitHub Actions.

Как выдавать доступы команде?

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

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

Подробнее о передаче проекта между командами — в статье как сменить подрядчика.

Что делать, если секрет утёк?

Если секрет утёк, его нужно сразу отозвать и заменить, а не удалять из репозитория и надеяться, что никто не заметил. Затем проверить журналы использования ключа и выяснить, как он утёк, чтобы это не повторилось.

План действий:

  1. Отозвать скомпрометированный ключ и выпустить новый.
  2. Обновить его во всех окружениях и перезапустить сервисы.
  3. Проверить журналы провайдера: были ли подозрительные запросы с этим ключом.
  4. Если затронуты персональные данные — оценить необходимость уведомления по закону.
  5. Разобрать причину и закрыть её: сканер, права, процесс.

Коротко

  • Секретам не место в коде и репозитории, даже приватном.
  • Храните их в переменных окружения, секретах CI/CD или менеджере секретов.
  • У каждого окружения свои ключи, у каждого сервиса — минимальные права.
  • Доступы людей — персональные, с двухфакторной аутентификацией и регулярной проверкой.
  • Утёкший ключ сразу отзывают и заменяют, затем разбирают причину.

Частые вопросы

  • Можно ли хранить секреты в приватном репозитории?

    Нет. Приватный репозиторий видят все разработчики и подрядчики, его копии остаются на ноутбуках и в CI, а история коммитов хранит секрет даже после удаления файла.

  • Как часто менять ключи?

    Обязательно — при уходе сотрудника или подрядчика с доступом и при подозрении на утечку. Плановую ротацию критичных ключей удобно делать раз в несколько месяцев, если процесс автоматизирован.

  • Как передать доступы новому подрядчику?

    Через менеджер паролей или секретов с отдельными правами, а не в мессенджере. Подрядчику выдают собственные учётные записи с нужным минимумом прав, чтобы после окончания работ их можно было просто отключить.