Плейбук: утечка ключа, токена или пароля из репозитория

Отзовите утёкший ключ, токен или пароль в панели сервиса в первые минуты, потом чистите git. Как искать секреты заранее — другой текст: секреты в git. Как хранить переменные CI: секреты для GitLab CI. Сутки: первые 24 часа. Каталог: каталог плейбуков.

Статья опирается на логику направления «Управление инцидентами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. CIS Control 17: cisecurity.org/controls. Это не российский закон. Значения секретов в статью и в чат инцидента не копируем.

Признаки и что не делать

Бот или человек написал, что ключ в публичном репозитории; сканнер CI упал; в биллинге чужие вызовы API. Не публикуйте секрет ещё раз «для коллег». Не делайте git commit --amend как будто истории нет: клон уже могли снять. Не оставляйте ключ живым, пока «перепишем файл».

Первые шаги

1. В панели сервиса: отозвать, запретить, выпустить новый. Старый не используйте для проверки «жив ли».
2. По журналу сервиса: вызовы с момента утечки. Если читали данные клиентов — сроки РКН.
3. Сделать репозиторий закрытым, если он был открыт по ошибке. Историю чистите по статье про секреты, не в первые пять минут.
4. Ротация всего, что лежало рядом в том же файле.
5. Кто имел push — сверка доступа: заявка на доступ.

Приоритет: критический для ключей облака, почты, платёжных API; высокий для внутренних токенов. Эскалация директору, если есть чужие вызовы или ПДн. Независимый канал связи, не чат в том же GitLab, если токен GitLab и утёк.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление инцидентами» (хаб: инциденты, карта: карта зрелости). Профилактика лежит в данных и SSDLC. Этот плейбук — часы после находки.

Как проверить

1. В плейбуке шаг 1 — отзыв, не git filter.
2. Контакты панелей облака записаны вне репозитория.
3. Значения секретов в карточке инцидента не хранят.

Источники

• CIS Control 17: cisecurity.org/controls.