Microsoft делает акцент на безопасности (часть 4)

Опубликовано: 6 Апреля, 2023
Microsoft делает акцент на безопасности (часть 4)

  • Microsoft делает акцент на безопасности (часть 2)
  • Microsoft делает акцент на безопасности (часть 3)
  • Microsoft делает новый акцент на безопасности (часть 5)
  • Microsoft делает акцент на безопасности (часть 6)
  • Microsoft делает акцент на безопасности (часть 7)
  • Microsoft делает акцент на безопасности (часть 8)
  • Microsoft делает акцент на безопасности (часть 9)

Введение

В первой части этой серии статей я рассказал о том, как Microsoft провела свою первую конференцию Ignite в первую неделю мая в Чикаго, причем многие сессии были посвящены безопасности в облаке. Мы говорили об объявлении о более гибких циклах исправлений (и о возможном окончании вторника исправлений, как мы его знаем) и о введении Windows 10 Device Guard. Во второй части мы начали рассматривать новые функции, продукты и службы безопасности, начиная с того, которому уделялось много внимания: Microsoft Advanced Threat Analytics. В части 3 мы более подробно рассмотрели презентации Ignite о том, что Microsoft делает для обеспечения безопасности в облаке и, в частности, в Office 365.

Управление идентификацией в Office 365

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

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

Управление идентификацией долгое время было проблемой на предприятии, а облако еще больше усложнило ее. Однако это не обязательно. Интеграция удостоверений и управление ими в Office 365 были упрощены, и в этом году на Ignite главный менеджер программы Дэвид Брандт объяснил участникам, насколько в своей одноименной презентации.

Модель идентификации, соответствующая потребностям вашей организации

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

Самым простым и, возможно, наиболее подходящим для малого бизнеса является облачное удостоверение Office 365, в котором все управление удостоверениями и элементы управления выполняются в облаке Office 365. Для этого вообще не нужны локальные серверы; вы отдаете все в руки Microsoft и можете значительно снизить уровень внутренних накладных расходов на ИТ.

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

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

Давайте подробнее остановимся на каждой из моделей айдентики:

Модель облачной идентификации

В этом сценарии вам не нужно задействовать какие-либо локальные серверы. Все учетные записи пользователей и информация об учетной записи хранятся в облаке Azure, в котором работает Office 365. Azure Active Directory аутентифицирует пользователя, который входит непосредственно в облачную службу. Требуются очень небольшие административные накладные расходы. Azure AD хранит всю информацию о пользователях для ваших служб Exchange, SharePoint и Lync в Office 365 точно так же, как Active Directory для локального домена хранит информацию об учетной записи пользователя для этого домена.

Обратите внимание, что вы поддерживать отдельный локальный каталог и использовать облачную модель, но учетные записи не будут синхронизироваться между ними. Это может быть хорошим способом протестировать Office 365, прежде чем принять решение о переходе на него. Облачная модель не так масштабируема, как другие; Microsoft рекомендует его организациям с 200 и менее пользователями.

Синхронизированная модель идентификации

В этой конфигурации у вас по-прежнему есть локальное управление идентификацией, а облачный каталог синхронизируется с вашими собственными службами Active Directory, поэтому пароли синхронизируются как на локальных серверах, так и в облаке. Вы создаете учетные записи пользователей на своих локальных контроллерах домена. Затем учетные записи пользователей и связанные с ними пароли синхронизируются с Azure AD в облаке. Таким образом, пользователи могут использовать те же имена пользователей и пароли для входа в облачную службу, которые они используют для локального входа во внутреннюю сеть. Azure AD сверяет пароль с данными синхронизированной учетной записи, когда пользователь входит в облако.

Средство синхронизации Microsoft Azure Active Directory (DirSync) используется для синхронизации учетных записей. Он устанавливается на сервер в вашем локальном домене или на сервере в Azure. Этот инструмент может синхронизировать все домены AD в вашем лесу с Office 365. Он относительно прост в использовании и, вероятно, будет предпочтительной моделью для большинства предприятий.

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

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

Еще одно улучшение, добавленное в 2014 году, — это возможность для пользователей с синхронизацией хэшей паролей использовать многофакторную проверку подлинности (MFA) с Office 365. Ранее для использования MFA требовалась федеративная модель. Office 365 MFA доступен в планах для среднего бизнеса, предприятий, учебных заведений и некоммерческих организаций, а также в отдельных планах Office 365 (например, Exchange Online). Для реализации MFA не требуется никаких дополнительных покупок или подписок. Вторым фактором аутентификации является телефонный звонок, текстовое сообщение или уведомление приложения на смартфоне пользователя.

Модель федеративной идентификации

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

Если в вашей организации уже развернута служба AD FS, имеет смысл использовать ее и для Office 365, хотя это и не обязательно. Вы по-прежнему можете использовать синхронизированное удостоверение для Office 365 и AD FS для других целей. Если у вас еще нет AD FS и у вас нет причин нуждаться в федеративном удостоверении, вероятно, лучше всего подойдет синхронизированная модель. Обратите внимание, что если вы используете сторонний поставщик федеративных удостоверений, например Centrify, IBM Tivoli Federated Identity Manager

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

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

Резюме

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

  • Microsoft делает новый акцент на безопасности (часть 2)
  • Microsoft делает акцент на безопасности (часть 3)
  • Microsoft делает акцент на безопасности (часть 5)
  • Microsoft делает акцент на безопасности (часть 6)
  • Microsoft делает акцент на безопасности (часть 7)
  • Microsoft делает акцент на безопасности (часть 8)
  • Microsoft делает акцент на безопасности (часть 9)