Планшет и домен: единство и борьба противоположностей

Давайте представим себе довольно распространенный на сегодняшний день сценарий. В корпоративной сети развернуто некоторое количество бизнес-приложений. Эти приложения опубликованы для доступа снаружи по HTTPS. Мобильные сотрудники компании, находясь за пределами корпоративной сети, хотят подключаться к этим приложениям со своих личных планшетов, работающих под Windows, iOS или Android. Эти устройства либо невозможно включить в домен, либо пользователи просто не будут этого делать. Как повысить безопасность доступа с таких устройств к корпоративным приложениям? Помочь может служба регистрации устройств (Device Registration Service, DRS) в Windows Server 2012 R2.

В этой статье я сосредоточусь на основных принципах и архитектуре DRS. Детали настройки можно посмотреть в четвертом модуле курса « Корпоративные устройства. Как управлять гибридными учетными данными».

В чем основная проблема?

Внутри корпоративной сети есть веб-приложение с доступом по HTTPS, опубликованное для подключения снаружи. С любой платформы из любого браузера подключились, весь трафик между браузером и приложением шифруется, чего еще желать. Но при всех очевидных преимуществах современных мобильных устройств, планшетов в частности, есть и обратная сторона. То, что везде удобно носить с собой, легко может быть потеряно или украдено. Любой новый «владелец» устройства любопытства ради или же по злому умыслу может попытаться «поизучать» URLs в history браузера. И при сохраненных cookies, которые наверняка используются на личных устройствах, получить доступ в том числе к приложениям организации не составит труда.


Увеличить
(кликните на изображение для его увеличения)

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

Одно из решений – использование DRS из состава Windows Server 2012 R2.

В чем основная идея?

Как следует из названия службы, DRS реализует процедуру регистрации устройства. В процессе регистрации DRS генерирует X.509-сертификат, который загружается на устройство, а также создает в Active Directory новый объект, содержащий информацию как об устройстве, так и пользователе, выполнившем регистрацию.

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


Увеличить
(кликните на изображение для его увеличения)

Важно отметить несколько моментов:

1. Процедура регистрации максимально проста и не требует предварительной настройки устройства ИТ-специалистом.
2. DRS поддерживает различные платформы:
3. Windows 8.1 и выше
4. iOS 6 и выше
5. Android – Samsung KNOX
6. Windows 7 Pro (включенная в домен)
7. DRS не требует развертывания PKI.

Как это выглядит?

В Windows Server 2012 R2 служба DRS устанавливается вместе с ADFS. ADFS, как видно из рисунков выше, играет ключевую роль в процессе аутентификации. Чтобы воспользоваться сервисом регистрации для приложения необходимо настроить аутентификацию через ADFS. Поскольку по соображениям безопасности сервер с ADFS как правило располагают внутри корпоративной сети, в зоне периметра нужна проксирующая компонента, которая будет принимать запросы из Интернета и перенаправлять их ADFS. Роль прокси может выполнять Web Application Proxy (WAP) – новая служба Windows Server 2012 R2. ADFS, в свою очередь, выполняет аутентификацию пользователя и, если настроена регистрация устройств, проверку сертификата. В случае успешной аутентификации ADFS формирует маркер (token) доступа для запрашиваемого приложения и возвращает маркер браузеру на пользовательском устройстве. После чего пользователь получает доступ к приложению.


Увеличить
(кликните на изображение для его увеличения)

Если говорить о требованиях к инфраструктуре, то для использования DRS необходимо расширить схему AD и иметь как минимум один сервер с Windows Server 2012 R2 и поднятой ролью ADFS.

Процесс регистрации устройства изображен на следующем рисунке.


Увеличить
(кликните на изображение для его увеличения)

Давайте посмотрим, как выглядит этот процесс с точки зрения владельца планшета с Windows 8.1, и что при этом происходит за кадром. В роли корпоративного приложения будет выступать SharePoint 2013. В моей инфраструктуре ADFS настроена таким образом, что регистрация устройств требуется, только если устройство находится за пределами корпоративной сети. Если же планшет подключен, например, к корпоративному Wi-Fi, то достаточно аутентификации по логину и паролю пользователя. И, конечно же, от пользователя вообще ничего не требуется, если он обращается к приложению с доменного компьютера в корпоративной сети. Имеет место полноценный Single Sign-On. Возможность настройки подобных условий доступа (conditional access), причем для конкретного приложения – еще одно серьезное преимущество использования ADFS для рассматриваемого сценария. Как задаются политики conditional access, можно посмотреть в упомянутом четвертом модуле курса « Корпоративные устройства. Как управлять гибридными учетными данными».

Итак, сотрудник компании находится за пределами компании и в браузере планшета, не включенного в домен, набирает URL корпоративного портала SharePoint. Запрос через WAP перенаправляется ADFS, и мы видим такую картину.


Увеличить
(кликните на изображение для его увеличения)

Как видно, элементы страницы аутентификации ADFS, равно как и страниц сообщений об ошибках (картинка, логотип, тексты сообщений), настраиваются. Пользователь указывает логин и пароль своей доменной учетной записи, причем логин вводится в формате User Principal Name (UPN). Так как устройство пока не зарегистрировано, в доступе отказано.


Увеличить
(кликните на изображение для его увеличения)

