Давайте представим себе довольно распространенный на сегодняшний день сценарий. В корпоративной сети развернуто некоторое количество бизнес-приложений. Эти приложения опубликованы для доступа снаружи по 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) и осуществляется проверка сертификата. И только если обе проверки успешно пройдены, пользователь получает доступ к приложению. По сути мы имеем дело с двухфакторной аутентификацией.
Но важно отметить несколько моментов:
- Процедура регистрации максимально проста и не требует предварительной настройки устройства ИТ-специалистом.
- DRS поддерживает различные платформы:
- Windows 8.1 и выше
- iOS 6 и выше
- Android – Samsung KNOX
- Windows 7 Pro (включенная в домен)
- 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. Очевидно, в такой ситуации владелец должен как можно быстрее оповестить свою службу ИТ. Что тогда предпримет ИТ? Посмотрим на несколько вариантов.
Если сервис регистрации устройств вообще не используется.
- Можно запретить доступ учетной записи пользователя к опубликованным приложениям. Но что, если он в длительной поездке, и ему нужен доступ к приложению с другого устройства (основного ноутбука, второго планшета и пр.)?
- Можно сбросить пользователю пароль. Но не всегда очевидно, как это отразится на доступе к другим сервисам.
Оба решения, а также другие варианты, которые можно предложить, вполне применимы, но не идеальны.
Если устройство было зарегистрировано.
Администратору достаточно найти в 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
Автор: ashapo
