Подключение к корпоративному облаку

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

Рисунок 1. Подключение к облачным сервисам / IaaS-инфраструктуре

Подключение конечных пользователей к облачным сервисам

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

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

• RDP-клиент.
• RemoteApp.
• Веб-доступ.
• Remote access VPN.
• VPN site-to-site.
• DirectAccess.
• VDI.

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

RDP-клиент (подключение посредством удаленного рабочего стола)

Удаленный рабочий стол — это один из наиболее распространенных, удобных, универсальных и часто используемых инструментов, дающих возможность удаленного доступа к рабочему месту, которое развернуто в том числе и в облаке.

В основе такого типа доступа лежит RDP (Remote Desktop Protocol) — проприетарный протокол прикладного уровня. Именно он обеспечивает удаленную работу пользователя с компьютером, на котором запущен сервис терминального доступа. На сегодняшний день существуют клиенты практически для всех операционных систем семейства Windows, Linux, FreeBSD, Mac OS X, iOS, Android, Symbian. Клиента удаленного рабочего стола можно дополнительно конфигурировать. Пользователь может сохранить свой логин/пароль, чтобы при подключении не вводить их каждый раз заново. Однако с точки зрения безопасности лучше этого не делать. Также можно настроить параметры экрана, раскладки клавиатуры, звуков проигрывания и прочее. Если есть необходимость в использовании локальных ресурсов компьютера, с которого выполняется подключение к удаленному рабочему столу, и буфер обмена — так и это «пожалуйста». Помимо описанных выше опций, пользователь может менять параметры графики, что в случае низкой скорости Интернета сделает работу более комфортной.

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

Но как обстоит дело с безопасностью и насколько такое подключение может считаться надежным? Если при подключении по RDP выбрать настройки по умолчанию, при реализации удаленного доступа будет использоваться слабое шифрование и трафик может быть расшифрован по пути. Однако существует ряд дополнительных методов, которые помогут защитить и оптимизировать RDP. Примером является технология Remote Desktop Gateway (шлюза удаленных рабочих столов), ранее известная как шлюз служб терминалов (Terminal Services Gateway, TSG).

Remote Desktop Gateway (шлюз удаленных рабочих столов) представляет собой инструмент, посредством которого удаленные авторизованные пользователи смогут подключаться как к ресурсам физической сети предприятия, так и к сети в облаке IaaS-провайдера.

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

RemoteApp (удаленные приложения служб терминалов)

Решение RemoteApp является разновидностью рассмотренного выше варианта. В чем сходства и отличия?

Дело в том, что RemoteApp — это инструмент, который позволяет организовать удаленный доступ к установленным приложениям на сервере в облаке.

Клиент по-прежнему может использовать приложения, как если бы они были установлены локально. Если на данном этапе повествования разница не совсем очевидна, двигаемся дальше.

Рассматривая вариант с RDP, мы говорили о непосредственномподключении к удаленному рабочему столу, дающему возможность работы с экземпляром операционной системы. Пользователь видит рабочий стол, программы, иконки, панель управления и прочее. С вариантом RemoteApp дело обстоит иначе: пользователь видит только запущенное удаленное приложение в рамках своего физического устройства. Клиент, к примеру, запускает ярлык Microsoft Word, расположенный на рабочем столе своего локального компьютера, после чего инициируется процесс проверки подлинности. При этом Word не установлен на локальной станции пользователя. После успешной аутентификации/авторизации приложение запускается и готово к работе. Как это реализовано? На удаленном сервере «публикуется» приложение. А при запуске ярлыка средствами RemoteApp происходит подключение к удаленному серверу. В рамках запуска ярлыка приложения формируется RDP-сессия, после чего стартует и запускается само приложение без возможности отображения удаленного рабочего стола. Этот процесс для пользователя создает эффект локальной установки приложения. Данный вариант будет полезен, к примеру, в следующих случаях:

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

