В предыдущей статье я упомянул переход на Intune Standalone, который позволил нам в большей степени использовать возможности Azure Active Directory, а именно работать с Conditional Access. В этой расскажу подробнее о том, как это можно сделать.
Что это такое?
Conditional Access (CA) – это механизм проверки каждого процесса подключения к системе на основе настроенного сценария и решения, устанавливающего, что делать с этим подключением. А его можно запретить, разрешить без условий или разрешить с условиями. Является компонентом Azure AD.
Сценарий этот описывается следующими настройками:
Assignments — в каких случаях сценарий должен срабатывать.
Access controls — что нужно предпринять.
В секции Assignments содержатся:
— Users and groups — какие пользователи попадают под действие политики. Это могут быть все пользователи в Azure AD или конкретные группы/пользователи. Отдельно можно указать исключения. Вы можете применить политику для всех пользователей за исключением отдельной группы.
— Cloud apps — сценарии могут применяться к любому приложению, зарегистрированному в Azure AD. То есть вы не ограничены работой только с приложениями Office 365.
— Conditions – дополнительные условия.
— Sign-in risk – возможность использования механизма оценки риска авторизации. Оценивается откуда, в какое время, с использованием какого клиента, насколько это поведение обычно и т.д. Требуется лицензия Azure AD Premium 2.
— Device platforms — возможно указать к какой платформе будет применима политика. Например, создание политики только для мобильных клиентов или только для Windows машин.
— Locations – подразумевают сетевые локации. Можно использовать список доверенных IP адресов.
— Client apps (preview) – оценивает тип клиента. Возможно использовать, чтобы создать политику только для браузера или EAS (Exchange Active Sync). Для тех, кто захочет закрыть использование OWA на мобильных устройствах, но оставить опцию для настольных компьютеров.
— Device state (preview) – дает возможность исключить устройства в определенном статусе.
Далее необходимо настроить, что именно будет делать или требовать политика.
Для этого существуют две секции:
Grant – именно тут происходит настройка сценария: блокировка доступа или требование дополнительных мер безопасности.
Session – осуществление контроля в самой сессии. Пока возможно использование только с Exchange Online и Sharepoint Online. Более подробная информация здесь.
Теперь давайте рассмотрим некоторые сценарии использования.
Сценарий 1. Открыть доступ к приложениям Azure AD только на мобильных устройствах, управляемых Intune.
Допустим, нам необходимо ограничить доступ к приложениям, зарегистрированным в Azure AD и дать его только устройствам, которые управляются Intune. И это должно быть применимо для всех устройств.
Мы выбираем применение политики на всех пользователей.
Далее выбираем все приложения.
ВАЖНО: Портал по управлению Azure (portal.azure.com) тоже расценивается как приложение, поэтому будьте аккуратны. Есть байка — если создать политику на всех пользователей и все приложения, которая будет блокировать любые подключения, то никто и никогда больше не попадет в ваш tenant и даже поддержка Майкрософта вам не поможет.
Теперь нам нужно настроить политику, для применения только на мобильные устройства. Для этого нужно перейти в Device Platforms и выбрать мобильные ОС (iOS, Android, Windows Phone).
Мы выбрали все необходимые условия, для применения политики, теперь выбираем условие разрешения подключения. В данном случае необходимой опцией является требование к устройству соответствовать политикам безопасности в Intune (Compliance Policy). Состояние устройства берется из Intune.
После создания и применения политики, пользователи с устройствами управляемыми Intune, продолжат пользоваться приложениями. Те же, кто использовал устройства не подключенные к Intune, увидят сообщение, предлагающее зарегистрировать устройство.
Сценарий 2. Доступ к корпоративному порталу только с корпоративных компьютеров.
Необходимо настроить синхронизацию между Active Directory и Azure Active Directory. Таким образом, компьютеры из AD будут существовать как Hybrid Azure AD joined. Внутренний портал при этом должен быть зарегистрирован в Azure AD. Можно даже настроить SSO.
Теперь дело за политикой, которая будет применяться на нужных пользователей и требовать подключения только с Hybrid Joined устройств при подключении к указанному порталу/приложению. Сработает всё только из коробки с IE и Edge. Для Chrome потребуется расширение.
А если что-то сломается?
В какой то момент времени, вы можете обнаружить ситуации, когда пользователь не может зайти в приложение и вы не совсем понимаете какая именно политика в этом виновата.
В этом случае помогут Sign-in логи в Azure AD с функцией фильтрации по статусу применения политики.
В деталях каждого события, вы сможете увидеть какая политика отработала и почему.
Выводы
Conditional Access позволяет гибко разграничивать доступ к приложениям и сервисам. Условий и сценариев использования может быть бесконечное множество. Лучше всего этот сервис раскрывается с сервисами Microsoft. Например, его можно интегрировать с Azure Application Proxy для ограничения доступа к внутренним ресурсам или интеграции со средствами защиты конечных устройств (endpoint protection) при закрытии доступа к корпоративной сети.
Что это такое?
Conditional Access (CA) – это механизм проверки каждого процесса подключения к системе на основе настроенного сценария и решения, устанавливающего, что делать с этим подключением. А его можно запретить, разрешить без условий или разрешить с условиями. Является компонентом Azure AD.
Сценарий этот описывается следующими настройками:
Assignments — в каких случаях сценарий должен срабатывать.
Access controls — что нужно предпринять.
В секции Assignments содержатся:
— Users and groups — какие пользователи попадают под действие политики. Это могут быть все пользователи в Azure AD или конкретные группы/пользователи. Отдельно можно указать исключения. Вы можете применить политику для всех пользователей за исключением отдельной группы.
— Cloud apps — сценарии могут применяться к любому приложению, зарегистрированному в Azure AD. То есть вы не ограничены работой только с приложениями Office 365.
— Conditions – дополнительные условия.
— Sign-in risk – возможность использования механизма оценки риска авторизации. Оценивается откуда, в какое время, с использованием какого клиента, насколько это поведение обычно и т.д. Требуется лицензия Azure AD Premium 2.
— Device platforms — возможно указать к какой платформе будет применима политика. Например, создание политики только для мобильных клиентов или только для Windows машин.
— Locations – подразумевают сетевые локации. Можно использовать список доверенных IP адресов.
— Client apps (preview) – оценивает тип клиента. Возможно использовать, чтобы создать политику только для браузера или EAS (Exchange Active Sync). Для тех, кто захочет закрыть использование OWA на мобильных устройствах, но оставить опцию для настольных компьютеров.
— Device state (preview) – дает возможность исключить устройства в определенном статусе.
Далее необходимо настроить, что именно будет делать или требовать политика.
Для этого существуют две секции:
Grant – именно тут происходит настройка сценария: блокировка доступа или требование дополнительных мер безопасности.
Session – осуществление контроля в самой сессии. Пока возможно использование только с Exchange Online и Sharepoint Online. Более подробная информация здесь.
Теперь давайте рассмотрим некоторые сценарии использования.
Сценарий 1. Открыть доступ к приложениям Azure AD только на мобильных устройствах, управляемых Intune.
Допустим, нам необходимо ограничить доступ к приложениям, зарегистрированным в Azure AD и дать его только устройствам, которые управляются Intune. И это должно быть применимо для всех устройств.
Мы выбираем применение политики на всех пользователей.
Далее выбираем все приложения.
ВАЖНО: Портал по управлению Azure (portal.azure.com) тоже расценивается как приложение, поэтому будьте аккуратны. Есть байка — если создать политику на всех пользователей и все приложения, которая будет блокировать любые подключения, то никто и никогда больше не попадет в ваш tenant и даже поддержка Майкрософта вам не поможет.
Теперь нам нужно настроить политику, для применения только на мобильные устройства. Для этого нужно перейти в Device Platforms и выбрать мобильные ОС (iOS, Android, Windows Phone).
Мы выбрали все необходимые условия, для применения политики, теперь выбираем условие разрешения подключения. В данном случае необходимой опцией является требование к устройству соответствовать политикам безопасности в Intune (Compliance Policy). Состояние устройства берется из Intune.
После создания и применения политики, пользователи с устройствами управляемыми Intune, продолжат пользоваться приложениями. Те же, кто использовал устройства не подключенные к Intune, увидят сообщение, предлагающее зарегистрировать устройство.
Сценарий 2. Доступ к корпоративному порталу только с корпоративных компьютеров.
Необходимо настроить синхронизацию между Active Directory и Azure Active Directory. Таким образом, компьютеры из AD будут существовать как Hybrid Azure AD joined. Внутренний портал при этом должен быть зарегистрирован в Azure AD. Можно даже настроить SSO.
Теперь дело за политикой, которая будет применяться на нужных пользователей и требовать подключения только с Hybrid Joined устройств при подключении к указанному порталу/приложению. Сработает всё только из коробки с IE и Edge. Для Chrome потребуется расширение.
А если что-то сломается?
В какой то момент времени, вы можете обнаружить ситуации, когда пользователь не может зайти в приложение и вы не совсем понимаете какая именно политика в этом виновата.
В этом случае помогут Sign-in логи в Azure AD с функцией фильтрации по статусу применения политики.
В деталях каждого события, вы сможете увидеть какая политика отработала и почему.
Выводы
Conditional Access позволяет гибко разграничивать доступ к приложениям и сервисам. Условий и сценариев использования может быть бесконечное множество. Лучше всего этот сервис раскрывается с сервисами Microsoft. Например, его можно интегрировать с Azure Application Proxy для ограничения доступа к внутренним ресурсам или интеграции со средствами защиты конечных устройств (endpoint protection) при закрытии доступа к корпоративной сети.
Protos
Спасибо, теперь немного больше буду понимать язык ( hybrid, comliant, joined) наших ИТ-шников когда объясняют почему ничего не работает и что именно
daedrayg Автор
Тут, к сожалению, достаточно сложно использовать исключительно русский язык, так вся документация существует практически исключительно на английском.