Облако стало новым стандартом для бизнеса — компании переносят туда данные, приложения и целые отделы. Но вместе с тем появились новые угрозы, которые старая защита просто не замечает. Один сотрудник случайно открыл доступ к файлам — и данные клиентов уже видны всему интернету. Разработчик поменял настройку — и в системе появилась дыра. Все это происходит быстро и незаметно, а традиционные проверки раз в квартал такие вещи не ловят.
Именно поэтому появились специальные инструменты облачной безопасности: CSPM смотрит, правильно ли все настроено, CWPP следит за тем, что происходит внутри систем прямо сейчас, а CNAPP делает и то, и другое в одном окне. Кибер Медиа разбирается, чем эти решения отличаются друг от друга, и какое из них стоит выбрать в зависимости от тех или иных задач.
Раньше безопасность работала по простому принципу: есть забор — фаервол, — и все, что внутри него, считается своим и безопасным. Внутри сети все условно доверенное, снаружи — враждебное. Этот подход отлично работал, когда серверы стояли в собственном дата-центре и не менялись неделями. Облако эту логику сломало полностью. Серверы и контейнеры теперь живут минуты и секунды — пока старый инструмент защиты пытается на них установиться, они уже исчезли и на их месте появились новые. Инфраструктура больше не строится руками — она описывается в коде и разворачивается автоматически за несколько минут. Это удобно, но каждое такое обновление может случайно открыть дыру в безопасности. Команда узнаёт об этом только через несколько недель. Именно в этот промежуток действуют злоумышленники. Казалось бы, ответ прост — внедрить специализированный инструмент. Но на практике компании сталкиваются с барьерами, которые чаще всего оказываются не техническими, а организационными.
Константин АнисимовЗаместитель генерального директора Astra Cloud
Главные барьеры преимущественно организационные, а не технические. Речь идет о разобщенности команд безопасности и разработчиков, завышенных ожиданиях быстрой окупаемости вложений и недооценке времени на настройку политик (в реальности это не менее 4–6 недель). Единая платформа выгодна при работе сразу в нескольких облаках, желании сократить разрастание инструментария и при зрелых процессах службы безопасности. Точечные решения оправданы при уже сделанных инвестициях, узкой специализации или жестких требованиях интеграции с унаследованными системами.
Есть еще один подводный камень, о котором многие узнают только после первого инцидента — разделение ответственности между компанией и облачным провайдером. На первый взгляд кажется, что если данные хранятся у AWS или Azure, то провайдер и отвечает за их безопасность. Провайдер отвечает за то, чтобы сами серверы физически работали, не ломались и были защищены на уровне железа. А вот за то, кто и как настроил доступ к вашим данным, кто выдал лишние права сотруднику, кто случайно открыл папку с документами для всего интернета — отвечаете вы сами.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
Главным барьером для внедрения таких платформ на сегодняшний день является даже не бюджет, а исторически сложившийся «зоопарк» из разрозненных инструментов и дефицит кадров, способных работать с облачной спецификой. Переход на единую платформу оправдан, когда инфраструктура разрастается до десятков кластеров Kubernetes и сотен микросервисов: в этой точке управлять каскадом из отдельных CSPM и CWPP становится крайне сложно и требования к человеческим ресурсам возрастаютв геометрической прогрессии. Если же у вас три виртуальные машины и один кластер, то использование тяжеловесного CNAPP будет избыточным и неоправданным: на внедрение, поддержку и управление уйдет больше сил, чем будет профита.
CSPM — это инструмент, который постоянно проверяет настройки вашего облака и сравнивает их с принятыми стандартами безопасности. Он подключается к облаку через официальный интерфейс и не требует установки каких-либо программ на серверы — просто смотрит на конфигурацию снаружи и сразу видит проблемы. Типичные находки: папки с данными, случайно открытые для всего интернета; порты, через которые может зайти кто угодно; отключенная двухфакторная аутентификация у администраторов. Все это — классические ошибки, которые случаются не от злого умысла, а просто по невнимательности. CWPP работает принципиально иначе — он не смотрит на настройки снаружи, а наблюдает за тем, что происходит внутри ваших систем прямо сейчас. Он видит, какие программы запускаются, какие соединения устанавливаются, какие файлы открываются. Если контейнер, который должен просто раздавать страницы сайта, вдруг начинает скачивать сторонние файлы и выполнять незнакомые команды — это сигнал тревоги. Возникает закономерный вопрос: нужно ли устанавливать агент в каждую систему или достаточно смотреть на все снаружи через API?
Константин Анисимов
Заместитель генерального директора Astra Cloud
Это ложная дилемма. Безагентный подход (через облачные интерфейсы и моментальные снимки) обеспечивает мгновенный охват, но видит лишь статическую картину — образы, конфигурации, известные уязвимости. Для защиты в среде исполнения нужен агент или низкоуровневый сенсор ядра. Только он покажет реальное поведение процесса в контейнере, аномалии в памяти и попытки горизонтального перемещения по инфраструктуре. Для бессерверных вычислений безагентного подхода достаточно при сканировании кода функций. Однако более глубокий анализ требует интеграции с журналами аудита облачной платформы.
Большинство современных платформ не заставляют выбирать между скоростью и глубиной — они предлагают комбинированный подход. Сначала быстро подключиться без установки агентов и за несколько часов увидеть общую картину по всей инфраструктуре: где дыры, где лишние права, где данные лежат в открытом доступе. Это уже дает огромную ценность, особенно если раньше никакого мониторинга не было вообще. Затем, там, где нужна более глубокая защита — например, в системах с финансовыми данными или в ключевых сервисах — точечно добавляют агента, который следит за происходящим в реальном времени. Отдельная история — бессерверные функции, когда код просто запускается в облаке по требованию и сразу же гасится. Там агентов установить не получится в принципе. Поэтому в таких средах смотрят на настройки доступа и журналы событий, которые автоматически ведет сам провайдер.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
Рынок явно движется в сторону безагентных подходов через сканирование снимков дисков и API. Это дает мониторинг без излишней нагрузки на производительность и «конфликтов» с разработчиками. Однако для полноценной рантайм-защиты и блокировки атак в реальном времени агенты (или их современные инкарнации вроде eBPF) все еще необходимы. В бессерверной архитектуре выбора практически нет — там мы ограничены тем, что дает провайдер, поэтому упор делается на анализ конфигураций и прав доступа
CNAPP объединяет CSPM и CWPP в одну платформу с общим графом рисков. Ценность — в корреляции: уязвимая машина с открытым SSH и подозрительным трафиком — не три разных алерта в трех консолях, а единый критический путь атаки. Attack Path Analysis сводит тысячи алертов к пяти-десяти реальным векторам. В мультиоблачных средах CNAPP берет на себя роль абстрактного слоя, транслирующего единые политики CIS/NIST во все подключенные облака и нормализующего различия в моделях IAM.
Константин Анисимов
Заместитель генерального директора Astra Cloud
Зрелые платформы CNAPP транслируют единый набор политик (по стандартам CIS, NIST) во все облачные среды и нормализуют различия в моделях управления доступом разных провайдеров. Ключевая проблема кроется в семантическом расхождении. Группы безопасности у разных провайдеров ведут себя по-разному, и формальное соответствие требованиям может создавать ложное чувство защищенности. Необходимы регулярная кросс-облачная корреляция рисков и проверка того, что согласованность политик работает в реальной среде исполнения, а не только на бумаге.
Семантическое расхождение — ключевая ловушка мультиоблачной безопасности. Группа безопасности AWS EC2 и Network Security Group Azure выполняют схожую функцию, но работают по разным правилам. Формальное «compliant» в консоли CNAPP может скрывать принципиально разные фактические конфигурации. Компании, добивающиеся реальной согласованности, инвестируют в экспертизу по каждому провайдеру параллельно с платформой.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
Обеспечить абсолютно идентичную политику безопасности в AWS, Azure и GCP невозможно, если пытаться копировать настройки один в один. Даже разница в архитектуре IAM у них слишком велика. Реально достичь только верхнеуровневого соответствия, используя абстракции, которые предоставляют внешние решения. На практике всё равно нужно будет писать специфичные правила под каждое облако, просто управлять ими станет удобнее централизованно.
Есть простое правило: чем раньше нашел проблему — тем меньше она стоит. Если разработчик допустил ошибку в настройках и ее поймали до того, как код ушел на рабочие серверы — это пять минут и одна исправленная строка. Если та же ошибка обнаружилась уже в работающей системе — сервис останавливают. Именно поэтому проверки безопасности перестают быть отдельным этапом в конце и встраиваются прямо в процесс разработки. Система автоматически проверяет каждое обновление кода еще до того, как оно попадает на рабочие серверы. Если находит проблему — останавливает процесс и сообщает об этом прямо в том инструменте, где разработчик работает. Не нужно ждать письма от службы безопасности и разбираться в чужих отчетах — все видно сразу.
Константин Анисимов
Заместитель генерального директора Astra Cloud
Принцип ранней «встройки» безопасности в процесс разработки меняет сам характер отношений. Таким образом, служба безопасности перестает быть «привратником на финише» и становится поставщиком инструментов для команд разработки. На практике это болезненный переход — специалисты по безопасности теряют монополию на решения, разработчики получают новую ответственность за уязвимости. Компании, вовлекающие разработчиков в выбор платформы с самого начала, добиваются значительно более высокого уровня внедрения и совместно согласованных показателей эффективности.
Этот переход дается непросто. Команда безопасности годами работала по одной схеме: разработчики делают продукт, безопасность проверяет его перед выходом и говорит, что можно исправить. Теперь эта схема ломается. Специалисты по безопасности перестают быть последней инстанцией и становятся теми, кто настраивает инструменты, пишет правила и помогает разработчикам не допускать ошибок с самого начала. Разработчики, в свою очередь, получают новую ответственность — следить за безопасностью своего кода, а не перекладывать это на отдельную команду. На первых порах это замедляет работу и вызывает трения: одни чувствуют, что теряют контроль, другие — что получили лишнюю нагрузку. Но компании, которые прошли этот переход, в итоге работают быстрее — потому что проблемы решаются там и тогда, где они возникают, а не накапливаются до релиза.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
Интеграция внутрь конвейера фундаментально меняет роль ИБ: из «постфактум аудита» они превращаются в поставщиков сервиса. На первых порах это всегда вызывает недопонимание между командами, так как пайплайны и TTM замедляются. Но в зрелых компаниях это приводит к тому, что DevOps начинают упреждающе исправлять ошибки на ранних стадиях, а SecOps фокусируются на сложных векторах атак, а не на рутинных проверках и запусках сканеров образов или линтеров.
Когда инцидент уже произошел, скорость расследования определяет масштаб ущерба. CNAPP силен на этапе первичной сортировки: граф атаки связывает IAM-активность, конфигурации, уязвимости и поведение рабочих нагрузок в единую цепочку. Аналитик видит не изолированный алерт, а полный путь — через какой сервис вошли, какую роль использовали, к каким ресурсам получили доступ. Именно такой контекст необходим для быстрой атрибуции при целевых атаках.
Константин Анисимов
Заместитель генерального директора Astra Cloud
CNAPP силен на этапе первичной сортировки инцидента. Граф атаки с корреляцией данных об учетных записях, конфигурациях и рабочих нагрузках дает контекст, недостижимый для разрозненных инструментов. В 2025 году число целевых атак на облачную инфраструктуру со стороны государственно-аффилированных группировок выросло на 266% год к году — именно здесь платформа незаменима для быстрой атрибуции. Но есть ограничения в глубине криминалистического анализа. CNAPP не заменяет защиту конечных точек для анализа памяти хоста и не обеспечивает полный перехват сетевых пакетов. Это лишь карта атаки, не полный инструментарий расследования. Тогда как полноценное реагирование на инциденты требует интеграции с системами мониторинга событий и автоматизации ответных действий.
Там, где CNAPP заканчивается, начинаются специализированные инструменты. Для анализа памяти хоста нужен EDR, для захвата сетевых пакетов — NDR, для корреляции событий из всей инфраструктуры — SIEM. CNAPP в этой связке выступает «картой» расследования: он показывает, где искать, но не объяснит, что именно произошло на уровне системных вызовов.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
CNAPP бесценен при расследовании тем, что он может связать сущности: например, показывает, как через открытый порт и уязвимое веб-приложение злоумышленник добрался до роли с доступом к бакету. Но его возможности заканчиваются там, где начинаются глубокие системные вызовы внутри ОС или специфичный сетевой трафик, не проходящий через облачные шлюзы. Для таких вещей всё равно нужны классические EDR, SIEM и иной мониторинг инфраструктуры
ИИ в продуктах облачной безопасности — одна из наиболее гипертрофированных маркетингом тем. Реальная польза есть в нескольких конкретных областях: обнаружение аномалий в поведении рабочих нагрузок на основе ML; автоматическая приоритизация рисков — сведение тысяч алертов к десятку критических путей с учетом контекста; классификация чувствительных данных. Новый вектор — безопасность самих ИИ-систем в облаке: ML-модели, векторные базы данных и AI-агенты создают отдельный класс рисков, который платформы только начинают закрывать.
Константин Анисимов
Заместитель генерального директора Astra Cloud
Реально работает в случаях обнаружения аномалий в поведении рабочих нагрузок на основе машинного обучения, автоматической приоритизации рисков (тысячи оповещений сводятся к десятку критических путей атаки), классификации чувствительных данных в модуле управления их защитой. Также, вполне осуществима задача обеспечения видимости и управления правами доступа для развертываемых в облаке средств ИИ, как нового вектора атаки. Пока что остается маркетингом: «автоматическое устранение угроз с помощью ИИ» зачастую означает шаблонные рекомендации без учета контекста конкретной среды; генерация политик через запросы на естественном языке нестабильна в промышленной эксплуатации.
Что пока остается преувеличением: обещания полностью автономного устранения угроз без участия человека, генерация политик через запросы на естественном языке с промышленной надежностью, «предсказание атак до их начала». Доверять ИИ автоматическую перенастройку критических систем — прав доступа, сетевых политик — в production пока рискованно для любой реальной организации.
Артём Бруданин
Руководитель отдела кибербезопасности RTM Group
Искусственный интеллект уже сегодня реально помогает в приоритизации рисков и фильтрации информационного шума — он неплохо понимает, какая из тысячи уязвимостей действительно критична в данном контексте. Всё остальное, вроде «автоматического исправления кода» или «предсказания атак», пока остается маркетингом. И доверять ИИ автоматическую перенастройку архитектуры (например, прав доступа) в продакшене сейчас не рискнет ни один вменяемый специалист.
CSPM, CWPP и CNAPP — не конкурирующие решения, а уровни зрелости. CSPM логично начинать раньше всего: он не требует агентов, а первую критическую мисконфигурацию нередко обнаруживает за часы. CWPP добавляется, когда статической картины конфигурации перестает хватать. CNAPP как платформа оправдана при мультиоблачной среде и десятках кластеров — для трех виртуальных машин overhead превысит пользу.
Три вещи, которые влияют на успех больше, чем выбор вендора: реалистичные сроки внедрения, участие разработчиков с первого дня и критический взгляд на AI-обещания. Облачная безопасность — не проект с датой завершения, а непрерывный процесс. Инструменты работают ровно настолько, насколько команда умеет с ними работать.
Атаки на системы искусственного интеллекта смещаются с уровня кода на уровень данных.
Бурное внедрение нейросетей в бизнес-процессы породило не только новые возможности, но и специфические угрозы: от галлюцинаций и утечек обучающих выборок до жестких требований EU AI Act.
47% экспертов, представляющих руководство средних и крупных компаний, считают атаки с целью вымогательства главным риском своей информационной безопасности в 2025 году.
Корпоративные VPN перестают быть технической «данностью» и переходят в категорию регулируемых сетевых сервисов.
Вельц Сергей Владимирович - технический директор, соучредитель ООО "КБ ТехноСкор" специально для читателей Кибер Медиа рассказывает, как банку автоматизировать комплаенс-контроль, отказаться от рутины и превратить управление рисками из угадывания в точный расчет с помощью AI-агентов.
В 2026 году ландшафт цифровых коммуникаций претерпевает серьезные изменения: на фоне локальных сбоев связи, инфраструктурных ограничений и растущей потребности в автономности пользователи массово переходят на альтернативные способы общения.
Количество кибератак растет, а вместе с ними — и бюджеты на информационную безопасность.
Принцип security by obscurity знаком каждому, кто хоть немного погружен в кибербезопасность.
Категорирование объектов критической информационной инфраструктуры в 2026 году обрело новые контуры.
Современная атака может не оставить ни одного файла на диске — и при этом полностью скомпрометировать инфраструктуру.
