Защита облака: почему старые подходы не работают?

Защита облака: почему старые подходы не работают?

В облаке ресурсы появляются и исчезают за минуты, классического сетевого периметра нет, а доступ к управлению инфраструктурой регулирует сервис IAM с публичным интерфейсом. Традиционные инструменты безопасности оказываются бессильны в такой среде. Как же выстраивать защиту инфраструктуры в облаке?

image
  1. Динамичная и эфемерная среда вместо статических серверов
  2. Привычного сетевого периметра больше не существует
  3. IAM стал новым периметром безопасности
  4. Нельзя защитить облако, охраняя отдельные виртуальные машины
  5. Защита по облачным правилам: CNAPP-решение Cloud Advisor

Динамичная и эфемерная среда вместо статических серверов

Что изменилось?

On‑premise инфраструктура статична. Её безопасность строится вокруг защиты физического «железа» и фиксированного периметра сети. Серверы и их конфигурации меняются редко и предсказуемо.

В облаке всё иначе. Бизнес ценит его за скорость и гибкость. Однако эти преимущества достигаются ценой создания принципиально новой, динамичной среды. Это палка о двух концах: то, что приносит выгоду бизнесу, усложняет жизнь ИБ.

Главными причинами высокой изменчивости облачной инфраструктуры являются:

  • Система самообслуживания. Ресурсы в облаке могут создаваться разными сотрудниками — DevOps-инженерами, разработчиками, администраторами — как правило, без предварительного согласования с ИБ.
  • Высокая частота изменений. Ресурсы и конфигурации меняются постоянно из-за быстрых и частых развёртываний, которые обновляют продукты и вносят исправления. В результате активы «живут» часы или дни, а не годы.
  • Автоматизация. Ресурсы могут создаваться и управляться автоматически — через код инфраструктуры (IaC) или автомасштабирование. Эта особенность исключает возможность ручного контроля каждого изменения службой безопасности.

Традиционные средства защиты не успевают за появлением новых ресурсов в облаке и отстают от скорости изменений. Это неизбежно приводит к появлению «слепых зон» — активов, которые есть в инфраструктуре, но остаются невидимыми для системы безопасности. По данным Cloud Advisor в среднем 97% виртуальных машин остаются не покрыты такими традиционными инструментами защиты, как антивирус и средства управления уязвимостями.


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

Вывод для CISO

Чтобы защитить облако, безопасность должна двигаться с его скоростью и «говорить на его языке» – уметь работать с API провайдера. Это означает эволюционный переход от традиционных инструментов безопасности к безагентному cloud-native подходу, который обеспечивает 100% покрытие и контроль над динамической инфраструктурой.

Именно такое решение предлагает Cloud Advisor — #1 CNAPP (Cloud-Native Application Protection Platform, платформа для защиты облачной инфраструктуры и приложений) в России. Его безагентная технология DiskScan обеспечивает глубокий анализ безопасности виртуальных машин и контейнеров на скорости облака.

Вот как это работает:

  1. Через API облачного провайдера автоматически создаётся снимок (снапшот) виртуальной машины (ВМ).
  2. Снимок передаётся в изолированный сканер, работающий в периметре пользователя, который проводит: выявление уязвимостей ПО, поиск вредоносного кода, аудит конфигурации ОС, обнаружение секретов (ключей, паролей) в открытом виде и другие проверки. На производительность рабочей ВМ этот процесс не влияет.
  3. После завершения анализа снимок диска удаляется.

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

Привычного сетевого периметра больше не существует

Что изменилось?

В on-premise безопасность строилась на защите сетевого периметра. Критичные данные находились в корпоративной сети за межсетевыми экранами и VPN. Вся инфраструктура — «внутри».

Периметр on-premise инфраструктуры

В облаке привычного сетевого периметра больше не существует. Теперь только NGFW или групп безопасности недостаточно — необходимо дополнительно контролировать ещё и конфигурацию ресурсов.

