Skip to content
RiverCore
Отчёт Sysdig 2026: облачная безопасность переходит на машинную скорость
cloud security reportmachine identitiesAI packagesSysdig 2026 cloud native security findingsmachine speed cloud threat detection

Отчёт Sysdig 2026: облачная безопасность переходит на машинную скорость

20 апр 20267 мин. чтенияJames O'Brien

Раньше пит-стоп в Формуле 1 занимал почти минуту на замену четырёх шин. Сейчас — меньше двух секунд, и ни один человек в боксах не решает, когда опустить домкрат: это делают датчики и оборудование. Новый отчёт Sysdig фактически говорит о том, что облачный SOC оказался в той же точке. Человек с блокнотом по-прежнему полезен, но он больше не тот, кто нажимает на курок.

Что произошло

В понедельник, как сообщил SecurityBrief UK, компания Sysdig опубликовала отчёт Cloud-Native Security and Usage Report 2026, основанный на анализе миллиардов программных пакетов и сотен тысяч облачных идентификаторов. Главный тезис, сформулированный старшим стратегом по кибербезопасности Кристал Морин, заключается в том, что облачная защита смещается от операций под руководством человека к обнаружению угроз и реагированию на них на машинной скорости.

Цифры говорят сами за себя. AI-специфичные пакеты выросли на 25% год к году. Предприятия стали использовать в шесть раз больше пакетов машинного обучения по сравнению с предыдущим годом. При этом лишь 1,5% AI-связанных ресурсов были публично доступны — это говорит о том, что команды на самом деле проявляют осторожность в отношении того, что они открывают для внешнего доступа.

Европа выглядит на удивление передовой. Европейские организации обеспечили более 50% всех отслеживаемых в исследовании AI и ML пакетов, а также более 34% внедрений Falco — инструмента обнаружения угроз во время выполнения с открытым исходным кодом, используемого в контейнерах и средах Kubernetes. GDPR не заморозил их — он их дисциплинировал.

На стороне защиты: более 70% команд безопасности теперь используют поведенческое обнаружение, и эти инструменты охватывают 91% облачных сред. Самая впечатляющая статистика: число организаций, автоматически завершающих подозрительные процессы в момент срабатывания правила обнаружения, выросло на 140% по сравнению с предыдущим годом.

Основатель и CTO Sysdig Лорис Деджоанни высказался прямо: «Команды безопасности оптимизировали рабочие процессы с участием людей, но достигли своего предела. Угрозы с применением AI развиваются слишком быстро для дашбордов, алертов и ручной сортировки. Эра облачной безопасности под управлением человека подходит к концу, а рост автономии AI определит следующее поколение киберзащиты». В отчёте также отмечается, что злоумышленники используют AI для эксплуатации уязвимостей в течение нескольких часов после их раскрытия.

Техническая анатомия

Суть изменений — в том, где теперь находится цикл принятия решений. На протяжении десяти лет стандартный конвейер облачного SOC выглядел так: телеметрия в SIEM, SIEM в очередь алертов, аналитик к дашборду, аналитик к тикету, тикет к исполнителю. Каждая стрелка в этой цепочке — это задержка размером с человека. Прекрасно работает, если ваш противник — тоже человек, набирающий команды в Burp Suite. Перестаёт работать, когда противник — это скрипт, читающий CVE-ленту, выбирающий эксплуатируемую уязвимость и имеющий рабочий эксплойт ещё до того, как остыл кофе в день Patch Tuesday.

Поведенческое обнаружение — это то, что делает автономию достаточно безопасной для внедрения. Сигнатурные инструменты срабатывают на «мы это уже видели». Поведенческие инструменты, работающие на уровне ядра или среды выполнения контейнера, срабатывают на «этот процесс делает то, чего эта рабочая нагрузка никогда не делала». Falco — главный пример здесь: инспекция системных вызовов на базе eBPF, правила, описывающие намерение, а не хэши. Когда 91% сред обладает таким уровнем видимости во время выполнения, можно реально доверять автоматическому действию по уничтожению процесса, не сжигая продакшн каждый вторник.

