По ту сторону границы доверия: как устроен пентест облака

Пользователь доверяет облачному провайдеру настройку и сопровождение IT-сервисов, включая хранение данных. В свою очередь, провайдер гарантирует, что расположенные в его инфраструктуре сервисы не выйдут из строя, а данные будут храниться в режиме строгой конфиденциальности.
Чтобы подтвердить защищенность своих платформ, провайдеры выбирают разные стратегии: кто-то запускает программы багбаунти, кто-то полагается на регулярные внутренние аудиты, а кто-то привлекает сторонние команды исследователей. Однако в вопросах методологии тестирования на проникновение облачных инфраструктур остается много белых пятен: единого стандарта не существует, и успешность проверки зависит от опыта и уровня конкретной команды.

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

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

Ключевые моменты

• Облачная инфраструктура сложнее, чем классическое веб-приложение. Упрощенно ее можно представить в виде отеля с тремя зонами: сайт бронирования (External — внешний контур), номера посетителей (Overlay — логический слой), зона для персонала (Underlay — инфраструктурный/базовый слой). Облачный сервис хорошо защищен, если границы доверия между такими контурами не удается нарушить.
• Ценность облачного пентеста измеряется не количеством найденных уязвимостей и не самим фактом выполнения кода. Удаленное исполнение команд в изолированном клиентском контейнере — это лишь самое начало пентеста, а не финал. Главная цель — доказать, что злоумышленник может преодолеть границы доверия.
• Исследование должно давать ответ на пять критических вопросов: может ли атакующий прочитать, изменить или удалить данные других клиентов; удастся ли перехватить сервисную учетную запись IAM провайдера; ведет ли компрометация среды исполнения к распространению атаки на другие ресурсы и сервисы; реализуемо ли воздействие на внутренние ресурсы провайдера из сегментов с низким уровнем доверия и возможен ли побег из виртуального окружения.
• Отрицательный результат — тоже результат. Если пентестер не смог перейти из клиентского окружения (tenant plane) во внутреннюю среду провайдера (provider overlay), это ценный вывод. Он показывает, какие границы защиты работают на практике, а какие держатся лишь на допущениях и требуют дополнительных механизмов контроля.

Основные термины

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

Тенант (от англ. tenant — квартиросъемщик или арендатор) — логически изолированная единица внутри облачной платформы. Это могут быть, к примеру, пользователь (в частности, организация), отдельный проект или аккаунт в облаке или другая единица административной и ресурсной изоляции.

Клиентское окружение (tenant plane) — IT-сервисы и данные, которыми клиент управляет штатно: виртуальная машина, Kubernetes-кластеры, база данных, объектные хранилища и управляемые приложения.

Панель управления (management console) — графический веб-интерфейс и точка входа для клиента на уровне External.

Среда исполнения сервиса (service runtime) — фактическая среда, в которой работает облачный продукт провайдера: процесс, контейнер, под (pod), виртуальная машина или microVM.

Плоскость управления сервисом (service management plane) — внутренние компоненты провайдера, которые создают, обновляют, перезапускают, резервируют и удаляют среду исполнения сервиса (service runtime).

Сервисная учетная запись IAM (service identity) — специальный цифровой идентификатор для программ, роботов, облачных служб и серверов, который позволяет им автоматически и безопасно получать доступ к нужным облачным ресурсам без участия человека.

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

Начальная зона (initial zone) — контекст, в котором исследователь оказался сразу после первоначального успешного перехода: конкретная среда исполнения (runtime), сервисная учетная запись IAM (service identity), пространство имен (namespace), сетевые маршруты и набор доступных сервисов.

Внутренняя среда провайдера (provider overlay) — скрытая от клиента внутренняя среда провайдера, доступная из начальной зоны (initial zone): сетевые сегменты, DNS-зоны, служебные API и компоненты управления.

Управляющий контур или контур управления (control plane) — компоненты платформы, которые принимают глобальные управляющие решения и меняют ее состояние: выделяют ресурсы, назначают права, настраивают сеть, координируют состояние.