В тексте сообщения об ошибке я указал действия, которые необходимо совершить пользователю для регистрации планшета. Эти действия отличаются для разных платформ. Так, для iOS надо просто пройти по URL: https://<имя adfs-сервера>/enrollmentserver/otaprofile. Для Windows 8.1 регистрация предусмотрена в интерфейсе ОС: PC Settings->Network->Workplace и называется Workplace join.


Увеличить
(кликните на изображение для его увеличения)

Нажав на кнопку Join, увидим уже знакомое окно аутентификации ADFS.


Увеличить
(кликните на изображение для его увеличения)

Каким образом Windows 8.1 обнаруживает ADFS? Из введенного пользователем UPN берется суффикс, в данном случае, contosomsspb.com, к нему пристыковывается предопределенное имя, enterpriseregistration и получается FQDN, enterpriseregistration.contosomsspb.com, которое ОС пытается разрешить в IP. Соответственно, чтобы такой механизм обнаружения DRS работал, необходимо зарегистрировать в публичном DNS-домене организации A record с именем enterpriseregistration и IP-адресом пороксирующей компоненты, например, сервера WAP.

Если пароль введен верно, то выполняется регистрация устройства, и мы возвращаемся в предыдущее окно, где можно заметить, что операция Workplace join завершена.


Увеличить
(кликните на изображение для его увеличения)

Что же происходит за кадром? На самом планшете с помощью оснастки Certificates можно обнаружить появление нового сертификата.


Увеличить
(кликните на изображение для его увеличения)

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

В Active Directory соответствующий сертификату объект можно найти в новом контейнере RegisteredDevices. Имя объекта совпадает с CN сертификата. Атрибуты этого объекта можно посмотреть, например, с помощью ADSI Edit.


Увеличить
(кликните на изображение для его увеличения)

Среди атрибутов мы найдем имя устройства, тип и версию ОС, SID пользователя, выполнившего регистрацию, дату и время регистрации и др.

Пробуем снова подключиться к порталу, снова попадаем на страницу ADFS, снова вводим credentials учетной записи AD. Но теперь помимо проверки пароля успешно завершается и проверка сертификата и доступ к приложению получен.


Увеличить
(кликните на изображение для его увеличения)

Более того, после первого успешного подключения пользователь получает SSO для этого приложения. Он может закрыть браузер, перезагрузить машину, открыть браузер снова, набрать URL и… получить доступ к приложению безо всяких дополнительных вопросов. Действительно, cookies обеспечивают первый фактор аутентификации, сертификат – второй. Естественно, не навечно, и периодически пользователю придется подтверждать свою аутентичность вводом пароля. Но это срок контролирует ИТ.

Дополнительные соображения безопасности

Давайте вернемся к ситуации с утерей/кражей планшета. Если устройство уже зарегистрировано, для приложения реализован SSO и устройство попало в чужие руки. Первая линия защиты – пароль или PIN-код для входа в устройство. Для недоменных устройств обязательную блокировку можно включить, например, через Microsoft Intune или другое MDM-решение. Если этого не было сделано? Получается, мы дали злоумышленнику дополнительные козыри – ему остается просто открыть браузер и набрать URL. Очевидно, в такой ситуации владелец должен как можно быстрее оповестить свою службу ИТ. Что тогда предпримет ИТ? Посмотрим на несколько вариантов.

Если сервис регистрации устройств вообще не используется

1. Можно запретить доступ учетной записи пользователя к опубликованным приложениям. Но что, если он в длительной поездке, и ему нужен доступ к приложению с другого устройства (основного ноутбука, второго планшета и пр.)?
2. Можно сбросить пользователю пароль. Но не всегда очевидно, как это отразится на доступе к другим сервисам.

Оба решения, а также другие варианты, которые можно предложить, вполне применимы, но не идеальны.

Если устройство было зарегистрировано

Администратору достаточно найти в AD объект, ассоциированный с утерянным устройством, и либо удалить объект, либо в его свойствах для атрибута msDS-IsEnabled задать значение FALSE.


(кликните на изображение для его увеличения)

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


Увеличить
(кликните на изображение для его увеличения)

Ну а если пароль пользователя скомпрометирован и стал известен злоумышленнику? Ничто не помешает ему выполнить повторную регистрацию. Один из вариантов противодействия такому сценарию – использование сервиса многофакторной аутентификации (MFA) Microsoft Azure для регистрации устройства. В этом случае при регистрации устройства пользователю кроме ввода пароля необходимо будет пройти дополнительную проверку – ответить на входящий звонок на его мобильный телефон, либо ввести полученный по SMS код, либо использовать специальное приложение (Multi-Fator Auth), которое опять же есть в online store Microsoft, Google и Apple.


Увеличить
(кликните на изображение для его увеличения)

Но это уже тема отдельного разговора.

Итак, сервис регистрации устройств, появившийся в Windows Server 2012 R2, поможет обеспечить дополнительный уровень безопасности при удаленном подключении к корпоративным приложениям с личных мобильных устройств, не включенных в домен AD и работающих под управлением различных ОС.

Детали по установке и настройке ADFS и DRS можно найти, например, здесь.

Особенности настройки для устройств iOS, создание политик условного доступа, развертывание WAP и пр.:
https://technet.microsoft.com/en-us/library/dn280939.aspx