Поделиться через

Защита Microsoft 365 от локальных атак

  • Статья

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

В этой статье показано, как настроить системы для защиты облачной Microsoft 365 среды от несанкционированного доступа в локальной среде, в том числе к следующим элементам:

  • Параметры конфигурации клиента Microsoft Entra
  • Безопасное подключение клиентов Microsoft Entra к локальным системам
  • компромиссы, необходимые, чтобы системы обеспечивали защиту облачных систем от несанкционированного доступа из локальной среды.

Корпорация Майкрософт настоятельно рекомендует придерживаться принципов, изложенных в этом руководстве.

Источники угроз в локальных средах

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

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

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

  • Федеративные отношения доверия, например проверка подлинности SAML, используются для проверки подлинности в Microsoft 365 с помощью локальной инфраструктуры идентификации. Если сертификат для подписи маркера SAML скомпрометирован, федерация позволяет всем пользователям, имеющим этот сертификат, олицетворять любого пользователя в облаке.

    Мы рекомендуем по возможности отключить отношения доверия федерации для проверки подлинности в Microsoft 365.

  • Синхронизацию учетных записей можно использовать для изменения привилегированных пользователей (включая их учетные данные) или групп с правами администратора в Microsoft 365.

    Рекомендуется убедиться в том, что синхронизированные объекты не имеют привилегий уровнем выше, чем у пользователя Microsoft 365. Вы можете управлять привилегиями напрямую или путем включения их в доверенные роли или группы. Убедитесь, что эти объекты не имеют прямого или вложенного назначения в доверенных облачных ролях или группах.

Защита Microsoft 365 от локальной компрометации

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

Эталонная архитектура защиты Microsoft 365 в соответствии с описанием в следующем списке.

  1. Полностью изолируйте учетные записи администратора Microsoft 365. Они должны:

    • Мастер в идентификаторе Microsoft Entra.
    • проходить проверку подлинности с использованием многофакторной проверки подлинности;
    • Защищенный условным доступом Microsoft Entra.
    • быть открытыми для доступна только с рабочих станций под управлением Azure.

    Использование этих учетных записей администратора ограничено. Локальные учетные записи не должны иметь прав администратора в Microsoft 365.

    Дополнительные сведения см. в статье О ролях администраторов. Кроме того, см. сведения о ролях Microsoft 365 в идентификаторе Microsoft Entra.

  2. Управление устройствами из Microsoft 365. Использование соединения Microsoft Entra и управления мобильными устройствами на основе облака (MDM) для устранения зависимостей в локальной инфраструктуре управления устройствами. Эти зависимости могут компрометировать управление устройствами и безопасностью.

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

  4. Используйте облачную проверку подлинности Microsoft Entra, чтобы устранить зависимости от локальных учетных данных. Всегда используйте надежную проверку подлинности, например Windows Hello, FIDO, Microsoft Authenticator или многофакторную проверку подлинности Microsoft Entra.

Конкретные рекомендации по безопасности

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

Изоляция привилегированных удостоверений