Контур данных (data plane) — компоненты, которые переносят и обрабатывают пользовательские данные и прикладной трафик. Существуют компоненты (или системы), которые находятся на стыке разных архитектурных уровней, поэтому их нельзя автоматически относить к контуру данных или контуру управления. Например, это системы журналирования (logging), резервного копирования и биллинга. Они меняют свою роль в зависимости от того, какую именно задачу в данный момент выполняет компонент и как его работа влияет на пользовательский трафик.

Ячейка (cell) — ограниченный фрагмент платформы, внутри которого совместно используются вычислительные, дисковые, сетевые и управляющие компоненты (часто привязан к региону, зоне доступности, типу сервиса или группе клиентов).

Поды (pods, от англ. pod — стручок) — наименьшие вычислительные единицы в Kubernetes. Они представляют собой один или несколько контейнеров, которые развернуты на одном хосте и разделяют общие ресурсы.

Межтенантное воздействие (cross-tenant impact) — подтвержденное воздействие из контекста одного tenant на ресурсы другого без предусмотренного архитектурой доверительного отношения.

Воздействие на уровне провайдера (provider-level impact) — влияние на управляющий, инфраструктурный или supply-chain-компонент провайдера, выходящее за пределы исходного клиентского ресурса.

Клиентская рабочая нагрузка (tenant workload) — это совокупность вычислительных ресурсов, процессов и приложений, которые клиент запускает и использует в своем тенанте для выполнения бизнес-задач. Сюда входят виртуальные машины, контейнеры (например, под в Kubernetes), бессерверные функции, управляемые базы данных и любые другие активные сервисы, обрабатывающие данные клиента.

Что необходимо проверить пентестеру

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

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

Что делает границу реальной? Механизмы контроля: аутентификация и авторизация (IAM, RBAC), изоляция (виртуализация, контейнеризация, сетевые разграничения), криптография (mTLS), обработка входных данных и другие. Мы строим карту потенциальных границ и проверяем каждую: действительно ли она обеспечена механизмами контроля или держится на допущениях (архитектурных, инфраструктурных, реализационных и прочих).

Облачная платформа как объект исследования

Приступая к анализу защищенности традиционной системы, мы обычно отталкиваемся от базовых архитектурных паттернов. Для веб-приложений это условный стек из веб-сервера (Nginx, Apache и прочих), серверной логики, объектного хранилища, интеграций со сторонними сервисами. Для аппаратных решений — цепочка от физических интерфейсов до прошивки и обработчиков протоколов.

Для облачных решений характерна высокая неопределенность архитектурной реализации. Стандарты и референсные архитектуры облачных вычислений (например, NIST SP 800-145 и ISO/IEC 17788) задают роли участников и связи между компонентами облака, но не предписывают строгих правил реализации платформы.

Из-за отсутствия единого технического регламента внешне одинаковая управляемая база данных (managed database) у одного провайдера работает в изолированной виртуальной машине, у второго — в пространстве имен общего Kubernetes-кластера, а у третьего — в выделенном кластере клиентского окружения (tenant cluster). Аналогичная вариативность касается выбора ПО. Провайдер может использовать OpenStack, Kubernetes, собственный управляющий контур или их комбинацию — поэтому знакомое название продукта не дает полного представления о внутреннем устройстве системы.

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

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

Аналогия с отелем и три уровня облака

Чтобы систематизировать пентест в условиях отсутствия единого стандарта построения облачной инфраструктуры, мы используем внутреннее деление облака на три уровня: External, Overlay и Underlay. Проще всего представить облачную платформу как большой отель: у него есть публичная зона для гостей, служебные помещения для персонала и технические этажи с инженерными коммуникациями. Эта аналогия не охватывает все детали, но хорошо показывает, как распределяются зоны ответственности и переходы между ними.

Внешний слой (External) — в отеле это сайт бронирования, двери и стойка регистрации. На этом уровне пентестер взаимодействует с компонентами облака так же, как типичный пользователь: входит в учетную запись, обращается к публичному API, создает IT-сервисы и подключается к их конечным точкам. Работы на этом уровне схожи с внешним тестированием на проникновение или оценкой безопасности приложений. Основная цель — получение первичного доступа снаружи в чужой тенант или переход на уровень Overlay.

