API-ключ попал в Git: почему удаления строки недостаточно
Разработчик замечает пароль базы в последнем коммите, удаляет строку, делает новый commit и успокаивается. Но секрет остается в предыдущем объекте Git, мог попасть в чужой клон, журнал сборки, уведомление бота и кеш площадки. Исправление текста не прекращает полномочия уже опубликованного ключа.
Первая цель инцидента - лишить секрет силы. Вторая - понять, использовал ли его кто-то. Переписывание истории важно, но идет после отзыва, потому что занимает время и не умеет забрать уже скопированное значение.
Остановите распространение, не стирая доказательства
Ограничьте новые публикации ветки и доступ к артефактам CI, если это возможно без остановки критичного сервиса. Зафиксируйте репозиторий, путь, commit, время обнаружения и тип секрета. Не вставляйте полное значение в чат, задачу или снимок экрана.
Сохраните необходимые журналы в защищенное место: выдача токена, вызовы API, входы, изменения прав и сборки. Срок хранения может быть коротким. Массовое удаление логов ради сокрытия ключа уничтожает основу расследования.
Определите владельца секрета и систему, которая может его отозвать. Если это сторонний сервис, используйте официальный кабинет или аварийный контакт. Не ждите ответа автора коммита, когда ключ позволяет изменить рабочие данные.
Отзыв важнее удаления
Отключите ключ, пароль, токен или сертификат. Если система не поддерживает немедленный отзыв, максимально сократите права, ограничьте сеть или заблокируйте учетную запись по согласованной процедуре. Затем создайте новый секрет с минимально необходимыми полномочиями.
Не меняйте только отображаемое имя ключа. Убедитесь, что прежнее значение перестало работать. Проверьте безопасным тестом ожидаемую ошибку старого токена и успешную работу нового.
Если один пароль использовался в нескольких системах, инцидент шире репозитория. Меняйте все совпадающие учетные данные и прекращайте практику повторного использования.
Ротация должна учитывать зависимые сервисы
Составьте список потребителей: рабочее приложение, тестовая среда, задания cron, CI, мониторинг и локальные инструменты. Новый ключ сначала помещают в разрешенное хранилище секретов, затем обновляют потребителей и только после проверки удаляют временный переходный доступ.
OWASP рекомендует централизовать выдачу, аудит и ротацию. Секреты не следует встраивать в образ контейнера через Docker ENV или ARG: они остаются в определении и слоях. Предпочтительнее передавать значение во время развертывания из хранилища или через защищенный смонтированный файл.
Обычная переменная окружения удобна, но может попасть в дамп, журнал или список процессов. Выбор механизма зависит от платформы; главное, чтобы значение не жило в исходном коде и не копировалось в каждый конфигурационный файл.
Проверка возможного использования
Ищите обращения от необычных адресов, регионов, user-agent, времени и операций. Сравните с нормальным профилем конкретного ключа. Один иностранный IP не доказывает злоупотребление: запрос мог идти через облачный runner. Необычная операция из привычной сети тоже может быть атакой.
Проверьте, какие права имел секрет в момент публикации. Токен только для чтения публичных данных несет другой риск, чем ключ администратора платежей. Зафиксируйте затронутые ресурсы и период от первого доступного коммита до подтвержденного отзыва.
Если есть признаки доступа к персональным данным или деньгам, подключите ответственных за безопасность, юриста и владельца бизнеса по плану инцидентов. Не обещайте отсутствие ущерба до анализа журналов.
Теперь очищайте историю
Удалите секрет из текущего дерева и истории с помощью рекомендованного для вашей площадки процесса. Переписывание меняет идентификаторы коммитов, требует принудительной публикации и затрагивает открытые запросы на слияние, форки и локальные клоны.
До операции создайте защищенную резервную копию репозитория и список веток и тегов. Согласуйте окно с командой. После переписывания участники должны получить инструкцию по новому клону или безопасной синхронизации, иначе старые объекты могут вернуться.
Очистите артефакты, кеши, логи CI, страницы документации и прикрепленные файлы, где значение повторилось. Обратитесь к поддержке хостинга, если объект остается доступен через кеш или fork. Но даже идеальная очистка не отменяет отзыв: копию нельзя гарантированно забрать с чужого компьютера.
GitHub блокирует часть утечек до публикации
Push protection проверяет изменения на поддерживаемые типы секретов и может остановить push. GitHub сообщает, что пользовательская защита для публичных репозиториев включена по умолчанию. В защищенных организациях обход можно контролировать и отправлять на согласование.
Если проверка сработала, лучший путь - убрать настоящий секрет из коммита. Опция bypass нужна для подтвержденного ложного срабатывания или управляемого исключения, а не как кнопка продолжить работу.
Автоматическое сканирование не видит каждый внутренний пароль. Добавьте собственные шаблоны там, где площадка это поддерживает, и локальную pre-commit проверку. Тестовые ключи должны быть явно недействительными и отличаться от рабочего формата, чтобы команда не привыкала обходить предупреждения.
Как хранить конфигурацию без секрета
В репозитории остается файл-пример с именами переменных и безопасными фиктивными значениями. Настоящий секрет поступает из менеджера секретов или защищенной конфигурации среды. Доступ выдается конкретному сервису, а не всей команде и всем этапам CI.
Назначьте владельца, срок и способ ротации. Запишите, как сервис переживает замену без простоя и кто имеет аварийный доступ. Секрет без владельца почти неизбежно станет вечным.
Протокол первых 30 минут
- Не распространять значение в новых сообщениях.
- Зафиксировать место и время утечки.
- Отозвать или жестко ограничить секрет.
- Выпустить замену с минимальными правами.
- Сохранить и начать анализ журналов.
- Обновить потребителей через защищенное хранилище.
- Спланировать очистку Git и внешних копий.
После инцидента измерьте не виновника, а время до отзыва, полноту журналов и число мест, где ключ пришлось менять вручную. Эти показатели показывают, готова ли система к следующей ошибке.
Секрет в Git нужно считать раскрытым с момента публикации, даже если репозиторий был закрытым и строку быстро удалили. Отзыв закрывает полномочия, журналы отвечают на вопрос об использовании, очистка уменьшает дальнейшее распространение, а защита push снижает вероятность повтора. Только вся цепочка завершает инцидент.
