Windows Azure изнутри

Трудная задача BYOD: подключение мобильных устройств к корпоративной сети

Грег Оливер
Бруно Теркали

Продукты и технологии:

Microsoft Azure, Azure Mobile Services

В статье рассматриваются:

• поддержка сложных мобильных корпоративных приложений;
• несколько подходов к управлению мобильными идентификациями;
• управление разными категориями контактов.

Остается еще немало проблем, связанных с инициативой Bring Your Own Device (BYOD) («Принеси свое устройство») в корпоративных средах и тем, как Azure Mobile Services может помочь разработчикам. Основное значение Mobile Services в том, что она демократизирует идентификацию и сокращает расходы и усилия на обеспечение безопасного доступа к защищенным корпоративным ресурсам. В этой статье мы подробнее рассмотрим, что необходимо для поддержки более сложных сценариев при подключении мобильных приложений к корпоративным ресурсам.

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

Не у всех права доступа одинаковы

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

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

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

Есть и две другие, не столь распространенные стороны идентификации. Клиентам зачастую нужен доступ к информации о своих учетных записях в каких-то компаниях наподобие PayPal или Netflix. Кроме того, подписчик в конечном счете является потенциальным клиентом. Он мог передать информацию о кредитной карте, но пока еще ничего не приобрел. Все эти типы пользователей имеют одну общую черту: все они хотят приносить и использовать собственные устройства с iOS, Android и Windows Phone для работы на предприятии.

Управление корпоративной безопасностью

В защите мобильных устройств на предприятии участвуют минимум пять программных стеков. Здесь мы подробнее рассмотрим Hybrid Connections, Azure Service Bus, Azure Active Directory Application Proxy и Microsoft Azure API Management.

Как было бы легко, если бы сотрудники предоставляли свои удостоверения для Active Directory через Web UI, получали маркер доступа и приступали к работе, но мир идентификации сложнее, и в нем больше всевозможных нюансов. Принцип «на все случаи жизни» просто не верен. Сотрудники, как правило, вынуждены использовать корпоративный провайдер идентификации.

На большинстве предприятий идентификация осуществляется по месту, обычно с использованием Active Directory, которая в основном предоставляет протокол на основе LDAP. В новом мобильном и облачном мире предприятиям нужен коммуникационный протокол на основе HTTP для взаимодействия с мобильными устройствами. Microsoft создала такую систему идентификации в Azure — Azure Active Directory (Azure AD). Одна из важных функций Azure AD заключается в том, что предприятия могут синхронизировать идентификации с облаком, используя синхронизацию каталогов. Подробнее об этом процессе см. по ссылке bit.ly/1ztaB9Z.

В Azure AD есть пара других важных функций. Azure AD поддерживает единый вход (single sign-on, SSO). Это позволяет сотруднику периодически обращаться к защищенным ресурсам без повторного входа и передачи удостоверений. Маркер доступа хранится локально как cookie на устройстве сотрудника. Вы можете ограничить срок действия этого маркера.

Azure AD также поддерживает OAuth 2.0, возможно, самый популярный открытый стандарт аутентификации. Он предоставляет клиентским приложениям безопасный делегированный доступ к серверным ресурсам от имени владельца ресурса. Используя OAuth 2.0, Azure AD может аутентифицировать пользователя и выдать маркер SAML 2.0 или JWT. Подробнее о том, как работают маркеры, см. по ссылке bit.ly/1pDc0rg.

Торговые партнеры

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

Рис. 1. Традиционная модель идентификации для федерации Active Directory

Партнеру нужно установить доверенные отношения между своей Active Directory и Active Directory другого предприятия. Это позволяет сотруднику из одной компании аутентифицироваться через свою Active Directory, а затем обмениваться маркера аутентификации с Active Directory другой компании, чтобы получить доступ к какому-то приложению в другой сети. Этот подход требует массы усилий в координации и ручных рабочих процессов для IT-администраторов.

