Аудит безопасности гибридного облака: проверка границ между локальной инфраструктурой и облаком

Гибридное облако — это не просто локальная инфраструктура, подключённая к аккаунту провайдера. Это цепочка доверия, которая проходит через каталоги пользователей, издателей токенов, маршрутизаторы, управляющие агенты, системы журналирования и несколько операционных команд. Если аудит рассматривает облачный тенант, а дата-центр оставляет «чёрным ящиком», он может пропустить именно те пути, которые делают архитектуру гибридной. Обратное тоже верно: привычная проверка внутренней сети мало говорит о возможностях синхронизированных учётных записей, облачных ролей и удалённых агентов.

Поэтому полезный вопрос заказчика звучит не как «безопасно ли настроены Azure, AWS или Google Cloud?», а так: «какие пользователи, команды и данные могут пересекать каждую границу, какой контроль должен их остановить и можем ли мы доказать, что он работает?» Ниже этот вопрос превращён в объём работ, план сбора доказательств, безопасную проверку и критерии ретеста. Материал дополняет руководство по оценке безопасности нескольких облаков, но сосредоточен на доверии между локальной средой и облаком.

Объект аудита — цепочка границ

Начинать следует с бизнес-потоков, а не с чек-листа провайдера. Выгрузка расчёта зарплаты может начаться в локальной базе, пройти по выделенному каналу, попасть в объектное хранилище и запустить облачную функцию. Администратор может войти под учётной записью Active Directory, получить облачный токен и из облачной плоскости управления запустить привилегированное расширение на сервере, который физически остаётся в дата-центре. Каждый такой поток пересекает несколько независимых границ.

Это меняет смысл слова «защищено». Приватная маршрутизация не доказывает шифрование. Синхронизированный объект каталога не доказывает, что блокировка исходной учётной записи завершает все сессии. Облачный журнал административных действий не доказывает, что чтение чувствительных данных записывается. Роль с названием «мониторинг» не доказывает, что агент не умеет выполнять привилегированный код. Аудит должен сопоставить каждое утверждение с конкретным режимом продукта, конечными точками и категорией журналов.

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

Как определить объём проверки

Хороший объём работ называет обе стороны каждого перехода. Нужно зафиксировать тенанты, организации, аккаунты, подписки, проекты, регионы и значимые группы ресурсов. Рядом должны быть леса и домены, провайдеры идентификации, серверы федерации и синхронизации, DNS-зоны, адресные пространства, шлюзы, операторские каналы, прокси и агенты удалённого управления. SaaS-приложения также входят в модель, если их сессии или подготовка учётных записей зависят от гибридной идентичности.

Формулировка «вся продуктивная среда» недостаточна без даты инвентаризации и метода сверки. Экспорт облачной организации стоит сопоставить с биллинговыми аккаунтами, каталогами идентичностей, реестром маршрутов и CMDB. Полезна выборка недавно созданных и недавно списанных активов. Осиротевшие подписки, устаревшие коннекторы и отключённые агенты важны: они могут сохранять ключи или доверие после того, как система учёта уже считает актив удалённым.

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

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

Синхронизация идентичностей, федерация и отзыв доступа

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

Отзыв доступа — последовательность, а не один переключатель. В Microsoft Entra ID запрет входа и отзыв refresh token могут оставить пригодными уже принятый access token или сессию приложения до срабатывания их собственных контролей; Continuous Access Evaluation действует только там, где поддерживается. Поэтому отдельно измеряют новую аутентификацию, обновление, принятие токена ресурсом и завершение сессии приложения.

Безопасный тест использует выделенные учётные записи и заранее согласованное максимальное время наблюдения. Создаётся сессия, фиксируются метки токена и cookie, учётная запись блокируется по штатной процедуре реагирования, после чего каждая граница наблюдается без попыток обойти защиту. Тест повторяют для значимого SaaS или внутреннего приложения, у которого есть собственная сессия. Вывод формулируют не как абстрактное «отзыв занял N минут», а как точное описание: какие учётные данные продолжали работать, в каком приложении и при какой конфигурации.

Сервер синхронизации также рассматривается как критическая инфраструктура. Проверяют, кто его администрирует, как защищены сервисные учётные записи и сертификаты, где журналируются изменения и может ли скомпрометированный локальный администратор повлиять на облачные роли через членство в группах. В обратную сторону рассматривают cloud writeback и provisioning, способные менять локальные объекты. Цель — определить оба направления полномочий.

Приватный канал и шифрование — разные контроли

Для каждого Direct Connect, ExpressRoute, partner interconnect, VPN и прикладного туннеля отдельно фиксируют физические или логические точки подключения и точки завершения шифрования. AWS Direct Connect по умолчанию не шифрует транзитный трафик. MACsec защищает канал второго уровня между конкретными устройствами и не создаёт сквозное шифрование через последовательность сегментов. Важен и режим: предпочтение шифрования с возможностью перехода к открытому трафику даёт другую гарантию, чем режим, останавливающий передачу при неудаче согласования.

Трафик ExpressRoute также не шифруется по умолчанию. В ExpressRoute Direct MACsec может защищать физический канал заказчик — Microsoft. IPsec покрывает путь между настроенными локальным шлюзом и шлюзом Azure. Нанесите эти точки на схему приложения: для оставшихся сегментов нужно отдельно выбрать защиту, например TLS.

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

