События, происходившие с марта 2020 года, выявили одну из ключевых отличительностей Office 365 и облачных SaaS-сервисов в целом: их доступность в любое время, в любом месте и на любом устройстве. Когда мир был вынужден работать из дома, приложения Office 365, такие как Teams, Outlook, SharePoint и OneDrive, могли легко быть доступны вне традиционной компаний сети, и даже на некоммерческих устройствах. actually, большинство подписек Office 365 и Microsoft 365 лицензируют пользователей устанавливать и использовать их приложения на до 5 устройств.

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

Azure Active Directory Conditional Access может вернуть администраторам контроль. Это часть Premium P1 лицензии Azure Active Directory, с Conditional Access вы можете контролировать условия, при которых пользователь получает или блокируется доступ к ресурсам Azure AD. даже если вы предоставляете доступ, вы можете заставить дополнительные меры, такие как ответ на запрос многофакторной аутентификации (MFA) или то, как должно быть снова залогинено.

Как Conditional Access идентифицирует корпоративные устройства

В нашем сценарии мы будем использовать Conditional Access, чтобы разрешить пользователям входить в Office 365 только на корпоративных устройствах. мы делаем это на основе состояние устройства.

Хотя в Conditional Access нет состояния устройства под названием “корпоративное устройство”, мы можем выявить два признака устройства и на основе них заключить, что устройство принадлежит корпорации:

1. Является ли устройство так называемым гибридным Azure AD-соединением?
2. Помечено ли устройство как соответствующее требованиям?

Гибридное Azure AD-соединение относится к состоянию, когда устройство подключено к вашему локальному каталогу Active Directory, но также синхронизировано и присоединено к облачному Azure AD. Мы рассмотрели, как достичь этого состояния устройств здесь. Это подходит только для устройств Windows.

На скриншоте ниже вы можете увидеть, как Azure AD сообщает о типе присоединения к гибридному Azure AD.

Помечено как соответствующее требованиям означает, что устройство зарегистрировано в решении управления мобильными устройствами, таком как Intune, и соответствует требованиям этого решения MDM, например, наличием активного брандмауэра. Во многих отношениях это более надежный метод, чем проверка принадлежности устройства к домену, поскольку вы также гарантируете уровень безопасности, что полезно для стратегии доверия нулю. Однако, если вас интересует лишь подтверждение того, что устройство зарегистрировано в Intune, вы можете установить политику соответствия без конкретных требований безопасности. Этот метод можно использовать для “больших 4” современных платформ: Windows 10, macOS, iOS и Android.

На скриншоте ниже показано, как Intune сообщает о соответствии устройства.

Точнее, правильным термином для обозначения устройства в любом из этих состояний является “управляемое устройство”. Это означает, что администратор ИТ обладает определенным уровнем контроля над устройством и может, к примеру, применять настройки и управлять ими либо с помощью групповой политики, либо через Intune.

Важно иметь в виду, что Azure AD может запрашивать у некоторых платформ и браузеров информацию о сертификатах, если используется политика условного доступа, основанная на состоянии устройства. Как правило, это касается платформ, не основанных на Microsoft, например, устройств Apple и Google. Это происходит потому, что информация о состоянии устройства хранится в сертификате на данном устройстве, и не все программное обеспечение автоматически предоставляет эту информацию Azure AD во время проверки подлинности.

Создание политики условного доступа

Политики условного доступа создаются в разделе “Azure AD” > “Безопасность” > “Условный доступ”. أفضل практика заключается в том, чтобы дать политике имя, четко указывающее на ее назначение. Это облегчит идентификацию политики и понимание ее целей в случае, если несколько политиков будут соответствовать попытке проверки подлинности, так как в такой ситуации на нее будут распространяться все соответствующие политики, и хорошая система именования значительно упростит решение проблем и управление.

Политики разбиваются на назначения и контроль доступа. Назначения представляют собой аналог чеклиста всего, что должно быть верным для входа, чтобы политика применялась к входу. Для большинства этих настроек можно указать как условия включения, так и исключения. Например, включить всех пользователей, за исключением IT-персонала. Если политика применяется, то контроль доступа определяет, будет ли доступ разрешен или запрещен и, в случае разрешения, какие другие шаги или меры должны быть применены или соблюдены.

Прежде чем погрузиться в Условный доступ, важно учитывать его мощь: это дает вам возможность полностью блокировать аутентификацию для всех приложений. Поэтому вы можете допустить ошибку в конфигурации и заблокировать важных пользователей от важных приложений, или даже всех администраторов. Рекомендуется создавать исключения для учетных записей экстренного доступа, активность входа в которые вы отслеживаете. Лично это первый шаг, который я предпринимаю при создании любых политик Условного доступа.

Назначения

Пользователи и группы определяют, к кому применится политика. Если вы не входите в это назначение, вы не подпадаете под ее правила. Для политики, которая блокирует доступ к Office 365 с неподконтрольных устройств, вы можете ограничиться всеми пользователями, но исключить гостей/внешних пользователей и учетные записи экстренного доступа. В качестве альтернативы можно включить только подходящую группу Azure AD.

