Итак, ты случайно запушил API-ключ, токен или пароль. Через пять минут заметил, удалил из кода, переписал историю Git и выдохнул. Поздравляю - ты сделал все неправильно, так как ключ всё ещё рабочий.

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

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

Также стоит попробовать найти все места, где секрет успел засветиться. Помимо Git-истории это могут быть CI-логи, артефакты сборки, форки, кэши, локальные клоны и уведомления о коммитах. С историей в гите тоже лучше разобраться подробнее. git filter-repo поможет убрать секрет из коммитов, но переписывание истории не удалит копии, которые уже разошлись. А если команда продолжит работать со старыми клонами, секрет можно случайно занести обратно. Чистку истории лучше координировать с остальными разработчиками и администраторами Git-хостинга. Если утечка секрета обнаружена не сразу, то вполне возможно, что придется разбираться с форками, pull request и кэшированными объектами.

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

В следующем посте расскажу о способах устранения и быстрого обнаружения таких уязвимостей.

#ks_без #ks_разработка