igorsmolin

Коллеги, приветствую! Мы продолжаем цикл статей посвященный облачным сервисам Microsoft. Сегодня мы с вами получим триальную подписку Microsoft 365 E5, познакомимся с некоторыми функциями Microsoft 365 и Azure AD. На практике разберем примеры задач, возникающих в работе с Microsoft 365. Напоминаю, что в этом цикле статей мы переводим и дополняем официальную документацию Microsoft.

Для изучения новых функций нам потребуется получить триальную лицензию Microsoft 365 E5. Также нам понадобится приземленная инфраструктура, которую мы разворачивали в первой части цикла статей.

Получаем триальную подписку Microsoft 365 E5

Для активации 30-дневной подписки Microsoft 365 E5 перейдем в портал администрирования Office 365, в раздел Выставление счетов > Приобретение служб и выберем нужную подписку.

Затем выбираем Получить бесплатно.

Теперь нам необходимо пройти процедуру подтверждения посредством СМС или телефонного звонка.

Вводим проверочный код и выбираем Попробовать бесплатно.

Если все верно, кликаем Попробовать.

Поздравляю, мы только что получили месячную подписку Microsoft 365 E5 на 25 пользователей.

Тестируем функции Microsoft 365

Функции идентификации

Password reset

Функция позволяет облачным пользователям самостоятельно сбрасывать свой пароль, не прибегая к помощи администраторов. Для того, чтобы ее включить, нам необходимо перейти в центр администрирования Azure Active Directory, в раздел Пользователи > Сброс пароля и выбрать в меню Разрешен самостоятельный сброс пароля нужную опцию. Мы можем указать отдельную группу, которой будет разрешено сбрасывать свои пароли самостоятельно, либо предоставить такую возможность всем пользователям в организации.

После сохранения внесенных изменений, пользователи, при попытке зайти в любой облачный сервис Microsoft 365, увидят сообщение о необходимости добавить о себе дополнительные сведения. Эта информация будет необходима для подтверждения подлинности пользователя при сбросе пароля в будущем.

По умолчанию Azure AD использует один способ проверки подлинности. В случае необходимости, мы можем изменить количество, либо изменить сами способы, доступные пользователям. Для этого нужно произвести необходимую конфигурацию в разделе Способы проверки подлинности.

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

После добавления требуемой информации, пользователь получит возможность сбрасывать свой пароль. Для выполнения этого действия ему потребуется перейти по ссылке https://aka.ms/sspr. Пользователь будет перенаправлен на сервис сброса пароля self-service password reset (SSPR).

От пользователя потребуется указать способ проверки подлинности и пройти ее.

В случае успеха, пользователь может сменить свой пароль.

На мой взгляд сброс пароля через браузер — не всегда лучший способ для решения этой задачи. Представим себе ситуацию, в которой пользователь использует учетные данные не только для доступа к облачным сервисам, но и к ОС Windows. По неизвестным причинам наш коллега забыл свой пароль. Как ему быть в таком случае? Также вспомним тот факт, что для решения возникшей проблемы, пользователю нужно вспомнить и перейти по определенному адресу, в сервис для самостоятельной смены пароля — self-service password reset (SSPR). Этот этап может оказаться сложным для самостоятельного решения, что повышает вероятность участия администратора.

В ходе знакомства со следующей функцией мы познакомимся с решением этой проблемы.

Функция Password reset доступна только для облачных учетных записей, но что делать в случае, если учетная запись — приземленная (в локальном Active Directory)? Решить такую задачу нам поможет функция Password writeback.

Password writeback

Функция Password writeback позволяет самостоятельно сбросить пароль для приземленных учетных записей Active Directory. Подобный функционал достигается за счет интеграции с приземленной инфраструктурой Active Directory.

Для включения этой функции нам потребуется произвести конфигурацию в Azure AD Connect, в приземленной Active Directory и в облачной Azure Active Directory.

Для начала переместимся на наш хост, где установлен Azure AD Connect и запустим его. Напоминаю, что инсталляцию Azure AD Connect мы уже рассматривали в предыдущих частях.