Почему ваш проверенный и надежный NGFW не может обеспечить 100% защиту от несанкционированного доступа в облачной инфраструктуре?

  1. Не всё можно «спрятать» за NGFW. Существуют ресурсы, которые технически невозможно поместить за межсетевой экран. К ним относятся объектные хранилища (S3-бакеты), облачные функции, снимки дисков, ключи шифрования и другие ресурсы. Их безопасность зависит исключительно от конфигурации облака, а не от правил сетевой фильтрации.
  2. Появление «теневого» периметра. IT-специалист с соответствующими правами может в любой момент создать публичный IP-адрес и назначить его виртуальной машине. В этом случае её трафик пойдёт напрямую в интернет, минуя настроенный вами NGFW.
  3. Публикация PaaS-сервисов. Для ресурсов вроде управляемых баз данных или контейнеров публичный доступ часто включается одной опцией в настройках. Активация этой галочки мгновенно выводит внутренний ресурс на внешний периметр в обход корпоративных файрволов.


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


Подробнее о том, как изменится периметр при переходе в публичное облако, и почему NGFW недостаточно для его защиты, читайте в блоге Cloud Advisor.

NGFW не может полноценно обеспечить защиту в таких условиях – необходим непрерывный контроль конфигурации облака. Только он позволяет выявить опасные настройки доступов, несогласованные публичные IP-адреса и ресурсы, нарушающие политики ИБ.

Вывод для CISO

Традиционный подход к защите периметра только с помощью NGFW больше не работает. Необходима комбинация двух инструментов:

  • Сетевой фильтрации – через NGFW или встроенные группы безопасности провайдера.
  • Контроля конфигураций с помощью отдельного инструмента для управления состоянием безопасности облака – CSPM (Cloud Security Posture Management), или платформы для защиты облачной инфраструктуры и приложений CNAPP (Cloud-Native Application Protection Platform), в которую этот инструмент интегрирован.

Cloud Advisor решает задачу контроля конфигурации облака, непрерывно анализируя настройки вашей инфраструктуры для выявления публично доступных ресурсов. Для этого платформа:

  • Обнаруживает такие проблемы, как случайно открытый публичный доступ к ресурсам (включая бакеты объектного хранилища, БД и пр.), некорректно настроенный доступ по SSH/RDP.
  • Анализирует сетевую связность: проверяет всю цепочку соединений, включая балансировщики нагрузки и NAT, что позволяет выявлять неочевидную (опосредованную) публичность ресурсов, не имеющих прямого публичного IP-адреса.
  • Контролирует группы безопасности, выявляя слишком широкие правила сетевой фильтрации.

Эти меры позволяют не только предупреждать об опасных настройках, но также сформировать и поддерживать в актуальном состоянии каталог ресурсов, обладающих реальной публичной доступностью — ВМ, баз данных, бакетов, Kubernetes кластеров, облачных функций и других сервисов.

Это даёт командам ИБ мгновенную картину реальных рисков, связанных с периметром, экономя часы на ручном анализе доступности ресурсов.

IAM стал новым периметром безопасности

Что изменилось?

IAM (Identity and Access Management) – это сервис, через который проходит каждая команда управления инфраструктурой. Если рассматривать веб-консоль и API провайдера как пульт управления, то IAM — это главный «контроллёр доступа» к этому пульту, который на основе назначенных администраторами прав и ролей определяет, запретить или разрешить конкретную команду. И именно с IAM связана ещё одна из угроз, которую не способен устранить NGFW.

Дело в том, что веб-консоль и API провайдера доступны из любой точки мира — они работают на стороне провайдера, за пределами защищаемой инфраструктуры клиента. Если злоумышленник завладел ключами доступа, он получает контроль над инфраструктурой в рамках соответствующих прав. В этом случае NGFW оказывается неэффективным: он предназначен для фильтрации трафика, идущего к инфраструктуре клиента, тогда как злоумышленник использует легальные механизмы управления провайдера (API и консоль). Это тоже атака извне, но направленная не на рабочие нагрузки, а на слой управления облаком, а этот канал NGFW попросту не контролирует.