Агенты удалённого управления меняют направление доверия

Гибридный агент может создать путь от облачной роли к локальному привилегированному процессу. На серверах с Azure Arc Custom Script Extension и Run Command по умолчанию выполняют сценарии от Local System в Windows или root в Linux. Локальные ограничения сужают путь, но добавление списка разрешённых расширений не удаляет уже установленные.

Нельзя делать упрощённый вывод «любой Contributor в облаке всегда получает root». Нужно определить назначенные Azure-роли, разрешённые операции с расширениями и эффективное локальное состояние. Эти уровни проверяют совместно: право запросить операцию в облаке и решение хоста принять её — разные условия. В выявленной проблеме описывается реально существующая комбинация.

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

Доказательства должны охватывать плоскость управления и операции с данными

Скриншот конфигурации слаб, если не связан с объёмом работ, временем и идентичностью. Лучше использовать машиночитаемые экспорты с ID тенанта или аккаунта, временем сбора и командами либо API. Если процесс позволяет, сохраняют хеш или неизменяемую копию. Для каждого существенного контроля нужны три вида доказательств: проектное, операционное и проверочное — что должно происходить, что система записывала за релевантный период и что случилось во время разрешённого теста.

Особенно легко ошибиться в стандартных настройках облачного журналирования. В AWS CloudTrail события управления описывают операции плоскости управления и по умолчанию записываются в журнал и хранилище событий; журналы операций с данными, например объектные операции, требуют явного выбора. В Google Cloud Admin Activity записывается, а Data Access обычно отключён по умолчанию, кроме оговорённых сервисов. Поэтому обнаружить «CloudTrail включён» или «Audit Logs присутствуют» ещё не значит доказать видимость чтения чувствительного объекта, вызова функции или операции с данными в БД.

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

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

1. Инвентаризацияпересчитать обе конечные точки, объекты доверия, агенты и владельцев
2. Конфигурациявыгрузить эффективное состояние IAM, сети, агентов и журналирования
3. Проверкавыполнить разрешённое безвредное действие с уникальным маркером
4. Корреляциянайти маркер в облаке, агенте, на хосте и в системе детектирования
5. Ретестповторить тот же критерий после исправления

Безопасной проверке нужны точные рамки разрешения

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

Выбирают наименее инвазивный метод, отвечающий на вопрос. Сначала — выгрузки без права изменения и запросы к логам. Затем — изменения силами владельца, если аудитору не нужен прямой доступ на запись. Используют тестовые идентичности и синтетические объекты. Предпочтителен тест запрещённой операции, когда отказ доказывает контроль. Если для оценки влияния потребовалась бы эксплуатация, согласуют безопасную границу доказательства: показывают достижимое полномочие или примитив выполнения, но не читают бизнес-данные и не закрепляются на хосте.

Здесь облачная red-team оценка отличается от рассматриваемого аудита. Red team движется к согласованной цели противника и может связывать несколько слабостей. Гибридный аудит способен остановиться, когда есть воспроизводимое доказательство ложности заявления о границе и достаточно контекста для исправления. Если главная задача — сверка с базовыми настройками, а не анализ межсредовых путей, полезен контекст аудита защищённой конфигурации.

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

Полезное описание проблемы называет исходное состояние, переход, эффект на стороне назначения и отсутствующее доказательство. «ExpressRoute не зашифрован» — слишком широко. Рабочая формулировка: «канал оператора приватный, однако для потока между точкой A и нагрузкой B нет подтверждённого шифрования после пограничного устройства». Вместо «отзыв медленный» нужно написать: «облачная учётная запись перестала получать новые токены, но приложение C принимало собственную сессию до заданного срока истечения».

Исправление назначают команде, которая может изменить контроль, и указывают зависимости. IAM может сократить время жизни токена, но аннулирование сессии реализует владелец приложения. Сеть включает MACsec, однако TLS после окончания канала остаётся ответственностью приложения. Облачная платформа ограничивает роль Arc, а серверная команда задаёт локальный список разрешённых расширений и удаляет существующие. SOC создаёт правило обнаружения, а владелец сервиса включает источник журналов операций с данными.

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

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

Что должен получить заказчик

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

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

У потенциального подрядчика стоит спросить, как он организует временный доступ, безопасность продуктивной среды, взаимодействие нескольких администраторских команд и доказательства для исключённых операторских или SaaS-сегментов. Уточните, различает ли он видимость плоскости управления и операций с данными и будет ли ретест повторять поведение, а не только повторно смотреть настройку. Такие ответы показательнее длинного перечня бенчмарков провайдеров.

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

Независимая оценка полезна, когда ответственность фрагментирована, после миграции остались перекрывающиеся контроли или организация не может доказать распространение действий реагирования через границу. Аудит облачной безопасности Pentest.red может объединить анализ IAM и федерации, проверку конфигурации без права изменения, выбранную ручную валидацию и анализ путей атаки в согласованном объёме работ. Иногда правильным следующим шагом будет внутреннее упражнение по сбору доказательств, если команда уже понимает пути доверия и закрывает узкий пробел. Результатом должен стать защищаемый фактами ответ: как ведёт себя гибридная система, кто исправляет каждый разрыв и как это будет проверено повторно.