Исследование Truffle Security: 9 308 раскрытых ключей AWS сохранили доступ

Исследование Truffle Security показывает, что утёкшие облачные учётные данные могут оставаться рабочими годами. В период с августа 2022 года по август 2026 года специалисты зафиксировали 431 875 находок AWS-секретов в публичных репозиториях, истории Git, наборах данных, Docker-образах, реестрах контейнеров и журналах систем непрерывной интеграции. После удаления повторов и проверки исследователи получили 64 024 уникальных AWS-ключа. 145

Главный вывод связан не только с масштабом утечек, но и с их долговечностью: 9 308 из 10 616 полных наборов учётных данных, проверенных 10 августа 2026 года, успешно прошли аутентификацию. Это примерно 88%. 145

Под угрозой оказались привилегированные аккаунты

В проверенной совокупности насчитывалось 10 625 root-учётных данных, 48 744 ключа IAM-пользователей и 4 655 ключей, которые не удалось классифицировать. На root-ключи пришлось 16,6% уникальных ключей. В AWS root-учётная запись обладает наивысшим уровнем привилегий, поэтому её ключ особенно опасен при утечке. 1

Truffle Security выявила 817 активных ключей, связанных с компаниями. Среди них были:

• 526 root-ключей — ключей с максимальными привилегиями в аккаунте AWS;
• 242 ключа IAM-пользователей с политикой AdministratorAccess, которая может предоставить полный контроль над аккаунтом;
• 768 ключей в общей сложности, способных дать злоумышленнику полный контроль над корпоративным аккаунтом AWS;
• 130 активных root-ключей управляющих аккаунтов AWS Organizations. Компрометация такого аккаунта потенциально может затронуть все входящие в организацию дочерние аккаунты. 13

В более узкой выборке IAM-пользователей, для которых удалось прочитать политики, 976 из 1 157 пользователей — 84% — имели AdministratorAccess. Ещё у 144 была политика IAMFullAccess. Truffle Security подчёркивает, что это ориентировочная оценка: пользователи, чьи политики можно было перечислить, не обязательно представляют всех утёкших IAM-пользователей. 1

Сколько аккаунтов AWS оказалось затронуто?

В предоставленных материалах фигурируют два разных числа, описывающих количество аккаунтов. В одном резюме говорится о 9 945 уникальных аккаунтах AWS, связанных с набором из 64 024 ключей. В резюме исходного отчёта указано 50 654 уникальных аккаунта. Источники не объясняют, почему оценки различаются, поэтому эти значения нельзя считать взаимозаменяемыми. 1

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

Hugging Face стал крупнейшим источником рабочих ключей

На платформе Hugging Face исследователи нашли 8 482 уникальных рабочих AWS-ключа в 3 394 публичных наборах данных. Это крупнейший отдельный источник в исследовании. Root-ключи составляли 17,9% найденных там ключей — это самая высокая доля среди отслеживаемых источников. 125

Проблему усиливает то, как распространяются публичные данные. Снимок репозитория с секретом может попасть в обучающий набор, а затем — в несколько производных наборов данных. Поэтому удаление ключа из исходного репозитория не гарантирует, что исчезли все его копии. 1

Эти результаты относятся к более широкому сканированию Hugging Face, проведённому Truffle Security. Компания заявила, что проверила 7,6 петабайта данных и 187 млн файлов, обнаружив 221 303 живых уникальных учётных данных в 6 003 наборах данных. В эту статистику входят все типы секретов, а не только ключи AWS. 6

Большинство ключей не меняли годами

Из 2 903 активных ключей, для которых удалось определить дату создания, медианный возраст составил 1 831 день — примерно пять лет. Половина ключей была старше пяти лет, самому старому было 17,4 года, а за последние 30 дней были созданы только 25 ключей — 0,9% выборки. 1

Новый ключ взамен имели лишь 398 из 2 903 ключей, то есть 13,7%. Это указывает на то, что большинство раскрытых секретов не были своевременно отозваны, заменены или удалены после публикации. 1