На уровне External штатно предоставляется доступ к тенанту. В отеле это сам номер: гость распоряжается вещами и оборудованием внутри своего номера, но его карточка не должна открывать соседние номера. В облаке клиент управляет только собственными данными, виртуальными машинами, подами (pods), базами данных, объектными хранилищами (S3 bucket) и учетными записями внутри своего проекта. Тенант — не отдельный уровень инфраструктуры, а то, что пользователь получает на уровне External. Именно здесь заканчиваются его легитимные полномочия и начинается первая граница доверия, которую проверяет пентестер.

Сервисный слой провайдера (Overlay) — в отеле это зона «Только для персонала»: кухни, прачечные, диспетчерская, служебные коридоры и система мастер-ключей. В облачной инфраструктуре это внутренний логический слой управления сервисами: среды исполнения управляемых сервисов, планировщики, системы резервного копирования, мониторинга (observability) и биллинга, IAM-система и внутренние API. Клиент пользуется результатом их работы, но не должен получать к ним доступ, не предусмотренный архитектурой.

Важно не путать этот термин с оверлейной сетью в классической сетевой инженерии (логическая сеть поверх транспортной андерлейной сети, например, сегменты VXLAN). В нашей методологии Overlay используется шире: как внутренний логический слой исполнения и управления облачными сервисами, который может дробиться в зависимости от конкретного облака. В таблице ниже он для наглядности разделен на два подуровня: среды исполнения клиентских сервисов и внутренние компоненты провайдера.

Инфраструктурный слой (Underlay) — в отеле это инженерные коммуникации, электрооборудование и системы физического доступа (СКУД), которые обеспечивают работу здания в целом. В облаке это аппаратный слой: физические серверы, хостовые операционные системы, гипервизоры, транспортная сеть, системы хранения и внеполосное управление. Неаккуратность работ на этом уровне может привести к серьезным деструктивным последствиям.

Но главное в этой аналогии — не сами помещения, а двери между ними. Уязвимость на сайте бронирования опасна, но найденный в номере мастер-ключ, который открывает все двери в здании или группе помещений, гораздо опаснее. В облаке работает то же правило: возможность удаленного исполнения кода (RCE) внутри изолированного клиентского контейнера (пода) — лишь локальная проблема. Компрометация сервисной учетной записи IAM, управляющей ресурсами региона, касается всей платформы.

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

Уровень	Что находится внутри	Типичная точка входа пентестера	Основная цель проверки
External (внешний уровень)	Публичный интерфейс облака (API), панель управления, IAM, конечные точки взаимодействия с IT-сервисами, SDK	Интернет или обычная клиентская учетная запись	Получение первичного доступа в клиентское окружение (tenant), выполнение кода, компрометация сервисной учетной записи IAM (service identity)
Overlay (IT-сервисы)	Среда исполнения сервиса (runtime): операционная система и ее компоненты, служебные агенты провайдера и продукта, СУБД	Пользовательские SQL-запросы, исполняемый код внутри задач, импортируемые плагины или образы операционных систем	Нарушить изоляцию среды исполнения сервиса (runtime), обнаружить излишние привилегии выданной сервисной учетной записи IAM (service identity)
Overlay (компоненты провайдера)	Система биллинга, резервные копии, мониторинг, система контроля доступа, внутреннее API облака	Подтвержденная начальная зона (initial zone), полученная на предыдущем шаге или предоставленная облачным провайдером, для экономии времени	Нарушить границы между сервисами, нарушить изоляцию тенантов, найти способы взаимодействия с управляющим контуром или IT-сервисами
Underlay (инфраструктурный слой)	Хостовые операционные системы, системы виртуализации (гипервизоры), транспортная сеть, системы хранения данных, контроллеры управления оборудованием (BMC) и другие низкоуровневые механизмы	Контролируемая виртуальная машина с доступом в инфраструктурный слой или привилегированная сервисная учетная запись IAM (service identity)	Проверить изоляцию виртуализации и соседних рабочих нагрузок, а также реальный масштаб воздействия