В идентификаторе Microsoft Entra пользователи, имеющие привилегированные роли, такие как администраторы, являются корнем доверия для создания и управления остальной частью среды. Чтобы свести к минимуму последствия компрометации, реализуйте следующие методы.

  • Используйте облачные учетные записи для ролей Microsoft Entra ID и Microsoft 365 с привилегированными ролями.

    Для каждой роли с высокими привилегиями необходимо выполнить следующее:

    • Просмотрите пользователей, имеющих onPremisesImmutableId и onPremisesSyncEnabled заданные. См. сведения о типе ресурса пользователя API Microsoft Graph.
    • Создайте облачные учетные записи пользователей для этих пользователей и удалите их гибридное удостоверение из привилегированных ролей.

  • Развертывание устройств с привилегированным доступом для привилегированного доступа для управления идентификатором Microsoft 365 и Microsoft Entra. См. раздел Роли и профили устройств.

    Разверните Microsoft Entra управление привилегированными пользователями (PIM) для JIT-доступа ко всем учетным записям человека с привилегированными ролями. Требуйте строгую проверку подлинности для активации ролей. См. раздел "Что такое Microsoft Entra управление привилегированными пользователями".

  • Предоставьте административные роли, которые обеспечивают минимальные права, необходимые для требуемых задач. См. сведения о наименее привилегированных ролях по задачам в идентификаторе Microsoft Entra.

  • Чтобы включить широкий интерфейс назначения ролей, включающий делегирование и несколько ролей одновременно, рассмотрите возможность использования групп безопасности Microsoft Entra или Группы Microsoft 365. Эти группы совместно называются облачными группами.

    Кроме того, включите также управление доступом на основе ролей. См. статью "Назначение ролей Microsoft Entra группам". Вы можете использовать административные единицы, чтобы ограничить область действия ролей частью организации. См. раздел "Административные единицы" в идентификаторе Microsoft Entra.

  • Разверните учетные записи аварийного доступа. Не используйте локальные хранилища паролей для хранения учетных данных. См. раздел "Управление учетными записями аварийного доступа" в идентификаторе Microsoft Entra.

Дополнительные сведения см. в статье Обеспечение безопасности привилегированного доступа. Кроме того, ознакомьтесь с рекомендациями по безопасному доступу для администраторов в идентификаторе Microsoft Entra.

Использование облачной проверки подлинности

Учетные данные являются основным вектором атаки. Чтобы лучше защитить учетные данные, реализуйте следующие методы.

Ограничения и компромиссы

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

Локальные учетные записи, синхронизированные с Active Directory, помечаются так, чтобы срок действия не истекал в идентификаторе Microsoft Entra. Этот параметр обычно компенсируются параметрами пароля в локальной службе Active Directory. Если ваш локальный экземпляр Active Directory скомпрометирован и синхронизация отключена, необходимо установить параметр EnforceCloudPasswordPolicyForPasswordSyncedUsers для принудительного изменения пароля.

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

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

Схема подготовки архитектуры показывает взаимодействие идентификатора Microsoft Entra с облачным персоналом, Microsoft Entra B 2 B, подготовкой приложений Azure и групповым лицензированием.

Мы рекомендуем использовать следующие методы подготовки:

  • Подготовка облачных приложений hr к идентификатору Microsoft Entra. Такая подготовка позволяет изолировать компрометацию локальной инфраструктуры. Эта изоляция не нарушает цикл соединения-mover-leaver из облачных приложений HR в идентификатор Microsoft Entra ID.

  • облачные приложения; По возможности разверните подготовку приложений Microsoft Entra в отличие от локальных решений подготовки. Этот метод защищает некоторые приложения SaaS от влияния вредоносных профилей злоумышленников через брешь в локальной среде. Дополнительные сведения см. в статье о подготовке приложений в идентификаторе Microsoft Entra.

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

    Мы рекомендуем ограничить гостевые учетные записи B2B следующими способами.

    • Ограничьте гостевой доступ для просмотра групп и других свойств в каталоге. Используйте параметры внешней совместной работы, чтобы запретить гостям чтение групп, к которым они не принадлежат.
    • Блокируйте доступ к порталу Azure. Изредка можно делать необходимые исключения. Создайте политику условного доступа, включающую всех гостей и внешних пользователей. Затем реализуйте политику для блокирования доступа. См. раздел Условный доступ.

  • Отключенные леса. Используйте подготовку облака Microsoft Entra для подключения к отключенным лесам. Такой подход устраняет необходимость устанавливать между лесами подключение или отношения доверия, что может усугубить последствия использования локальной бреши. Дополнительные сведения см. в разделе "Что такое облачная синхронизация Microsoft Entra Connect".

Ограничения и компромиссы

При использовании для подготовки гибридных учетных записей идентификатор Microsoft Entra ID-from-cloud-HR использует локальную синхронизацию для завершения потока данных из Active Directory в идентификатор Microsoft Entra. Если синхронизация прерывается, новые записи сотрудников не будут доступны в идентификаторе Microsoft Entra.

