Ровно двадцать лет назад Amazon Web Services (AWS)запустила службуSimple Storage Service (S3). Спустя несколько месяцев сервис Elastic Compute Cloud (EC2) компанииоткрылсядля публичного бета-тестирования, а в 2008 году был официально запущен. Эти события положили начало эре современного облачного хранения и вычислений по требованию, которая изменила подход организаций любого размера к своей ИТ-инфраструктуре.
Перенесемся в настоящее время, и вам будет трудно найти организации, которые не «перенесли» хотя бы часть своих рабочих нагрузок в облако или не планируют сделать это в ближайшее время. Действительно, некоторые из них теперь работают полностью в облаке, в то время как многие другие сочетают облачные рабочие нагрузки, часто в мультиоблачных конфигурациях, с локальными ресурсами, которые не будут выведены из эксплуатации в ближайшее время.
Среди всех общих черт этих организаций одна заслуживает более пристального внимания: разрастание виртуальных машин (ВМ) или неконтролируемый рост числа виртуальных машин, которые часто остаются без присмотра.
Растущая проблема
Поставщики публичных облачных услуг (CSP) по замыслу делают развертывание новых ВМ беспроблемным; в конце концов, это отчасти и делает их предложение таким привлекательным. Как могут подтвердить многие администраторы, новый экземпляр ВМ можно запустить за считанные минуты, но его вывод из эксплуатации редко вызывает такую же срочность.
Во многих компаниях, особенно в тех, где используются мультиоблачные конфигурации с участием AWS, Azure, GCP и/или других CSP, этот разрастающийся хаос приводит к накоплению рабочих нагрузок, которые находятся вне зоны контроля служб безопасности. CSP действительно обеспечивают базовую защиту, но текущая работа ложится на плечи клиента. Машины часто даже не получают обновлений операционной системы; хуже того, они, как правило, не мониторятся и подчиняются политикам доступа, которые не менялись с того дня, когда кто-то создал экземпляр. Это увеличивает риск того, что виртуальная машина «выйдет из-под контроля», оставаясь незамеченной — пока не станет слишком поздно.
Видимость облака как таковая является постоянной проблемой, поскольку только около23 % организацийсообщают, что имеют полное представление о своем присутствии в облаке. Неконтролируемый рост активов, включая парки виртуальных машин, является значительной частью проблемы. Основные пути атак — неправильно настроенные хранилища и открытые API — доминируют в сообщениях о нарушениях, отчасти потому, что они генерируют сигналы, видимые общественности. Между тем злоупотребление виртуальными машинами происходит более незаметно и внутри среды; запрос управляемой идентичности к облачному хранилищу не вызовет такой же тревоги, как попытка входа с внешнего IP-адреса.
В недавнемотчетеCloud Security Alliance (CSA) неправильная настройка и неадекватный контроль изменений были названы главной угрозой для облачных ресурсов, за которыми следуют слабые места в управлении идентификацией и доступом (IAM). Это соответствует идентификационно-ориентированной природе облачных рабочих нагрузок, где тщательной проверке подлежат как сама виртуальная машина, так и то, к чему она имеет доступ. Согласноотчету Microsoft«Состояние безопасности мультиоблачных сред в 2024 году», идентичности рабочих нагрузок, назначенные виртуальным машинам и другим нечеловеческим ресурсам, значительно превосходят по количеству человеческие идентичности, и этот разрыв только увеличивается по мере того, как организации запускают все больше вычислительных ресурсов.
Реальность довольно прозаична: например, инженер по машинному обучению выделяет виртуальную машину для задач обработки данных. Виртуальной машине присваивается идентификатор, но поскольку определение ее прав в соответствии с принципом минимальных привилегий было бы слишком трудоемким, она получает широкий доступ на чтение и запись к хранилищу данных и другим ресурсам. Проекты завершаются, но виртуальные машины с избыточными правами остаются «на произвол судьбы».
Оставлены гнить
Однако заброшенная виртуальная машина может не только «пылиться». Поскольку каждая виртуальная машина привязана к какой-либо форме идентификации, определяющей, к каким ресурсам рабочей нагрузки она может получить доступ в среде, забытые экземпляры могут быть использованы злоумышленниками для получения первоначального доступа. Поскольку виртуальные машины в одном виртуальном частном облаке (VPC) или виртуальной сети (VNet) часто могут обмениваться данными в направлении «восток-запад» без особых ограничений, виртуальная машина может сканировать соседние экземпляры, достигать внутренних баз данных или конечных точек хранилищ и использовать любые предоставленные ей разрешения. Слишком часто микросегментация сети оказывается слишком сложной задачей.
В гибридных средах сгибридными идентификациями ситуация может еще больше усложниться. Например, когда локальный Active Directory синхронизируется с Entra ID,скомпрометированная виртуальная машинав Azure, присоединенная к арендатору Entra ID, может получить доступ к общим файлам, базам данных, приложениям или другим ресурсам, которые являются частью основной локальной инфраструктуры организации.
Примеры реальных атак с использованием виртуальных машин найти несложно. В ходеодной кампании злоумышленники перемещались между экземплярами AWS EC2 через внутренний протокол удаленного рабочего стола (RDP), разместили сотни гигабайт похищенных данных на нескольких виртуальных машинах и запустили программу-вымогатель внутри облачной сети. Система мониторинга зафиксировала эту активность, но автоматическое реагирование не было настроено должным образом, чтобы остановить ее, и развертывание программы-вымогателя продолжилось.
Другие злоумышленники используют в своих целях ту самую простоту, с которой можно запускать виртуальные машины. Microsoftзафиксировалакампанию, в ходе которой взломанные учетные записи Azure использовались для развертывания кратковременных виртуальных машин в качестве одноразовой инфраструктуры для атак. Поскольку трафик поступал с легитимных IP-адресов, связанных с Azure, предупреждения были отклонены как ложные срабатывания.
Борьба с развертыванием и упадком
Скорее всего, ваши ИТ- и безопасности-команды небольшие и занимаются безопасностью наряду с другими ИТ-обязанностями, что во многом определяет, какие инструменты подходят для работы в таких масштабах. Продукты безопасности, которые полагаются на глубокие знания конкретной платформы, сложные процедуры развертывания и множество инструментов для управления различными частями ИТ-инфраструктуры, могут не подойти. Они могут даже упустить ту часть проблемы разрастания, которая имеет наибольшее значение.
Еще больше запутывает ситуацию вопрос: что происходит, когда инцидент связан со злоупотреблением идентификацией? Злоумышленник на несанкционированной виртуальной машине может не делать ничего подозрительного, если смотреть только изнутри виртуальной машины, когда он использует ее идентификацию для доступа к облачным или локальным ресурсам. Чтобы обнаружить аномалию, необходимо связать то, что происходит на самой виртуальной машине, с тем, что делает идентификация виртуальной машины в более широкой среде. Такая корреляция зависит от интеграции с решениями для управления идентификацией, такими как Entra ID и Active Directory.
Есть также вопрос скорости. Когда скомпрометированная облачная рабочая нагрузка может достичь локальных ресурсов через федеративную цепочку идентификации, промежуток времени между первоначальным взломом и серьезным ущербом может быть коротким. (Автоматическая) изоляция виртуальной машины до начала латерального перемещения должна происходить в любое время суток. Это один из сценариев, в которых корреляция на основе ИИ и обнаружение во время выполнения оправдывают себя — никто не может круглосуточно наблюдать за каждой рабочей нагрузкой и реагировать достаточно быстро.
Успешные вторжения обходятся предприятиям дорого. Согласнонедавнему опросу, каждая третья малая и средняя компания сообщила о наложении на нее значительных штрафов после кибератаки. Это также напоминание о том, что несоблюдение требований может повлечь за собой прямые финансовые последствия. Нормативные рамки, такие как NIST 800-53 и PCI DSS 4.0, становятся все более конкретными в отношении безопасности облачных рабочих нагрузок, и от компаний все чаще ожидается, что они будут обеспечивать надлежащее определение сферы действия идентификационных данных, присвоенных облачным рабочим нагрузкам, и их постоянный мониторинг. Простого демонстрирования средств контроля доступа на серверах, на которых хранятся конфиденциальные данные, недостаточно, если риск заключается в уровне идентификации.
Между тем, отчетIBM «Стоимость утечки данных в 2025 году»показал, что 30 процентов утечек затронули данные, разбросанные по нескольким средам, что свидетельствует о проблемах, с которыми сталкиваются организации при защите своих активов в различных средах. Значительная доля связанных с этим затрат обусловлена временем между проникновением и обнаружением, также известным как «время пребывания». Организации, которые не могут видеть, что происходит внутри их сред, как правило, обнаруживают утечки по «внешним» сигналам, таким как жалоба клиента, к моменту чего злоумышленник уже имеет доступ в течение нескольких недель или месяцев.
Заключительные мысли
Виртуальные машины (ВМ) — один из старейших и наиболее часто развертываемых современных облачных ресурсов. Разрастание ВМ происходит незаметно и часто выявляется только после того, как что-то пошло не так. Незащищенные рабочие нагрузки передают идентификационные данные и взаимодействуют друг с другом, а также с локальными ресурсами, используя схемы трафика, которые не все средства безопасности могут отслеживать и перехватывать.
Для начала каждойорганизации необходимо провести инвентаризациюсвоего парка виртуальных машин на всех облачных платформах, проверить разрешения, привязанные к идентификаторам каждой виртуальной машины, и провести аудит их настроек на предмет ненужной открытости в направлениях «восток-запад» и «север-юг». Как гласит пословица, хорошие заборы делают хороших соседей.
Для организаций, запускающих рабочие нагрузки в облачных и локальных средах, вопрос заключается в том, могут ли их инструменты безопасности следить за виртуальными машинами с той же строгостью, что и за конечными точками на рабочих столах сотрудников и другими частями их инфраструктуры. Только тогда они смогут увидеть полную картину и обеспечить безопасность своих данных в различных средах.