Реальная облачная платформа не всегда укладывается в эту матрицу. Средой исполнения сервиса может быть отдельная виртуальная машина, под (pod) в общем кластере или microVM. Гипервизор относится к Underlay-уровню, но его управляющий API может быть доступен из Overlay. Поэтому текущий уровень (External, Overlay или Underlay), на котором находится пентестер, определяется не только IP-адресом, но и сочетанием четырех признаков:

1. Кто контролирует компонент облачной инфраструктуры.
2. Чьи данные и ресурсы он обслуживает.
3. Какая сервисная учетная запись IAM используется для взаимодействия.
4. Насколько широко распространяются его полномочия.

Где проходят границы доверия

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

Каждый переход меняет зону доверия, но не обязательно означает выход в новую подсеть или получение root-прав. Это как проход через турникеты внутри одного и того же здания. Мы не оказались на улице (т. е. в новой подсети) и не получили ключи от всех дверей (root-права), но на каждом новом пропускном пункте у нас заново проверяют пропуск, потому что за этим турникетом действуют другие правила безопасности. Иногда граница проходит между двумя ролями в одном процессе, иногда — между API и воркером, а иногда — между гостевой виртуальной машиной и гипервизором. Что касается границы между API и воркером, уязвимость может возникнуть из-за разницы в обработке данных: внутренний API облака принимает от пользователя строку с нуль-байтом (\x00), считает ее допустимой и передает дальше, а фоновый воркер слепо доверяет этим данным и подставляет их в низкоуровневый запрос к СУБД PostgreSQL. Так как для библиотек на языке C символ \x00 означает жесткий конец строки, обработчик базы данных обрезает текст в месте внедрения этого байта, что ломает логику SQL-запроса и проверки прав, сбрасывает контекст обычного пользователя и заставляет систему сменить пароль главного администратора (postgres), приводя к полному захвату базы данных.

Пример 1. Строгая изоляция (управляемая СУБД)

Клиент арендует управляемую базу данных в своем тенанте. Ему разрешено выполнять SQL-запросы, но запрещено подключаться к операционной системе, в которой она работает. Здесь граница доверия проходит между правами роли в СУБД и средой исполнения ее процесса. Если в рамках разрешенных SQL-запросов пентестеру удается перейти к выполнению кода на уровне операционной системы от имени служебного процесса, исследователь получает полноценный доступ к ресурсам хоста. Это дает ему возможность не просто собирать информацию, а активно взаимодействовать с хостом: читать и изменять файлы, анализировать запущенные процессы, устанавливать сетевые соединения с внутренними сервисами и извлекать учетные данные (например, токен сервисной учетной записи IAM) для атаки на другие компоненты облака.

Пример 2. Легитимный доступ (управляемая виртуальная машина)

В другой реализации провайдер штатно поддерживает авторизацию по SSH-ключу, и пользователь подключается к ресурсу как к обычной виртуальной машине. Формально продукт по-прежнему называется «управляемая СУБД», но фактическая граница доверия смещается глубже — на уровень взаимодействия гостевой ОС и хостовой инфраструктуры. Сам доступ к операционной системе по SSH в этом случае не является нарушением — он предусмотрен моделью сервиса. Проверять нужно следующую границу: между сервисной виртуальной машиной и управляющими агентами, метаданными, хостом и управляющим контуром.

Из этого следуют несколько практических правил:

• Штатное выполнение пользовательского кода само по себе не доказывает нарушение изоляции. В таких IT-сервисах, как интерактивные блокноты (notebook), исполнители задач непрерывной интеграции (CI runner) или бессерверных-системах, выполнение кода является функцией продукта.
• Получение максимальных привилегий внутри пода не равно получению максимальных привилегий на ноде. После каждого перехода границы доверия (например, в зону с другими привилегиями, сервисными учетными записями) нужно заново определять видимые процессы, точки монтирования, интерфейсы, устройства и сервисные учетные записи IAM.
• Найденный токен сервисной учетной записи IAM не обязательно полезен для исследователя. Важно, кто его выпустил и какие системы его принимают. Играют роль также тенант и сервис, к которым он привязан, и разрешенные в них действия.
• Сам факт того, что из клиентского контейнера можно обратиться к внутреннему IP-адресу провайдера, еще не означает компрометацию. Во многих облаках часть внутренних сервисов штатно доступна по сети. Для компрометации атакующему нужно либо перехватить сервисный токен, либо найти внутренний сервис, который ошибочно принимает клиентские учетные записи или не требует аутентификации.
• Удаленное выполнение кода внутри среды, где работает сервис, еще не означает доступ к управляющему контуру. Это только начальная зона, из которой исследователь должен искать следующую границу доверия: сервисные токены, внутренние API провайдера, соседние контейнеры.

