Как с помощью микросегментации сети обеспечить безопасность мультиоблачной инфраструктуры

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

Микросегментация: особенности и основные варианты

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

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

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

Основные варианты микросегментации:

• на основе межсетевых экранов (МЭ) уровня гипервизора. В этом случае возможны проблемы совместимости с ИТ-инфраструктурой, т.е. не всегда получится защитить приложения, работающие на физических серверах или гипервизорах других производителей;

• на основе конечного хоста (например, iptables или Windows Firewall). Этот вариант обеспечивает защиту любых приложений в любой ИТ-инфраструктуре, но предполагает использование агентов. Кому-то наличие еще одного агента на хосте может показаться недостатком, однако это открывает дополнительные возможности по сбору flow-информации непосредственно с источника.

От теории к практике

Рассмотрим абстрактный пример компании Х. У нее есть собственный ЦОД, кроме этого компания пользуется услугами облачного сервиса. На текущий момент применяется традиционная сегментация. Внутри сегмента серверы свободно взаимодействуют друг с другом.

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

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

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

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

Еще одна проблема – недостаточная осведомленность о приложениях и их сетевых коммуникациях. Собирать данные с помощью Netflow (или другого flow-протокола) не позволяет существующая инфраструктура, т.к. не все коммутаторы его поддерживают или имеют достаточно ресурсов для работы. Проблему поддержки Netflow можно решить с помощью развертывания TAP или настройки SPAN на каждом коммутаторе, но в масштабах ЦОД – это дорогое удовольствие, т.к. потребуется внедрение устройств, генерирующих flow на основе сырого трафика.

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

Среди наиболее удобных инструментов можно выделить платформу Cisco Secure Workload (Tetration), предназначенную для целостной защиты рабочих нагрузок для многооблачных центров обработки данных. Она позволяет:

• осуществлять микросегментацию для реализации модели нулевого доверия на основе белого списка;

• определять базовые показатели поведения рабочей нагрузки и заблаговременно выявлять аномалии;

• обнаруживать уязвимости, распространенные и связанные с пакетами программного обеспечения, установленными на серверах;

• использовать проактивную защиту, помещая контролируемые узлы в карантин при обнаружении уязвимостей и блокируя обмен данными при обнаружении нарушений политики;

• обеспечить целостное понимание общего состояния безопасности центра обработки данных.

Как это работает

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

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

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

Компоненты решения

Программные сенсоры: представляют собой ПО, устанавливаемое на серверах под управлением операционных систем Linux или Microsoft Windows. Эти серверы могут быть как stand-alone-решением, так и элементом среды виртуализации или контейнерного типа, размещаемым в локальных центрах обработки данных или в любом общедоступном облаке. Нагрузка на ЦПУ, осуществляемая работой ПО сенсора, по умолчанию ограничена несколькими процентами и являются контролируемой, чтобы гарантировать соглашение об уровне обслуживания (SLA). Сенсоры могут как собирать данные телеметрии, так и выступать в качестве элемента управления на контролируемом узле для задач сегментации. Собираются следующие данные телеметрии:

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

• вариативность поведения: фиксирует любые межпакетные вариации, наблюдаемые в потоке, включая вариации времени жизни пакета (TTL), флагов TCP/IP и длины полезной нагрузки;

• сведения о процессе: фиксирует процессы, выполняемые на сервере, включая информацию о параметрах процесса, времени запуска и остановки, двоичном хеш-коде процесса и т. д.;

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

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

Примерами таких решений являются сенсоры:

• Cisco Nexus Platform Switches

• ERSPAN

• Application Delivery Controller (ADC) – F5, Citrix NetScaler

Прочие сенсоры:

• NetFlow

• журналы AWS VPC

Возможности Cisco Secure Workload

Рассмотрим возможности решения на частном примере подключения нового пользовательского устройства с ОС MS Windows к существующему ЦОД, находящемуся под управлением ПО Cisco Secure Workload. В состав ЦОД входят такие распространенные базовые компоненты, как серверы приложений, баз данных и балансировщик нагрузки.

