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

Введение

С появлением облачных вычислений, и особенно с Microsoft Azure, в сознании многих ИТ-организаций, которые раньше никогда бы не подумали об использовании каких-либо общедоступных облачных служб, многие из нас думают о том, как мы могли бы воспользоваться преимуществами общедоступных облачных служб. Сейчас все больше людей задумываются о том, чтобы воспользоваться преимуществами публичных облачных сервисов, потому что облачные вычисления прошли стадию шумихи, и большинство людей в отрасли знают и понимают новую парадигму облачных вычислений. Прошло всего около 8 лет, но лучше поздно, чем никогда.

Одна из вещей, которая помогла ИТ-организациям действительно задуматься о общедоступных облачных вычислениях, заключалась в том, что они поняли, что когда кто-то говорит «переход в облако», это на самом деле не обязательно означает «переезд». Вместо того, чтобы перемещать ИТ-активы в общедоступное облако, они могут свои центры обработки данных в общедоступное облако. Есть много вещей, которые рекомендуют этот подход, например, потенциальная экономия средств за счет того, что вам не нужно покупать собственное оборудование, не нужно будет строить новый локальный центр обработки данных и не иметь чтобы взять на себя накладные расходы на типичные начальные процессы проектирования, которые включают установку в стойку и стек, а также интеграцию с вашей текущей средой с физической точки зрения.

Таким образом, этот «переход в облако» на самом деле не «переезд» в облако, а скорее «расширение» в облаке. Корпоративные ИТ-отделы могут извлечь выгоду, расширив свою текущую локальную сеть до общедоступного облака. Это действительно не волшебство или революция, если подумать. Мы использовали co-lo объекты в течение многих лет. Большая разница в том, что поставщики облачных услуг, такие как Microsoft, позаботятся обо всем управлении оборудованием за вас. Все, что вам нужно сделать, — это разместить свои ИТ-активы на виртуальных машинах в общедоступной облачной среде Azure.

Модели облачных услуг

На самом деле есть несколько способов воспользоваться общедоступными облачными сервисами. Существует модель обслуживания SaaS, в которой поставщик облачных услуг размещает приложения для вас. Примером этого является Office 365. Также есть PaaS (платформа как услуга), когда поставщик облачных услуг предоставляет вам операционные системы, на которых вы можете развертывать код, так что вам не нужно управлять оборудованием или операционными системами, Azure сделает это за вас. Единственное, о чем вам нужно беспокоиться, это управление вашим кодом.

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

Компания Amazing Web Services заняла лидирующие позиции на рынке поставщиков облачных услуг, поскольку с самого начала сосредоточилась на IaaS. Они поняли, что корпоративные ИТ-отделы еще не в состоянии полностью внедрить услуги PaaS. Для этого есть ряд причин, в том числе тот факт, что мы все еще находимся в состоянии, когда большинство корпоративных организаций в первую очередь заинтересованы в IaaS, когда речь идет о массовом внедрении общедоступных облачных услуг. Microsoft также осознала это, и теперь они вложили огромное количество ресурсов в свой набор функций Azure Infrastructure Services, все спроектированные и разработанные для поддержки общедоступных облачных сервисов IaaS.

Azure и межлокальное подключение

Вы корпоративный ИТ-магазин, заинтересованный в Microsoft IaaS? Если это так, вам, вероятно, интересно узнать о возможностях Azure Infrastructure Services, а также о том, как вы можете расширить свою сеть в общедоступное облако Azure. В службах инфраструктуры Azure есть много-много функций, и вам потребуется, чтобы ваши архитекторы и дизайнеры работали вместе, чтобы сначала понять все возможности, которые могут предложить службы инфраструктуры Microsoft Azure.

Отличным местом для начала является серия Microsoft Infrastructure as a Service Foundations. Этот набор документов предоставляет вам информацию обо всем, что Microsoft в настоящее время может предложить как для локальной, так и для общедоступной облачной инфраструктуры как услуги.

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

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

Подключение локальных ресурсов к Azure

Существует несколько способов подключения сетевых ресурсов к общедоступному облаку Azure.

