Compartilhar via

Опции сетевой изоляции в виртуальных машинах и сетях

  • Artigo

Это – перевод статьи <https://blogs.msdn.com/b/windowsazure/archive/2014/03/28/network-isolation-options-for-machines-in-windows-azure-virtual-networks.aspx> Walter Myers.

Введение

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

Изоляция машин - опции

Существует три основных опции изоляции виртуальных машин друг от друга:

  • Изоляция машин внутри одной виртуальной сети
  • Изоляция машин в нескольких виртуальных сетях
  • Изоляция машин в нескольких виртуальных сетях, с поднятым VPN-каналом от локальной инфраструктуры ко всем виртуальным сетям

По умолчанию виртуальные машины под управлением Windows Server имеют два уже настроенных открытых порта: RDP и Remote PowerShell. Любые другие порты и точки доступа должны быть открыты внешним образом администратором, и все точки доступа могут иметь регламентированный с помощью Access Control Lists доступ.

Механизм работы ACL

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

После создания виртуальной машины применяется стандартный ACL, блокирующий весь входящий трафик. В этом ACL прописываются правила для создаваемых портов (например, RDP). Отметим также, что, как было указано выше, при создании виртуальной машины автоматически создаются порты для Powershell и RDP, и для них используются стандартные порты внутри виртуальной машины, но внешние порты (для внешних клиентов) конфигурируются случайным образом. Входящий трафик, таким образом, лимитируется только этими портами, и конфигурировать вручную брандмауэр уже не надо. Исходящий трафик разрешен.

clip_image001

С помощью ACL можно:

  • Выборочно разрешить или запретить входящий трафик с определенных IPv4 адресов или диапазонов на конкретные порты
  • Создать черный список IP-адресов
  • Создать до 50 правил в ACL на один порт
  • Использовать последовательность применения правил (по приоритетам)
  • Создать ACL на диапазон IP

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

Опция 1: Подсети внутри одной виртуальной сети

В Microsoft Azure можно настроить маршрутизацию на основе подсетей внутри одной виртуальной сети, но при этом нельзя создать ACL на внутренние DIP-адреса (частные адреса, выдаваемые виртуальным машинам системой). Для регламентирования доступа к машинам внутри одной виртуальной сети на тих машинах нужно настроить Windows Firewall with Advanced Security, как, например, на рисунке.

clip_image002

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

  • какие локальные порты должны все-таки принимать трафик
  • Какие IP-адреса находятся в "белом" листе
  • Какие авторизованные пользователи могут инициировать подключения

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

Опция 2: подсети в разных виртуальных сетях

Для изоляции виртуальных машин из разных сетей, или виртуальных машин от серверов, расположенных вне виртуальных сетей, можно использовать ACL. Этот подход естественен для изоляции приложений в Azure, так как по умолчанию, как уже было сказано, единственное, что разрешено сразу на виртуальных машинах - это порты для RDP и Powershell. Для виртуальной машины Azure, которая хочет подключиться к другой машине в другой виртуальной сети, ее VIP (внешний адрес) будет рассматриваться как DIP-адрес внутри одной сети. Поэтому, когда в ACL настраивается правило на разрешение, этот ACL будет использовать внешний VIP адрес машины, которая хочет открыть подключение, что изображено на рисунке ниже.

Мы можем выборочно разрешать или запрещать трафик (с портала или Powershell) на виртуальную машину, используя правила типов Permit/Deny. По умолчанию, когда мы создаем точку доступа (порт), на него разрешен весь трафик, поэтому важно понимать принципы создания и конфигурирования правил, а также их приоритезации. Обратим также внимание, что, если вы добавляете одно или более разрешающих правила, вы все еще запрещаете трафик для тех, кто в этих правилах не указан.

clip_image003

Посмотрим, как это работает, на примере с двумя виртуальными машинами, на которых находится фронтенд (они находятся в одном Cloud Service) и одной машине как бэкенде с SQL Server. Нам нужно обеспечить безопасность SQL Server таким образом, чтобы только две фронтендовых машины могли до него достучаться. На рисунке мы видим Cloud Service canis-testvms с публичным VIP адресом 168.62.207.83 , "за" которым работают наши фронтендовые машины canis-testvm1 и canis-testvm2.

clip_image004

На рисунке мы также видим, что фронтендовые машины располагаются в виртуальной сети testvirtualnetwork в своей отдельной подсети FrontEnd.

clip_image005

Бэкендовая машина с SQL Server sql12-01 лежит в виртуальной сети waltervirtualnetwork, в подсети BackEndSubnet.

clip_image006

Теперь нам нужно настроить доступ к машине с SQL Server. Сначала нужно создать точку доступа на порт 1433, с внешним портом 14333. Как писалось выше, стандартный ACL разрешит весь входящий трафик на новый порт, и как раз это мы и будем настраивать.