Использование облачных групп для совместной работы и доступа

Облачные группы позволяют отделить совместную работу и доступ от локальной инфраструктуры.

  • Совместная работа. Используйте для современной совместной работы Группы Microsoft 365 и Microsoft Teams. Откажитесь от локальных списков рассылки и перейдите на списки рассылки Групп Microsoft 365 в Outlook.
  • Доступ. Используйте группы безопасности Microsoft Entra или Группы Microsoft 365 для авторизации доступа к приложениям в идентификаторе Microsoft Entra.
  • Лицензирование Office 365. Используйте групповое лицензирование для подготовки Office 365 с помощью групп, предназначенных только для облака. Этот метод разделяет управление членством в группе из локальной инфраструктуры.

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

Управление устройствами из облака

Используйте возможности Microsoft Entra для безопасного управления устройствами.

Развертывание рабочих станций Microsoft Entra, присоединенных к Windows 10, с помощью политик управления мобильными устройствами. Включите Windows Autopilot для полной автоматизации процесса подготовки. Ознакомьтесь с планом реализации присоединения к Microsoft Entra и Windows Autopilot.

  • Использование рабочих станций Windows 10.
    • Откажитесь от компьютеров с Windows 8.1 и более ранних версий.
    • Не развертывайте компьютеры с серверными операционными системами в качестве рабочих станций.
  • Используйте Microsoft Intune в качестве центра для всех рабочих нагрузок управления устройствами. См . раздел Microsoft Intune.
  • Развертывание устройств с привилегированным доступом Дополнительные сведения см. в разделе Роли и профили устройств.

Рабочие нагрузки, приложения и ресурсы

  • Локальные системы единого входа (SSO)

    Не рекомендуется использовать локальную инфраструктуру управления федерацией и веб-доступом. Настройте приложения для использования идентификатора Microsoft Entra.

  • SaaS и бизнес-приложения, поддерживающие современные протоколы проверки подлинности

    Используйте идентификатор Microsoft Entra для единого входа. Чем больше приложений вы настраиваете для использования идентификатора Microsoft Entra для проверки подлинности, тем меньше риска в локальной компрометации. Дополнительные сведения см. в разделе "Что такое единый вход в Идентификатор Microsoft Entra".

  • Устаревшие приложения

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

    Выберите поставщика VPN, который поддерживает современную проверку подлинности. Интеграция проверки подлинности с идентификатором Microsoft Entra. В локальной компрометации можно использовать идентификатор Microsoft Entra для отключения или блокировки доступа, отключив VPN.

  • Серверы приложений и рабочих нагрузок

    Приложения или ресурсы, для которых требуются сервера, можно перенести в инфраструктуру как услугу (IaaS) Azure. Используйте доменные службы Microsoft Entra, чтобы отделить доверие и зависимость от локальных экземпляров Active Directory. Чтобы добиться этого развязки, убедитесь, что виртуальные сети, используемые для доменных служб Microsoft Entra, не имеют подключения к корпоративным сетям. См. также Доменные службы Microsoft Entra.

    Используйте многоуровневые учетные данные. Серверы приложений обычно считаются ресурсами уровня 1. Дополнительные сведения см. в статье о Корпоративной модели доступа.

Политики условного доступа

Используйте условный доступ Microsoft Entra для интерпретации сигналов и их использования для принятия решений по проверке подлинности. Дополнительные сведения см. в плане развертывания условного доступа.

Azure Monitor

После настройки среды для защиты Microsoft 365 от локальной компрометации обеспечьте упреждающий мониторинг среды. Дополнительные сведения см. в статье "Что такое мониторинг Microsoft Entra?

