Облачная безопасность: что должен знать CISO при переходе в публичное облако

Почему on-premises подходы не обеспечивают безопасность в облаке

В on‑premises защита традиционно начинается с двух ключевых направлений: контроля сетевых соединений (межсетевые экраны, VPN, IDS/IPS) и защиты конечных точек (антивирусы, агентские и сетевые сканеры уязвимостей). Оба направления рассчитаны на стабильную среду с предсказуемым составом активов, редкими изменениями и понятной сетевой топологией.

При переходе в облако компании часто пытаются перенести привычные инструменты безопасности «как есть» (lift and shift), но эта стратегия не работает: облачная инфраструктура устроена принципиально иначе. Сравним две среды по параметрам, которые определяют, где возникают новые риски и почему привычные процессы требуют пересмотра.

Кто отвечает за безопасность в облаке: модель разделения ответственности

Самое опасное заблуждение на старте работы в публичном облаке: «мы платим провайдеру — значит, безопасность больше не наша забота». Это миф: провайдер отвечает за безопасность только своей части инфраструктуры.

Провайдер (Cloud.ru, Yandex Cloud и другие) действительно берёт часть задач на себя: в модели IaaS — физическую инфраструктуру, сеть и платформу виртуализации. Но всё, что внутри облака — данные, доступы, конфигурации, безопасность приложений, — остаётся на стороне пользователя.

Граница ответственности не фиксирована: она смещается в зависимости от модели предоставления облачных услуг — IaaS, PaaS или SaaS.

Что делать

1. Определите свою зону ответственности. Хотя общая концепция разделения ответственности едина, детали различаются в зависимости от провайдера и сервиса. Уточните у вашего поставщика, какие ресурсы и настройки остаются на вашей стороне. Это устранит слепые зоны в облаке — участки инфраструктуры, которыми не занимаетесь ни вы, ни провайдер.
2. Донесите границы ответственности до технических команд. Разработчики и DevOps-инженеры должны понимать, где нельзя рассчитывать на провайдера. Провайдер обеспечивает доступность хранилища, но не исправит ошибочную политику бакета, разрешающую публичный доступ; обновляет гипервизор, но не ОС и ПО на виртуальной машине; патчит управляемую СУБД, но сетевой доступ, учётные записи и шифрование настраивает пользователь. Зафиксируйте правила в стандартах и чек-листах.
3. Обеспечьте безопасность в вашей зоне ответственности. Cloud Advisor — #1 CNAPP в России — контролирует конфигурацию облака и IAM, ищет уязвимости, вредоносное ПО и секреты в открытом виде, обеспечивает комплексную защиту виртуальных машин, контейнеров и кластеров Kubernetes.

Высокая изменчивость облачной среды

В IaaS классические задачи ИБ никуда не исчезают: управление уязвимостями, антивирусная защита, контроль безопасной конфигурации ОС и ПО на хостах (например, соответствие бенчмаркам CIS: отсутствие лишних сервисов, безопасные параметры SSH, корректные права на файлы, отключённые устаревшие протоколы и т. д.) по-прежнему остаются на стороне пользователя. Однако прежний способ их решения — установка агента на каждый хост или заведение локальной SSH-записи для сканера — в облаке не работает. Инфраструктура меняется так быстро, что ИТ-команда не успевает устанавливать агенты и поддерживать доступ ко всем виртуальным машинам: часть ресурсов неизбежно остаётся без покрытия. Рассмотрим факторы, которые создают эту динамику:

• Самообслуживание. Доступ к облаку есть у многих сотрудников с разным уровнем компетенций в ИБ. Задача инженера — быстро создать ресурс для своего проекта. Безопасная настройка не входит ни в его приоритеты, ни в его зону экспертизы, а участие ИБ в процессе часто не предусмотрено.
• Частый деплой. Регулярные релизы означают короткий жизненный цикл активов и постоянные изменения инфраструктуры.
• Автоматизация. Многие процессы в облаке осуществляются не вручную, а автоматически. Например, IaC и AutoScaling многократно увеличивают скорость и масштаб изменений.

В результате в облаке появляются ресурсы без установленных на них средств защиты. По данным Cloud Advisor, 83% виртуальных машин имеют уязвимости с оценкой CVSS выше 9,0 — во многом это следствие низкого покрытия традиционными агентскими и сетевыми сканерами.

Что делать