Первоначальная настройка

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

Добавление нового агента

Список существующих подов на вкладке «мониторинг», отражающей подключенные программные агенты.

Решением представляется два варианта установки программного агента: с автоматической привязкой и без. Для экономии времени рекомендуется к использованию вариант с автоматической привязкой. Для наглядности будем использовать его в дальнейшей работе компонентов решения.

Пример установки ПО программного сенсора на ОС MS Windows 2019.

Определение пула

Cisco Secure Workload может запускать алгоритмы машинного обучения для любой рабочей нагрузки, однако необходимо иметь механизм, задающий определенные границы. В связи с этим в платформе существует концепция, называемая «scoping». Она позволяет без затруднений осуществлять запросы по изменению настроек, связанных с определенными областями инфраструктуры, обеспечивая гибкость по мере развития структуры организации.

Картографирование (mapping)

Cisco Secure Workload может автоматически обнаруживать и сопоставлять соответствующие политики и приложения. В решении этот процесс называется сопоставлением зависимостей приложения (также известный как ADM).

Настроим процесс запуска ADM для одного из приложений. Автоматически обнаружим список разрешенных политик для приложения: для этого во вкладке "Segmentation" необходимо создать новое рабочее пространство.

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

Во время запуска функциональности ADM Cisco Secure Workload использует неконтролируемое пользователем машинное обучение для анализа всех метаданных заданной области и пытается сгруппировать конечные точки в кластеры.

Обнаруженные существующие политики можно просмотреть на вкладке "Policy".

Используем встроенные средства для понимания необходимости существования политики.

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

Графическое представление

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

В данном примере только узел load_balancers может открывать соединения с веб-серверами и только веб-серверы могут взаимодействовать с базами данных. Если отсутствует конкретное разрешающее правило, то будет согласована политика catch all.

Пример добавления политик

Политики можно добавлять или редактировать вручную на вкладке «Policy», как показано ниже.

Анализ политик

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

Анализ политики Cisco Secure Workload предоставляет информацию о потоке, включая информацию вплоть до IP-адреса и порта, с которого исходил поток.

Анализ политик решает, разрешен ли активный поток, будет ли он сброшен или отклонен, на основе политики, обнаруженной в результатах ADM.

Применение политик

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

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

Проверка примененных политик

На вкладке "Policy" представлены правила политики, перенесенные в рабочую нагрузку.

Результат внедрения микросегментации

В результате внедрения Cisco Secure Workload выполнено разделение по зонам (продуктив, разработка и т.д.), внутри зон – по приложениям. Для каждой рабочей нагрузки средствами хостового МЭ создан микросегмент. Трафик север-юг по-прежнему контролируется пограничными МЭ.

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

На рисунке 19 показан пример разделения по зонам – рабочим областям. Внутри рабочей области кластеры – сгруппированные по общим свойствам рабочие нагрузки (Рисунок 19) – и применяемые к ним политики.

С внедрением системы Cisco Secure Workload удалось автоматизировать рутинные задачи по поддержке политик в актуальном состоянии.

Сейчас алгоритм работы с политиками выглядит так: с помощью механизма ADM система самостоятельно группирует рабочие нагрузки в кластеры и генерирует whitelist политики; затем администратор может утвердить или изменить результат работы ADM.

В случае изменения членства рабочей нагрузки в кластере или рабочей области ADM запускается повторно и выдает обновленные политики, отражающие изменения потоков. При этом администратор всегда может определить свои собственные whitelist– и blacklist–политики. Итоговая политика будет представлять собой упорядоченный список правил, применяемый сверху вниз: абсолютные политики, создаваемые администратором (Рисунок 21), политики по умолчанию, создаваемые в рамках работы ADM (Рисунок 22), и политика catch all, обычно с действием deny (Рисунок 23).