Чтобы отличить реальное пересечение границы доверия от ложного срабатывания, мы используем четыре последовательных этапа с позиции исследователя:

1. Наличие сетевой видимости. Исследователь видит внутренний сервис провайдера из клиентского окружения. Это еще не взлом, но первый сигнал, что изоляция может быть недостаточной.
2. Аутентификация. Исследователю удается «представиться» сервису, который принимает токен или сертификат, скомпрометированный на предыдущем шаге (например, токен сервисной учетной записи или метаданных). Это уже серьезно: сервис считает запрос легитимным.
3. Авторизация. Объект воздействия наделяет текущий контекст конкретными правами. Это еще не выполнение опасных операций, а проверка того, что они разрешены.
4. Контролируемое действие за исходной границей доверия. Исследователь выполняет минимальное безопасное действие, подтверждающее, что полученные права работают на практике: например, создает тестовую запись в соседнем (обычно во втором тестовом) тенанте.

Первые два этапа дают лишь гипотезу о пересечении границы доверия. Объект виден в сети и принимает запросы — но это еще не значит, что исследователь может что-то в нем изменить. Подтвержденное воздействие появляется только на последних двух этапах, когда удается авторизоваться и выполнить контролируемое действие за исходной границей. Например, сетевая доступность соседней СУБД свидетельствует о недостаточной сетевой изоляции, но межтенантное воздействие появляется только тогда, когда из исходного контекста удается выполнить действие, не разрешенное моделью облака, над ресурсом другого тенанта — к примеру, чтение данных. При этом в целях этичного хакинга исследователь демонстрирует такое чтение исключительно между собственными тестовыми аккаунтами, чтобы не нарушать конфиденциальность реальных пользователей.

Модель злоумышленника и три цели исследования

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

1. Внешний злоумышленник без учетной записи. Проверяется публичная поверхность, регистрация, механизм входа, доступные извне сервисы и путь к первому клиентскому контексту. Уровень External.
2. Злоумышленник с легитимным доступом к тенанту. Ключевая модель для мультитенантного облака: клиент имеет право создавать собственные ресурсы и пытается выйти за их границы. Уровень External.
3. Внутренний злоумышленник со скомпрометированной средой исполнения (Runtime). Начальная точка — зараженный процесс, под или виртуальная машина. Сценарий особенно актуален для атак через цепочку поставок. Исследователь изучает возможности горизонтального перемещения в сетевом и хостовом окружении. Уровень Overlay или Underlay.
4. Внутренний злоумышленник со скомпрометированным токеном сервисной учетной записи IAM или учетной записью оператора. Такая модель предусматривает проверку IAM и процессов управления облачной платформой. Уровень Overlay или Underlay.

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

1. Сначала выполнение кода

Цель этого подхода — выполнить произвольный код внутри управляемого провайдером окружения. Для этого пентестер может атаковать, например, управляемую базу данных, бессерверную функцию, рабочую нагрузку CI/CD, PaaS-приложение, клиентскую виртуальную машину, контейнер, виртуальный сетевой шлюз.

Пример цепочки атаки через управляемый сервис

Пентестер взаимодействует с интерфейсом управляемого сервиса и выявляет уязвимость (например, CVE-2026-19478, как в случае с веб-интерфейсом GitLab) или в дополнительных модулях, которые внедрил облачный провайдер. Уязвимость позволяет исследователю удаленно выполнять код внутри среды исполнения (в операционной системе), находить сервисную учетную запись IAM и благодаря ей получать доступ к сервису управления ресурсами. Далее исследователь может искать в нем уязвимости и проникать во внутреннюю среду провайдера (то есть на уровень provider overlay).

