Приветствую, коллеги. Сегодня мы продолжим наше знакомство с Office/Microsoft 365. В этой части мы поговорим про некоторые функции идентификации и информационной безопасности доступные в Office 365. Напоминаю, что в этом цикле статей мы с вами изучаем, переводим и немного дополняем документацию Microsoft.
Тестируем функции Office 365
В прошлой части мы подготовили необходимую для тестирования приземленную и облачную инфраструктуры.
Теперь, когда мы готовы, перейдем к самому интересному — изучению функционала облачных сервисов.
Функции идентификации
В прошлой части мы решили одну практическую задачу — синхронизацию учетных данных из Active Directory в облако, применив функцию Password hash synchronization. В этой статье мы узнаем подробнее о том, как работает эта функция.
Password hash synchronization
Функция используется для упрощения аутентификации пользователей в облачных сервисах Office 365 и позволяет автоматически синхронизировать учетные данные из приземленного (on-premise) экземпляра Active Directory в облачный (cloud) Azure Active Directory. Пользователи при логине будут вводить те же учетные данные, что и в приземленном Active Directory.
Архитектурно аутентификация пользователя производится на стороне Office 365, по синхронизированным хэшам паролей пользователей (на самом деле хешам хешей).
На изображении ниже описан механизм работы функции.
- Каждые две минуты Azure AD Connect запрашивает у контроллеров домена хэши паролей пользователей (атрибут unicodePwd). Запрос выполняется по протоколу MS-DRSR, который используется для синхронизации данных между контроллерами домена.
- Перед ответом на запрос, контроллер шифрует MD4 хэш пароля пользователя при помощи функции MD5, которая применяется к ключу сессии RPC, а также криптографической соли. Затем результат отправляется AD Azure Connect через RPC сессию. Также контроллер передает соль, таким образом AD Azure Connect сможет расшифровать полученную информацию.
- AD Azure Connect получает ответ и при помощи криптографических функций и соли расшифровывает информацию к ее изначальному состоянию в виде MD4 хэша пароля.
- AD Azure Connect конвертирует оригинальные 16-байтные двоичные хэши пользователей в 64-байтные.
- AD Azure Connect добавляет 10-байтовую соль к каждому 64-байтовому хэшу пароля пользователя для дальнейшей защиты.
- AD Azure Connect комбинирует 64-байтовый хэш и соль и использует результат как входное значение для функции PBKDF2, в которой выполняется 1000 итераций хэширования алгоритма HMAC-SHA256.
- AD Azure Connect комбинирует 32-байтный результат, объединяет с солью и количеством SHA-256 итераций и передает полученную строку в Azure AD посредством TLS.
- При попытке входа пользователя в сервисы Office 365 он указывает свой пароль. Пароль проходит через такие же процедуры MD4+соль+PBKDF2+HMAC-SHA256. Если результат совпадает с хранимым в облаке, пользователь успешно проходит процедуру аутентификации.
Описанный механизм этого алгоритма позволяет нам убедиться в том, что пароли не передаются по сети в открытом виде ни в периметре локальной сети, ни за ее пределами. Также мы можем убедиться в том, что в облаке не хранятся даже MD4 хэши паролей пользователей, а лишь их результаты многократных преобразований.
Pass-through authentication
Функция является еще одним способом аутентификации и позволяет выполнять аутентификацию пользователей на приземленном экземпляре Active Directory при помощи установки специальных агентов (Authentication Agents). Агенты аутентификации являются посредниками между локальной и облачной AD. Их главная задача — установить исходящее и постоянное соединение с Azure AD и передавать запросы аутентификации локальному Active Directory через установленное соединение.
Рассмотрим механизм работы функции.
Механизм функции:
- Пользователь пробует аутентифицироваться или запрашивает доступ к облачному сервису (напр. Outlook).
- Если пользователь еще не аутентифицировался, его перенаправляет на страницу входа в Azure AD.
- Пользователь вводит свои логин и пароль.
- Azure AD помещает полученные логин и пароль в очередь и шифрует их при помощи открытых ключей агентов.
- Приземленный агент получает зашифрованные учетные данные из очереди в облаке.
- Агент дешифрует их при помощи своего закрытого ключа.
- Учетные данные проверятся в приземленном Active Directory.
- Active Directory возвращает результат проверки (корректность данных, истечение срока пароля, блокировка пользователя) агенту.
- Агент перенаправляет ответ Azure AD.
- Azure AD получает ответ. Если не требуется многофакторной аутентификации и соблюдены политики доступа, то пользователь успешно авторизуется.
- Если все успешно, пользователь получает доступ к приложению.
Давайте попробуем включить эту функцию в нашей лаборатории. Для этого запустим Azure AD Connect и нажмем на кнопку Configure.
Затем указываем раздел Change user sign-in и нажимаем Next.
Выбираем функцию Pass-through authentication.
На последнем этапе мы получим небольшую сводку о действиях, которые будут выполнены. Если мы согласны — нажимаем Configure.
После завершения установки мы можем проверить подключение агента к Azure AD. Для этого перейдем по ссылке — https://portal.azure.com/ и переместимся в раздел Azure AD Connect. Мы можем увидеть, что к Azure AD подключился один агент.
Восклицательный знак сообщает нам о рекомендации наличия высокой доступности агента путем установки дополнительных.
Мы можем перейти в раздел Проверка подлинности. В нем мы можем увидеть хост, откуда подключен агент.
Azure AD Seamless Single Sign-on
Функция позволяет выполнять пользователю сквозную аутентификацию. Если пользователь уже вводил свои учетные данные на доменном компьютере при входе в систему, то при попытке зайти в облачные сервисы Office 365, не потребуется вводить учетные данные повторно.
Сквозная аутентификация достигается за счет создания в локальной Active Directory учетной записи компьютера, которая представляет собой облачную Azure AD. Создаваемый объект типа компьютер под именем AZUREADSSOACC играет ключевую роль в работе функции Seamless Single Sign-on.
Рассмотрим механизм работы аутентификации в облачных сервисах.
- Пользователь пробует получить доступ к облачному приложению (напр. Outlook) с доменного компьютера.
- Если пользователь еще не аутентифицировался, его перенаправляет на страницу входа в Azure AD.
- Пользователь вводит свой логин (в некоторых случаях этот шаг может быть пропущен).
- Azure AD сообщает веб-браузеру пользователя о необходимости предоставить билет Kerberos.
- Клиентский браузер запрашивает в Active Directory билет для учетной записи компьютера AZUREADSSOACC, который представляет в приземленной инфраструктуре облачный Azure AD.
- Active Directory находит аккаунт компьютера и возвращает клиенту билет, зашифрованный с помощью секрета учетной записи компьютера.
- Браузер перенаправляет полученный билет в Azure AD.
- Azure AD дешифрует полученный билет, в котором содержится идентификационная информация пользователя.
- После проверки, Azure AD либо возвращает токен для запрашиваемого приложения (напр. Outlook), либо производит дополнительные проверки (напр. многофакторная аутентификация).
- Если вход пользователя успешен, он получает доступ к приложению (напр. Outlook).
Попробуем реализовать функцию в нашей тестовой лаборатории. Для этого запустим Azure AD Connect и нажмем на кнопку Configure. Далее перейдем в раздел User Sigh-In под названием Enable single sign-on и включим опцию Pass-through authentication.
От нас потребуется указать учетные данные доменного администратора.
На последнем этапе мы увидим сводку действий, которые будут выполнены.
Как итог — уведомление об успехе применения конфигурации.
На этом настройка в AD Azure Connect завершена. Однако, необходимо на стороне клиента, добавить в зону интранет веб-сайт https://autologon.microsoftazuread-sso.com.
Для этого откроем настройки Internet Explorer и добавим вышеуказанный сайт как показано ниже.
Дополнительно включаем опцию Allow updates to status bar via script.
В реальной среде мы можем автоматизировать этот процесс через групповые политики GPO.
Теперь, при попытке пользователя аутентифицироваться в сервисах Office 365 с доменного компьютера, не потребуется вводить учетные данные. Сквозная аутентификация доступна на различных браузерах и версиях Windows, однако в зависимости от их установленных версий может потребоваться дополнительная конфигурация. На текущий момент поддерживаются Google Chrome, Internet Explorer, Microsoft Edge, Mozilla Firefox, Safari.
Для проверки мы можем запустить браузер и перейти по ссылкам (необходимо подставить свои домены) (ссылки были сокращены для возможности чтения с мобильных устройств):
Если все настроено правильно, перед нами откроется страница с доступными нам приложениями без явной аутентификации пользователя.
Multi-factor authentication (MFA)
Функция позволяет добавить еще один слой безопасности при аутентификации пользователей в Office 365. Для успешного получения доступа к облачным сервисам, помимо логина и пароля, потребуется указать одноразовый код, который придет в виде СМС.
Перейдем в раздел Пользователи > Активные пользователи > Многофакторная проверка подлинности.
В открывшемся окне выберем интересующего пользователя и включим для него MFA путем нажатия кнопки Включить в разделе quick steps.
Состояние MFA должно изменить свой статус на Включено.
Теперь, при новой попытке аутентифицироваться, пользователь будет проинформирован о необходимости заполнить дополнительную информацию.
Пользователь должен привязать номер мобильного телефона к учетной записи.
А также пройти проверку, путем ввода отправленного ему кода.
После выполнения вышеописанных процедур, при новых попытках входа в Office 365, пользователь должен будет пройти еще один фактор аутентификации.
Функции информационной безопасности
Data classification
Функция позволяет нам классифицировать данные в сервисах Office 365 при помощи использования меток хранения (retention label).
Суть технологии состоит в том, что любому документу или электронному письму в Office 365 может быть назначена метка хранения, на основании которой, может быть выполнено какое-либо действие. Например, обеспечить хранение документа в течении продолжительного периода времени. Или наоборот, удалить документ спустя время.
В вашей компании могут использоваться документы различных типов, которые могут или должны быть обработаны в соответствии с различными регламентами или стандартами.
Это может пригодится, например, для бухгалтерии или отдела кадров. Возможно, что коллегам необходимо обеспечить сохранность каких-либо документов на протяжении длительного периода времени.
Либо это может пригодится для других отделов, где периодически проходит аудит, в соответствии с которым, также необходимо обеспечить сохранность и, дополнительно, неизменяемость документов.
Лучший способ понять как это работает — проверить на практике. Предположим в нашей компании появился регламент, подразумевающий хранение всех документов связанных с планированием бюджета на протяжении одного года. В качестве места хранения (репозитория) документов пользователи будут использовать сайт SharePoint к ограниченным доступом. В связи с этим, перед нами поставили задачу по решению этого вопроса.
Перед тем, как мы начнем, необходимо сказать пару слов о механизме работы. Функционал задачи, которую мы будем решать далее, включает в себя два ключевых понятия: метки хранения (retention label) и политики меток (label policy).
Метки хранения позволяют классифицировать документ или письмо. Политики меток позволяют нам указать сервисы, в которых будет опубликована метка хранения.
На иллюстрации ниже есть пять меток и две политики. Таким образом:
- Метка 1 будет опубликована в Exchange.
- Метка 2 не будет опубликована.
- Метка 3 будет опубликована в Exchange, SharePoint и OneDrive.
- Метки 4 и 5 будут опубликованы к SharePoint и OneDrive.
Теперь приступаем к решению задачи.
Переходим в центр администрирования Безопасноть. Выбираем раздел Классификация > Метки хранения и создаем новую метку под названием Budget.
На вкладке параметров метки включаем функцию хранения, указываем время хранения документов, а также действие, которое будет выполнено после достижения срока давности. В нашем случае — удалить.
На последней вкладке просмотрим действия которые будут выполнены и создаем метку.
Наш следующий шаг — опубликовать созданную метку для пользователей в необходимых сервисах Office 365. Для этого выберем пункт Publish Label.
Фактически это приведет к созданию политики меток. Укажем метку для публикации.
Теперь свяжем публикуемую метку с политикой меток путем выбора сервисов, где будет опубликована метка.
Присвоим произвольное имя нашей создаваемой политике.
Проверяем корректность действий которые будут выполнены и создаем политику. Обратите внимание, что процедура публикации меток может занять продолжительное время. Также необходимо учитывать, что появление меток в Outlook произойдет только в почтовых ящиках, размер которых составляет хотя бы 10мб.
Теперь, спустя некоторое время, метки будут опубликованы. Пока этот процесс идет, займемся созданием репозитория для документов в SharePoint.
Переходим в админ-центр SharePoint > Создать сайт и выбираем тип сайта Сайт группы.
Указываем необходимую информацию и добавляем администратора в качестве владельца сайта и идем дальше.
Добавляем участников и завершаем создание сайта.
Уже сейчас наши пользователи могут присваивать метки через свойства документов. Однако, предлагаю не обременять этим наших коллег, а присваивать документам метку Budget в этом сайте автоматически.
Для этого перейдем в раздел сайта Документы, кликнем значок настроек в верхней части экрана и выберем Параметры библиотеки.
Далее выберем раздел Применение метки к элементам текущего списка или библиотеки.
Укажем применяемую метку для файлов в этом каталоге. Если в вашем репозитории уже есть документы, мы можем применить метку к уже существующим файлам при помощи включения опции Применить метку к существующим элементам в библиотеке.
Создаем файл от лица пользователя и проверяем наличие метки.
Напоминаю, что метка Budget подразумевает хранение документов на протяжении года. Попробуем удалить документ с этой меткой.
Privileged access management
Функция позволяет нам добавить дополнительный слой безопасности для административных операций в Office 365 в виде подтверждения или одобрения выполнения административных задач.
Чтобы было проще понять, предположим, что вы работаете в большой организации с несколькими филиалам, со своими IT специалистами в каждом. В компании используется Office 365.
Часто администраторам выдаются полные привилегии без какого-либо контроля. К сожалению, учетные данные коллег администраторов Office 365 могут быть скомпрометированы и это может стать причиной возникновения крайне нежелательных событий для ответственных за работу IT сервисов в компании, вплоть до утери информации.
Также возможен еще один сценарий — недобросовестный администратор, который, по различным причинам, может специально и осознанно изменить конфигурацию сервисов с целью навредить организации.
Функция Privileged access management представляет решение этого вопроса и позволяет выдавать необходимые права администратора для решения задачи на некоторое время. Таким образом, мы можем контролировать конфигурацию сервисов и можем быть уверены, что никаких несогласованных действий в облаке Office 365 не выполняется. Только с одобрения ответственных за это людей.
На текущий момент, к сожалению, технология применима только к Excahnge.
Давайте протестируем функцию и попробуем ограничить выполнение задач с почтовыми ящиками для других администраторов Office 365. Начнем с создания группы, в которой будут указаны лица, кто сможет согласовывать выдачу привилегий.
Для этого перейдем в портале администратора в раздел Группы и добавим новую группу. Укажем ее тип — группа безопасности, поддерживающая почту.
Назовем ее Approver’s group.
Укажем электронный адрес группы — pam.
Следующий шаг — добавить участников в группу. Перейдем в раздел Группы, выберем созданную группу и нажмем на кнопку Просмотр всех и управление участниками.
Добавим учетную запись согласующего лица.
Следующий шаг — включение функционала Privileged access management. Нам необходимо перейти в раздел Параметры > Безопасность и конфеденциальность > Привелегированный доступ.
Включим флажок Требовать утверждения задач, требующих привилегированного доступа и укажем группу согласующих привилегированный доступ коллегам.
Еще один шаг выполнен. Следующий этап — создание политики доступа.
Перейдем в раздел Параметры > Безопасность и конфеденциальность > Привелегированный доступ и выберем Управление политиками доступа и запросами на доступ > Настройка политик > Создать политику.
В процессе создания политики укажем нижеуказанные сведения и добавим группу утверждающих.
С настройкой функции мы закончили. Теперь нам необходимо смоделировать ситуацию, при которой другому администратору может потребоваться изменить какие-либо настройки почтовых ящиков Exchange.
Для этого необходимо создать второго администратора в Office 365. Переходим в раздел Пользователи > Активные пользователи и выбираем Добавить пользователя.
Когда учетная запись будет готова, щелкнем по ней, выберем Учетная запись > Роли > Управление ролями и добавим привилегии глобального администратора.
Наконец-то мы готовы посмотреть как выглядит утверждение привилегированного доступа на практике. Предположим, что администратор, имеющий привилегии глобального, решил изменить параметры почтовых ящиков пользователей.
При попытке внести изменения, администратор увидит сообщение об ошибке.
Обратите внимание на тот факт, что у глобального администратора недостаточно прав. Чтобы выполнить эту операцию ему потребуется согласование повышения прав на некоторый период времени.
Для повышения прав администратору необходимо перейти в раздел Параметры > Безопасность и конфеденциальность > Привелегированный доступ > Создать запрос и заполнить форму для утверждения повышения прав.
После того, как администратор сформировал запрос на повышение привилегий, ответственным лицам на почту придет соответствующее уведомление.
Как написано во входящем письме, чтобы избежать фишинговых атак, в письме отсутствуют ссылки. Утверждающему лицу потребуется зайти в портал администратора и перейти в раздел Параметры > Безопасность и конфеденциальность > Привелегированный доступ, где можно принять решение по запросу.
В случае принятия решения, администратору в филиале будет отправлено письмо, содержащее информацию по решению.
Только после этих действий администратор сможет выполнить изменения параметров ящика которые хотел. Через час привилегии будут отозваны автоматически.
Итоги
Коллеги, сегодня мы познакомились с некоторыми функциями в Office 365. Нам удалось развернуть и протестировать их работу. Конечно, это не все, что может предложить облако от Microsoft. В следующей части мы продолжим наше знакомство и поговорим о функциях Microsoft 365.