Azure AD Conditional Access на удалёнке: политики «доверенное устройство + MFA + страна» против аномальных входов

Последние недели у нас довольно специфический контекст: клиенты, которые раньше сидели в периметре и не особо думали про аутентификацию снаружи, разом оказались на удалёнке. И вопросы посыпались соответствующие. Один из них - «а у нас Microsoft 365, люди заходят в Teams и SharePoint из домашних сетей, как понять что там происходит и как заблокировать что-то подозрительное».

Клиент - торговая компания, средний бизнес, лицензии Microsoft 365 Business Premium, гибридная среда: Exchange и файлы частично ещё on-premise, Teams и SharePoint уже в облаке. До карантина большинство сотрудников работало из офиса, Azure AD использовался в режиме «есть, синхронизировано с AD, но настроен по минимуму». Conditional Access - включён, но ни одной политики кроме «требовать MFA для администраторов» не было.

Работаем в рамках managed-сопровождения, поэтому задачу взяли целиком: спроектировать политики, раскатать в режиме только отчётности (report-only), несколько дней посмотреть что ловит, потом включить в боевом режиме.

Что такое Conditional Access и зачем он нужен именно сейчас

Conditional Access в Azure AD - это, по сути, движок политик: если пользователь, устройство и место входа соответствуют условиям, разрешить/заблокировать/потребовать что-то дополнительно. В офисном мире это было не так критично: всё равно все заходят из внутренней сети с корпоративных машин. Когда сотрудники разошлись по домам - картина изменилась принципиально. Входы идут с домашних Windows-машин, с телефонов, с ноутбуков родственников. Azure AD Sign-in logs у клиента за первую неделю удалёнки выглядели как праздник разнообразия: устройства самые разные, IP-адреса со всей страны и несколько - из-за рубежа (командировочные и те, кто уехал к родственникам заранее).

Microsoft как раз сейчас активно двигает Conditional Access совместно с Intune как связку для управления удалённым доступом. В частности, появился режим report-only, который позволяет «включить» политику без реального блокирования - посмотреть в логах что бы произошло. Это сильно снижает риск «включили и положили половину пользователей», что раньше было реальной проблемой при слепом применении политик.

Что решили построить

После разговора с клиентом и просмотра их Sign-in logs, договорились на три слоя политик.

Первое - MFA для всех входов из-за пределов корпоративной сети. Список известных IP офисов и VPN-шлюза внести в Named Locations как доверенные. Входы оттуда - без дополнительных требований. Входы со всех остальных IP - требовать MFA. Это базовая гигиена, которую надо было сделать давно.

Второе - блокировка входов из нетипичных стран. У клиента работа только в России, ни командировочных за рубеж, ни иностранных партнёров с доступом к Microsoft 365 нет. Создали Named Location типа Countries, добавили Россию как разрешённую. Политика: если страна входа не входит в список разрешённых - блокировать полностью. Без вариантов. Несколько попыток входа из Нидерландов и Германии в логах сразу нашли объяснение: VPN на телефоне у одного из менеджеров по умолчанию выходил через европейский сервер. Отключил - исчез из «подозрительных».

Третье - требование Compliant Device или Hybrid Azure AD Joined для доступа к SharePoint и Exchange Online. Вот это оказалось самым сложным. Intune у клиента был, но в режиме «установлен, несколько политик, реально не используется для compliance». Чтобы требовать compliant device - нужно сначала привести устройства в compliant состояние, иначе заблокируешь всех сразу.

Порядок раскатки и что пошло не так

Именно здесь пригодился режим report-only. Включили все три политики в нём, подождали три дня, разобрали логи.

По MFA - всё чисто. Примерно 15% входов шли из неизвестных IP (домашние сети), все они в report-only режиме получили бы требование MFA. Пользователи уже были зарегистрированы в Microsoft Authenticator с прошлой осени (делали это заранее), так что реального препятствия нет.

По странам - вылез тот самый VPN-менеджер и ещё двое с похожей ситуацией. Разобрались до включения боевого режима. Если бы включили без report-only - они бы просто оказались заблокированы и начали звонить.

По compliant device - картина неожиданная. Из примерно 40 устройств в Intune compliant статус имели меньше половины. Причины разные: политики Intune настроены с требованиями, которым старые машины не соответствовали (Windows 10 1803 на паре ноутбуков при политике «минимум 1903»); часть устройств зарегистрирована, но не проходила check-in больше 30 дней (лежали на складе). Включи мы политику боевую в этот момент - отрезали бы людей от SharePoint в самый разгар удалёнки.

Решение: политику по compliant device отложили на две недели, потратили это время на приведение Intune-политик в порядок. Подняли минимальную версию ОС до реалистичной (1903 вместо 1909, которая ещё не у всех), обновили ноутбуки которые могли быть обновлены, несколько старых машин вынесли в отдельную группу с более мягкими политиками.

Итог на сегодня

MFA для внешних входов и блокировка входов из нежелательных стран работают в боевом режиме вторую неделю. За это время было пятнадцать заблокированных попыток входа из-за рубежа - все оказались либо VPN на устройстве пользователя, либо один подозрительный вход по несуществующей учётке (кто-то брутфорсил). Ни одного реального инцидента с блокировкой легитимного пользователя.

Политика по compliant device пока в report-only, включаем по мере готовности парка устройств. По ощущению - ещё неделя-полторы.

Один полезный побочный эффект: Sign-in logs теперь смотрят регулярно, а не раз в квартал «если что-то случилось». Conditional Access генерирует достаточно структурированные данные, что аномалия видна невооружённым глазом. Это само по себе уже ценно - даже без политик.