Более 9 300 утёкших ключей AWS оставались рабочими годами

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

Сотни корпоративных ключей давали права администратора

Из активных ключей, которые удалось связать с корпоративными аккаунтами, 817 относились к компаниям. В их числе были:

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

Root-учётная запись предоставляет клиенту AWS максимальный уровень доступа. IAM-идентичность с политикой AdministratorAccess также может выполнять широкий круг операций во всех сервисах AWS. Действующий ключ такого уровня создаёт путь к захвату аккаунта, несанкционированному созданию ресурсов, доступу к данным и злоупотреблениям с облачными расходами.

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

Hugging Face стал крупнейшим отдельным источником

На Hugging Face пришлось 8 482 случая публикации ключей AWS — это крупнейший отдельный источник, выявленный в отчёте. По данным Truffle Security, 17,9% этих ключей были root-учётными данными.

Результат согласуется с более масштабным сканированием публичных данных Hugging Face. Truffle Security заявила, что проверила 7,6 петабайта датасетов и обнаружила действующие учётные данные в тысячах наборов данных. Это показывает, что секреты могут сохраняться не только в обычных репозиториях, но и в публично распространяемых данных.

Для команд информационной безопасности вывод очевиден: проверки только текущих исходных репозиториев недостаточно. Ключи могут сохраняться в истории Git, артефактах сборки, образах контейнеров, реестрах, опубликованных датасетах и выводе CI даже после того, как разработчики считают, что удалили их.

Многие ключи были очень старыми и почти не ротировались

Медианный возраст обнаруженных ключей составлял примерно 1 831 день, то есть около пяти лет. Самому старому ключу было 17,4 года. Только у 13,7% записей находился более новый ключ, связанный с тем же пользователем, что указывает на редкую ротацию большинства учётных данных.

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

Практический вывод: возраст ключа нужно считать самостоятельным сигналом риска. Если учётные данные несколько лет назад оказались в открытом доступе, нельзя автоматически считать их устаревшими. Их следует проверить, отозвать и расследовать ситуацию — если только владелец не может подтвердить, что ключ больше недействителен.

Бюджетные оповещения были редкостью

Truffle Security смогла получить информацию об аккаунтах 2 754 организаций, но бюджетные оповещения AWS были включены только у 262 из них.

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

Что решают уведомления AWS — и чего они не решают

В материалах исследования описываются механизмы AWS, способные обнаруживать опубликованные ключи доступа, уведомлять затронутых клиентов и применять ограничения или меры изоляции. Однако то, что большое число проверенных ключей продолжало работать, указывает: обнаружение или уведомление не всегда приводило к быстрому отзыву и замене ключей на стороне клиента.

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

Truffle Security характеризует свою проверку как тестирование только для чтения: исследователи проверяли факт аутентификации и метаданные аккаунта или разрешений, не изменяя ресурсы клиентов. Эта методика изложена со стороны Truffle Security и не подтверждена независимо всеми представленными источниками.

Что делать после утечки ключа AWS

1. Немедленно отозвать или заменить ключ

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

2. Устранить ключи root-пользователя

Root-ключи AWS не должны использоваться для регулярного программного доступа. Удалите их и переведите рабочие нагрузки на контролируемые идентичности с минимально необходимыми разрешениями.

3. Проверить права и владельца

Установите, какому аккаунту, пользователю, сервису и ресурсам принадлежал ключ. В первую очередь проверяйте ключи с root-правами, политикой AdministratorAccess, широким доступом к данным или возможностью создавать инфраструктуру.

4. Провести расследование до и после отзыва

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

5. Заменить постоянные ключи краткоживущими идентичностями

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

6. Настроить бюджетные оповещения и маршрут реагирования

Включите оповещения AWS Budgets и мониторинг аномалий расходов, а уведомления направьте сотрудникам, которые могут быстро принять меры. Финансовый контроль — это страховочная сетка, а не замена сканированию секретов, ротации ключей и регулярной проверке доступа.

Более широкий урок для облачной безопасности

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

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