Получить доступ

Разработчик случайно закоммитил ключ доступа к платёжному провайдеру и через час удалил его следующим коммитом. Что нужно сделать?

MiddleБезопасность приложения
Ещё спрашивают так:
  • Что делать, если секрет попал в git?
  • Где хранить секреты приложения?
Коротко

Секрет в истории git — утёк. Единственное надёжное действие — отозвать и перевыпустить (ротация), затем проверить журналы использования ключа.

  • Удаляющий коммит не убирает секрет из истории; клоны, форки, кэши и CI уже могли его получить
  • Переписывание истории — уборка, но не замена ротации
  • Профилактика: секреты в менеджере (Vault, облачный KMS), сканер секретов в pre-commit и CI

А ещё Публичные репозитории сканируют боты — ключи облаков используют за минуты

Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.

Подробно

Почему удаление не помогает. Git хранит все версии: объект с ключом доступен по старому коммиту. Репозиторий уже клонирован коллегами и CI, мог попасть в зеркала, кэш хостинга, в логи сборки. В публичных репозиториях ключи облачных провайдеров находят автоматические сканеры за минуты.

Порядок действий:

  1. отозвать ключ у провайдера и выпустить новый;
  2. обновить секрет во всех окружениях;
  3. проверить журнал использования старого ключа: были ли операции не от нас;
  4. по желанию — вычистить историю (git filter-repo) и попросить хостинг очистить кэш; это не отменяет первых шагов;
  5. разобрать причину и закрыть её.

Профилактика:

  • секреты не хранятся в репозитории — только в менеджере секретов (Vault, Yandex Lockbox, AWS Secrets Manager) с контролем доступа, аудитом и ротацией;
  • в приложение — через переменные окружения или примонтированные файлы, в Kubernetes — внешние секреты, а не значения в манифестах;
  • сканеры секретов: pre-commit (gitleaks), проверка в CI и на хостинге (push protection);
  • короткоживущие учётные данные (OIDC для CI, временные токены) вместо вечных ключей.

Что хотят услышать

  • Секрет считается скомпрометированным, ротация обязательна.
  • Почему удаление коммита не помогает.
  • Порядок реагирования, включая проверку использования.
  • Профилактика: менеджер секретов, сканеры.

Частые ошибки

  • Ограничиться переписыванием истории.
  • Хранить секреты в зашифрованном файле в репозитории с ключом рядом.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✓Считать ключ скомпрометированным и немедленно ротировать: он остался в истории git
  • ✗Ничего: удаляющий коммит убрал ключ из репозитория
  • ✗Достаточно сделать репозиторий приватным
  • ✗Достаточно переписать историю через force-push, ротация не нужна

Что спросят дальше

  • Как организовать регулярную ротацию секретов?
  • Чем это относится к категории Security Misconfiguration?

Разбор темы

Связанные вопросы

Закрытая бета

Подсказки на собеседовании — в реальном времени

sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.

  • Промокод на 2 часа — сверх пробных 30 минут
  • Программа для Windows — скачать сразу, войти — через Яндекс ID или VK ID
  • Прямая связь с разработчиком: что улучшить — сделаем