clip_image007

Нажмем Manage ACL. Диалог Manage Endpoint ACL содержит в себе информацию об ACL. Так, первый ACL, который я добавлю, будет перекрывать стандартный ACL с правилом Deny. Второй ACL, по приоритету выше, я добавлю с указанием VIP-адреса Cloud Service, в котором лежат мои фронтендовые машины. В CIDR-формате это будет равно /32 (168.62.207.83/32), то есть просто один-единственный IP. Для SQL Server обе фронтендовых машины имеют один IP.

clip_image008

Таким образом можно настроить регламенты доступа по внешним VIP-адресам между виртуальными сетями, в которых не используется VPN на внешнюю инфраструктуру.

Опция 3: подсети в разных виртуальных сетях + VPN

С наличием в инфраструктуре VPN общая концепция стандартной изоляции виртуальных сетей не меняется (описано выше), однако добавляются другие опции для обеспечения коммуникаций. Мы рассмотрим это на примере - есть локальные подсети в нескольких виртуальных сетях, и они должны иметь полный доступ к виртуальным машинам в обеих виртуальных сетях по внутреннему DIP-адресу при условии отсутствия блокировки в брандмауэре. Так, у нас будет две виртуальных сети и локальная инфраструктура, и наша цель - чтобы они имели доступ в адресное пространство друг друга. Это можно сделать с помощью настройки локального маршрутизатора как хаба в конфигурации spoke-to-spoke. Маршутизатор будет хабом, spokes - VPN-устройства Site-To-Site на стороне Azure.

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

clip_image009

Дальше нам надо настроить локальный маршрутизатор (у меня Cisco ASA 5505), добавив ACL из одной виртуальной сети в другую. Например, если локальная сеть имеет адресное пространство 192.168.1.0/24 , а одна из виртуальных сетей 10.5.0.0/16, то нам надо будет добавить в ACL запись о доступе из локальной сети в виртуальную сеть, и из 10.5.0.0/16 в 10.4.0.0/16:

access-list AzureAccess extended permit ip 192.168.1.0 255.255.255.0 10.4.0.0 255.255.0.0

access-list AzureAccess extended permit ip 10.5.0.0 255.255.0.0 10.4.0.0 255.255.0.0

То же самое надо будет сделать для сети с 10.5.0.0/16:

access-list AzureAccess2 extended permit ip 192.168.1.0 255.255.255.0 10.5.0.0 255.255.0.0

access-list AzureAccess2 extended permit ip 10.4.0.0 255.255.0.0 10.5.0.0 255.255.0.0

Следующий шаг - настройка NAT между двумя внешними виртуальными сетями:

object-group network VPN_OUT_AZ1

network-object 10.4.0.0 255.255.0.0

object-group network VPN_OUT_AZ2

network-object 10.5.0.0 255.255.0.0

nat (outside,outside) 1 source static VPN_OUT_AZ1 VPN_OUT_AZ1 destination static VPN_OUT_AZ2 VPN_OUT_AZ2 no-proxy-arp route-lookup

Каждая виртуальная сеть будет иметь доступ в другую через шлюз VPN, используя DIP-адрес, учитывая отсутствие запрещающих правил в брандмауэре. Это может не выглядеть как хорошее решение, так как сетевой трафик может ходить туда-обратно через хаб, что выльется в увеличение стоимости решения и дополнительной латентности, но оно вполне рабочее для организаций, которые не хотят выставлять внешние порты и точки доступа. Если же это не так, то можно использовать внешние порты для обеспечения подключения между двумя и более виртуальными сетями, и обезопасить их IPSec и Group Policy Objects.

clip_image010

Обеспечение безопасности с помощью Windows Firewall/IPsec

С IPSec в Windows Firewall with Advanced Security мы имеем простой механизм для обеспечения коммуникаций, которые должны быть правильным образом аутентифицированы и защищены. Этот механизм является, тем не менее, масштабируемым и позволяет обеспечить целостность данных и, опционально, защитить данные от доступа извне. IPSec использует криптографию для защиты коммуникаций поверх IP.

В качестве примера у нас есть две виртуальных сети, машина с DIP-адресом 10.5.1.5, локальный домен (машина не в нем), и IPSec-сертификат, который можно настроить в Windows Firewall with Advanced Security или PowerShell. Это означает, что любая машина, которая захочет получить доступ к защищенным точкам доступа, должна будет иметь IPSec-сертификат. Еще у нас есть две машины в домене, 10.4.1.6 и 10.5.1.4, которые можно настроить так, чтобы для подключения им нужно было бы обеспечить IPSec (в Windows Firewall, PowerShell или групповых политиках). Эти машины могут быть защищены вне зависимости от того, получается ли к ним доступ через внутренние DIP-адреса или через внешние VIP. Для внешних VIP можно использоавть ACL, создав белый список разрешенных IP-адресов.

