//LEARN Online Event

Ok, das ist etwas kurzfristig, aber dennoch den Blogpost wert!

Morgen(!) am 24.4.2014 wird der offizielle //LEARN online Event stattfinden. //LEARN ist gewissermaßen eine von MVPs durchgeführte Follow-Up Veranstaltung zur //BUILD Konferenz, die weltweit auf 8 Sprachen mit dem Support von Microsoft durchgeführt wird. Wer sich also für Neuerungen im Windows Phone Kosmos interessiert, dem sei dieses Event ans Herz gelegt.

Mehr Info zum Event inklusive Themenübersicht gibt es auf dem Blog von MVP Peter Nowak. Zur direkten Anmeldung (keine Sorge, kost nix!) geht es hier.

????? ??????? ???????? ? ??????????? ??????? ? ?????

Это – перевод статьи <http://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 могут быть настроены как расширение вашей локальной инфраструктуры, вы можете накрыть их текущими политиками безопасности, используемыми для локальной инфраструктуры.

Ссылки

Enterprise Mode for Internet Explorer 11

“I used to access to my internal portal everyday and now is not loading properly, how can I go back to IE8?”

This has been one of the most common complains about the usage of Internet Explorer 10 and 11 on Windows 8 for the last year, and the truth is that we have had some friction between the “Legacy Compatibility” and the “Modern Compatibility”.

Your old websites which are using hard-coded Active X controls, old scripting languages and remarkable plug-ins, heroes in another era, are struggling with the new browsers that are based on new technologies, are touch friendly and use more powerful and slightly different script engines. But, you want to take the full advantage of the new technologies.

That’s why we just brought the “Enterprise Mode” for IE 11.

image

Open your Internet Explorer and press “Alt”, go to Tools and there you will find the Enterprise Mode, easy as that.

image

According to Net Applications, Internet Explorer 8 still has more than 20% of the desktop browser market share; despite the fact that IE9, IE10, and IE11 have superseded IE8, many customers still rely on Internet Explorer 8 to run their business.

By providing better backward compatibility for Internet Explorer 8, Internet Explorer 11 with Enterprise Mode is intended to help break this dependency and provide the best of both worlds: A modern, up-to-date browser that helps customers extend their existing investments in older Web apps.

What does Enterprise Mode provide in terms of compatibility?

  • User agent string differences: We have replicated the original IE8 user agent string so Enterprise Mode will make work sites that fail if they can’t recognize IE8 as the browser.
  • Active X controls and other binaries
  • Deprecated functionality, such as CSS Expressions
  • Pre-caching and pre-rendering

Also, why move to IE11 is a better choice? Performance

JavaScript performance in enterprise mode is slightly slower than IE11 but still much faster than IE8.

So now you don’t have an excuse for don’t move to a modern browser anymore :)

  • Documentation and Other Resources:
  • Build session- Better App Compat with Enterprise Mode IE11:  http://channel9.msdn.com/Events/Build/2014/2-559
  • IE 11 in TechNet: http://technet.microsoft.com/en-us/ie/dn262703.aspx
  • TechNet contains updated information for exploring, planning, deploying, managing, and supporting Internet Explorer
  • A section on Enterprise Mode has been added to the Internet Explorer 11 Deployment Guide
  • The Build session on Better App Compat with Enterprise Mode for Internet Explorer 11 is available as a technical overview.
  • Public forums for discussing Enterprise Mode deployment, management, and best practices are available on TechNet Forums.