На рис. 2 представлен современный подход к управлению идентификацией. Как правило, копии идентификаций сотрудников размещаются в Azure, хотя некоторые идентификации могут находиться только в Azure. Этот подход требует минимального сопровождения, так как исходная копия большинства идентификаций управляется локально на предприятии. Фоновый процесс синхронизации поддерживает облачную копию идентификаций в полностью синхронизированном состоянии. Пользователи могут напрямую подключаться к Azure AD в информационном центре облака, а затем они перенаправляются в соответствующее приложение.

Рис. 2. Современный подход к управлению идентификацией

Разработчики мобильных приложений найдут на GitHub ряд библиотек, использующих преимущества Azure AD (bit.ly/1qmeipz).

Поддерживаются Android, iOS, Microsoft .NET Framework, JavaScript, Node.js и др. Так, пример с iOS показывает, как заставить интерактивный код авторизации оперировать рабочей учетной записью. Вы можете связать эту рабочую учетную запись с сервером Active Directory, выполняемым в вашем информационном центре, или работать исключительно в облаке с Azure AD. На серверной стороне вы могли бы использовать либо Node.js API на основе REST, либо .NET Web API.

Клиентский доступ

Вы обычно не рассматриваете возможность предоставления доступа сайтам и сервисам для клиентов к защищенным ресурсам своей компании. Однако такой доступ более распространен, чем вы думаете. Например, Wells Fargo может понадобиться предоставить финансовые данные клиента через Web с помощью защищенного веб-сайта или мобильного приложения, а Netflix — защищенный доступ к защищенным ресурсам, таким как текущий баланс по счету или история платежей. Это становится особенно важно для клиентов, использующих мобильные устройства.

В некоторых сценариях имеет смысл использовать даже провайдеры идентификации социальных сетей, например Microsoft Account, Facebook, Google или Twitter. Этот подход был детально продемонстрирован в статье за ноябрь 2014 года (msdn.microsoft.com/magazine/dn818496), где мы написали «родное» приложение iOS, использующее Twitter в качестве провайдера идентификации.

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

Средства безопасного соединения

Помимо идентификации, есть несколько средств, помогающих пользователям безопасно подключаться к ресурсам в корпоративных сетях. Один такой пример — Azure Service Bus Relay (рис. 3), который обеспечивает элегантный способ упрощения доступа к защищенными ресурсам. Azure Service Bus Relay можно рассматривать как облачный сервис, действующий в качестве шлюза и посредника в соединении между клиентом и корпоративными ресурсами. Service Bus Relay аутентифицируется и открывает только исходящие порты. Он также поддерживает Topics и Queues, поэтому вы могли бы реализовать какую-либо форму распределенного обмена сообщениями. Вы даже могли бы включить Event Hubs, если вам нужно обрабатывать большие объемы событий.

Рис. 3. Azure Service Bus Relay

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

Сервис Application Proxy

Второй способ сделать защищенные ресурсы доступными извне брандмауэра — задействовать сервис Azure AD Application Proxy, в настоящее время находящийся на стадии предварительной версии. Он обеспечивает защищенный доступ к внутренним веб-приложениям и сервисам организации по протоколам HTTP и HTTPS.

Крупное преимущество этого подхода в том, что пользователи могут применять SSO, среду «родных» приложений и по-прежнему использовать неуправляемое, не включенное в домен устройство. В предыдущей статье мы обсуждали концепцию подключения рабочей области (workplace join), которая является облегченной версией концепции полного включения устройства в домен (bit.ly/1tE7dRR). Это поддерживает те сценарии BYOD, где пользователь хочет сохранить контроль за своим личным устройством.

Azure AD Application Proxy обеспечивает тесную интеграцию с Azure AD, SSO, Software-as-a-Service (SaaS) и локальными приложениями, многофакторной аутентификацией и регистрацией устройств. Коннектор создает мостик между ресурсом и прокси приложения, а значит, и мобильного приложения. Эти коннекторы в основном направляют трафик и поддерживают избыточность, масштабирование и несколько сайтов.

