Если API ключ случайно попал в публичный Git-репозиторий, считать его скомпрометированным нужно сразу. Даже если файл был удален через минуту, ключ мог попасть в кэши, форки, поисковые индексы или автоматические сканеры.
Первое действие — не удаление строки из файла, а отзыв или ротация ключа в сервисе, которому он принадлежит. Только после этого нужно чистить репозиторий и проверять последствия.
Коротко: что делать
- Немедленно отозвать или перевыпустить ключ
- Проверить логи использования ключа
- Удалить секрет из текущего кода и истории Git
- Проверить CI/CD, env и серверы на старый ключ
- Добавить защиту от повторного коммита секретов
Основные причины
Секреты попадают в Git из-за локальных конфигов, .env, тестовых файлов, CI-настроек и отсутствия pre-commit проверки.
- Файл .env не был добавлен в .gitignore
- Ключ временно вставили в код для теста
- Секрет оказался в логах или fixtures
- CI/CD переменные продублировали в репозитории
- Не настроен secret scanning и pre-commit hook
Пошаговая диагностика
После ротации нужно понять, успел ли ключ использоваться и где он еще остался.
- Проверить audit logs сервиса, которому принадлежит ключ
- Найти ключ по всей истории репозитория
- Проверить forks, releases и CI artifacts
- Проверить серверные env и переменные деплоя
- Проверить, не попали ли другие секреты рядом
Как исправить проблему
Исправление состоит из ротации секрета, очистки истории и внедрения защиты на будущее.
- Отозвать старый ключ и выпустить новый с минимальными правами
- Перенести секреты в env, vault или защищенные переменные CI
- Очистить историю через git filter-repo или аналогичный инструмент
- Попросить команду пересинхронизировать репозиторий после переписывания истории
- Включить secret scanning и pre-commit проверку
Безопасный план решения
Не начинайте с переписывания Git-истории, пока ключ активен. Сначала отключите секрет, иначе время на чистку репозитория оставит окно для злоупотребления.
Чего не стоит делать
- Не считать ключ безопасным после удаления одного коммита
- Не публиковать новый ключ в том же месте
- Не давать новому ключу лишние права
- Не забывать про CI, логи и артефакты сборки
Что подготовить перед исправлением
- Какой сервис использует ключ
- Ссылка на репозиторий или локальная копия
- Время попадания ключа в Git
- Доступ к настройкам ключей и логам сервиса
FAQ
Достаточно удалить файл из репозитория?
Нет. Старый ключ нужно отозвать, потому что он остается в истории и мог быть скопирован.
Нужно ли переписывать историю Git?
Да, если секрет был в публичном репозитории. Но это делается после ротации ключа.
Как избежать повторения?
Использовать .gitignore, env, secret scanning, pre-commit hooks и ключи с минимальными правами.
Когда стоит обратиться за помощью
Помощь нужна, если ключ связан с платежами, облаком, рассылками, базой данных или production-сервисами. Тут важно действовать быстро и без лишней паники.
Итог
Начните с отзыва ключа и проверки логов. Если нужно безопасно провести ротацию, очистку Git-истории и настройку защиты, можно написать в Telegram @rabotator_support.