• Подключения VPN-клиента удаленного доступа (то, что Azure называет подключением «точка-сайт»)
• Туннельный режим IPsec между сайтами VPN
• Выделенные каналы WAN

Подключение VPN-клиента удаленного доступа

Первый вариант, клиентские VPN-подключения удаленного доступа, не подключает всю сеть к общедоступному облаку Microsoft Azure. Это позволяет вам подключаться к виртуальной сети Azure (о которой мы поговорим чуть позже) с помощью клиентского VPN-подключения удаленного доступа, что позволяет подключать отдельные машины к виртуальной сети Azure. Это удобно для удаленного управления виртуальными машинами, расположенными в виртуальной сети Azure. Клиентское VPN-подключение удаленного доступа использует протокол SSTP для подключения к виртуальной сети Azure, и он более безопасен, чем использование альтернативного метода (RDP) для управления виртуальными машинами, расположенными в виртуальной сети Azure.

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

Затем вам нужно будет пройти аутентификацию на виртуальной машине. Учитывая, что для установления VPN-подключения требуется сертификат, вероятность того, что злоумышленник получит доступ к этому сертификату, очень мала. Это отличается от подключения по протоколу RDP, где такие приложения, как «подборщики паролей», потенциально могут скомпрометировать виртуальные машины путем подбора пароля.

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

Туннельный режим IPsec между сайтами VPN

Следующий вариант, туннельный режим IPsec между сайтами VPN, — это то, с чего начинается история подключения «предприятие к общедоступным облачным службам Azure». Виртуальные частные сети «сеть-сеть» существуют уже давно. На каждой стороне подключения (локальной стороне и стороне виртуальной сети Azure) находится «VPN-шлюз». VPN-соединение устанавливается между VPN-шлюзами. Соединение осуществляется через общедоступный Интернет.

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

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

Чтобы гарантировать, что никто не увидит передачу данных через сеть VPN между сайтами, вся информация, передаваемая через Интернет через VPN между сайтами, шифруется с использованием протокола IPsec. Этот уровень шифрования помогает смягчить проблемы безопасности, связанные с передачей привилегированной информации через общедоступный Интернет. Тем не менее, соединения по-прежнему передаются через общедоступный Интернет, и вам нужно будет определить, подходит ли вам соотношение риска и выгоды.

Преимущества и недостатки VPN типа site-to-site

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

Недостатком межсайтовых VPN является то, что они могут быть относительно медленными и ненадежными. Подключения между локальными сетями и виртуальной сетью Azure зависят от подключения к Интернету. Нет никаких гарантий, когда дело доходит до подключения к Интернету. Даже если ваш интернет-провайдер предоставляет вам соглашения об уровне обслуживания (SLA), он не может нести ответственность за все точки между вашей точкой присутствия и самой виртуальной сетью Azure. Microsoft также предоставляет вам SLA, но опять же, SLA применяются только к сетевым проблемам, находящимся под контролем Microsoft, аналогично ситуации с SLA, которую вы имеете с вашим локальным интернет-провайдером.

Вопрос производительности является еще одним важным соображением. Уровни производительности, которые вы увидите для VPN между сайтами, зависят от используемого оборудования. Например, если вы используете брандмауэр Cisco ASA серии 5500, вы увидите, что максимальная производительность VPN между сайтами составляет около 250 Мбит/с. Вы можете подумать, что это очень хорошо для подключения к Интернету, и это так. Но мы говорим здесь о расширении центра обработки данных, и в этом случае скорость 250 Мбит/с явно анемична по сравнению с сетями 10/40 Гбит/с, которые вы, вероятно, построили локально.

Шлюз Microsoft Azure VPN может поддерживать пропускную способность до 200 Мбит/с, если вы решите использовать высокопроизводительный шлюз Azure (который будет стоить больше, чем стандартный VPN-шлюз). Стандартный VPN-шлюз Azure имеет максимальную скорость около 80 Мбит/с. С такими скоростями вы действительно думаете, что больше вычислений для филиалов, чем для корпоративных центров обработки данных.

Резюме

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