Как выглядит со стороны пользователя: для пользователя запускаемые удаленные приложения служб терминалов выглядят так, как если бы они исполнялись непосредственно в системе пользователя. Отображается НЕ рабочий стол удаленной системы с запущенными на ней приложениями, а приложения интегрируются в рабочий стол системы пользователя с масштабированием окна и собственным значком приложения в панели задач.

Веб-доступ к службам терминалов

Доступ к определенным приложениям и рабочим столам в облаке (оба рассмотренных ранее варианта) можно организовать с помощью браузера, который сегодня установлен на подавляющем большинстве устройств. Для пользователя такой вариант выглядит следующим образом: запускает браузер, вводит необходимый адрес, проходит проверку подлинности, а далее работает с «опубликованным» приложением/приложениями или удаленным рабочим столом/столами. При этом ярлыки приложений размещаются на предварительно настроенной веб-странице.

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

Еще одним вариантом подключения к облачным сервисам является подключение VPN.

Напомним, что VPN (Virtual Private Network) представляет собой виртуальную частную сеть, являясь обобщенным названием технологии, позволяющей обеспечить одно или несколько надежных сетевых соединений поверх такой небезопасной сети, как Интернет, используя при этом различные средства криптографии.

Существует два типа VPN-туннелей: Remote access VPN и Site-to-site VPN. Рассмотрим каждый из них более подробно.

Remote access VPN

Еще одним удобным, безопасным и достаточно часто используемым инструментом подключения к ресурсам облака является Remote access VPN.

Remote access VPN — означает, что надежный, защищенный туннель организуется между приложением на компьютере клиента и каким-либо устройством (например, VPN-концентратором, маршрутизатором, Cisco ASA и т. п.), расположенном, в нашем случае, в облаке хостинг-провайдера.

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

Рисунок 2. Пример подключения Remote access VPN

Как указано на рисунке 2, для доступа к ресурсам файлового сервера в облаке каждому пользователю необходимо использовать VPN-подключение. После успешной аутентификации и авторизации пользователь получает доступ к File_server1.

Site-to-site VPN

Однако возможен и такой сценарий: сотрудникам компании из своей не виртуализированной, не облачной инфраструктуры необходимо подключение к ресурсу в облаке.

Как бы это выглядело при уже знакомой реализации Remote access VPN?

Рисунок 3. Пример реализации VPN-подключения к ресурсу в облаке

Как видно из рисунка 3, каждый пользователь, прежде чем получить доступ к ресурсам в облаке, устанавливает отдельное VPN-подключение к VPN-серверу, а затем обращается к ресурсам файлового сервера File_server1. А как это же самое выглядит при Site-to-site VPN? Начнем, пожалуй, с определения.

Site-to-site VPN — подразумевает наличие двух устройств (например, VPN Server 1 и VPN Server 2 рисунка 4), между которыми устанавливается туннель. В этом случае пользователи находятся за устройствами, в локальных сетях, и на их компьютерах не требуется установка какого-либо специального программного обеспечения.

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

Рисунок 4. Пример реализации Site-to-Site VPN-соединения

В таком сценарии пользователь обращается к ресурсу в облаке напрямую. В нашем примере к ресурсу File_server1 в подсети облака при таком обращении VPN Server 1 устанавливает VPN-соединение с сервером VPN Server 2 в облаке, после чего пользователь видит содержимое запрашиваемого ресурса. На стороне клиента при этом отпадает необходимость создания исходящего VPN-подключения. Такая конфигурация носит название Site-to-Site VPN.

DirectAccess

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

DirectAccess позволяет реализовать возможность удаленного доступа к ресурсам корпоративной сети следующим образом: как только компьютер пользователя подключается к сети Интернет, он сразу получает доступ и к ресурсам Интернета, и ко всей корпоративной сети.

Т. е. пользовательский компьютер, сконфигурированный в качестве клиента DirectAccess, автоматически устанавливает туннель до сервера DirectAccess и через него получает доступ ко всей корпоративной сети. При этом от пользователя не требуется никаких дополнительных действий.

