Ключ доступа к облачной инфраструктуре Amazon Web Services, случайно попавший в открытый репозиторий, перестаёт работать частично уже через десять секунд. Такую скорость даёт автоматическая политика безопасности, которую облачный провайдер применяет к учётной записи без участия владельца. Долгосрочные ключи доступа остаются одним из главных способов проникновения в облачные среды: они дают постоянное право на служебные операции, а не временное. Если такому ключу выданы широкие полномочия, злоумышленник получает возможность создавать новые учётные записи, запускать вычислительные ресурсы и выгружать данные за пределы инфраструктуры. Утечка происходит по-разному: чаще всего через публичные репозитории с исходным кодом или файлы с переменными окружения, случайно оказавшиеся в открытом доступе. Механизм автоматической реакции существует не первый год, но за последнее время он заметно ускорился.
Описание
Чтобы сократить окно между утечкой и её обнаружением, GitHub развивает программу партнёрского сканирования секретов. Каталог шаблонов для поиска чувствительных данных появился в 2018 году, а Amazon присоединилась к нему в 2020-м. Сегодня в программе участвуют больше двухсот поставщиков услуг, а общее число шаблонов перевалило за пятьсот. Сканирование публичных репозиториев включено по умолчанию, для частных хранилищ его активируют вручную. Найденную строку платформа сверяет с поставщиком услуги и, если ключ действительно активен, отправляет уведомление. С августа 2023 года работает защита от отправки: GitHub предупреждает разработчика до того, как секрет окажется в ветке проекта, и предлагает отменить операцию. Периодические проверки позволяют отделить рабочие ключи от случайного набора символов.
Эффективность этой связки проверили на практике. По данным Unit 42, исследователи компании Palo Alto Networks разместили тестовый ключ в публичном репозитории и фиксировали реакцию систем. Изолирующая политика применилась через десять секунд после публикации, ещё через секунду пришло уведомление от GitHub. Затем в консоли облачного аккаунта появилось предупреждение о риске, а в службу поддержки автоматически ушло обращение с описанием инцидента и рекомендацией заменить ключ. Весь путь от утечки до формального уведомления занял меньше минуты и не потребовал вмешательства человека. Исследователи отдельно отметили, что событие привязки политики попадает в журналы аудита, хотя сама автоматическая операция не указывает на исполнителя.
Политика изоляции появилась в августе 2020 года и с тех пор переписывалась несколько раз. Первая версия запрещала около трёх десятков операций в пяти сервисах: управлении доступами, виртуальных машинах, работе с организациями, бессерверных вычислениях и простых облачных серверах. В 2021 году список расширили хранилищем объектов, добавив запреты на удаление файлов, изменение правил доступа и создание копий. Следующие редакции закрыли выкуп данных из хранилищ, резервирование вычислительных мощностей и работу с сервисами искусственного интеллекта. Каждое новое ограничение появляется после того, как злоумышленники осваивают очередной сервис. Майнинг криптовалют через вычислительные функции, массовое удаление файлов ради требования выкупа и несанкционированные обращения к моделям машинного обучения уже отражены в списках запретов. Запреты имеют приоритет над любыми разрешениями, поэтому даже широкие полномочия учётной записи не помогают обойти ограничения.
Полного отключения ключа при этом не происходит. Владелец аккаунта сохраняет возможность работать, а злоумышленник теряет доступ лишь к перечисленным действиям. Такой компромисс снижает ущерб, но не закрывает проблему целиком: продвинутые атакующие способны использовать разрешённые операции. Остаются и слепые зоны у защиты от публикации. Если разработчик отправляет в репозиторий сразу тысячи файлов или объём превышает 50 мегабайт, проверка может не сработать. Не сработает она и тогда, когда в одной отправке оказывается больше пяти секретов: уведомления получат только первые из них. Пропущенные ключи остаются активными до следующей проверки, и это окно злоумышленник способен использовать.
Реакция на утечку не должна зависеть от одного сотрудника. AWS предлагает инструмент, который собирает обращения службы поддержки в одном месте, - Systems Manager Explorer. Служба журналирования CloudTrail (система аудита событий внутри аккаунта), включённая по умолчанию на 90 дней, сохраняет записи о привязке политики к учётной записи, и по ним настраивают оповещение в удобной системе мониторинга. Полезно отслеживать и автоматические проверки со стороны GitHub: они обращаются к облаку с характерными признаками, по которым нетрудно отличить их от действий пользователя. Не менее важно, чтобы команды, отвечающие за репозитории и за облачную инфраструктуру, обменивались такими сигналами. Разрыв в коммуникации приводит к тому, что письмо об инциденте оседает в почте инженеров, а служба безопасности узнаёт о нём спустя недели. Чем быстрее ключ попадёт под наблюдение, тем меньше времени останется у того, кто попытается им воспользоваться.