По вопросам сотрудничества: @namewasntdrown
@qtosh1
Post #52
619

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