Переходим в пункт View current configuration и нажимаем Next.

В разделе Synchronized Directories нам необходимо определить служебная учетную запись, которая используется для взаимодействия с Azure Active Directory.

Этот момент очень важен, так как именно через эту учетную запись происходит взаимодействие между приземленной и облачной инфраструктурами. Для успешной процедуры смены пароля нам потребуется расширить права служебной учетной записи указанной в разделе Synchronized Directories.

Теперь переходим на контроллер домена и запускаем оснастку Active Directory Users and Computers (ADUC). Во вкладке Вид включаем Дополнительные компоненты.

Кликаем на объект нашего домена правой кнопкой и выбираем Свойства.

Переходим в раздел Безопасность и выбираем Дополнительно. Находим служебную учетную запись для взаимодействия с Azure Active Directory. В разделе Привилегии добавляем права на смену и сброс паролей.

В разделе свойств находим и добавляем: изменение lockoutTime и изменение pwdLastSet.

На этом изменения в Active Directory завершены, снова переходим на хост, где установлен Azure AD Connect. Выбираем пункт Customize synchronization options.

Доходим до раздела Optional Features и включаем функцию Password writeback.

Дожидаемся окончания процесса включения функции. Еще один этап конфигурации пройден. Теперь перейдем к последнему — Azure Active Directory.

Переходим в центр администрирования Azure AD, затем в разделе Пользователи > Сброс пароля > Интеграция с локальной средой включаем функцию при помощи кнопки Включить обратную запись паролей в локальный каталог.

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

Чуть ранее в этой статье, я упоминал, что задача сброса пароля может решаться разными способами. Один из них, через браузер, мы уже рассмотрели и узнали, что этот метод не всегда будет самым удобным. Более того, возник вопрос, что же делать если пользователь забыл свой пароль и он используется для доступа в систему?

Давайте узнаем, как эту проблему можно решить при помощи меню Сбросить пароль в Windows. Более того, мы сразу посмотрим в действии смену пароля приземленной учетной записи через Azure AD.

К сожалению меню сброса пароля само по себе не появится. Необходимо заранее позаботиться об этом и создать один ключ в реестре. Способы доставки этой конфигурации могут быть разные: Microsoft Intune, Group Policy и т.д. Для нашей демонстрации создадим этот ключ вручную.

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

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount /v AllowPasswordReset /t REG_DWORD /d 1

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

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

Далее пользователю будет предложен предпочитаемый способ проверки использования учетной записи. Процедура стандартная: на указанный номер будет отправлено СМС или совершен звонок. Пользователь вводит полученный код.

Если проверка пройдет успешно, пользователь сможет указать и подтвердить свой новый пароль.

Теперь наш пользователь сможет войти в систему с новым паролем.

Обратите внимание, что нам удалось изменить пароль в приземленном экземпляре Active Directory через Azure Active Directory.

Azure AD Identity Protection

Функция обеспечивает защиту учетных записей пользователей в AD Azure и позволяет решать следующие задачи:

• Автоматизация обнаружения и исправления опасных операций аутентификации в сервисах Microsoft 365.
• Изучение подробностей и деталей опасных операций аутентификации в сервисах Microsoft 365.
• Экспорт полученных данных в сторонние приложения для дальнейшего анализа.

Типы рисков и обнаружения

Ключевым для понимания термином в этой функции являются — риски. Они делятся на два типа: риски пользователя и риски операций входа.

• Риск пользователя — представляет собой вероятность того, что учетные данные пользователя скомпрометированы. Такие риски рассчитываются при помощи собственных источников анализа угроз, команд безопасности Microsoft и других доверенных источников.
• Риск операций входа — представляет собой вероятность того, что операция выполняется без ведома владельца учетной записи. Такие риски рассчитываются при помощи систем машинного обучения Microsoft, на основе данных, полученных из других тенантов Azure, пользовательских учетных записей Microsoft Account и Xbox.