Сценарии для мониторинга

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

  • Подозрительное действие

    Отслеживайте все события риска Microsoft Entra для подозрительных действий. См. статью Практическое руководство. Анализ риска. Защита идентификации Microsoft Entra изначально интегрирован с Microsoft Defender для удостоверений.

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

  • Предупреждения аналитики поведения пользователей и сущностей (UEBA)

    Используйте UEBA для получения полезных сведений об обнаружении аномалий. Microsoft Defender for Cloud Apps предоставляет UEBA в облаке. См. раздел Изучение поведения пользователей, совершающих рискованные действия.

    Локальную аналитику UEBA можно интегрировать из Расширенной защиты от угроз (ATP) Azure. Microsoft Defender для облака Приложения считывают сигналы из Защита идентификации Microsoft Entra. См. раздел Подключение к лесу Active Directory.

  • Операции в учетных записях для аварийного доступа

    Осуществляйте мониторинг любого доступа, для которого используются учетные записи для аварийного доступа. См. раздел "Управление учетными записями аварийного доступа" в идентификаторе Microsoft Entra. Создание предупреждения для исследований. Этот мониторинг должен включать следующие действия:

    • Вход в систему
    • Управление учетными данными
    • Все обновления членства в группах
    • Назначения приложений

  • Действие привилегированной роли

    Настройка и проверка оповещений системы безопасности, созданных microsoft Entra управление привилегированными пользователями (PIM). Отслеживайте прямое назначения привилегированных ролей за пределами PIM, активировав создание предупреждений при непосредственном назначении пользователя. См. раздел Оповещения системы безопасности.

  • Конфигурации на уровне клиента Microsoft Entra

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

    • Обновление личных доменов
    • Изменения Microsoft Entra B2B для списков разрешений и блок-списков
    • Microsoft Entra B2B изменяет разрешенные поставщики удостоверений, например поставщики удостоверений SAML через прямую федерацию или социальные входы
    • Изменения в политике условного доступа или управления рисками

  • Объекты приложения и субъекта-службы в Azure Active Directory (Azure AD)

    • Новые приложения или субъекты-службы, которые могут требовать применения политик условного доступа
    • Учетные данные добавлены в субъекты-службы
    • Действие получения согласия для приложения

  • Пользовательские роли

    • Обновления в определениях настраиваемых ролей
    • Вновь созданные настраиваемые роли

Управление журналами

Определите хранилища журналов и стратегию хранения, а также схему и реализацию для обеспечения единообразия набора средств. Например, можно рассмотреть системы управления данными и событиями безопасности (SIEM), такие как Microsoft Sentinel, общие запросы и сборники схем для расследований и криминалистики.

  • Журналы Microsoft Entra. Последовательно придерживайтесь рекомендаций по таким параметрам, как диагностика, хранение журналов и прием SIEM, для принятия созданных журналов и сигналов.

    Стратегия журнала должна включать следующие журналы Microsoft Entra:

    • Действия при входе
    • Журналы аудита
    • События риска

    Идентификатор Microsoft Entra обеспечивает интеграцию Azure Monitor для журнала действий входа и журналов аудита. См . журналы действий Microsoft Entra в Azure Monitor.

    Используйте Microsoft API Graph для приема событий риска. См. сведения об использовании API-интерфейсов защиты идентификаторов Microsoft Graph.

    Журналы Microsoft Entra можно передавать в журналы Azure Monitor. См. статью "Интеграция журналов Microsoft Entra с журналами Azure Monitor".

  • Журналы безопасности операционной системы гибридной инфраструктуры. Из-за особенностей контактной зоны все журналы ОС инфраструктуры гибридной идентификации должны архивироваться и тщательно отслеживаться как система уровня 0. Включите следующие элементы:

    • Агенты Application Proxy.

    • Агенты обратной записи паролей.

    • Компьютеры шлюза защиты паролей.

    • Серверы политики сети (NPSs), имеющие расширение RADIUS многофакторной проверки подлинности Microsoft Entra

    • Microsoft Entra Connect

      Чтобы отслеживать синхронизацию удостоверений, необходимо развернуть Microsoft Entra Connect Health. См. раздел "Что такое Microsoft Entra Connect".

Следующие шаги