Именно это на самом деле измеряет скачок в 140% по автоматическому завершению процессов. Дело не в том, что команды внезапно стали смелее. Дело в том, что соотношение сигнала к шуму в обнаружениях во время выполнения наконец пересекло порог, при котором kill -9 для подозрительного процесса менее рискован, чем ожидание десяти минут, пока аналитик его изучает. Каждый, кто смотрел, как очередь обнаружений растёт вечером в пятницу, прекрасно понимает, почему это соотношение важно.

Уровень идентификаторов — вот где всё становится по-настоящему странным. Пользователи-люди составляют лишь 2,8% управляемых идентификаторов в облачных инфраструктурах. Остальные 97,2% — машины: сервисные аккаунты, идентификаторы рабочих нагрузок, CI-раннеры, Lambda-роли, сервисные токены Kubernetes, боты, агенты и всё активнее — AI-ассистенты для написания кода со своими собственными учётными данными. Каждый из них — потенциальная точка опоры, сопоставленная с реальными техниками в матрице ATT&CK в разделах доступа к учётным данным и горизонтального перемещения. Старый сценарий IAM, построенный вокруг квартальных проверок доступа и людей, которые входят в систему по понедельникам, просто не масштабируется на такое соотношение.

Кто пострадает

Очевидные проигравшие — аутсорсинговые SOC-подразделения первого уровня, чьё всё ценностное предложение сводится к «мы будем следить за вашим дашбордом». Если 70%+ обнаружений основаны на поведении, а автоматическое реагирование становится стандартом, человек перед вкладкой Splunk, читающий алерты, — самое дорогостоящее и медленное звено конвейера. Я бы предположил, что этот уровень в течение следующих 18 месяцев поглотится инженерией обнаружения, а MSSP, которые не перестроятся, потеряют продления контрактов в пользу платформ, поставляющих policy-as-code.

Операторы iGaming, управляющие мультирегиональными инфраструктурами Kubernetes, подвержены риску особым образом. Регулируемые юрисдикции требуют журналов аудита и персональной ответственности людей за решения в области безопасности, но атакующие окна, которые описывает Морин — эксплуатация в течение нескольких часов после раскрытия уязвимости — означают, что «ждать совета по управлению изменениями» — это фактически согласие на взлом. Ближайшие 90 дней для руководителей платформ в этой вертикали — это работа по документированию: доказательство регуляторам, что автоматическое завершение процессов поддаётся аудиту, может быть отменено и журналируется.

Команды финтех и платёжных систем сталкиваются с проблемой машинных идентификаторов в полной мере. Уровень оркестрации платежей может иметь тысячи сервисных аккаунтов в PSP, движках борьбы с мошенничеством, сервисах учёта и задачах сверки. Доля пользователей-людей в 2,8% от общего числа идентификаторов, вероятно, завышена для такого стека. Если права доступа недостаточно ограничены, одна скомпрометированная учётная запись CI-конвейера означает полный провал. Именно здесь, по моим ожиданиям, будут происходить самые дорогостоящие инциденты 2026 года.

Команды инфраструктуры в сфере криптовалют и DeFi — те, кто управляет валидаторами, RPC-флотами и мостовыми ретрансляторами — всегда жили в мире, где атакующий автоматизирован. Они прочитают этот отчёт и кивнут. Их проблема не в принятии машинной скорости защиты, а в том, чтобы объяснить страховщикам, почему поведенческое обнаружение во время выполнения заслуживает скидки на премию.

Европейские технические руководители выходят из этого в выгодном свете. 50-процентная доля в принятии AI-пакетов наряду с 34-процентной долей Falco говорит о том, что те, кто работает в условиях жёсткого регулирования, также строят системы на инструментированных основаниях. Это история, которую стоит рассказать на следующем заседании совета директоров.

Руководство для команд безопасности