Риски рассчитываются при помощи различных типов обнаружения, как в режиме реального времени (online), так и автономно (offline). Давайте познакомимся с ключевыми типами.

Типы обнаружения рисков пользователя

• Утечка учетных данных — определяет компрометацию учетной записи. Обычно учетные записи взламывают для дальнейшей продажи. Если сервисы Microsoft получают информацию о продаже учетных записей в даркнете, такие данные проверяются в Azure AD для подтверждения утечки.
• Аналитика угроз Azure AD — определяет необычную для пользователя активность или проверяет активность на соответствие известным шаблонам атак.

Типы обнаружения рисков входа пользователя

• Анонимный IP-адрес (online) — определяет выполнение входа при использовании анонимного IP-адреса (напр. Tor, анонимный VPN).
• Необычные перемещения (offline) — определяет вход в разных географических местоположениях, один из которых, является нетипичным для пользователя.
• IP-адрес связанный с вредоносным ПО (offline) — определяет, что IP-адрес устройства, откуда производится аутентификация, связан с ботнетом. Обнаружение происходит при помощи сопоставления адреса устройства и адресов, которые соединялись с известным бот-сервером.
• Необычные свойства входа (online) — хранит информацию о предыдущих выполненных входах. Если аутентификация выполняется из нового места с нетипичными свойствами, такой вход будет считаться рискованным.
• Вредоносный IP-адрес (offline) — определяет попытки входа с вредоносного IP-адреса. IP-адрес будет считаться вредоносным в случае большого количества неудачных попыток аутентификаций или в случае применения других источников репутации IP-адреса.

Мы с вами познакомились с ключевыми типами обнаружения рисков. Чуть далее мы увидим на практике, как они работают. Но перед этим, нам необходимо узнать подробнее про отчеты.

Отчеты

Инструмент Azure AD Identity Protection предоставляет нам возможность просмотра отчетов, при помощи которых, мы можем получить дополнительную информацию об инцидентах, а также выполнить некоторые действия по ним.

Отчеты расположены в центре администрирования Azure AD, в разделе Все службы > Azure AD Identity Protection > Отчеты. Всего их три:

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

• Рискованные входы в систему — в этом отчете мы можем узнать информацию о статусах рискованных входов: какие попытки входа отмечены как рискованные, исправленные, отклоненные, у каких попыток подтверждена компрометация или безопасность входа. Здесь же нам доступны сведения о рисках: уровень, типы обнаружения. Также доступна дополнительная информация: сведения об устройстве, приложении, местоположении, MFA, примененных политиках условного доступа.
  Как администраторы мы можем подтвердить компрометацию входа или отметить событие как безопасное.

• Обнаружение рисков — в этом отчете мы можем узнать информацию о: каждом рискованном событии входа, включая тип обнаружения, связанные события входа, информацию о местоположении.

Тестирование работы обнаружения рисков

Давайте на практике узнаем, как работают некоторые типы обнаружения рисков, а также где и как можно увидеть информацию о подозрительных и рискованных входах в систему. Воспроизведем несколько сценариев из реальной жизни.

Обращаю внимание на тот факт, что для тестирования некоторых типов может понадобится история входов пользователей сроком до 30 дней.

Анонимный IP-адрес — самый простой для моделирования тип обнаружения риска при входе.

Все, что нам нужно сделать — выполнить вход в облачный сервис Microsoft 365 в веб-браузере Tor.

Необычное перемещение — для этого сценария нам понадобится установить любое расширение для Tor (Firefox), позволяющее менять свойство user-agent.

Сначала выполним вход с привычного для пользователя устройства и браузера. Затем, запустим Tor, изменим user-agent на любой другой и попробуем выполнить вход в облачные сервисы.

Уведомления об обнаружении угроз

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

Для включения оповещений перейдем в раздел Все службы > Azure AD Identity Protection > Предупреждения об обнаружении пользователей под угрозой и выберем минимальный уровень риска и пользователей, кому будут отправляться оповещения.