Выбирайте нативные решения для облачной безопасности. Публичное облако даёт две важные новые возможности, которых нет в on-premises. Первая — получение по API провайдера полной информации обо всех ресурсах и их конфигурации: ВМ, хранилища, управляемые базы данных, сетевые настройки, права доступа, группы безопасности и многое другое. Вторая — технология создания снапшотов, которая позволяет проводить анализ безопасности ВМ по её снимку, без установки агентов и подключения к самой машине. Использование этих возможностей позволяет решать задачи, с которыми агентские и сетевые сканеры справляются с трудом.

Ведущие CNAPP-платформы, включая Cloud Advisor, защищают виртуальные машины без агентов. Они сканируют снапшоты (снимки) дисков, созданные через API провайдера. Это даёт три главных преимущества:

1. Мгновенное масштабирование и 100% охват. При подключении к облаку решение через API провайдера инвентаризирует все существующие ресурсы и сканирует ВМ. Новые ресурсы обнаруживаются и сканируются автоматически сразу после появления в инфраструктуре. Так обеспечивается и поддерживается 100% покрытие облачной инфраструктуры без дополнительных трудозатрат.
2. Нулевое влияние на продуктивную среду. Сканируется изолированная копия данных: ресурсы (CPU/RAM) продуктивных систем не расходуются, не замедляя работу приложений.
3. Низкая стоимость владения (TCO). Не нужно устанавливать, обновлять и поддерживать сотни агентов, заводить SSH-записи и обеспечивать их сетевую связность.

Новый слой управления — новые риски

Ключевое отличие облака от on-premises — появление нового критического слоя управления: конфигурации облака. Именно здесь определяются публичность ресурсов и права доступа (IAM). Контроль этого слоя полностью лежит на пользователе.

Ошибки в настройке облачных сервисов — например, случайно открытый публичный доступ к хранилищу или слишком широкие правила групп безопасности — открывают атакующему прямой путь в инфраструктуру.

Традиционные инструменты не анализируют конфигурацию облака и связи между ресурсами. Например, SIEM/SOC, в который отправляют логи облака (из сервисов Audit Trails или Cloud Trace Service), часто считают достаточным средством контроля облака, но он работает только с событиями и может зафиксировать лишь факт изменения в инфраструктуре. При этом он не знает текущего состояния: какие настройки действуют сейчас, какие ресурсы доступны из интернета, какие права есть у служебного (сервисного) аккаунта. Он не оценивает настройки на соответствие лучшим практикам и бенчмаркам провайдера, не видит взаимосвязей между ресурсами, а ошибки, допущенные до подключения аудит-логов, для него не существуют вовсе.

Ручной контроль тоже невозможен, так как настройки меняются ежедневно.

Результат закономерен: по данным Cloud Security Alliance за 2026 год, недостатки в управлении идентификацией и доступом (IAM, Identity and Access Management) вышли на первое место в рейтинге угроз облачной безопасности. Мисконфигурации в облаке также остаются в числе ключевых рисков: в отчёте Cloud Security Alliance за 2025 год, посвящённом разбору реальных инцидентов, ошибки в настройке облачных ресурсов фигурировали в половине проанализированных случаев.

Разберём обе особенности облачной среды подробнее.

Периметр размыт: как контролировать публичность в облаке

В облаке легко открыть публичный доступ к ресурсу. Даже если виртуальная машина стоит за NGFW, разработчик может назначить ей публичный IP, и тогда трафик пойдёт в обход сетевой фильтрации. Некоторые ресурсы (например, объектные хранилища и облачные функции) в принципе нельзя спрятать за межсетевой экран в облаке: доступ к ним определяется настройками конфигурации и правами доступа.

Куда исчез периметр в облаке?

Подпишитесь на рассылку Cloud Advisor и получите детальную схему доступов к ресурсам в публичном облаке, чтобы взять под контроль все точки входа в инфраструктуру.

Получить

Я даю согласие на получение информационной и рекламной рассылки

Закрыть

Что делать

Помимо классической фильтрации трафика с помощью NGFW или Security Groups, необходим постоянный контроль конфигураций облачных ресурсов. Он позволяет определить, какие из них фактически доступны из интернета с учётом публичных IP, правил групп безопасности и настроек прав доступа. Эту задачу решают платформы класса CSPM (Cloud Security Posture Management): они отслеживают изменения в настройках облачной среды, уведомляют о рисках безопасности и дают рекомендации по их устранению.

IAM — новый периметр

В облаке инфраструктурой — ресурсами, сетью, правами доступа — управляют через публичный API и консоль провайдера. Кто и какие операции может выполнять, определяет сервис IAM (Identity and Access Management). Злоумышленник с действующими учётными данными получает ровно те права, что назначены учётной записи, а его вход выглядит легитимным: сетевые средства защиты не распознают в нём атаку. Поэтому IAM становится главным рубежом безопасности облачной инфраструктуры.