Пример цепочки атаки через виртуальное окружение

Цепочка начинается с компрометации клиентской рабочей нагрузки (tenant workload). Исследователь заранее прячет вредоносный код в популярный образ ОС или контейнера. Клиент облака скачивает этот зараженный образ, запускает его — и хакер получает доступ внутрь этого конкретного контейнера. Далее он находит способы выхода за пределы контейнера (с помощью CVE-2026-43284) в среду исполнения — контейнерный рантайм, гипервизор или хост-агент. Оттуда он выходит на общий с другими контейнерами хост и получает возможность воздействовать на управляющие компоненты провайдера.

2. Сначала учетные данные

Исследователь может получить не доступ к среде исполнения, а учетные данные, которые признаются облачными сервисами: токен сервисной учетной записи, учетные данные для доступа к метаданным, mTLS-сертификат, начальный токен (bootstrap) или ключ к объектному хранилищу.

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

3. Административный или сервисный контекст

Цель этого сценария — обойти технические ограничения, получив легитимный доступ через каналы, предназначенные для персонала. Маршрут часто начинается с эксплуатации человеческого фактора (фишинг, инсайдеры, утечка доступов сотрудников или подрядчиков). Однако итоговая точка входа во внутреннюю среду становится технической: подключение через VPN оператора, портал поддержки, средство удаленной поддержки, административную рабочую станцию, SSH-сертификат или серийную консоль. Несмотря на то что маршрут нередко начинается с компрометации человека, итоговая начальная зона (технический контекст с определенными привилегиями и доступом к ресурсам, в котором оказался исследователь) может совпасть с первым сценарием. Например, доступ к хосту управляемой базы данных (DBaaS-host) может быть получен не через эксплуатацию уязвимости, а через легитимный административный канал, который затем используется для эскалации привилегий.

Разбираемся с архитектурным зоопарком

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

OpenStack-подобная инфраструктура

В IaaS-сервисах на базе OpenStack обычно присутствует большой набор компонентов: сервисная учетная запись IAM, вычислительные ресурсы, сеть, образ и блочное хранилище (block storage), а также API-процессы, воркеры, брокер сообщений (message broker) и базы состояния платформы.

Управляемый сервис, построенный поверх такого IaaS-слоя, может использовать отдельную виртуальную машину для каждого экземпляра базы данных, несколько экземпляров на общей виртуальной машине, Kubernetes-кластер на виртуальных воркерах или даже выделенный тенант для конкретного продукта.
Хотя наличие, к примеру, брокера сообщений RabbitMQ характерно для OpenStack, один лишь факт его обнаружения еще не доказывает, что перед нами классическая установка OpenStack. Провайдер мог изменить схему доверия, добавить собственный API и заменить часть компонентов.

Платформы с архитектурой Kubernetes

В облаках такого класса центральный Kubernetes-кластер контролирует всю инфраструктуру: не только контейнеры, но и виртуальные машины, другие клиентские Kubernetes-кластеры и управляемые сервисы. На уровне среды исполнения сервиса продукт может представлять собой под в общем пространстве имен, приложение внутри тенанта, виртуальную машину KubeVirt или воркер отдельного кластера. Снаружи все варианты выглядят как один продукт, но их границы доверия и дальнейшая поверхность атаки кардинально различаются.

Поскольку управление платформой строится на базе Kubernetes-кластера, где основной единицей авторизации является токен сервисного аккаунта, особенно важно понимать, где находится полученная в результате пентеста сервисная учетная запись IAM: в клиентском кластере, в управляемом кластере или у оператора, обслуживающего несколько тенантов. Одинаковые на вид токены могут иметь права только на один под либо позволять менять ресурсы сразу в нескольких окружениях.

Собственный управляющий контур и системы управления конфигурацией

Провайдер может вовсе отказаться от коробочного решения. В качестве примера в такой архитектуре публичный API может разрабатываться внутри компании, виртуальные машины — разворачиваться через libvirt или легковесный IaaS-слой, управление сетью — автоматизироваться скриптами вокруг Open vSwitch (OVS), объектное хранилище — строиться на Ceph, а конфигурация узлов — распространяться через SaltStack или другую систему управления конфигурациями.