clip_image011

Применяем IPSec к одной виртуальной машине вручную

Для обеспечения максимальной защиты виртуальной машины в виртуальной сети можно поднять Windows Firewall и настроить его на запрет всех входящих подключений, после чего открывать порты по необходимости и настраивать для них IPSec. Для того, чтобы вручную настроить IPSex в Windows Server 2008 (и позже), надо запустить Windows Firewall и создать в Inbound Rules новое правило.

clip_image012

Дальше можно выбрать определенные порты и защитить их IPSec.

clip_image013

По нажатию на Customize… надо настроить использование IPSec.

clip_image013[1]

clip_image014

Это все, что нужно сделать для ручной настройки IPSec.

Настройка IPSec с помощью групповых политик

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

Для того, чтобы настроить групповые политики, добавим вошедшие в домен серверы в OU Azure Server.

clip_image015

Приведем брандмауэр машины (не контроллера домена) к виду как на рисунке ниже.

clip_image016

На контроллере домена запустим оснастку Group Policy Management и, в нужном домене (в нашем случае canisnetworks.com) создадим новый объект в разделе Group Policy Objects.

clip_image017

Настроим GPO.

clip_image018

Теперь я сделаю две вещи:

  1. Включу Domain Profile.
  2. Настрою порт мониторинга SCOM 5723 на использование IPSec.

Первое можно сделать в Computer Configuration | Policies | Windows Settings | Windows Firewall with Advanced Security | Windows Firewall Properties.

clip_image019

Теперь надо раскрыть раздел Windows Firewall и выбрать Inbound Rules. Сейчас здесь пусто.

clip_image020

Создадим правило.

clip_image021

Повторив шаги, сделанные ранее, я теперь выберу Port rule.

clip_image022

В Protocol and Ports введу номер порта. На странице Action выберу Allow the connection if it is secure option .

clip_image023

Все остальное оставим по умолчанию.

clip_image024

Выберем Domain Profile на странице Profile.

clip_image025

Закроем редактор - мы создали и настроили GPO.

clip_image026

Теперь нужно прилинковать этот GPO к OU с нашими серверами. Сделаем это, нажав правой кнопкой на OU и нажав Link an Existing GPO….

clip_image027

В Select GPO выберем наш GPO и нажмем OK.

clip_image028

Теперь применим GPO к виртуальной машине - выполним из нее команду gpupdate /force.

clip_image029

Проверим результат применения политики командой gpresult /r /scope computer.

clip_image030

Откроем Windows Firewall и проверим, оба ли объекта GP на месте и включен ли Domain Profile.

clip_image031

Проверим также наше правило на порт 5723 в разделе Inbound Rules.

clip_image032

Вот и все.

Ограничение исходящего из виртуальных машин трафика

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

Начнем с виртуальной машины, на которой установлен SQL Server, с Windows Firewall with Advanced Security.

clip_image033

Сейчас машина может выходить в интернет. Нам нужно ограничить ее доступ таким образом, чтобы она могла выходить только в локальную инфраструктуру по VPN 192.168.1.0/24. По умолчанию же, как уже говорилось, весь исходящий трафик разрешен.

clip_image034

Сменим настройку на Block.

clip_image035

Интернет для нашей виртуальной машины теперь закрыт.

clip_image036

Перейдем в раздел Outbound Rules и создадим новое правило типа Custom.

clip_image037

На странице Program оставим настройки.

clip_image038

На странице Protocol and Ports выберем TCP.

На Scope выберем опцию “These IP addresses:” и нажмем Add….

clip_image039

В диалоге укажем нашу подсеть.

clip_image040

На странице Action выберем “Allow the connection”.

clip_image041

На странице Profile выберем Domain.

clip_image042

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

clip_image043

clip_image036[1]

Таким образом мы ограничили виртуальную машину от доступа в интернет, но теперь мы не можем достучаться и до машин, расположенных в Microsoft Azure. Это решается добавлением IP-адресов или диапазонов в правило, созданное нами ранее. Например, я хочу открыть доступ на pcv94pjwnj.database.windows.net.

clip_image044

Я пингую сервер, чтобы получить его IP.

clip_image045

И добавляю этот IP в белый список IP-адресов в правиле.

clip_image046

Теперь доступ к серверу открыт.

clip_image047

Если я хочу указать диапазон IP, используемых в Microsoft Azure, то список этих диапазонов доступен здесь -  here.  Диапазонов много, поэтому будет лучше подходить к открытию доступа к ним избирательно и добавлять только те записи, которые действительно должны использоваться и принадлежат вашему датацентру.

clip_image048

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

Резюме

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

Ссылки