Туннель между клиентом и сервером DirectAccess устанавливается автоматически, и этот процесс для пользователя абсолютно прозрачен. Не нужно запускать какие-либо VPN-соединения, не нужно вводить учетные данные — логин и пароль, пин-код для смарт-карты и пр. Более того, если связь с Интернетом на какое-то время теряется (и при этом, естественно, разрывается туннель), а затем восстанавливается, то опять же автоматически, без участия пользователя восстанавливается и туннель в корпоративную сеть.

VDI (виртуализация рабочих столов)

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

Со стороны клиента все так же просто: необходимо наличие интернет-соединения и настольного ПК / ноутбука / мобильного телефона / планшета. При соблюдении этих условий пользователь имеет доступ к своему виртуальному рабочему месту из любой точки мира, и это заслуга VDI.

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

Выделяется сервер в облаке IaaS-провайдера, на который устанавливается гипервизор. На нем, в свою очередь, разворачиваются отдельные виртуальные машины — как правило, с клиентской ОС. На конечном устройстве пользователя запускается программа-клиент и происходит подключение к инфраструктуре. Такой тип подключения, на первый взгляд, мало чем отличается от RDP-подключения. Но в чем же разница? В случае RDP-подключения к терминальному серверу — это отдельная сессия на общем сервере Windows.

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

При работе в терминальном режиме изоляция происходит на уровне сессии, и если приложение вызывает сбой на уровне самой ОС, то вместе с пользователем, запустившим такое приложение, перезагрузятся и остальные пользователи, работающие на этом же сервере. А при использовании виртуализации десктопов перезагружена будет только одна виртуальная машина.

Подключение конечных пользователей к облачным сервисам

Подключение локальной инфраструктуры компании к IaaS-инфраструктуре в облаке

Помимо рассмотренных выше вариантов подключения конечных пользователей к облачным сервисам, существуют и иные задачи, которые касаются вопросов подключения локальной инфраструктуры компании к IaaS-инфраструктуре облака.

Когда такой подход может быть востребован?

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

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

Предлагаем рассмотреть возможные варианты подключения локальной инфраструктуры компании к IaaS-инфраструктуре в облаке:

• аренда выделенного канала и подключение к ЦОД для доступа к облаку;
• проброс своего кабеля до ЦОД;
• использование точек обмена трафиком.

Рассмотрим каждый из вариантов более подробно:

Аренда выделенного канала и подключение к ЦОД для доступа к облаку

Рисунок 5. Пример сценария с выделенным ISP-каналом для доступа к ЦОД в облаке

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

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

Проброс своего кабеля до ЦОД

Рисунок 6. Пример сценария с пробросом собственного кабеля до ЦОД

Внутренняя сеть заказчика и сеть в облаке IaaS-провайдера могут быть соединены пробросом собственного кабеля клиента до ЦОД назначения. Компании, которые нуждаются в высокоскоростных телекоммуникационных каналах, по экономическим соображениям в большинстве случаев предпочли бы ранее рассмотренный нами вариант: аренду каналов или выкуп оптических волокон в уже проложенной линии связи.

Однако повышенные требования к безопасности и эксплуатационным показателям канала связи вынуждают их делать выбор в пользу прокладки собственной оптической линии.

Использование точек обмена трафиком

Рисунок 7. Пример сценария с использованием точки обмена трафиком

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

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

Наиболее крупными и известными площадками, где размещаются точки обмена трафиком, являются:

• M9 (ул. Бутлерова, д. 7) в Москве
• Большая Морская (ул. Большая Морская 18) в Санкт-Петербурге.

Большинство корпоративных IaaS-провайдеров размещают собственное сетевое оборудование на этих площадках, что значительно упрощает процесс подключения клиентов к облачным ресурсам дата-центров таких поставщиков.

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