В такой архитектуре сервис управления виртуальными машинами может получать настройки из внутреннего HTTP-сервиса, резервное копирование — выполняться скриптом с общими учетными данными, биллинг — принимать события из очереди, а внутренний агент — взаимодействовать с управляющим контуром по mTLS. Почти каждый компонент здесь специфичен для провайдера, а главная зона риска связана не с уязвимостями в известных продуктах (например, на базе решений с открытым исходным кодом), а с логическими ошибками на стыках между внутренними системами.

Гибридная платформа

На практике чаще всего встречается комбинация подходов

1. Ядро инфраструктуры (IaaS-слой) построено на OpenStack
2. Для управляемых сервисов используют Kubernetes
3. Система хранения работает на базе Ceph
4. IAM, системы биллинга и внутреннее API — собственная реализация.

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

• Наличие в среде исполнения исследуемого хоста Kubernetes-токена и DNS-кластера дает основание предполагать, что сервис работает в контексте пода (pod).
• Запущенный процесс qemu-guest-agent говорит о том, что мы находимся внутри виртуальной машины, а не на физическом сервере.
• Подключенные тома Ceph/RBD указывают на наличие отдельного слоя хранения (storage plane) в архитектуре платформы, реализованного через распределенное блочное хранилище.
• Большое количество сетевых интерфейсов CNI или Open vSwitch (OVS) означает, что это общий узел (shared node) Kubernetes

При этом любой такой признак нуждается в дополнительных проверочных тестах.

Как выбрать следующую границу доверия

После осмотра пентестером начальной зоны дальнейший маршрут определяется сочетанием двух факторов:

1. Сетевая видимость — какие сегменты, сервисы и тенанты достижимы.
2. Уровень доступного доверия — какие учетные данные, сертификаты и методы API признаются валидными в этих сегментах.

Иногда сеть почти не имеет ограничений, но все сервисы требуют корректной mTLS-аутентификации. В другом случае сеть почти закрыта, зато найденный сервисный аккаунт может через штатный API создавать ресурсы во всем регионе. Поэтому сетевую доступность (открытые порты) и сервисную учетную запись IAM нужно рассматривать вместе.

На этом этапе исследователь обычно фокусируется на нескольких критических направлениях исследования.

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

Системы хранения и резервирования данных — этот слой связывает среду исполнения, плоскость управления (management plane) и пользовательские данные. Исследователь анализирует области действия ключей, привязку снимков состояния и резервных копий к тенантам, временные тома восстановления (restore volumes) и то, как воркеры определяют владельца ресурса.

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

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

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

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

Типовые цепочки атак и реальные инциденты

На практике сценарии атак редко копируют друг друга, но несколько примеров хорошо показывают, как именно злоумышленники преодолевают границы доверия.

1. От управляемой базы данных к данным других пользователей

Исследователь разворачивает собственную управляемую базу данных и использует штатные SQL-операторы и процедуры для составления SQL-запросов. Однако из-за бреши в изоляции выполнение кода выходит за рамки изолированной среды исполнения и переносится в общую среду исполнения сервиса. Там обнаруживается токен сервисной учетной записи IAM, не привязанный к конкретному экземпляру управляемой базы данных. Подтверждением нарушения изоляции служит успешная манипуляция с базой данных другого (тестового) тенанта.

В данном кейсе сама возможность выполнять SQL-запросы не была уязвимостью. Критический переход произошел между контекстом тенанта и общей сервисной учетной записью IAM. Итогом атаки стало межтенантное воздействие, для которого даже не потребовалось получать root-привилегии на хосте.

Похожая логика была продемонстрирована в публичном кейсе ChaosDB: функция Jupyter Notebook в Azure Cosmos DB создавала риск доступа к ключам других клиентов. Этот пример важен тем, что уязвимость в отдельной пользовательской функции управляемого сервиса оказала влияние на другие компоненты платформы.

 

2. От Kubernetes-пода к данным других пользователей