Для Облачные приложения или действия выберите Office 365. Можно выбрать более одного облачного приложения, поэтому может быть разумно создать политику, ограничивающую все приложения, которые вы считаете чувствительными, а не только Office 365. Приложение Office 365, перечисленное в Условном доступе, фактически является коллекцией других приложений, которые вы можете выбирать индивидуально. Например, оно включает Exchange Online и SharePoint Online, но в теории вы можете выбрать только компонентные приложения. Причина, по которой вы хотите выбрать Office 365, а не какую-либо из его составляющих частей, заключается в интегрированной природе сервиса. Выбор единой платформы уменьшает проблемы, связанные с зависимостями, которые они имеют друг на друга.

Условия – это место, где вы указываете сигналы и свойства аутентификации, такие как IP-адреса, операционные системы и приложения (что, грубо говоря, означает доступ через веб или клиентское приложение). В нашем примере мы будем блокировать доступ ко всем методам доступа к Office 365, поэтому не указывайте какие-либо условия. Это означает, что каждое условие применяется. Однако обычно эти условия применяются для установления разных правил для доступа через веб и клиентские приложения.

Вы также заметите условие состояния устройства, но на самом деле мы его не выберем для этой политики. Продолжайте чтение, чтобы узнать почему.

Управление доступом

Теперь, когда мы разобрались с элементом “если это…”, пришло время для “тогда это…”. Управление доступом разделено на разрешение и сеансовые настройки.

На панели предоставления выберите предоставление доступа и установите отметки для обязательного устройства, которое должно быть помечено как соответствующее требованиям и требующего гибридного устройства, присоединенного к Azure AD. У вас также будет возможность выбрать, должно ли устройство соответствовать обоим этим требованиям или только одному из них. Рекомендуется выбрать требовать одного из выбранных элементов управления, чтобы обеспечить доступ как устройствам, присоединенным к домену локальной сети, так и устройствам, присоединенным только к Azure AD.

Мы здесь сказали “вы можете получить доступ, но вам нужно управляемое устройство”. Другими словами, это также означает “вы не можете получить доступ, если не являетесь управляемым устройством”. Предполагая, что наш процесс присоединения к домену локальной сети безопасен, а регистрация Intune ограничена корпоративными устройствами, это ограничивает весь доступ к Office 365 только корпоративными устройствами.

Настройки сеанса контролируют то, что пользователь может делать после получения доступа. Например, в сеансах веб-браузера вы можете использовать принудительные ограничения приложения, чтобы блокировать загрузки из служб, таких как Exchange Online и SharePoint Online. Надеюсь, это заставит вас задуматься о различных способах формирования ваших политик: возможно, одна из них блокирует доступ на полные приложения на неуправляемых устройствах, а другая позволяет доступ только к веб-приложениям, запрещая загрузки.

Развертывание политики условного доступа.

После применения всех настроек ваша политика условного доступа теперь может быть установлена в режимы только отчёт или вкл. Назначение режима “только отчёт” состоит в том, чтобы позволить журналам входа в Azure AD аудитеть то, что могло произойти без прерывания рабочей среды. Затем вы можете использовать эту информацию для понимания последствий политики: например, какие нарушения мы можем ожидать, и, следовательно, какой вид обучения мы должны предоставить нашим пользователям.

В нашем случае для режима “только отчёт” действует значительное предупреждение. Как упоминалось ранее, для Azure AD, чтобы определить состояние устройства, ему необходимо запросить сертификат, а некоторые платформы не позволяют делать это автоматически. Даже если вы работаете в режиме “только отчёт”, ему все равно нужен этот сертификат, чтобы знать, что он мог бы сделать. Вы всегда будете предупреждены об этом в политиках, если вы включаете настройки на основе состояния устройства.

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

Пользовательский опыт

Если пользователь попытается получить доступ к любому ресурсу Office 365 на устройстве не являющемся корпоративным (совместимым с Intune или гибридно присоединенным к Azure AD), Azure AD сообщит им, что доступ заблокирован. Это верно для любых способов доступа, будь то веб-приложение или полноценное клиентское приложение. Снова вы можете использовать условия для установления различных правил как для веб-приложений, так и для клиентских приложений.

На корпоративных устройствах процесс аутентификации не меняется по мере восприятия пользователем: им будет легко пройти дальше. Единственным исключением является случай, когда приложение не может проверить состояние устройства. Это не должно быть проблемой для приложений первой стороны, таких как пакет Office 365, но, например, это может быть проблемой для сторонних браузеров, даже в Windows. Ваши пользователи могут получить ошибку, аналогичную той, что показана на скриншоте выше. Chrome для Windows поддерживает состояние устройства при использовании расширения Windows 10 Accounts, и, как можно предположить, Chromium-основанный Edge поддерживает это стандартно.

Связанная статья:

• Почему вам следует ограничить доступ к Office 365 с помощью политик безопасности Microsoft Conditional Access