Удалил ключ из Git — а он остался в истории
Разработчик закоммитил ключ к облаку, заметил, удалил следующим коммитом и выдохнул. Через пару дней ключом уже пользовались чужие: в истории он лежал целиком.
Недавно исследователи просканировали историю коммитов открытых репозиториев и нашли тысячи действующих ключей к облакам и ИИ-сервисам. Среди находок оказался доступ администратора крупной корпоративной ИИ-платформы. Всё это уже «удалили» из кода, но не из истории.
У меня такой случай был у владельца небольшой софтверной компании. Подрядчик вынес в репозиторий ключ от облачного хранилища, через час стёр. Мы нашли ключ в старом коммите, когда делали аудит. Хранилище с базой клиентов и договорами месяцами открывалось любому, кто знал, где искать.
Чем это грозит бизнесу
• Утечка базы клиентов и документов: по ключу заходят в хранилище как свои.
• Чужой счёт за облако: на вашем ключе майнят или гоняют нейросети, а платите вы.
• Потеря доверия: узнаёте не вы, а клиент, которому пришло письмо от мошенников с его реальными данными.
Что делать
1. Считать скомпрометированным любой ключ, который хоть раз попадал в репозиторий, и перевыпустить его. Удаление строки из кода ничего не отзывает.
2. Включить автоматическую проверку: сканер секретов в репозитории блокирует коммит с ключом до публикации. Есть бесплатные и российские решения, настройка занимает вечер.
3. Хранить ключи в хранилище секретов (например, в Яндекс Cloud Lockbox), а в коде оставлять только ссылку на него.
4. Выдавать ключам минимум прав и срок жизни: даже украденный ключ тогда мало что откроет.
Что изменится
Было: ключ живёт годами, права у него полные, о краже узнаёте из чужого письма. Стало: утёкший ключ либо заблокирован до коммита, либо уже мёртв, а при самом плохом исходе открывает один небольшой участок. По стоимости это несопоставимо с ущербом от одной серьёзной утечки.
