Сеть и безопасность Azure (часть 2)

Введение

В части 1 этой серии мы начали обсуждение сетевой безопасности Azure с обсуждения основ локального подключения к виртуальной сети Azure. Мы рассмотрели первые два метода, которые вы можете использовать для подключения локальной сети к Azure — клиентское VPN-подключение удаленного доступа и VPN-подключение между сайтами. Подробнее об этих двух типах подключения читайте в этой статье.

Преимущества выделенных каналов WAN

Последний способ подключения, доступный вам для подключения локальной сети к виртуальной сети Azure, — это выделенная ссылка на глобальную сеть. Большинство из нас, «старых» ИТ-специалистов, знакомы с выделенными каналами WAN; мы используем их в течение многих лет. Существует ряд преимуществ доступности, безопасности и производительности при использовании выделенных каналов глобальной сети:

• Выделенные каналы WAN не зависят от Интернета. Это выделенные двухточечные соединения между вашей локальной сетью и сетью поставщика услуг. Это обеспечивает гораздо чем все, что вы могли бы использовать, что зависит от подключения к Интернету.
• Выделенные каналы WAN не работают через «общую» инфраструктуру. Другими словами, ваши соединения между локальной сетью и сетью поставщика услуг не передают трафик для нескольких клиентов. Это означает, что выделенный канал WAN также , чем любое решение для подключения через Интернет.
• Выделенные каналы WAN могут быть (если вы решите заплатить за это) гораздо более производительными, чем решения для подключения, зависящие от Интернета. Уровень производительности определяется соглашениями, которые вы заключаете со своей телефонной компанией, и договоренностями, которые поставщик услуг заключил с телефонной компанией, поэтому существует потенциал для гораздо

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

Как работает ExpressRoute

ExpressRoute предоставляет два типа подключений, которые связывают локальную сеть с виртуальной сетью Azure.

• Ссылки через поставщика сетевых услуг — они используют подключения с многопротокольной коммутацией по меткам (MPLS) для прямой связи вашего сайта с виртуальной сетью Azure.
• Ссылки через поставщика Exchange — эти ссылки включают начальное подключение к сети поставщика Exchange, которая, в свою очередь, подключается к виртуальной сети Azure.

Выбор между поставщиком Exchange или поставщиком сетевых услуг зависит в значительной степени от ваших текущих отношений с телекоммуникационными компаниями и требований к пропускной способности, которые вам потребуются в рамках вашего архитектурного проекта. Это определенно не то, что вы просто хотите «попробовать». Прежде чем инвестировать в ExpressRoute, необходимо очень серьезно отнестись к процессу планирования и проектирования.

Соединения с поставщиками сетевых услуг будут достигать максимальной скорости около 1 Гбит/с. Если вам нужна более высокая пропускная способность (и если вы серьезно относитесь к расширению центра обработки данных в облаке, вы это сделаете), то вы можете использовать подключения через поставщиков Exchange, где максимальная пропускная способность составляет около 10 Гбит/с.

Дополнительные сведения об ExpressRoute можно найти здесь.

Защита подключений ExpressRoute

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

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

Ограничения и предостережения

Существует ряд ограничений, связанных с подключением ExpressRoute к виртуальной сети Azure, но они аналогичны тем, с которыми вы столкнетесь в большинстве решений для выделенных каналов глобальной сети. Например, несмотря на то, что соединение может представлять собой соединение уровня 2 между вашей локальной сетью и виртуальной сетью Azure, это не так. На самом деле это соединения уровня 3, а это означает, что технологии уровня 2, такие как тегирование VLAN 802.1q, не будут работать, поэтому вам необходимо принять это во внимание при разработке решения.

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

• Верите ли вы, что поставщик услуг сети или коммутатора сможет адекватно изолировать вашу выделенную связь по глобальной сети от злоумышленников?
• Верите ли вы, что ваш поставщик облачных услуг может изолировать и защитить виртуальную сеть, чтобы она была защищена от вторжения как со стороны самого поставщика облачных услуг, так и от внешнего злоумышленника?
• Вы хотите разрешить весь входящий и исходящий трафик через локальную сторону выделенного канала глобальной сети? Если нет, понимаете ли вы свой профиль сетевого трафика, чтобы определить, какие подключения можно инициировать как в локальной сети, так и за ее пределами через подключение ExpressRoute?

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

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

• Входящие из Интернета
• Входящие из локальной сети
• Входящие из Интернета через локальную сеть
• Входящий трафик из Интернета через VPN-подключение к локальной сети.

Входящие из Интернета

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

Входящие из локальной сети

После подключения локальной сети к виртуальной сети Azure с помощью ExpressRoute какой трафик вы разрешите входящий из локальной сети в виртуальную сеть Azure? Другими словами, кому и на каких устройствах разрешено инициировать новые подключения из локальной сети к виртуальной сети Azure?

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

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

Например, предположим, что вы размещаете бизнес-приложение в виртуальной сети Azure. Интерфейсный веб-сервер находится в подсети DMZ в виртуальной сети Azure, а сервер бизнес-логики также находится в виртуальной сети Azure (но не в DMZ; сервер бизнес-логики находится в подсети, отдельной от подсети DMZ)., но все еще в той же виртуальной сети Azure). Уровень базы данных находится локально. Это типичный гибридный дизайн приложения.

У локальных клиентов в этом сценарии есть как минимум два возможных способа доступа к этой линии бизнес-приложений:

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

Оба эти варианта работают. Но какой из них будет работать лучше всего для вас? Рассмотрим следующее:

• Клиентские подключения, которые проходят через Интернет:
  • Использовать пропускную способность Интернета
  • Использовать пропускную способность локальной сети
  • Пройдет через установленный корпоративный брандмауэр и/или прокси
  • Потенциально подвержены компрометации через Интернет
  • Подпадают под определенные ограничения доступности Интернета
• Клиентские подключения, которые проходят через подключение ExpressRoute:
  • Использовать выделенную полосу пропускания канала WAN
  • Использовать локальную пропускную способность
  • Будет проходить через локальный шлюз к ExpressRoute.
  • Будут генерироваться расходы из-за ответного трафика из виртуальной сети Azure в локальную сеть.
  • Меньше шансов быть скомпрометированными по сравнению с опцией через Интернет
  • Обеспечьте более высокую доступность, связанную с жестко запрограммированными соглашениями об уровне обслуживания поставщиком сети/биржи и облачного сервиса.

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

Резюме

В этой статье мы обсудили ExpressRoute, который позволяет создать выделенное подключение по глобальной сети к виртуальной сети Azure. ExpressRoute — это способ, с помощью которого большинство корпоративных организаций собираются подключить свою локальную сеть к виртуальной сети Azure для расширения своих центров обработки данных. ExpressRoute имеет много преимуществ по сравнению с удаленным доступом и VPN-подключениями типа «сеть-сеть» в плане доступности, надежности, безопасности и производительности. Затем мы начали обсуждение некоторых вопросов безопасности, которые вам необходимо рассмотреть, начиная с некоторых сценариев управления входящим доступом. В следующей статье мы продолжим обсуждение сценариев входящего доступа, а затем поговорим о том, как создавать зоны безопасности с помощью групп безопасности сети. Тогда увидимся!