Вопрос с собеседования · System design

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

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

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

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

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

Подробно

Почему удаление не помогает. 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

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

Разбор собеседования