Если взломанный провайдер хранил ваши ключи API: блокировка доступа, замена и проверка начислений

Цель

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

Предварительные условия

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

Шаги

1. Определите область возможного раскрытия. Выясните, какие ключи хранил провайдер и какие легитимные потребители совместно их использовали. Зафиксируйте идентификаторы, разрешения и ответственных. В документации Google Cloud для инвентаризации указана команда gcloud services api-keys list --project=PROJECT_ID; замените заполнитель идентификатором своего проекта. Перечень ключей помогает выявить потенциально затронутые ключи, но не доказывает их кражу. Справочник CLI.

2. Пресеките доступ до восстановления. Приостановите затронутую интеграцию и отзовите раскрытые ключи у их издателя. Удаление сохранённой копии не равнозначно отзыву на стороне издателя. Процедура реагирования OWASP ставит на первое место немедленный отзыв, затем замену и очистку. Допустите контролируемый перерыв в работе вместо продолжения использования раскрытых учётных данных. Не передавайте новые секреты затронутому сервису, пока его восстановление не подтверждено. Реагирование на раскрытие секретов по OWASP.

3. Заменяйте ключи через доверенные каналы. Выпустите новые ключи и обновите их у каждого авторизованного потребителя. Google Cloud также описывает поэтапную ротацию ключей API: создать новый ключ, обновить приложения, затем удалить предыдущий. Если ради доступности вы используете период одновременного действия ключей, явно учтите время, пока раскрытый ключ остаётся пригодным для использования. Не приравнивайте незаметно создание нового ключа к отзыву старого. Процедура издателя.

4. Проверьте учётную запись. Изучите доступные записи аудита с самого раннего возможного момента раскрытия до пресечения доступа. Ищите неожиданные вызовы, новые учётные данные, новые идентичности и изменения ресурсов; для такого расследования Google Cloud указывает Cloud Logging и Security Command Center. Сохраните относящиеся к делу подтверждения, прежде чем устранять несанкционированный доступ. Отдельно сопоставьте использование и начисления с ожидаемой нагрузкой и передайте идентификаторы спорных запросов, временные метки и записи начислений через канал поддержки с аутентификацией. Не рассчитывайте на возмещение как на гарантированный результат. Рекомендации по расследованию.

5. Ограничьте дальнейший доступ. Разделите интеграции и среды, предоставляйте только необходимые разрешения и по возможности отдавайте предпочтение краткоживущим учётным данным. Google Cloud рекомендует ограничения по API и приложениям для снижения риска злоупотребления ключами. Настройте ограничения под легитимного потребителя и убедитесь, что он продолжает работать. Ограничения ключей, жизненный цикл секретов.

6. Настройте меры контроля затрат и различайте их действие. Где возможно, настройте лимиты расходов или квоты, обеспечиваемые издателем, а также уведомления в отслеживаемый канал. Установите, какие настройки действительно останавливают запросы. AWS Budgets прямо предупреждает, что задержки начислений и уведомлений могут привести к расходам сверх порога оповещения. Проверьте доставку уведомлений, не создавая намеренно избыточных расходов. Ограничения бюджетного контроля.

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

Ожидаемый результат

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

Ограничения и основание проверки

Это предлагаемое обобщение эксплуатационных практик, а не проверенная процедура восстановления. Отсутствующие журналы не позволяют установить отсутствие злоупотреблений. Google Cloud предупреждает, что уже выданные токены служебных учётных записей имеют собственные сроки действия: исследуйте производный доступ, не предполагая, что замена исходного ключа его аннулирует. Здесь не заявлено ни о затронутой версии ПО, ни о выпуске с исправлением.