Связанные с IAM инциденты занимают второе место в рейтинге угроз облачной инфраструктуре по версии Cloud Security Alliance.

Контроль IAM становится ключевой задачей защиты. Анализа событий, которые хранятся в логах облачного провайдера (например, Cloud.ru Cloud Trace Service или Yandex Audit Trail) и содержат совершенные в прошлом действия, уже недостаточно. В облачном IAM необходимо проактивно выстраивать строгие политики, определяющие, кто, откуда и какие операции может выполнять.

Кроме того, управление доступом в облаке оказывается гораздо сложнее, чем в on-premise, из-за специфики самой среды:

  1. API-центричное управление. В отличие от on-premise, где управление инфраструктурой, как правило, ведётся из внутренней сети, в облаке любое действие — вплоть до удаления виртуальных машин и баз данных — выполняется через публично доступный API провайдера. Как было сказано выше, этот канал управления находится вне зоны контроля пользовательского NGFW, поэтому качество настройки IAM-политик и защищенность ключей доступа становятся критичными факторами безопасности.
  2. Права есть не только у пользователей. В облаке учетные записи имеют не только сотрудники, но и рабочие нагрузки (виртуальные машины, контейнеры, функции) и их число может достигать тысяч.
  3. Отсутствие MFA для API. Доступ автоматизированных учетных записей (например, сервисных аккаунтов) осуществляется программно по ключам, без второго фактора защиты. Утечка ключа = мгновенный доступ.
  4. Хаос с ключами. Секреты (API-токены, AK/SK и другие) часто хранятся в исходном коде, конфигурационных файлах или переменных окружения как на локальных ПК, так и на серверах, создавая тысячи потенциальных точек утечки.

Пример из жизни

Сотрудник создаёт учётную запись для работы с API и создает для неё ключи доступа (Access Key/Secret Key). Он сохраняет их на рабочем ноутбуке — например, в конфигурационном файле проекта или папке «Загрузки».

Затем ключи утекают, например:
— через вредоносное ПО (установленный из интернета кейген с «трояном» передал ключи злоумышленникам);
— через публичный код (разработчик забыл ключи в репозитории на GitHub, где их нашли злоумышленники при сканировании).

Получив ключи, злоумышленник подключается к API облачного провайдера из любой точки мира и получает все права, привязанные к учетной записи, для которой был создан ключ. Сетевые экраны (NGFW) и группы безопасности бессильны, так как атака идёт не через ваш периметр, а через API облачного провайдера.

Таким образом, в облачной среде IAM становится критически важным участком безопасности. А так как отслеживать этот «зоопарк» прав и ключей вручную невозможно, необходим автоматизированный контроль.

Вывод для CISO

Нужен инструмент, который решит все связанные с IAM вопросы комплексно. Таким решением являются платформы класса CNAPP. Например, Cloud Advisor предлагает следующие возможности:

  • Проверяет соблюдение принципа наименьших привилегий: выявляет избыточные права, неиспользуемые разрешения и чрезмерно широкие роли, помогая сократить поверхность атаки.
  • Контролирует соблюдение лучших практик IAM: проверяет наличие MFA, выявляет долгоживущие/неротируемые ключи доступа, а также локальных (не федеративных) пользователей и неактивные учётные записи.
  • Находит секреты в открытом виде на ВМ и в контейнерах.
  • Приоритизирует угрозы с учётом контекста: сопоставляет риски IAM с уязвимостями, публичной доступностью и другими факторами. Это помогает не просто перечислить угрозы, а оценить их реальную опасность. Например, уязвимость на публично доступной виртуальной машине с привилегированными правами доступа к базе данных будет признана критической, тогда как та же уязвимость на изолированной ВМ без особых прав получит средний или низкий приоритет.