IAM (Identity and Access Management) — это центральная система управления доступом к облаку. Она определяет, кто (пользователь, сервис или программа) и к каким ресурсам (виртуальным машинам, базам данных, хранилищам) имеет право обращаться и какие действия выполнять.

Управлять приходится не только людьми. Рабочие нагрузки (виртуальные машины, контейнеры, облачные функции) получают права через служебные (сервисные) аккаунты и роли. Многофакторная аутентификация для них не применима.

Автоматизация добавляет ещё один класс идентификаторов — ключи и токены доступа к API (Access Keys). Их используют CI/CD-конвейеры, IaC-инструменты, скрипты и интеграции между сервисами. Чем больше автоматизации, тем больше таких секретов: каждой интеграции нужны свои учётные данные. Они распределены по всей инфраструктуре — в конфигурационных файлах, переменных окружения, репозиториях, на дисках виртуальных машин и т. д. — и нередко попадают в открытый доступ.

Утечка одного ключа даёт злоумышленнику доступ к облаку с правами вплоть до административных в обход всех сетевых средств защиты.

Что делать

• Регулярно аудируйте роли и политики IAM, удаляйте неактивные учётные записи, соблюдайте принцип наименьших привилегий.
• Используйте федерацию удостоверений для всех пользователей — это упрощает отзыв доступов при увольнениях.
• Внедрите MFA для всех пользовательских учётных записей.
• Ограничивайте права служебных (сервисных) аккаунтов и ролей.
• Настройте регулярную ротацию ключей доступа.
• Внедрите автоматический поиск секретов в открытом виде.
• Ограничьте доступ к консоли управления доверенными IP-адресами.

Cloud Advisor помогает реализовать эти меры комплексно: обеспечивает непрерывный контроль IAM, даёт рекомендации по соблюдению лучших практик и автоматически находит секреты (ключи, токены, пароли), хранящиеся в открытом виде на виртуальных машинах и в контейнерах. Это позволяет обнаружить и устранить риски, связанные с недостатками в управлении IAM, до того, как ими воспользуется злоумышленник.

Взаимосвязь компонентов и пути атаки

В on-premises компоненты инфраструктуры были относительно статичны и изолированы. В облаке всё взаимосвязано: виртуальные машины, контейнеры, облачные функции, базы данных, хранилища, управляемые сервисы, группы безопасности, пользователи, роли. Один скомпрометированный ресурс может стать точкой входа во всю инфраструктуру через боковое перемещение (lateral movement) — тактику, при которой атакующий последовательно продвигается по смежным системам к критичным ресурсам.

Что делать

Необходим полный контекст облачной среды. Его даёт решение класса CNAPP — единая платформа облачной безопасности. CNAPP обладает полной картиной рисков в публичном облаке, отслеживает сложные зависимости между ресурсами, выявляет критические угрозы и помогает ИБ-команде фокусироваться на том, что требует первоочередного устранения.

CNAPP: защита, созданная для облака

CNAPP (Cloud-Native Application Protection Platform) — класс решений, который объединяет контроль конфигурации облака, управление доступами, безопасность Kubernetes, защиту рабочих нагрузок и vulnerability management в облаке в единой платформе. Единый контекст отличает CNAPP от набора разрозненных инструментов: платформа сопоставляет выявленные риски и находит реальные пути атаки.

Облако — это новая среда с другой моделью управления и другой скоростью изменений. Защита облака должна учитывать все эти особенности. Именно такое решение — Cloud Advisor, #1 CNAPP в России.

Что даёт Cloud Advisor:

• Безопасность в зоне ответственности пользователя — от конфигурации облака и прав доступа в IAM до виртуальных машин, контейнеров и кластеров Kubernetes.
• Полное покрытие без агентов. Подключение за минуты и инвентаризация всех облачных ресурсов с автоматическим обнаружением и сканированием новых активов сразу после их появления в инфраструктуре. Без затрат на поддержание покрытия.
• Защита от специфических облачных угроз. Непрерывный контроль конфигурации облака и IAM — ошибки в них чаще всего приводят к инцидентам в публичном облаке.
• Анализ контекста. Платформа находит токсичные комбинации рисков и строит критические пути атаки. Вместо тысячи алертов ИБ-команда получает короткий список угроз, требующих первоочередного устранения.

У 88% компаний Cloud Advisor обнаружил на периметре уязвимости с показателем CVSS выше 9,0. Узнайте свою статистику — запишитесь на бесплатный пилот Cloud Advisor.