Битва титанов безопасного удаленного доступа UAG DirectAccess против WS 2012 DirectAccess (часть 1)

Мы всегда были большими поклонниками удаленного доступа здесь, в «комплексе Шиндер» в Техасе. Я помню, как мы впервые собрали сервер маршрутизации и удаленного доступа на базе Windows NT 4 и настроили его как VPN-сервер PPTP. В то время мы никогда раньше не пользовались VPN и не знали, чего от него ожидать. В то время у нас не было двух подключений к Интернету (у нас была только одна телефонная линия POTS) в нашем доме, поэтому мы решили, что это хороший предлог, чтобы отправиться в короткий отпуск в отель, в котором были «модемные порты», к которым мы могли бы подключить ноутбук IBM и проверить соединение VPN.

Мы добрались до отеля и подключили ноутбук к порту модема. Первое, что нам нужно было выяснить, это номер телефона нашего интернет-провайдера, чтобы мы могли подключиться к Интернету. В «дни динозавров» 1990-х все было не так, как сегодня, с практически повсеместным подключением к Интернету (по крайней мере, в городских районах США). К счастью, я смог позвонить своему сыну домой, и он смог прочитать мне номер телефона в настройках интерфейса вызова по требованию на сервере. Я ввел информацию для коммутируемого доступа для коммутируемого клиента на своем компьютере с Windows 95 и установил соединение.

Мы с нетерпением ждали, когда модем подключится к интернет-провайдеру, издавая звук резиновой арфы, когда он согласовал сверхбыстрое (для того времени) соединение со скоростью 28,8 Кбит/с. Настал момент истины — будет ли работать VPN-подключение? И если это произойдет, как я узнаю? Смогу ли я на самом деле получить файлы, которые находятся на моем компьютере дома, даже если я нахожусь в отеле в 20 милях от меня? Я запустил программное обеспечение VPN-клиента и нажал «Подключиться». Казалось, что происходит что-то хорошее, поэтому я ввел UNC-путь к папке на своей рабочей станции дома и почти как по волшебству получил доступ к файлам на своем домашнем компьютере!

Что было тогда; это - сейчас

Сейчас мы все воспринимаем это как должное. Виртуальные частные сети — довольно обычная штука в облачном мире. Удаленный доступ к файлам, папкам, веб-сайтам и любой необходимой информации — тривиальное дело. Существует множество различных способов получить удаленный доступ к вашей информации. Вы можете настроить VPN-сервер с помощью Windows, вы можете настроить дешевый маршрутизатор NAT для работы в качестве VPN-сервера, вы можете опубликовать свой компьютер через публикацию удаленного рабочего стола, вы можете настроить сервер удаленного рабочего стола и шлюз. Или вы можете просто поместить всю свою информацию в облачную систему хранения, такую как Microsoft SkyDrive, и даже не беспокоиться о включении удаленного доступа к частной сети; просто подключитесь к облачному ресурсу и готово.

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

Тот старый VPN

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

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

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

VPN 2.0

Поиски лучшего пути увенчались успехом в первой половине первого десятилетия двадцать первого века. Решение было названо «SSL VPN». Как и в случае с «облаком» сегодня, SSL VPN был несколько расплывчатым термином, который использовался для описания всего, что позволяло пользователям удаленный доступ к корпоративным ресурсам через SSL-соединение. Неважно, было ли это на самом деле VPN-подключение; это нужно было сделать только через SSL, чтобы получить ярлык. И когда дело дошло до их «новейших и лучших» SSL VPN, поставщики распространяли массу шумихи, что объясняет, почему эти решения, как правило, были такими дорогостоящими.

Что такое SSL VPN? SSL VPN обычно обеспечивают подключение удаленного доступа через SSL с использованием одного или нескольких из следующих методов:

• Обратный прокси. Да все верно. Многие поставщики думали, что было бы здорово назвать решение для обратного прокси-сервера SSL SSL VPN! Используя это определение, вы могли бы назвать ISA Server 2004 решением SSL VPN, поскольку оно поддерживает обратный веб-прокси для соединений SSL. Большинство технических специалистов не были обмануты этим и считали SSL VPN на основе обратного веб-прокси не более чем маркетинговой рекламой.
• Перенаправление портов и сокетов. Этот тип SSL VPN может использовать часть программного обеспечения на стороне клиента для перехвата определенных портов и сокетов, а затем заключать их в заголовок SSL. Затем заголовок SSL удаляется из соединения в точке сервера SSL VPN и перенаправляется в пункт назначения. Проблема в том, что поставщики SSL VPN заявляли, что SSL VPN «без клиента». Кроме того, это не настоящее VPN-решение, поскольку в сети назначения не установлено PPP-соединение виртуальной сети. Опять же, это пахло и ощущалось как шумиха.
• Инкапсуляция протокола. Этот метод использует тот факт, что вы можете инкапсулировать практически любой протокол в заголовок HTTP, а затем зашифровать его с помощью TLS и использовать для доступа к сети TCP-порт 443. Вот как исходная и последующие версии протокола RPC/HTTP работают для Outlook и Exchange. Это довольно изящно. К сожалению, вам необходимо иметь шлюз протокола для каждого протокола, который вы хотите использовать, а оболочка протокола должна быть встроена в клиентское приложение. Конечным результатом является то, что вы можете получить доступ к некоторой информации в корпоративной сети, но это далеко не обычный «сетевой» опыт.
• Настоящий SSL-VPN. Некоторые поставщики фактически предоставляют настоящее решение SSL VPN. Под «верным» я подразумеваю, что настоящее согласование PPP происходит после того, как SSL-соединение установлено с сервером SSL VPN. После согласования клиент получает виртуальное сетевое подключение к сети назначения и ему назначается действительный IP-адрес в этой сети. Доступны все протоколы, как и в традиционной VPN. После того, как утихла шумиха вокруг всего повального увлечения SSL VPN, Microsoft впоследствии выпустила протокол Secure Socket Tunnel Protocol (SSTP), который обеспечивает настоящее соединение SSL VPN, и включил клиент в клиенты Windows 7 и выше.

SSL VPN были популярны в течение короткого периода времени, поскольку обещали быть более гибкими, чем традиционные VPN. Проблема с ними в том, что они никогда не были по-настоящему «бесклиентными» и стоят непомерно дорого. Опять же, должен был быть лучший способ.

Введите RDP

Службы терминалов были тем, чем многие люди впервые с удовольствием пользовались при работе в корпоративной сети. Они могли получить доступ к полной среде рабочего стола, подключившись к терминальному серверу. Но что, если бы вы могли делать то же самое через Интернет? Несмотря на то, что клиентская система находилась в Интернете и не имела прямого подключения к корпоративной сети, клиент мог подключиться к системе, уже находящейся в корпоративной сети, и работать на той системе, которая имела полный доступ к сети. Это обеспечивает жизнеспособное решение для удаленного доступа.

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

Решение для удаленного рабочего стола можно дополнительно улучшить, воспользовавшись преимуществами шлюза служб терминалов. Таким образом, конечные пользователи могут использовать соединение SSL (которое инкапсулирует протокол RDP) для подключения к шлюзу служб терминалов, а затем шлюз или сопутствующее устройство могут выступать посредниками в соединениях, чтобы убедиться, что соединение перенаправлено на соответствующий терминал. сервер. Это оказывается достойным решением. Но он по-прежнему требует, чтобы пользователь «сделал что-то», чтобы это произошло. Это не совсем прозрачное решение.

Удаленный доступ сделан правильно

Казалось, что мы становились все ближе и ближе к тому, чего мы хотим и что нужно нашим пользователям, но, казалось, мы так и не достигли этого. Затем эти дни подошли к концу, когда Microsoft представила решение, отвечающее всем нашим требованиям как сетевых администраторов и администраторов безопасности, а также отвечающее всем требованиям наших пользователей. Это решение — DirectAccess.

И именно с этого мы начнем во второй части этой серии статей. Мы поговорим о DirectAccess как о безопасном решении для удаленного доступа, а затем перейдем к сути дела: какую форму DirectAccess следует использовать: UAG DirectAccess или Windows Server 2012 DirectAccess? У них схожие возможности и функции, но что их отличает? Оставайтесь с нами во второй части, где мы начнем битву титанов: UAG против Windows Server 2012 DirectAccess. Тогда увидимся! – Деб.