Non-Human Identities: почему боты и API-аккаунты стали главной целью хакеров Большинство компаний всё ещё строят безопасность вокруг людей: фишинг, пароли, двухфакторная аутентификация. Но реальность изменилась. Сегодня инфраструктурой управляют машины - боты, сервисные аккаунты, API-ключи, токены автоматизации. И именно они становятся главной целью атак. Если посмотреть на современные инфраструктуры, то соотношение машинных аккаунтов к человеческим обычно в промежутке 10–50 : 1 В облачных же сервисах вообще может доходить до 100:1 🔔 Почему это идеальная точка входа для атаки: 1. Разработчик сохраняет изменения в системе контроля версий (например, Git) и фиксирует их в репозитории Вместе с кодом в коммит случайно попадает конфигурационный файл с ключом. Через несколько минут этот ключ уже индексируют автоматические сканеры - такие боты постоянно мониторят GitHub в поиске секретов. По статистике безопасности тысячи ключей утекaют в публичные репозитории каждый день, и вскоре атакующий получает доступ к найденному ключу. 2. Получив ключ, злоумышленник первым делом проверяет, какие действия он позволяет выполнять Нередко оказывается, что сервисный аккаунт имеет довольно широкие права: • читать хранилище • писать в хранилище • создавать новые токены • читать секреты • управлять инфраструктурой Так происходит потому, что при создании аккаунта разработчик часто выдаёт максимальные права, чтобы всё работало без ограничений 3. Если ключ даёт доступ к хранилищу или базе данных, атакующий начинает выгружать информацию В таких хранилищах нередко находятся: • пользовательские данные • внутренние документы • резервные копии • конфигурации инфраструктуры На этом этапе компания может даже не заметить ничего подозрительного, поскольку доступ осуществляется с валидным ключом 4. Далее злоумышленник пытается найти дополнительные ключи и токены В облачной инфраструктуре они часто хранятся в разных местах: • в переменных окружения • в конфигурациях сервисов • в системах сборки • в секрет-хранилищах Один найденный ключ нередко приводит к нескольким новым, и так начинается перемещение внутри инфраструктуры Если среди обнаруженных токенов оказываются ключи с административными правами, атакующий получает возможность: • запускать новые серверы • менять конфигурацию инфраструктуры • читать любые данные • создавать новые учётные записи В этот момент инфраструктура фактически скомпрометирована, и всё это может начаться всего с одного API-ключа ⌨️ Самое страшное, что это не просто на бумаге, а реальные кейсы которые происходили в крупных компаниях: Uber (2022) Атакующий получил доступ к внутренним системам после того, как нашёл жёстко прописанные учётные данные в скриптах PowerShell. Через них удалось получить доступ к внутренним сервисам и административным инструментам. Microsoft (2023) Китайская группа получила доступ к подписывающему ключу сервисных токенов. Это позволило подделывать токены и читать почтовые ящики в облаке, включая почту государственных структур США ℹ️ Главная проблема В большинстве компаний хорошо управляют пользователями. Но почему то почти не управляют машинными учётными записями: • API-ключами • сервисными аккаунтами • токенами автоматизации • ключами из CI/CD А их обычно в десятки раз больше, чем людей. Поэтому безопасность меняется 🔒 Сегодня всё больше компаний начинают защищать именно машинные идентичности: • полный учёт всех ключей • короткоживущие токены • автоматическая ротация секретов • минимальные права доступа • мониторинг использования ключей Потому что в современной инфраструктуре самая опасная учётная запись - это та, которой пользуется не человек или же о которой все забыли 👥 Devsprout - Подписаться