Разделяй и властвуй: многомерные политики безопасности

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



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



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



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



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

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

Одномерный последовательный подход к политикам безопасности не зарекомендовал себя как правильная тактика для поддержки операционной безопасности.

Многомерность в виртуальном пространстве

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

Как тогда быть с описанной проблемой в разрезе программно-определяемой среды?

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

Следующая схема дает представление о взаимодействии между компонентами в окружении Horizon View с минимум 4-мя периметрами, которые следует принимать во внимание: внутренние клиентские сети, внешние клиентские сети, DMZ (демилитаризованные зоны) и внутренняя сеть.



В контексте NSX мы будем использовать Service Composer, который создает «пузырьки», предназначенные для группировки объектов в заивисимости от атрибута рабочей нагрузки и независимо от их IP-адресов, VLAN или местоположения.

Для начала давайте рассмотрим среду, с которой мы будем работать:



Первым шагом будет группировка значимых частей приложения, которые должны быть защищены. Создадим 3 группы в зависимости от типа рабочей нагрузки: одна для Security Servers, действующих в качестве прокси по отношению к Интернету, другая для Connection Servers, действующих в качестве брокеров рабочего стола, и, наконец, для всех виртуальных рабочих столов, которые будут созданы. Идея здесь заключается в том, что теперь администраторы (View admins) cмогут добавить любой из этих сервисов куда угодно в ЦОД, и они будут автоматически добавлены в соответствующие группы.



Давайте сделаем последний «пузырь», чтобы охватить всю экосистему Horizon View.



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



Групповая политика, полученная в результате, затем распространяется и исполняется для каждого участника «пузырька» Horizon View, микро-сегментируя каждый элемент в собственный периметр безопасности.

Продолжим. Наше приложение по-прежнему должно управляться конкретным администратором (View Admin). Как и любые другие пользователи, администраторы будут использовать View Client для своих vDesktop, затем NSX Distributed Firewall распознает их как часть группы «View Admins» в Active Directory и применит динамические правила к их vDesktops, позволяя им управлять любыми элементами внутри «пузырька» Horizon View, но и ограничивая их только этими элементами.



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



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

Добавление «измерений» приложению становится проще, потому что мы подходим к проблеме со стороны функциональных групп, а не с точки зрения создания сложносочиненных политик безопасности. Например, теперь можно легко установить корпоративные правила безопасности для «всех MS Win2003srv», используя атрибут виртуальной машины «OS-Type» для динамического выбора участников группы.



В прошлом это потребовало бы понимания, где расположены все серверы Windows 2003, какими брандмауэрами они закрыты, а затем копирования адаптированных версий одного и того же набора правил для размещения различных IP в каждом межсетевом экране. Когда некоторые серверы будут обновлены до текущей версии, тот же ручной процесс будет происходить снова, пока наш «пузырь» просто не удалить их из списка, так как они не будет соответствовать критериям членства.

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

Комплексная безопасность как она есть

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

Виртуализация сети с распределенными виртуализированными службами безопасности предлагают новые возможности, позволяя перегруппировывать сервисы, а не диапазон IP-адресов, набор хостов и т. д., а также дают выгоды от снижения общей сложности в разработке политик безопасности. Групповые политики, микро-сегментация для одной виртуальной машины, проверка трафика…. Все такое.