Перед применением политик, автоматически сгенерированных средствами ADM, хотелось бы понимать, как они повлияют на приложение. Запускаем функцию анализа политик, чтобы проверить их на живом трафике, но без фактического применения (Рисунок 24). В результате проверки потоки трафика делятся на четыре категории:

• Permitted – поток разрешен и сетью (завершен), и политикой;

• Escaped – поток разрешен сетью (завершен), но в соответствии с политикой должен быть запрещен;

• Rejected – поток запрещен и сетью (не завершен), и политикой;

• Mis-Dropped – поток запрещен сетью (не завершен), но в соответствии с политикой должен быть разрешен.

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

Использование на хостах агентов открывает дополнительные полезные возможности. Например, можно делать инвентаризацию установленного программного обеспечения, а затем использовать эту информацию для идентификации известных уязвимостей. В итоге получаем: CVE-идентификатор уязвимости (Рисунок 25); пакеты, которые необходимо исправить (Рисунок 26); рабочие нагрузки, на которых установлены уязвимые пакеты (Рисунок 27).

В качестве временного решения информация по уязвимостям может быть использована для создания динамических политик, закрывающих возможность эксплуатации этих уязвимостей. Используем идентификатор CVE в качестве фильтра для отбора уязвимых рабочих нагрузок (Рисунок 28). Затем этот фильтр применяется в качестве параметра политики фильтрации (Рисунок 29). По мере исправления уязвимостей будут меняться и настройки динамических политик.

Другая интересная возможность, доступная благодаря агентам – сбор сетевой статистики непосредственно с источника. Агенты периодически экспортируют на коллектор flow-информацию (IP-протокол, IP источника/назначения, L4-порты, количество пакетов/байтов, TCP-флаги и т.д.), IP-информацию (TTL, IP-флаги, IP options и т.д.), TCP-информацию (sequence number, ack number, rcvd windows size). Кроме того, агенты собирают информацию о процессах, их владельцах, командах, используемых для запуска процессов. В итоге мы получаем полную и актуальную информацию обо всех сетевых взаимодействиях (Рисунок 30).

Помимо сетевой статистики, агенты могут собирать и экспортировать информацию, необходимую при расследовании инцидентов: по удачным и неудачным попыткам входа в систему, созданию и удалению учетных записей, эскалации привилегий, запуску ранее не используемых команд, изменению хеша исполняемых файлов и прочим аномалиям. Она отправляется на движок форензики, где происходит сопоставление выявленных событий с заранее созданными правилами. В случае выявления соответствия выполняется одно из действий: Record – событие сохраняется для дальнейшего анализа; Alert – для события создается уведомление. Для каждого события доступна визуализация (Рисунок 31). Можно наглядно увидеть родительский процесс, список порожденных дочерних процессов, тип учетной записи, из-под которой процесс запущен. По каждому процессу доступна подробная информация (Рисунок 32).

Но часть межсетевых экранов никуда не делась, поэтому появляется новая проблема: нужно обеспечить согласованность политик, реализованных на этих межсетевых экранах, с политиками на рабочих нагрузках. В нашем примере мы интегрируем Cisco Secure Workload с продуктом AlgoSec Security Management Suite, одной из основных задач которого является управление изменениями политик безопасности на межсетевых экранах.

Cisco Secure Workload через Kafka обменивается политиками приложения с модулем AlgoSec AppViz (Рисунок 33). После того, как драфт политик загружен и применен (Рисунок 34), AlgoSec автоматически создает запрос на изменение (Рисунок 35), который далее обрабатывается с помощью модуля AlgoSec FireFlow. В процессе обработки модулем FireFlow запрос проходит стадии:

• планирования, когда автоматически определяется список всех устройств, требующих изменений (Рисунок 36); если изменения не требуются, то запрос автоматически закрывается;

• оценки рисков, которые могут возникнуть в результате внесения изменений (Рисунок 37);

• автоматического применения изменений на устройствах (Рисунок 38).

Резюме

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

Авторы - Руслан Ибрагимов и Дмитрий Баранцев.