API-ключ попал в Git: удаления строки недостаточно

Если API-ключ попал в репозиторий GitHub, сразу отзовите его у выдавшего сервиса или замените так, чтобы прежний ключ перестал работать. Затем проверьте его использование, выпустите новый ключ и обновите зависимые приложения. Удаление строки из файла не прекращает действие уже раскрытого ключа, а очистку истории Git нужно оценивать после отзыва.

Исправленный файл не означает, что прежняя версия исчезла. Документация GitHub по сканированию секретов указывает, что эта функция проверяет историю Git во всех ветвях на известные типы учётных данных и рекомендует немедленно заменить обнаруженный секрет. Само сканирование зависит от типа репозитория и доступных ему функций защиты, поэтому отсутствие оповещения не стоит считать доказательством безопасности ключа.

В первые минуты прекратите действие ключа

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

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

Проверьте использование за время раскрытия

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

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

Выпустите замену и обновите зависимости

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

Уберите значение из текущей версии кода и конфигурации репозитория. Если секрет лежал в локальном файле настроек, добавьте путь к нему в .gitignore и прекратите отслеживать этот файл; правило .gitignore само по себе не удаляет уже сохранённые версии. Если тот же ключ попал в клиентский код, отправляемый пользователю, потребуется устранить и утечку в браузерной сборке: изменение репозитория не убирает ранее опубликованный секрет из доступных копий приложения.

Оцените необходимость очистки истории Git

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

Инструкция GitHub по удалению конфиденциальных данных описывает применение git-filter-repo и последствия переписывания истории: меняются идентификаторы коммитов, а прежние данные могут сохраняться в клонах, ответвлениях и ссылках из запросов на слияние. Согласуйте работу с участниками репозитория и обновление их локальных копий, иначе старая история может вернуться при следующей отправке изменений. Принудительная отправка очищенной ветви сама по себе не удаляет секрет из чужих клонов; для оставшихся ссылок на GitHub в некоторых случаях требуется обращение в поддержку платформы.

Поставьте проверку перед следующей отправкой

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

Перед коммитом просматривайте подготовленные изменения командой git diff --cached и добавляйте файлы осознанно, особенно когда рядом с кодом находятся локальные настройки. Секреты храните вне исходников, ограничивайте их права и срок действия там, где это позволяет поставщик. Закрывайте инцидент после проверки всех затронутых приложений и доступных журналов, фиксации решения об истории и подтверждения, что прежний ключ отключён, а новый работает там, где нужен.

Читайте также:

• API-ключ утёк в браузер: как хранить секреты без неожиданных счетов
• Как настроить автоматическое удаление истории Google и проверить, что осталось в аккаунте
• Монетизация YouTube: набрать просмотры недостаточно — канал проверят целиком