Пентестер запускает собственный контейнер, после чего за счет уязвимости изоляции перехватывает управление основным хостом. На хосте обнаруживается привилегированная сервисная учетная запись Kubernetes, обрабатывающая запросы от API управляющего кластера. Контролируемое действие с соседним подом, принадлежавшим второму тестовому тенанту, подтверждает нарушение изоляции.

Именно так выглядела цепочка Azurescape, опубликованная Unit 42: побег из контейнера, получение привилегированной сервисной учетной записи IAM и компрометация мультитенантного кластера Kubernetes. Главным событием тут стал не побег из контейнера, а возможность получения токена сервисного аккаунта, валидного для других тенантов.

3. Через публичную операцию к изменению внутренних облачных ресурсов

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

Это пример воздействия на уровне инфраструктуры облачного провайдера: конечная точка (воркер) в публичном API способна компрометировать будущие рабочие нагрузки сторонних клиентов, даже если исследователь не сканировал соседние тенанты и не получал доступ к их данным.

4. Побег из виртуальной машины

Стартовая точка для исследования — собственная виртуальная машина пентестера в облаке. Обнаружение уязвимости в системе виртуализации позволяет реализовать вектор guest-to-host («гость-на-хосте») и выполнить произвольный код на хостовой машине самого гипервизора. Далее исследователь переходит из хоста гипервизора в сеть управления или управляющий контур, что считается переходом через следующую границу доверия.

Публичные исследования показывают, что побег из систем виртуализации — реальный класс угроз. Чаще всего они связаны с ошибками в механизмах разделения памяти, уязвимостями в общих буферах обмена или общих папках. При этом наличие публичной CVE не доказывает уязвимость конкретного облака. Для успеха атаки важны также версия гипервизора, конфигурация и наличие дополнительных слоев защиты (например, жесткие политики на уровне ОС). Проверка техник «гость-на-хосте» в общей публичной инфраструктуре сопряжена с высоким риском деструктивного воздействия на сам гипервизор и его виртуальные машины, поэтому строго регламентирована и проводится только по согласованию с провайдером.

Что считать результатом пентеста

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

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

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

Безопасное подтверждение воздействия

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

До начала работ в правилах взаимодействия нужно зафиксировать:

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

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

Важно разделять два формата работ. Владелец тенанта может тестировать собственные ресурсы в рамках правил конкретного облака, но это не всегда дает право исследовать инфраструктуру провайдера. Пентест внутренней среды провайдера и инфраструктурного слоя требует отдельного разрешения со стороны владельца платформы.

Заключение

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

• External (Внешний уровень): публичная поверхность атаки, включающая публичные API, панели управления, сервисы IAM, конечные точки взаимодействия с IT-сервисами и SDK. Пентест здесь оценивает возможность получения первичного доступа в клиентское окружение (tenant) и компрометации учетных записей.
• Overlay (IT-сервисы): виртуальный слой на стороне клиента, где функционируют среды исполнения (runtime), операционные системы, СУБД и служебные агенты. Проверки здесь направлены на нарушение изоляции рантайма и поиск избыточных привилегий сервисных учетных записей IAM. Напомним, что мы ввели и второй уровень Overlay, поскольку среда исполнения клиентского сервиса и внутренняя инфраструктура провайдера имеют разные границы доверия и разные точки входа. О нем дальше.
• Overlay (Компоненты провайдера): внутренняя логическая среда облака. Сюда входят системы биллинга, резервного копирования, мониторинга, контроля доступа и внутренние API. Атаки на этом уровне нацелены на нарушение границ между сервисами/тенантами и поиск способов несанкционированного взаимодействия с управляющим контуром.
• Underlay (Инфраструктурный слой): фундамент платформы. Он включает хостовые операционные системы, системы виртуализации (гипервизоры), транспортную сеть, системы хранения данных (СХД), контроллеры управления оборудованием (BMC) и другие низкоуровневые механизмы. Целью проверок является оценка изоляции виртуализации и реального масштаба воздействия на соседние рабочие нагрузки.

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

Именно такой системный подход позволяет превратить разрозненные технические находки в измеримый, доказанный риск для конкретного пользователя, сервиса или всей облачной платформы.

Что будет в следующей статье

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