На этой неделе — три шага. Первый: проверьте, сколько ваших обнаружений всё ещё требуют ручной сортировки перед любым действием. Если это число превышает 50%, вы работаете с SOC образца 2019 года. Выберите три семейства правил с высокой достоверностью (поведение криптомайнеров, паттерны обратных оболочек, дамп учётных данных) и переведите их в режим автоматического завершения с возможностью аварийного переопределения. Тезис Морин о закрытии асимметричного разрыва — правильный ориентир здесь.

Второй: проведите перепись идентификаторов. Извлеките каждого нечеловеческого принципала в вашей облачной инфраструктуре, сопоставьте с владеющей рабочей нагрузкой и отметьте всё, что остаётся без владельца. Сверьтесь со списком CISA KEV для любого сервиса, чьи учётные данные могут находиться в публичном образе или старом репозитории. Число машинных идентификаторов будет только расти по мере того, как AI-агенты для написания кода начнут отправлять PR, так что любая гигиена, которую вы откладываете сейчас, станет в десять раз сложнее в следующем квартале.

Третий: обеспечьте видимость во время выполнения в контейнерах, если ещё не сделали этого. Falco — с открытым исходным кодом, eBPF зрелый, и порог входа ниже, чем продление вашего EDR. Скучная часть — написание правил, соответствующих вашим реальным рабочим нагрузкам, а не развёртывание настроек по умолчанию. Место, где всё рушится, — когда алерты срабатывают, а никто не владеет путём реагирования, поэтому подключите их к тому же потоку автоматического завершения до того, как включите.

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

Ключевые выводы

  • Отчёт Sysdig 2026 позиционирует машинную скорость защиты как единственный жизнеспособный ответ на атаки с применением AI, эксплуатирующих CVE в течение нескольких часов после раскрытия.
  • Поведенческое обнаружение теперь защищает 91% облачных сред, а число организаций, автоматически завершающих подозрительные процессы, выросло на 140% год к году.
  • Машинные идентификаторы доминируют в облачных инфраструктурах с долей 97,2%, что делает IAM для нечеловеческих субъектов центральной проблемой безопасности, а не второстепенной.
  • Европейские организации лидируют как по принятию AI-пакетов (50%+), так и по внедрению Falco (34%+), что говорит о взаимном усилении регулирования и инструментирования.
  • Роль SOC первого уровня по наблюдению за дашбордами — это член пит-команды с блокнотом: всё ещё в боксах, но больше не тот, кто опускает домкрат.

Часто задаваемые вопросы

В: Что на практике означает «защита на машинной скорости» для команды облачной безопасности?

Это означает, что решения об обнаружении и реагировании выполняются автоматизированными системами за миллисекунды, а не направляются через очередь к аналитику-человеку. На практике подозрительный процесс уничтожается правилом во время выполнения в момент проявления аномального поведения, а человек проверяет это действие постфактум, а не авторизует его заранее.

В: Почему машинные идентификаторы составляют 97,2% всех облачных идентификаторов?

Современные облачные архитектуры работают на сервисных аккаунтах, идентификаторах рабочих нагрузок, CI/CD-раннерах, сервисных токенах Kubernetes, ботах и всё активнее — AI-агентах для написания кода, каждому из которых нужны учётные данные для доступа к системам. Сотрудники-люди составляют ничтожную долю, потому что большинство реальной работы внутри облачной инфраструктуры выполняется автоматизированными компонентами, взаимодействующими между собой.

В: Безопасно ли автоматически завершать подозрительные процессы в продакшн-среде?

Это безопаснее, чем раньше, поскольку поведенческие обнаружения дают более точные алерты по сравнению с сигнатурными, и Sysdig сообщает, что охват теперь составляет 91% облачных сред. Риск уничтожения легитимного процесса реален, поэтому команды, как правило, начинают с узких семейств правил с высокой достоверностью и включают возможность аварийного переопределения, прежде чем расширять область применения.

JO
James O'Brien
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// RELATED ARTICLES
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU