Давайте представим себе довольно распространенный на сегодняшний день сценарий. В корпоративной сети развернуто некоторое количество бизнес-приложений. Эти приложения опубликованы для доступа снаружи по 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) и осуществляется проверка сертификата. И только если обе проверки успешно пройдены, пользователь получает доступ к приложению. По сути мы имеем дело с двухфакторной аутентификацией.
Но важно отметить несколько моментов:
В 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
В этой статье я сосредоточусь на основных принципах и архитектуре 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
Комментарии (5)
lostpassword
18.04.2015 10:03Здравствуйте!
Извините, не вполне понял, где в данном механизме повышается защищенность системы.
То, что везде удобно носить с собой, легко может быть потеряно или украдено. Любой новый «владелец» устройства любопытства ради или же по злому умыслу может попытаться «поизучать» URLs в history браузера. И при сохраненных cookies, которые наверняка используются на личных устройствах, получить доступ в том числе к приложениям организации не составит труда.
Это совершенно понятно. Далее:
В доменной сети средствами групповых политик подобных ситуаций легко избежать.
Здесь вопрос: а как сертификат помогает избежать компрометации в случае утери ноутбука? Украли ноутбук, открыли историю браузера, нашли страницу с корпоративным порталом — сертификат все так же подгрузился, и злоумышленник уже в системе. В чем отличие от схемы, где используется только пароль?
<...>
Как быть с устройствами, которые в домен включить невозможно? Подходы могут быть разными: можно настроить обязательное использование пароля или PIN-кода для входа на устройство, можно сгенерировать и установить сертификат на планшет.
Далее вы говорите следующее:
Давайте вернемся к ситуации с утерей/кражей планшета. Если устройство уже зарегистрировано, для приложения реализован SSO, и устройство попало в чужие руки. Первая линия защиты – пароль или PIN-код для входа в устройство. Для недоменных устройств обязательную блокировку можно включить, например, через Microsoft Intune или другое MDM-решение. Если этого не было сделано? Получается, мы дали злоумышленнику дополнительные козыри – ему остается просто открыть браузер и набрать URL. Очевидно, в такой ситуации владелец должен как можно быстрее оповестить свою службу ИТ.
Выходит, что на устройстве никакой дополнительной защиты не получается.
После некоторого раздумья я пришел к выводу, что данное решение принципиально на безопасность подключения к системе практически не влияет, и главная его прелесть именно в стандартизации процедуры подключения пользователей и в упрощении администрирования этих подключений. Это действительно так или я где-то ошибся?
ashapo Автор
20.04.2015 10:26И да, и нет. Для доступа к приложению на устройстве должен быть сертификат. Если злоумышленник каким-то образом узнал ваш пароль (например, подсмотрел, сидя рядом в аэропорту), он все равно не сможет воспользоваться им со своего (любого) устройства. Пока не выполнит регистрацию устройства. Чтобы он не смог выполнить регистрацию своего устройства, зная только ваш логин и пароль, для процесса регистрации можно и даже нужно подключить MFA.
Теперь перейдем к ситуации с кражей устройства. Действительно, если регистрация устройства уже была выполнена, и сертификат в системе, от момента кражи до момента, когда об этом узнает служба ИТ, злоумышленник может получить доступ к приложению. В отличие от ситуации, когда сертификат находится на смарт-карте или USB-ключе, и для доступа нужно завладеть и планшетом, и смарт-картой. Но это неизбежное следствие использования личных устройств для доступа к корпоративным данным. И каждая организация решает для себя, приемлем ли такой компромисс между безопасностью и удобством.
Наконец, как только ИТ-отдел узнает о краже, путем блокировки сертификата, блокируется доступ с конкретного устройства. Это можно рассматривать исключительно как упрощение администрирования, либо как характеристику системы безопасности, благодаря которой, оценив риски, мы решим реализовать такой сценарий, либо же решим этого не делать.
Botkin
Не понял. Android пока только ограниченный набор устройств с KNOX?
ashapo Автор
В локальном варианте да. Есть облачная реализация DRS, она поддерживает любые устройства Android 4+. Детали и дополнительные ссылки здесь.