Практический вывод прост: секрет, однажды попавший в публичный доступ, следует считать скомпрометированным навсегда — даже если исходный файл или запись в репозитории отредактированы. Старые копии могут сохраняться в истории Git, образах контейнеров, пакетах и публичных наборах данных. 1

Отсутствие бюджетных уведомлений повышало риск криптомайнинга

Механизмы контроля расходов тоже использовались редко. Среди 2 754 аккаунтов, настройки которых удалось прочитать, бюджетное уведомление было настроено только у 262 — 9,5%. Медианный порог срабатывания составлял 8 долларов. 12

Таким образом, у 90,5% аккаунтов из доступной для анализа выборки не было обнаруживаемого бюджетного предупреждения. Получив рабочие ключи, злоумышленники могли запускать майнинг криптовалют или другие ресурсоёмкие задачи, а организация могла заметить проблему лишь после существенного роста счёта. 12

Совокупные расходы анализируемых аккаунтов в июле 2026 года составили 420 631 доллар. Пятьдесят аккаунтов потратили более 1 000 долларов, а девять — более 10 000 долларов за месяц. Эти данные отражают расходы наблюдавшихся аккаунтов и сами по себе не доказывают, что они были вызваны злоупотреблением ключами. 1

Карантин AWS не всегда означал немедленную блокировку

Truffle Security сообщила, что AWS применяла к обнаруженным утёкшим IAM-ключам политику AWSCompromisedKeyQuarantine. Она ограничивает возможности ключа, но не обязательно сразу отключает саму аутентификацию. 1

Среди проверенных активных IAM-ключей такую политику имели 929 из 7 590 — 12%. Ещё у 112 ключей была обнаружена её старая версия, применение которой AWS прекратила в 2023 году. По данным Truffle Security, некоторые ключи оставались рабочими даже после давно полученных уведомлений о компрометации. 1

Поэтому карантинную политику следует воспринимать как сигнал об утечке, а не как доказательство того, что секрет уже безопасно выведен из эксплуатации. Организации должны установить владельца ключа, проверить его права и немедленно отозвать или заменить его. 1

Как проходила проверка

Truffle Security повторно проверяла только те наборы учётных данных, для которых располагала полной информацией. Для анализа аккаунтов и привилегий специалисты использовали доступные только для чтения вызовы IAM, проверяя по одному ключу за раз. Материалы самих ключей не публиковались, а всем владельцам, которых удалось установить, направлялись уведомления. 15

Это важно учитывать при интерпретации показателя в 88%: он относится к подмножеству полных наборов учётных данных, которые удалось повторно проверить, а не ко всем найденным публичным упоминаниям или частичным секретам. 14

Что организациям стоит сделать

Исследование поддерживает следующий базовый план реагирования:

1. Удалить root-ключи доступа. Truffle Security считает, что для штатной операционной работы они не нужны. 1
2. Проверить все IAM-ключи, включая секреты в репозиториях, истории Git, CI-логах, образах, реестрах и опубликованных наборах данных. 1
3. Немедленно отозвать или заменить раскрытые ключи. Удаления видимой копии недостаточно, если секрет сохранился в истории или производных артефактах. 1
4. Ограничить срок жизни ключей и enforce-ить ротацию. Старые и неиспользуемые учётные данные лучше удалить, чем оставлять доступными на неопределённый срок. 1
5. Настроить бюджетные уведомления. Даже небольшой порог, например 10 долларов, может помочь раньше заметить несанкционированные расходы. 1
6. Отслеживать AWSCompromisedKeyQuarantine и расследовать появление этой политики как возможный признак утечки. 1
7. Внедрить постоянное сканирование секретов в исходном коде, истории изменений, системах сборки, контейнерных артефактах, реестрах и публичных наборах данных. 1

Главное предупреждение исследования заключается в том, что публикация секрета — не разовое событие. Без отзыва, ротации и постоянного мониторинга AWS-ключ может годами оставаться рабочей дверью в облачную инфраструктуру.