Application Proxy дает несколько преимуществ. Прежде всего вы можете реализовать тонкое управление на уровне приложения, устройства, пользователя и местонахождения. Существующие клиентские приложения не требуют модификации, равно как и сами устройства. Он также поддерживает многофакторную аутентификацию (multifactor authentication, MFA), которая способна обеспечить дополнительный уровень защиты для ресурсов с высокой степенью конфиденциальности. MFA предоставляет несколько вспомогательных сервисов, например оповещения о попытках мошенничества (fraud alerts), белых списках IP-адресов и поддержку звонка на мобильный телефон или отправку SMS как второй фактор аутентификации.

Третье преимущество Application Proxy — изоляция между сотовыми сетями и сетями на предприятии. Внутренние сервисы никогда напрямую не доступны, потому что сам Application Proxy находится в Azure AD и коннектор достижим напрямую от защищенного ресурса. Наконец, Application Proxy защищает от атак с отказом в обслуживании, обеспечивая вам контроль над регулировкой трафика, работой с очередями и управлением сеансами.

API Management

Третий подход к обеспечению доступа к защищенными ресурсам — Azure API Management, который также ведет действует как прокси ваших локальных ресурсов. Это позволяет вам предоставлять веб-сервисы, реализованные за брандмауэром, внешнему миру. Чтобы этот вариант был работоспособен, вам придется внести некоторые изменения в локальный веб-сервер, а также создать и сконфигурировать API на портале Azure. Вы можете создавать свой API с помощью .NET Web API или Node.js.

Сначала мы рассмотрим аутентификацию в Azure API Management — базовую аутентификацию, которая обеспечивает внешний доступ к локальному веб-серверу на основе IIS. Первый шаг в поддержке этого сценария — внесение некоторых изменений в ваш локальный веб-сервер IIS и включение базовой аутентификации. В IIS можно выбрать значок авторизации и перейти к базовой аутентификации, чтобы добавить пользователя. Azure API Management будет обращаться к локальному IIS под этим пользовательским профилем.

Следующий подход, применимый с Azure API Management, — аутентификации по общему секрету (shared secret authentication). Это означает, что прокси API Management понадобится хранить секретный ключ. Он помещает этот ключ в HTTP-заголовок перед попыткой подключиться к внутреннему веб-сервису на предприятии. Ничего удивительного в том, что внутреннему веб-сервису потребуется извлечь секретный ключ из HTTP-заголовка и обработать запрос на авторизацию.

Вы можете реализовать аутентификацию по общему секрету, перейдя на портал Azure Management Portal, выбрав раздел API Management и указав Policies в меню. В данном случае вы добавите политику, которая не что иное, как секретный ключ, передаваемый вашему локальному веб-серверу. Добавляемый вами файл определения политики является XML-документом.

Hybrid Connections

Четвертый и, по-видимому, самый простой подход к выдаче прав доступа к защищенными ресурсам — применение Hybrid Connections (рис. 4), функционала Azure BizTalk Services, который в настоящее время находится на стадии предварительной версии. Hybrid Connections использует технологию Service Bus Relay для создания простого, безопасного и эффективного соединения между локальным процессом и сервисом Azure Mobile Services или сайтом Azure Web Sites. С помощью Hybrid Connections можно подключаться к любому ресурсу на предприятии, использующему TCP или HTTP для соединений, в том числе к базам данных и ERP-решениям на основе SQL, Oracle and SAP.

Рис. 4. Microsoft Azure BizTalk Services: Hybrid Connections

Здесь предъявляется требование, чтобы локальный процесс (на предприятии) был доступен через статический TCP-порт, например SQL Server по порту 1433. Вы можете задействовать любую инфраструктуру для подключения к ресурсу, включая Node.js, Java или .NET Framework. Большинство конфигурационных требований Service Bus Relay абстрагируется с помощью Hybrid Connections. Никаких обязательных изменений в исходном коде локального процесса нет.