Рекомендация

  • Применяйте IAM Access Control Lists (ACL) для ограничения доступа к консоли управления и API по IP-адресам, если такую возможность предоставляет провайдер. Это фактически фаерволл для доступа к облаку, который блокирует злоумышленников, даже если они получили учётные данные, не требующие второго фактора.
  • Контролируйте пользователей, которые могут создавать учётные записи для работы через API (например, сервисные аккаунты) или генерировать ключи AK/SK и регулярно проводите их аудит.

Нельзя защитить облако, охраняя отдельные виртуальные машины

Что изменилось?

В on-premise работала тактика «защищай каждый хост». Инструменты оценивали риски изолированно: сканер уязвимостей — старое ПО на хосте, NGFW — подозрительный сетевой трафик. Риск был линейным.

В облаке все взаимосвязи усиливаются, риск происходит из контекста. Уязвимость на изолированной виртуальной машине — лишь потенциальная проблема. Эта же уязвимость на публично доступной виртуальной машине — уже прямая угроза. А если на этой машине также хранится ключ доступа от бакета S3 с данными пользователей, это критический риск, который требует немедленного вмешательства.

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

Вывод для CISO

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

CNAPP-платформа Cloud Advisor делает это автоматически:

  • Строит единый граф: объединяет данные об уязвимостях, правах, секретах и сети в одну модель и выявляет токсичные комбинации угроз.

  • Помогает фокусироваться на главном: отсекает шум, позволяя сосредоточиться на критическом 1% угроз, который влияет на 90% безопасности вашего облака.

Защита по облачным правилам: CNAPP-решение Cloud Advisor

Cloud Advisor — первое в России решение класса CNAPP (Cloud-Native Application Protection Platform). В отличие от разрозненных сканеров и агентов, платформа обеспечивает защиту облака комплексно: от управления уязвимостями до контроля IAM и конфигурации облака.

Cloud Advisor не выдаёт разрозненные алерты, а строит цельную картину рисков. Он анализирует, как уязвимости, права доступа и публичные ресурсы связаны друг с другом, и находит критические пути атаки — цепочки, которыми может воспользоваться злоумышленник. В результате ИБ-специалисты работают с реальными угрозами, а не обрабатывают бесконечные списки оповещений.

Созданный специально для защиты облака, Cloud Advisor учитывает его особенности:

  1. Не отстаёт от темпа изменений в облаке. Мгновенно обнаруживает новые ресурсы и проводит их комплексное сканирование полностью безагентским методом.
  2. Обеспечивает полный контроль периметра в облаке: непрерывно проверяет конфигурацию облака и правила групп безопасности, находит опасные настройки и точно определяет, какие ресурсы доступны извне.
  3. Контролирует IAM и соблюдение лучших практик: проводит глубокий анализ учетных записей и прав доступа, выявляя такие риски, как нарушение принципа наименьших привилегий, наличие пользователей и ролей с опасными привилегиями, локальных пользователей, отсутствие ротации секретов или MFA – десятки проверок, затрагивающих все аспекты безопасности сервиса IAM.
  4. Видит угрозы на всех уровнях облачной инфраструктуры и их взаимосвязи и находит действительно критичные: не просто показывает список уязвимостей и ошибок, а выявляет возможные пути атаки. Это позволяет ИБ-команде не тратить время на ложные алерты, а фокусироваться на устранении реальных угроз, которые могут привести к взлому или утечке.

Хотите получить полный контроль над безопасностью в облачной среде? Оцените возможности Cloud Advisor на практике. Оставьте заявку на демонстрацию и пилотный доступ, и эксперты покажут, как платформа обеспечивает комплексную защиту облачной инфраструктуры.

95%
отсеяно
при отборе
Антипов жжет
Рынок генетического материала.
Высокий, умный, здоровый = дороже.
Почему одна сперма стоит 40 евро, а другая - 20000. И при чем тут Дарвин.