Управляемые сервисы кибербезопасности – штука по определению автоматизированная и стандартизированная. Однако всегда найдется заказчик, которому сервис нужен «точно такой же, только меньше, но другой». И тогда появляются нетиповые решения и новые стандарты. В этом посте мы расскажем, как решали такие задачи при подключении сервиса защиты от сетевых угроз Unified Threat Management (UTM). <cut/>
Обычно схема подключения сервиса UTM выглядит так: в облачной инфраструктуре для клиента создается изолированное пространство с необходимым объемом вычислительных ресурсов и индивидуальная виртуальная сеть. В этом пространстве строится сервисная цепочка и разворачивается UTM, что позволяет отделить трафик разных клиентов. На площадке клиента устанавливается специальное устройство CPE (Customer Premises Equipment), которое отвечает за доставку трафика до облачной инфраструктуры по защищенному каналу связи (IPSec VPN).
Но это обычно. Теперь же расскажем про варианты исподвыподверта.
Вариант 1. Минимальные изменения на стороне заказчика
Допустим, есть сервисы, которые должны быть доступны для клиентов из Интернета. Для этого необходимо их либо опубликовать с помощью правил NAT (Network Address Translation), используя промежуточное устройство L3, либо подключить напрямую (этот способ менее безопасен).
Итак, сервисы опубликованы и доступны по выделенным белым IP-адресам, но теперь появилась новая проблема: нужно защитить их от внешних атак. Типовая схема предоставления сервиса UTM предполагает, что защита периметра переносится в облачную инфраструктуру, соответственно, вся коммуникация с Интернет будет осуществляться через диапазон IP-адресов «РТК-Солар». Таким образом, будет изменена белая адресация для сервисов.
Мы столкнулись с ситуацией, когда клиенту необходимо было защитить сервисы, при этом выделенные публичные IP-адреса для них не должны были измениться, чтобы не переписывать клиентское ПО и не вносить дополнительных изменений в сетевую архитектуру.
Что же мы сделали?
Архитектура сервиса была разработана так, чтобы клиенту нужно было только установить и активировать СРЕ на своей площадке перед сервером. Для активации требуется подключиться к СРЕ (ноутбук/ПК) и перейти по ссылке, которая будет указана в инструкции. После этого СРЕ построит защищенный канал связи до облачной инфраструктуры.
Все запросы к сервисам маршрутизируются вначале на UTM, там они обработаются политиками безопасности (трафик будет очищаться), далее направятся по защищенному каналу связи до СРЕ. В конце СРЕ направит трафик до сервера клиента, на котором развернуты сервисы.
Для реализации данной схемы выделенная публичная подсеть клиента была перенесена в облачную инфраструктуру. Далее инженеры развернули виртуальный UTM, а на граничных маршрутизаторах облачной инфраструктуры прописали next-hop на белый IP-адрес UTM и объявили подсеть в «Ростелеком» по BGP. На самом UTM добавили маршруты и применили политики безопасности к трафику, проходящему через них.
Затем на площадке клиента организовали новое подключение к Интернет, чтобы можно было назначить белый IP на WAN-интерфейс устройства (CPE). На LAN-интерфейс был назначен IP-адрес из перенесенной подсети, который был шлюзом по умолчанию для сервисов клиента. Таким образом, устройство CPE заменило PE (Provider Edge router).
Вариант 2. Безопасный SD-WAN
Предположим, что в компании было установлено периметровое средство защиты (например, Firewall) и организован централизованный выход в Интернет. Бизнес рос и развивался, постоянно открывались новые офисы и филиалы, и со временем стало все сложнее поддерживать сетевую связность между площадками, отделять корпоративный трафик от трафика, идущего в Интернет. В дополнение ко всему на каждой площадке требовалось организовать отказоустойчивость на уровне канала, т.е. подключение к двум разным операторам.
Для решения данного кейса была разработана архитектура сервиса с использованием технологии программно-определяемых распределенных сетей SD-WAN. В результате стала возможна организация единой логической архитектуры защищенной сети передачи данных, которая не зависит от используемых каналов операторов связи, будь то LTE или Ethernet с разными типами подключения: IPoE static, IPoE DHCP, PPPoE. На всех площадках к устройству подключаются два канала от разных провайдеров для организации резервирования. На некоторых площадках по желанию клиента СРЕ дублируется для организации отказоустойчивости.
Клиент сам решает, отправить ли в облачную инфраструктуру весь трафик или его часть. В последнем случае можно использовать статические маршруты или PBR (Policy-Based Routing).
Вариант 3. Сервис UTM в роли центра сетевой инфраструктуры
Для объединения площадок клиента используется технология SD-WAN. Топология сетевой связности full-mesh (каждый с каждым). Если у клиента подключено к сервису более одной площадки, то все запросы в Интернет (за пределы инфраструктуры) направляются на UTM, а все запросы между площадками – напрямую по защищенным каналам связи (IPSec VPN) от CPE к CPE. Соответственно, трафик между площадками не проходит через UTM.
Мы столкнулись с задачей организации централизованного выхода в Интернет и контроля трафика между площадками на UTM. Клиенту нужна была сегментация сети (трафик между площадками должен был проходить через IPS, чтобы уменьшить поверхность возможной атаки в рамках одного сегмента и предотвратить ее распространение). Для решения этой задачи были использованы существующие у заказчика аппаратные устройства, которые умеют строить защищенные каналы связи. От UTM до площадок клиента были подняты туннели IPSec VPN и созданы необходимые правила маршрутизации и фильтрации трафика. В результате весь он обрабатывается на UTM.
Использование IPSec-туннелей с роутерами клиента не мешает применять SD-WAN. Часть площадок могут быть подключены с помощью существующих VPN-устройств, а часть – через CPE, и у всех со всеми будет сетевая связанность.
Удаленные пользователи также могут работать с внутренними сервисами по защищенному каналу связи RA VPN, который терминируется на UTM.
Вариант 4. Защита облачной инфраструктуры
Предположим, клиент приобрел виртуальные мощности в Национальной облачной платформе, развернул свою инфраструктуру (серверы, рабочие станции и т.п.) и все это ему нужно защитить от сетевых атак.
Для этого случая проработано использование CPE в виртуальном исполнении (vCPE). Устройство разворачивается на выделенных мощностях как обычная виртуальная машина с минимальными параметрами: 2vCPU/ 4G RAM/ 10G storage. Виртуальное vСРЕ ничем не отличается по функциональности от аппаратного. Оно тоже служит для организации защищенных каналов связи с сервисом UTM и другими СРЕ, которые расположены на площадках клиента. После активации vCPE клиент сам определяет, какой трафик будет идти через UTM.
_______________________________________________________________________
P.S.: разумеется, подавляющее большинство кейсов удается эффективно решить типовыми схемами подключения UTM, без вот этих танцев с бубнами. Но если вдруг нет, то и «бубны», и «перламутровые пуговицы» у нас найдутся.
Александр Молчанов, пресейл-архитектор "РТК-Солар"