| Новые программы oszone.net |  |
Изоляция приложений и инфраструктуры - это важный момент в корпоративных развертываниях. Корпоративные клиенты ищут средства для защиты своих инфраструктур от неавторизованного или нежеланного доступа. Например, классический сценарий, в котором есть фронтенд и бэкенд, и машины в определенной сети или подсети должны быть доступны только конкретным клиентам или компьютерам по конкретному порту, плюс должна быть проверка по IP клиента - находится ли он в белом списке. Все это можно сделать в Microsoft Azure, как в случае регламентирования доступа внешних клиентов виртуальных машин, так и из локальной инфраструктуры по VPN. Изоляция машин - опции Существует три основных опции изоляции виртуальных машин друг от друга:
По умолчанию виртуальные машины под управлением Windows Server имеют два уже настроенных открытых порта: RDP и Remote PowerShell. Любые другие порты и точки доступа должны быть открыты внешним образом администратором, и все точки доступа могут иметь регламентированный с помощью Access Control Lists доступ. Механизм работы ACL ACL - это объект, состоящий из списка правил. При создании и применении ACL к порту виртуальной машины происходит применение фильтра пакетов на уровне хостового узла виртуальной машины, что означает, что трафик с удаленных IP будет фильтроваться на уровне хостового узла, не доходя до виртуальной машины. Это важно, так как убирает нагрузку на виртуальную машину, которая могла бы возникнуть при фильтрации пакетов. После создания виртуальной машины применяется стандартный ACL, блокирующий весь входящий трафик. В этом ACL прописываются правила для создаваемых портов (например, RDP). Отметим также, что, как было указано выше, при создании виртуальной машины автоматически создаются порты для Powershell и RDP, и для них используются стандартные порты внутри виртуальной машины, но внешние порты (для внешних клиентов) конфигурируются случайным образом. Входящий трафик, таким образом, лимитируется только этими пор��ами, и конфигурировать вручную брандмауэр уже не надо. Исходящий трафик разрешен.
С помощью ACL можно:
Таким образом, ACL-ы - это ключевой механизм регламентирования доступа и защиты портов виртуальных машин. Опция 1: Подсети внутри одной виртуальной сети В Microsoft Azure можно настроить маршрутизацию на основе подсетей внутри одной виртуальной сети, но при этом нельзя создать ACL на внутренние DIP-адреса (частные адреса, выдаваемые виртуальным машинам системой). Для регламентирования доступа к машинам внутри одной виртуальной сети на тих машинах нужно настроить Windows Firewall with Advanced Security, как, например, на рисунке.
Для защиты сервера брандмауэр можно настроить на блокировку всех входящих подключений с учетом:
В этом случае исключения брандмауэра будут включать локальные DIP (Dynamic IP) внутри их собственных подсетей и других подсетей, входящих в виртуальную сеть, все же внешние порты будут обезопасены ACL-ами. Исключения в брандмауэре, разумеется, должны включать в себя локальные порты, на которые происходит форвардинг с внешних портов, настроенных в ACL. Опция 2: подсети в разных виртуальных сетях Для изоляции виртуальных машин из разных сетей, или виртуальных машин от серверов, расположенных вне виртуальных сетей, можно использовать ACL. Этот подход естественен для изоляции приложений в Azure, так как по умолчанию, как уже было сказано, единственное, что разрешено сразу на виртуальных машинах - это порты для RDP и Powershell. Для виртуальной машины Azure, которая хочет подключиться к другой машине в другой виртуальной сети, ее VIP (внешний адрес) будет рассматриваться как DIP-адрес внутри одной сети. Поэтому, когда в ACL настраивается правило на разрешение, этот ACL будет использовать внешний VIP адрес машины, которая хочет открыть подключение, что изображено на рисунке ниже. Мы можем выборочно разрешать или запрещать трафик (с портала или Powershell) на виртуальную машину, используя правила типов Permit/Deny. По умолчанию, когда мы создаем точку доступа (порт), на него разрешен весь трафик, поэтому важно понимать принципы создания и конфигурирования правил, а также их приоритезации. Обратим также внимание, что, если вы добавляете одно или более разрешающих правила, вы все еще запрещаете трафик для тех, кто в этих правилах не указан.
Посмотрим, как это работает, на примере с двумя виртуальными машинами, на которых находится фронтенд (они находятся в одном Cloud Service) и одной машине как бэкенде с SQL Server. Нам нужно обеспечить безопасность SQL Server таким образом, чтобы только две фронтендовых машины могли до него достучаться. На рисунке мы видим Cloud Service canis-testvms с публичным VIP адресом 168.62.207.83 , "за" которым работают наши фронтендовые машины canis-testvm1 и canis-testvm2.
На рисунке мы также видим, что фронтендовые машины располагаются в виртуальной сети testvirtualnetwork в своей отдельной подсети FrontEnd.
Бэкендовая машина с SQL Server sql12-01 лежит в виртуальной сети waltervirtualnetwork, в подсети BackEndSubnet.
Теперь нам нужно настроить доступ к машине с SQL Server. Сначала нужно создать точку доступа на порт 1433, с внешним портом 14333. Как писалось выше, стандартный ACL разрешит весь входящий трафик на новый порт, и как раз это мы и будем настраивать.
Нажмем Manage ACL. Диалог Manage Endpoint ACL содержит в себе информацию об ACL. Так, первый ACL, который я добавлю, будет перекрывать стандартный ACL с правилом Deny. Второй ACL, по приоритету выше, я добавлю с указанием VIP-адреса Cloud Service, в котором лежат мои фронтендовые машины. В CIDR-формате это будет равно /32 (168.62.207.83/32), то есть просто один-единственный IP. Для SQL Server обе фронтендовых машины имеют один IP.
Таким образом можно настроить регламенты доступа по внешним VIP-адресам между виртуальными сетями, в которых не используется VPN на внешнюю инфраструктуру. Опция 3: подсети в разных виртуальных сетях + VPN С наличием в инфраструктуре VPN общая концепция стандартной изоляции виртуальных сетей не меняется (описано выше), однако добавляются другие опции для обеспечения коммуникаций. Мы рассмотрим это на примере - есть локальные подсети в нескольких виртуальных сетях, и они должны иметь полный доступ к виртуальным машинам в обеих виртуальных сетях по внутреннему DIP-адресу при условии отсутствия блокировки в брандмауэре. Так, у нас будет две виртуальных сети и локальная инфраструктура, и наша цель - чтобы они имели доступ в адресное пространство друг друга. Это можно сделать с помощью настройки локального маршрутизатора как хаба в конфигурации spoke-to-spoke. Маршутизатор будет хабом, spokes - VPN-устройства Site-To-Site на стороне Azure. Для настройки этой конфигурации нам нужно настроить локальную сеть, соответствующую настроенной виртуальной сети в облаке, для того, чтобы наши сети могли видеть адресное пространство друг друга, что можно увидеть на рисунке. Для каждой локальной сети у меня есть адресное пространство 192.168.1.0/24 , и дополнительное адресное пространство для каждой виртуальной сети, которая соответствует сети, к которой нужно получить доступ.
Дальше нам надо настроить локальный маршрутизатор (у меня 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.
Обеспечение безопасности с помощью 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-адресов.
Применяем IPSec к одной виртуальной машине вручную Для обеспечения максимальной защиты виртуальной машины в виртуальной сети можно поднять Windows Firewall и настроить его на запрет всех входящих подключений, после чего открывать порты по необходимости и настраивать для них IPSec. Для того, чтобы вручную настроить IPSex в Windows Server 2008 (и позже), надо запустить Windows Firewall и создать в Inbound Rules новое правило.
Дальше можно выбрать определенные порты и защитить их IPSec.
По нажатию на Customize… надо настроить использование IPSec.
Это все, что нужно сделать для ручной настройки IPSec. Настройка IPSec с помощью групповых политик Если виртуальные сети подключены к локальной инфраструктуре по VPN, машины в этих сетях могут становиться членами локального домена. После входа на них можно применить групповую политику таким образом, чтобы к ним применялись политики IPSec. Для того, чтобы настроить групповые политики, добавим вошедшие в домен серверы в OU Azure Server.
Приведем брандмауэр машины (не контроллера домена) к виду как на рисунке ниже.
На контроллере домена запустим оснастку Group Policy Management и, в нужном домене (в нашем случае canisnetworks.com) создадим новый объект в разделе Group Policy Objects.
Настроим GPO.
Теперь я сделаю две вещи:
Первое можно сделать в Computer Configuration | Policies | Windows Settings | Windows Firewall with Advanced Security | Windows Firewall Properties.
Теперь надо раскрыть раздел Windows Firewall и выбрать Inbound Rules. Сейчас здесь пусто.
Создадим правило.
Повторив шаги, сделанные ранее, я теперь выберу Port rule.
В Protocol and Ports введу номер порта. На странице Action выберу Allow the connection if it is secure option .
Все остальное оставим по умолчанию.
Выберем Domain Profile на странице Profile.
Закроем редактор - мы создали и настроили GPO.
Теперь нужно прилинковать этот GPO к OU с нашими серверами. Сделаем это, нажав правой кнопкой на OU и нажав Link an Existing GPO….
В Select GPO выберем наш GPO и нажмем OK.
Теперь применим GPO к виртуальной машине - выполним из нее команду gpupdate /force.
Проверим результат применения политики командой gpresult /r /scope computer.
Откроем Windows Firewall и проверим, оба ли объекта GP на месте и включен ли Domain Profile.
Проверим также наше правило на порт 5723 в разделе Inbound Rules.
Вот и все. Ограничение исходящего из виртуальных машин трафика По понятным причинам общеиспользуемой корпоративными пользователями практикой является ограничение исходящего трафика с серверов, особенно находящихся в бэкенде и оперирующих важными данными. В публичном облаке это обретает еще большую важность, так как клиент проявляет большую степень доверия, просто выбирая облачного провайдера как опцию, и не хочет, чтобы безопасность была ниже, нежели его локальная. Ниже мы рассмотрим, как ограничить исходящий из виртуальной машины трафик. Мы почти не будем использовать групповые политики, хотя кое-где они все же будут. Начнем с виртуальной машины, на которой установлен SQL Server, с Windows Firewall with Advanced Security.
Сейчас машина может выходить в интернет. Нам нужно ограничить ее доступ таким образом, чтобы она могла выходить только в локальную инфраструктуру по VPN 192.168.1.0/24. По умолчанию же, как уже говорилось, весь исходящий трафик разрешен.
Сменим настройку на Block.
Интернет для нашей виртуальной машины теперь закрыт.
Перейдем в раздел Outbound Rules и создадим новое правило типа Custom.
На странице Program оставим настройки.
На странице Protocol and Ports выберем TCP. На Scope выберем опцию “These IP addresses:” и нажмем Add….
В диалоге укажем нашу подсеть.
На странице Action выберем “Allow the connection”.
На странице Profile выберем Domain.
Теперь, после создания этого правила, я могу подключиться к локальному SQL Server или любому серверу , размещенному в локальной инфраструктуре, однако к внешнему интернету доступ закрыт.
Таким образом мы ограничили виртуальную машину от доступа в интернет, но теперь мы не можем достучаться и до машин, расположенных в Microsoft Azure. Это решается добавлением IP-адресов или диапазонов в правило, созданное нами ранее. Например, я хочу открыть доступ на pcv94pjwnj.database.windows.net.
Я пингую сервер, чтобы получить его IP.
И добавляю этот IP в белый список IP-адресов в правиле.
Теперь доступ к серверу открыт.
Если я хочу указать диапазон IP, используемых в Microsoft Azure, то список этих диапазонов доступен здесь - here. Диапазонов много, поэтому будет лучше подходить к открытию доступа к ним избирательно и добавлять только те записи, которые действительно должны использоваться и принадлежат вашему датацентру.
Вот и все. Теперь то, как настраивать исходящий доступ, должно быть полностью понятно. Учитывайте, что периодически диапазоны Azure меняются, поэтому стоит проверять список раз в пару месяцев, иначе может получиться ситуация, когда нужный ресурс не будет доступен в связи с его отсутствием в белом списке. Резюме Мы рассмотрели несколько методов защиты виртуальных машин в Azure. В связи с тем, что машины в Azure могут быть настроены как расширение вашей локальной инфраструктуры, вы можете накрыть их текущими политиками безопасности, используемыми для локальной инфраструктуры. Ссылки
Теги:
Виртуальные машины.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