Чтобы использовать Hybrid Connections, сконфигурируйте небольшой объем метаданных в Azure Management Portal. Установите агент на сервер, где размещен ваш процесс (SQL Server, MySQL, веб-сервис и т. д.). За кулисами применяется соединение Service Bus Relay, а для аутентификации — SAS-ключ. Вы можете менять ключи независимо для серверной и клиентской сторон с портала. Поскольку используется Service Bus Relay, входящие конечные точки или прокси не нужны.

Если вы предпочитаете больше простоты в своих усилиях по подготовке и разработке, Hybrid Connections может оказаться подходящим для вас решением. Кроме того, он доступен в бесплатном уровне Azure BizTalk Services, благодаря чему вы можете использовать его без лишних затрат, оплачивая только выходную пропускную способность.

Переходим к демонстрации

Как и обещали, теперь мы продемонстрируем некоторые рассмотренные здесь методы, используя родное приложение iOS в сочетании с его серверной частью AMS в качестве платформы. Мы добавим веб-сервис и SQL Server на предприятие с помощью Hybrid Connections. Ради экономии места и использования уже существующих ресурсов, пожалуйста, прочитайте учебное пособие от группы AMS по ссылке bit.ly/1mK1LQF. В инструкциях вы найдете ссылки на дополнительные учебные ресурсы (bit.ly/1vFiPuv и bit.ly/1xLWuuF), где описывается создание полного решения, которого состоит из:

• серверной части Web API, установленной как сервис AMS и зарегистрированной в тенанте Azure AD;
• родного приложения iOS, зарегистрированного в том же тенанте Azure AD;
• поддержки двухсторонней связи в тенанте между Web API и сервисом AMS.

От вас потребуется выполнить несколько шагов, в том числе создать метаданные в Azure Management Portal, а также с помощью родных средств разработки (Visual Studio, Xcode, Android и др.) создать сами приложения. Закончив это, вы должны получить работающую систему, которая требует от вас аутентификации в приложении iOS с предоставлением удостоверений Azure AD. После этого приложение позволит выполнять CRUD-операции над данными To Do. Добавьте в мобильный сервис код, показанный на рис. 5.

Рис. 5. Клиентский код использует защищенные ресурсы через гибридное соединение

// Используем соединение с SQL Server
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Используем соединение с веб-сервисом
try
{
  const string URL = "http://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

В информации о соединении для SQL Server и обращения к веб-сервису (это простой шаблонный веб-сервис) фигурирует лишь имя гибридного соединения.

Заключение

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

Все детали этой реализации см. в публикации «Go Live» в блоге Azure (bit.ly/1rVbtCp), а версию на Java см. по ссылке bit.ly/1zW7XpZ.

Грег Оливер (Greg Oliver) присоединился к организации Microsoft Azure ISV в 2010 г. Большую часть своего времени помогает компаниям в планировании и реализации их перехода на облачные технологии. Совсем недавно работал с популярной компанией, разрабатывающей игры, в переходе от конкурирующего облачного провайдера. До присоединения к Microsoft был партнером по технологиям в одной из начинающих компаний.

Бруно Теркали  (Bruno Terkaly) — ведущий инженер программного обеспечения в Microsoft. Его основная цель — обеспечить разработку лидирующих в отрасли приложений и сервисов, способных работать на любых устройствах. Он отвечает за развитие главных возможностей облачных и мобильных технологий на территории США. Помогает партнерам в выводе их приложений на рынок, обеспечивая руководство при проектировании архитектур и глубокие технические знания на этапах оценки, разработки и развертывания приложений, создаваемых независимыми поставщиками ПО (ISV). Кроме того, Бруно тесно взаимодействует с группами облачных и мобильных технологий, организуя обратную связь и влияя на их дорожные карты.

Выражаем благодарность за рецензирование статьи эксперту Microsoft Сантошу Чандвани (Santosh Chandwani).