Письмо, сообщающее об обнаружении риска, будет выглядеть примерно так.

Чтобы настроить отправку сводки по возникшим инцидентам перейдем в раздел Все службы > Azure AD Identity Protection > Еженедельный дайджест и выберем пользователей.

Сводка будет выглядеть примерно так.

Конфигурация и тестирование политик

Ранее мы с вами узнали, что Azure AD Identity Protection также позволяет автоматизировать задачи обнаружения и исправления опасных операций аутентификаций. Для решения этих вопросов мы можем использовать три политики, с каждой из которых, мы сейчас познакомимся.

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

Для включения политики перейдем в раздел Все службы > Azure AD Identity Protection > Политика рисков пользователей, выберем пользователей или целую группу, к которым она будет применяться, степень риска, механизм контроля подразумевающий требование изменения пароля и включим политику.

Теперь посмотрим на то, как ее применение будет выглядеть со стороны пользователей. В случае обнаружения рисков пользователя при входе, ему потребуется пройти процедуру смены пароля в соответствии с нашей политикой рисков пользователей. Сперва пользователю будет необходимо пройти проверку подлинности.

Затем пользователь увидит страницу со сменой пароля.

Если в политике мы укажем Блокировать доступ, пользователь получит сообщение о блокировке его учетной записи.

Политика рисков при входе в систему — использование этой политики дает нам возможность автоматизации задач проверки подлинности или блокировки доступа пользователей в случае обнаружения рисков при входе в систему.

Для включения политики перейдем в раздел Все службы > Azure AD Identity Protection > Политика рисков при входе в систему, выберем пользователей или целую группу, к которым она будет применяться, степень риска, механизм контроля подразумевающий требование проверки подлинности и включим политику.

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

Политика регистрации MFA — использование этой политики дает нам возможность подготовить пользователей к использованию многофакторной аутентификации для обеспечения безопасности их учетных записей.

Для включения политики перейдем в раздел Все службы > Azure AD Identity Protection > Политика регистрации MFA, выберем пользователей или целую группу, к которым она будет применяться, выберем единственный механизм контроля и включим политику.

Теперь посмотрим на то, как ее применение будет выглядеть со стороны пользователей. При попытке входа пользователю будет предложено выполнить проверку подлинности в MFA. Предложение можно будет пропустить, однако спустя 14 дней, проверку будет необходимо завершить.

Azure AD Conditional Access

Функция позволяет управлять пользовательским доступом к облачным сервисам Microsoft при помощи применения различных условий. Microsoft предпочитает использовать термин сигналы (русскоговорящему, для восприятия, легче воспринимать термин условия вместо сигналов). Давайте посмотрим на архитектуру этой функции, чтобы лучше понять как она устроена.

Архитектура

Мы можем увидеть, что функционал поделен на три раздела: сигналы (signals), решения (verify every access attempt), приложения и информация (apps and data). В ходе конфигурации политик условного доступа, нам действительно будет необходимо пройти эти три этапа и указать условия, приложения и решение для каждой политики.

Рассмотрим общие сигналы которые могут применяться для создания политик условного доступа.

• Пользователь или членство в группе.
• Информация о географическом расположении или IP-адресе пользователя.
• Информация о платформе устройств пользователей.
• Приложения к которым пользователи хотят получить доступ.
• Риск подключения.
• Клиентские приложения.
• Состояние устройства.

Также рассмотрим общие решения которые могут применяться для создания политик условного доступа.

• Заблокировать доступ
• Предоставить доступ
• Предоставить доступ, но:
  • Требовать многофакторную аутентификацию (MFA).
  • Требовать соответствие политикам Intune.
  • Требовать гибридное подключение устройства к Azure AD.
  • Требовать использование утвержденных клиентских приложений, которые поддерживают современную (modern) аутентификацию.

Функция условного доступа может применяться для решения различных задач идентификации. Например для:

• Требования многофакторной аутентификации у администраторов.
• Требования многофакторной аутентификации для задач управления и конфигурации Azure.
• Блокировки входа пользователей использующие устаревшие протоколы аутентификации.
• Блокировки или предоставление доступа из определенного местоположения (напр. страна или IP).
• Требования определенных местоположений (напр. страна или IP) для процедуры многофакторной аутентификации.
• Блокировки входа пользователей представляющим угрозу для безопасности.

Конфигурация политик

Давайте попробуем реализовать один из сценариев условного доступа на практике. Предположим, что мы бы хотели ограничить доступ ко всем облачным приложениям Microsoft 365 у некоторых пользователей во всех странах, кроме РФ. Решение нашей задачи разделится на две части: создание объекта стран и создание политики.

Сначала мы с вами создадим объект расположения в котором будут указаны все страны, кроме РФ. Далее мы создадим блокирующую политику к которой мы применим список стран и пользователей.

Коллеги, напоминаю, что это упрощенная демонстрация функционала, поэтому при внедрении условного доступа в своей компании, тщательно продумывайте свои политики.

Идем в центр администрирования Azure AD. Переходим в раздел Все службы > Безопасность > Именованные расположения Azure AD и выбираем Создать расположение.

Произвольно называем наше расположение и выбираем все страны, кроме РФ.

Далее переходим в раздел Все службы > Удостоверение > Условный доступ Azure AD и выбираем Новая политика.

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

Также укажем облачные приложения для которых будет применяться наша политика. Обратите внимание на предупреждение. Если мы неаккуратно настроим политику, то можем потерять доступ к порталу Azure.

Теперь выберем условие. В нашем случае указываем ранее созданное расположение.

В качестве решения или выполняемого действия политики выберем блокировку доступа. Также нам необходимо включить политику.

Как итог — мы должны увидеть созданную политику и ее состояние должно быть отмечено как включена.

Тестирование

Конфигурация политики условного доступа закончена. Давайте посмотрим на нее в действии с точки зрения пользователя. Мы смоделируем ситуацию, при которой пользователь попробует получить доступ к облачным приложениям Microsoft 365 из РФ и из другого региона. Для этого мы воспользуемся встроенным VPN в браузере Opera.

Пользователь переходит на страницу portal.office365.com и пробует получить доступ. Внешний IP пользователя относится к РФ.

Пользователь успешно прошел процедуру аутентификации и готов к работе.

Теперь, мы включим VPN и укажем в качестве нашего региона — Европу.

Теперь попробуем точно также выполнить вход от имени этого же пользователя.

Обратите внимание на тот факт, что пользователь корректно ввел свои учетные данные. Однако из-за политики условного доступа, пользователь не сможет войти в сервисы Microsoft 365.

В ходе внедрения новых политик условного доступа может возникнуть мысль о том, что было бы неплохо заранее узнать результат политики при определенных условиях, которые нет возможности смоделировать. Также эта возможность могла бы пригодится для целей диагностики и решения проблем связанными с использованием политик. Для этого Azure предлагает инструмент What If. При помощи него мы можем узнать какие политики будут применяться на основе заданных параметров без необходимости воспроизведения условий.

Чтобы им воспользоваться перейдем в раздел Все службы > Удостоверение > Условный доступ Azure AD > Параметр WhatIf.

Давайте попробуем указать условия задачи которую мы только что рассматривали. Выберем пользователя, приложения и информацию об IP и регионе (РФ).

В результате инструмент не сообщит нам об использовании каких-либо политик.

Теперь изменим данные IP и региона (США) и попробуем еще раз.

Мы увидим политику которая будет применяться при указанных условиях.

Итоги

Коллеги, сегодня мы еще больше узнали об облаке Microsoft. Нам удалось получить бесплатную подписку Microsoft 365 E5, мы познакомились с некоторыми функциями идентификации в Microsoft 365 и Azure AD, а также попробовать их в действии. Я очень рад, если этот материал пригодился или кому-то помог в изучении предмета этой статьи. Надеюсь, что у меня еще останется немного триальной лицензии для дальнейшего изучения Microsoft 365.