Рекомендации по всем архитектурам изолированных сред

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

Общие рекомендации по настройке клиентов Microsoft Entra (изолированные или нет), см. в руководстве по развертыванию компонентов Microsoft Entra.

Принципы безопасности изолированных сред

При проектировании изолированных сред важно учитывать следующие принципы:

• Используйте только современную проверку подлинности. Приложения, развернутые в изолированных средах, должны использовать современную проверку подлинности на основе утверждений (например, SAML, * Auth, OAuth2 и OpenID Connect) для использования таких возможностей, как федерация, совместная работа Microsoft Entra B2B, делегирование и платформа согласия. В связи с этим устаревшие приложения, работа которых зависит от устаревших методов проверки подлинности, например NT LAN Manager (NTLM), в изолированные среды переноситься не будут.

• Принудительное применение строгой проверки подлинности. При доступе к службам и инфраструктуре изолированных сред всегда должна использоваться строгая проверка подлинности. По возможности следует использовать беспарольную аутентификацию, например Windows Hello для бизнеса или ключи безопасности FIDO2.

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

  • Использование облачных ПК Windows 365 (Облачный ПК) с API Microsoft Graph.

  • Используйте условный доступ и настройте фильтр для устройств как условие.

• Устранение устаревших механизмов доверия. Изолированные каталоги и службы не должны устанавливать отношения доверия с другими средами с помощью устаревших механизмов, таких как отношения доверия Active Directory. Все взаимные доверия между средами должны устанавливаться с использованием современных конструкций, таких как федерация и идентификация на основе заявлений.

• Изоляция служб. Минимизируйте поверхность атаки, защитив базовые удостоверения и инфраструктуру служб от раскрытия. Разрешайте доступ только с использованием современных методов проверки подлинности для служб и безопасного удаленного доступа (также защищенного современными методами проверкой подлинности) для инфраструктуры.

• Назначения ролей на уровне каталога. Избегайте или уменьшайте количество назначений ролей на уровне каталога (назначение администратора пользователей в области каталога, а не в области AU) или ролей каталога, относящиеся к службе, с действиями уровня управления (назначение администратора базы знаний с разрешениями на управление членством в группах безопасности).

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

Обеспечение идентификаций пользователей.

Привилегированные учетные записи

Создание учетных записей в изолированной среде для административного персонала и ИТ-команд, управляющих средой. Это позволяет добавлять более надежные политики безопасности, такие как управление доступом на основе устройств для безопасных рабочих станций. Как описано в предыдущих разделах, непроизводственные среды могут использовать совместную работу Microsoft Entra B2B для подключения привилегированных учетных записей к непроизводственным арендаторам, используя тот же подход и средства управления безопасностью, предназначенные для привилегированного доступа в производственной среде.

Облачные учетные записи — это самый простой способ подготовки личных удостоверений в клиенте Microsoft Entra, который хорошо подходит для сред зеленых полей. Однако, если есть локальная инфраструктура, которая соответствует изолированной среде (например, лес Active Directory для подготовительной среды или управления), можно рассмотреть возможность синхронизации удостоверений с этой инфраструктуры. Это особенно верно, если локальная инфраструктура, описанная здесь, используется для решений IaaS, требующих доступа к серверу для управления плоскости данных решения. Дополнительные сведения об этом сценарии см. в разделе Защита Microsoft 365 от локальных атак. Синхронизация из изолированных локальных сред может также потребоваться, если существуют определенные требования к соответствию нормативным требованиям, например проверка подлинности только по смарт-карте.

Аутсорсинг ролей с высоким риском

Чтобы смягчить внутренние угрозы, возможно передать управление доступом к Ролям глобального администратора и Администратора привилегированных ролей на обслуживающего поставщика услуг с помощью совместной работы Azure B2B или делегировать доступ через партнера CSP или Lighthouse. Этот доступ может контролироваться сотрудниками компании с помощью потоков утверждения в Azure Privileged Identity Management (PIM). Такой подход может значительно сократить количество внутренних угроз. Это подход, который можно использовать для удовлетворения требований к соответствию для клиентов, которых волнует этот вопрос.

Подготовка нечеловеческих удостоверений

Учетные записи для аварийного доступа

Корпорация Майкрософт рекомендует организациям постоянно назначать роль глобального администратора двум аварийным учетным записям доступа только в облаке. Такие учетные записи имеют высокий уровень привилегий и не назначаются конкретным лицам. Учетные записи ограничены сценариями аварийного реагирования или чрезвычайными ситуациями, когда обычные учетные записи не могут использоваться, или все другие администраторы случайно заблокированы. Эти учетные записи должны быть созданы в соответствии с рекомендациями по учетным записям аварийного доступа.

Управляемые удостоверения Azure

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

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

Гибридные учетные записи службы

Некоторым гибридным решениям может потребоваться доступ как к локальным, так и к облачным ресурсам. Примером сценария использования может быть приложение, которое использует служебную учетную запись в AD DS для доступа к локальным серверам, присоединенным к домену, а также имеет учетную запись в Microsoft Entra ID, так как требуется доступ к Microsoft Online Services.

Как правило, у локальных учетных записей служб нет возможности интерактивного входа, что означает, что в облачных сценариях они не могут выполнять строгие требования к учетным данным, таким как многофакторная проверка подлинности. В этом сценарии вместо учетной записи службы, синхронизированной из локальной среды, следует использовать управляемое удостоверение или принципал службы. Для служебного субъекта (SP) используйте сертификат в качестве способа аутентификации или защитите SP с помощью условного доступа.

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

Назначение ресурса

Корпоративное решение может состоять из нескольких ресурсов Azure, а его доступ должен управляться и контролироваться как логическая единица — группа ресурсов. В этом сценарии группы безопасности Microsoft Entra можно создавать и связывать с соответствующими разрешениями и назначением ролей во всех ресурсах решения, чтобы добавление или удаление пользователей из этих групп приводит к разрешению или запрету доступа ко всему решению.

Рекомендуется использовать групповые лицензии и группы безопасности для служб Майкрософт, которые полагаются на наличие назначенных лицензий у пользователя в качестве предварительного условия для предоставления доступа (например, Dynamics 365, Power BI).

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

Идентификатор Microsoft Entra также поддерживает прямое назначение пользователей сторонним службам SaaS (например, Salesforce, Service Now) и локальным приложениям для подготовки единого входа и идентификации. Управление прямыми назначениями на ресурсы можно осуществлять из облака в сочетании с проверками доступа Microsoft Entra и управлением правами Microsoft Entra. Прямое назначение может быть хорошим подходом для назначения, ориентированного на конечного пользователя.

В некоторых сценариях может потребоваться предоставить доступ к локальным ресурсам через локальные группы безопасности Active Directory. В таких случаях при проектировании процессов соглашения об уровне обслуживания следует учитывать цикл синхронизации с идентификатором Microsoft Entra.

Управление аутентификацией

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

Управление учетными данными

Надежная квалификация

Все удостоверения личности (локальные учетные записи и внешние удостоверения, предоставленные через совместную работу B2B) в изолированном окружении должны быть обеспечены надежными учетными данными проверки подлинности, такими как многофакторная аутентификация или ключ FIDO2. Если в средах с базовой локальной инфраструктурой применяется строгая проверка подлинности, например с помощью смарт-карт, такую проверку подлинности с помощью смарт-карт можно продолжать использовать в облаке.

Учетные данные без пароля

Решение без пароля — это лучший вариант для обеспечения наиболее удобного и безопасного метода проверки подлинности. Учетные данные без пароля, такие как ключи безопасности FIDO и Windows Hello для бизнеса, рекомендуются для удостоверений пользователей с привилегированными ролями.

Защита паролем

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

Самостоятельное управление паролями

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

Пароли внешних идентификаций

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

Учетные данные служебных принципалов

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

В обоих случаях Azure Key Vault можно использовать с удостоверениями, управляемыми Azure, чтобы среда выполнения (например, функция Azure) могла извлекать учетные данные из хранилища ключей.

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

Политики доступа

В следующих разделах приведены рекомендации по решениям Azure. Общие рекомендации по политикам условного доступа для отдельных сред см. в рекомендациях по условному доступу, руководстве по операциям Microsoft Entra и условном доступе для нулевого доверия:

• Определите политики условного доступа для облачного приложения API управления службой Windows Azure для обеспечения безопасности удостоверений при доступе к Azure Resource Manager. Это касается средств управления для MFA и средств управления на основе устройств, обеспечивающих доступ только через защищенные рабочие станции (дополнительные сведения см. в разделе "Привилегированные роли" в подразделе "Управление удостоверениями"). Кроме того, используйте условный доступ для фильтрации устройств.

• Все приложения, подключенные к изолированным средам, должны иметь явные политики условного доступа, применяемые в процессе подключения.

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

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

Проблемы с проверкой подлинности

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

• Используйте настройки доступа внешних удостоверений между клиентами для управления тем, как они сотрудничают с другими организациями Microsoft Entra и другими облаками Microsoft Azure через B2B сотрудничество и B2B прямое подключение.

• Для конкретной конфигурации и управления устройствами можно использовать фильтры устройств в политиках условного доступа для выбора в качестве целевого объекта или исключения определенных устройств. Это позволяет ограничить доступ к средствам управления Azure с назначенной защищенной рабочей станции администрирования (SAW). Среди других возможных подходов — использование виртуального рабочего стола Azure, Бастиона Azure или Облачного компьютера.

• Приложения для управления выставлением счетов, такие как портал Azure EA или учетные записи выставления счетов MCA, не представлены в качестве облачных приложений, которые могут служить целевыми объектами условного доступа. В качестве компенсирующего элемента управления определите с помощью условия "Все приложения" отдельные учетные записи администрирования и целевые политики условного доступа для этих учетных записей.

Управление удостоверениями

Привилегированные роли

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

• Отсутствие постоянно разрешенного доступа. Ни у каких учетных записей пользователей не должно быть постоянно разрешенного доступа для исполнения привилегированных операций в изолированных средах. Управление доступом на основе ролей Azure (RBAC) интегрируется с Microsoft Entra Privileged Identity Management (PIM). PIM обеспечивает активацию по требованию, определяемую контролирующими механизмами безопасности, такими как многофакторная аутентификация, рабочий процесс утверждения и ограниченная длительность.

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

• Ограничение привилегированного доступа. Создайте облачные группы и группы с назначением роли для высоких привилегий или конфиденциальных привилегий. Это обеспечит защиту назначенных пользователей и объекта группы.

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

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

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

• Привилегированный доступ с защищенных рабочих станций. Любой привилегированный доступ должен осуществляться с защищенных заблокированных устройств. Отделение этих конфиденциальных задач и учетных записей от рабочих станций и устройств ежедневного использования обеспечивает защиту привилегированных учетных записей от фишинга, уязвимостей приложений и ОС, различных атак с олицетворением и кражи учетных данных, например регистрация нажатия клавиш, атаки Pass-the-Hash и Pass-The-Ticket.

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

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

  • квалификация пользователей с привилегированными ролями (например, сотрудник с полной занятостью или поставщик, уровень допуска, гражданство);

  • явная несовместимость ролей (также известная как разделение обязанностей), Примером может служить рекомендация, согласно которой команды с ролями каталога Microsoft Entra не должны заниматься управлением привилегированными ролями Azure Resource Manager и тому подобное.

  • выбор предпочтительного варианта (прямого назначения пользователей или групп) для той или иной роли.

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

Доступ к ресурсам

• Аттестация. Удостоверения с привилегированными ролями следует периодически проверять для сохранения актуальности и оправданности членства. Проверки доступа Microsoft Entra интегрируются с ролями RBAC Azure, членством в группах и внешними идентификациями Microsoft Entra B2B.

• Жизненный цикл. Привилегированные операции могут требовать доступа к нескольким ресурсам, таким как бизнес-приложения, приложения SaaS, а также группы ресурсов и подписки Azure. Управление правами Microsoft Entra позволяет определять пакеты доступа, представляющие набор ресурсов, назначенных пользователям в качестве единицы, устанавливать срок действия, рабочие процессы утверждения и т. д.

Управление жизненным циклом арендатора и подписки

Жизненный цикл клиента

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

  • Бизнес-обоснование для его создания. Создание нового клиента Microsoft Entra значительно усложнится, поэтому важно определить, необходим ли новый клиент.

  • Облако Azure, в котором она должна быть создана (например, коммерческая, правительственная и т. д.).

  • Тип среды (рабочая или нерабочая).

  • Требования к месту расположения данных в каталоге.

  • Кто будет управлять им

  • Обучение и понимание общих требований к безопасности.

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

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

• Создание клиента Azure AD B2C можно контролировать с помощью Политики Azure. Политика выполняется, когда подписка Azure связана с клиентом B2C (предварительное требование для выставления счетов). Заказчики могут ограничить создание клиентов Azure AD B2C определенными группами управления.

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

Жизненный цикл подписки

Ниже приведены некоторые рекомендации по проектированию управляемого процесса жизненного цикла подписки.

• Определите таксономию приложений и решений, требующих ресурсов Azure. Все команды, запрашивающие подписки, должны предоставить при запросе свой "идентификатор продукта". Такая таксономия информации определяет следующее:

  • Учётная запись Microsoft Entra для настройки подписки

  • учетную запись Azure EA, используемую для создания подписки;

  • Соглашение об именовании

  • назначение группы управления;

  • Другие аспекты, такие как тегирование, перекрестное распределение затрат, использование представления продукта и т. д.

• Запретите создание нерегламентированной подписки через порталы или другими средствами. Вместо этого рассмотрите возможность программного управления подписками с помощью Azure Resource Manager и извлечения отчетов о потреблении и выставлении счетов программным способом. Это может помочь ограничить предоставление подписок исключительно для авторизованных пользователей и обеспечить выполнение ваших целей политики и таксономии. Рекомендации по следованию принципам AZOps могут быть использованы для создания практического решения.

• При подготовке подписки создайте облачные группы Microsoft Entra для хранения стандартных ролей Azure Resource Manager, необходимых группам приложений, таким как участник, читатель и утвержденные пользовательские роли. Это позволяет управлять назначениями ролей Azure RBAC с управляемым привилегированным доступом в большом масштабе.

  1. Настройте группы для получения доступа к ролям Azure RBAC с помощью Microsoft Entra PIM с соответствующими элементами управления, такими как политика активации, проверки доступа, утверждающие и т. д.

  2. Затем делегируйте управление группами владельцам решений.

  3. Не назначайте владельцев продукта в роли администратора доступа пользователей или владельца, чтобы избежать непреднамеренного прямого назначения ролей в обход Microsoft Entra PIM или потенциальной сменой подписки на другого клиента.

  4. Если заказчики решили включить в непроизводственных клиентах управление подписками для всех клиентов с помощью Azure Lighthouse, убедитесь, что при проверке подлинности для управления подписками применяются те же политики доступа из рабочей привилегированной учетной записи (например, привилегированный доступ только с защищенных рабочих станций).

• Если в вашей организации есть предварительно утвержденные эталонные архитектуры, подготовка подписки может быть интегрирована с такими средствами развертывания ресурсов, как Azure Blueprints или Terraform.

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

Роли EA и MCA

• Портал Соглашения Azure Enterprise (Azure EA) не интегрируется с Azure RBAC или условным доступом. Чтобы устранить эту проблему, используйте выделенные учетные записи администрирования, к которым можно целенаправленно применять политики и дополнительный мониторинг.

• Портал Azure EA Enterprise не предоставляет журнал аудита. Чтобы устранить эту проблему, рассмотрите возможность применения автоматизированного управляемого процесса подготовки подписок с учетом описанных выше рекомендаций и используйте выделенные учетные записи EA и аудит журналов проверки подлинности.

• Роли Клиентского соглашения Майкрософт (MCA) изначально не интегрируются с PIM. Чтобы устранить эту проблему, используйте выделенные учетные записи MCA и отслеживайте их использование.

Клиенты Azure AD B2C

• В клиенте Azure AD B2C встроенные роли не поддерживают PIM. Чтобы повысить безопасность, рекомендуется использовать совместную работу Microsoft Entra B2B для подключения команд разработчиков, управляющих управлением доступом к удостоверениям клиентов (CIAM) из клиента Azure, назначьте их привилегированным ролям Azure AD B2C и применяйте политики условного доступа к этим выделенным учетным записям администрирования.

• Привилегированные роли клиента Azure AD B2C не интегрированы с проверками доступа Microsoft Entra. Устранение рисков заключается в создании выделенных учетных записей в клиенте Microsoft Entra организации, добавлении этих учетных записей в группу и выполнении регулярных проверок доступа в этой группе.

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

• Мы рекомендуем логическое владение исходной подпиской на Microsoft Entra клиента B2C, чтобы она соответствовала подразделениям разработчиков CIAM, таким же образом, как используются остальные подписки Azure для решений B2C.

Операции

Ниже приведены дополнительные операционные соображения для Microsoft Entra ID, относящиеся к нескольким изолированным средам. Ознакомьтесь с Azure Cloud Adoption Framework, эталоном безопасности облака Майкрософт и руководством по операциям Microsoft Entra, чтобы получить подробные рекомендации по работе с отдельными средами.

Роли и обязанности в различных средах

Архитектура SecOps на уровне предприятия. Члены команд операций и безопасности из всех сред в организации должны совместно определить следующее:

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

• принципы определения иерархии групп управления в каждой среде;

• Система выставления счетов (EA Portal или MCA), состояние безопасности, операционная готовность и подход к делегированию.

• процесс создания арендатора

• таксономия корпоративного приложения;

• процесс подготовки подписки Azure;

• границы изоляции и автономии администрирования и оценка рисков в командах и средах;

• общие базовые средства управления конфигурацией и безопасностью (технические и компенсирующие) и операционные базовые показатели, используемые во всех средах;

• общие стандартные операционные процедуры и средства, охватывающие несколько сред (например, мониторинг и подготовка);

• согласованное делегирование ролей в нескольких средах;

• разделение обязанностей между средами;

• общее управление логистическими цепочками для привилегированных рабочих станций;

• Соглашения об именовании.

• механизмы корреляции между средами.

Создание клиента. Конкретная команда должна сама создать клиент, следуя стандартизованным процедурам, определенным в архитектуре SecOps на уровне предприятия. Сюда входит следующее:

• Базовая подготовка лицензий (например, Microsoft 365).

• Подключение к корпоративному плану выставления счетов (например, Azure EA или MCA).

• Создание иерархии групп управления Azure.

• Настройка политик управления для различных периметров, включая идентификацию, защиту данных, Azure и т. д.

• Развертывание стека безопасности на согласованную архитектуру кибербезопасности, включая параметры диагностики, подключение SIEM, подключение CASB, подключение PIM и т. д.

• Настройка ролей Microsoft Entra на основе согласованного делегирования.

• Настройка и распространение начальных привилегированных рабочих станций.

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

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

Архитектура средств для работы в разных средах. Некоторые средства, такие как предоставление удостоверений и потоки управления версиями, могут потребоваться для работы в нескольких средах. Эти средства должны считаться критически важными для инфраструктуры и должны проектироваться, разрабатываться, реализовываться и администрироваться как таковые. В результате всякий раз, когда потребуется определить средства для нескольких сред, необходимо будет привлекать архитекторов из всех этих сред.

Инвентаризация и визуальный контроль

Обнаружение подписок Azure. Для каждого обнаруженного клиента глобальный администратор Microsoft Entra может повысить уровень доступа для получения видимости всех подписок в среде. Это повышение назначит им встроенную роль администратора доступа пользователей в корневой группе управления.

Предоставление доступа на чтение для обозрения ресурсов. Группы управления позволяют масштабируемо назначать RBAC в нескольких подписках. Клиенты могут предоставить роль читателя центральной ИТ-команде, настроив назначение ролей в корневой группе управления, которая будет распространяться на все подписки в среде.

Обнаружение ресурсов. После получения доступа на чтение ресурсов в среде для запроса ее ресурсов можно использовать Azure Resource Graph.

Ведение журналов и мониторинг

Централизованное управление журналами безопасности — прием журналов из каждой среды централизованным образом, следуя согласованным рекомендациям для всех сред (например, диагностические параметры, хранение журналов, прием SIEM и т. д.). Azure Monitor можно использовать для приема журналов из разных источников, таких как конечные точки, сетевые журналы безопасности операционных систем и т. д.

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

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

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

• Действия при входе

• Журналы аудита

• События риска

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

На следующей схеме показаны различные источники данных, которые необходимо включить в стратегию мониторинга:

Клиенты Azure AD B2C можно интегрировать с Azure Monitor. Мы рекомендуем отслеживать Azure AD B2C, используя те же критерии, которые описаны выше для идентификатора Microsoft Entra.

Подписки, в которых включено управление несколькими клиентами с помощью Azure Lighthouse, позволяют включать мониторинг нескольких клиентов, если журналы собираются с помощью Azure Monitor. Соответствующие рабочие области Log Analytics могут находиться в клиенте ресурса и анализироваться централизованно в управляемом клиенте с помощью книг Azure Monitor. Чтобы узнать подробнее, проверьте Мониторинг делегированных ресурсов в большом масштабе - Azure Lighthouse.

Журналы безопасности ОС для гибридной инфраструктуры

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

• серверы AD FS и Web Application Proxy

• Microsoft Entra Connect

• агенты прокси-сервера приложений

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

• Устройства шлюза защиты паролей.

• NPS с расширением RADIUS для многофакторной аутентификации Microsoft Entra

Microsoft Entra Connect Health необходимо развернуть для мониторинга синхронизации идентификаторов и федерации (при необходимости) для всех сред.

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

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

Следующие сценарии необходимо явно отслеживать и исследовать:

• Подозрительные действия – Все события риска Microsoft Entra должны отслеживаться на предмет подозрительных действий. Во всех арендаторах должны быть определены сетевые именованные расположения, чтобы избежать ошибочных обнаружений в сигналах на основе местоположения. Microsoft Entra ID Protection изначально интегрирована с Azure Security Center. Рекомендуется, чтобы любое исследование для обнаружения рисков включало в себя все среды, в которых удостоверение предоставлено (например, если человеческое удостоверение имеет активное обнаружение рисков в корпоративном арендаторе, команда, которая обслуживает клиента, должна также исследовать активность соответствующей учетной записи в этой среде).

• Оповещения аналитики поведения пользователей и сущностей (UEBA). UEBA следует использовать для получения аналитических сведений на основе обнаружения аномалий. Приложения Microsoft 365 Defender для облака предоставляют UEBA в облаке. Заказчики могут интегрировать локальную версию UEBA из продукта Microsoft 365 Defender для удостоверений. MCAS считывает сигналы от Microsoft Entra ID Protection.

• Действия учетных записей аварийного доступа. Любой доступ с использованием учетных записей аварийного доступа должен отслеживаться. При этом должны создаваться оповещения для расследований. Этот мониторинг должен включать:

  • Вход в систему

  • Управление учетными данными

  • Есть ли какие-либо обновления по членству в группах?

  • Назначения приложений

• Учетные записи управления выставлением счетов. Учитывая конфиденциальность учетных записей с ролями управления выставлением счетов в Azure EA или MCA и их значительные привилегии, рекомендуется отслеживать приведенные ниже действия и оповещать о них.

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

  • Любая попытка пройти проверку подлинности в приложениях, отличных от EA Portal.

  • Любая попытка пройти проверку подлинности в приложениях, отличных от Azure Resource Management, при использовании выделенных учетных записей для задач выставления счетов MCA.

  • Назначение ресурсам Azure с помощью выделенных учетных записей для задач выставления счетов MCA.

• Активность привилегированной роли - Настройка и проверка оповещений системы безопасности созданных Microsoft Entra PIM. Если ограничение прямых назначений RBAC не может быть полностью обеспечено техническими средствами управления (например, командам разработчиков продукта необходимо предоставить роль Владельца, чтобы они могли выполнять свою работу), то настройте оповещения, чтобы отслеживать прямое назначение привилегированных ролей за пределами PIM, создавая предупреждения при каждом назначении пользователя напрямую к подписке с помощью Azure RBAC.

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

  • назначение на классические роли на уровне подписки.

• Конфигурации на уровне клиента. Любая служба настройки конфигурации на уровне клиента должна создавать оповещения в системе:

  • обновление личных доменов;

  • обновление фирменной символики;

  • Список разрешений и блоков Microsoft Entra B2B

  • Microsoft Entra B2B поддерживаемые поставщики удостоверений (поставщики удостоверений SAML через прямую федерацию или социальные учетные записи)

  • изменения в политиках условного доступа.

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

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

  • действие получения согласия для приложения.

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

  • назначения ролей RBAC в группе менеджмента

  • Политики Azure, применённые в MG;

  • подписки, перемещаемые между группами управления;

  • любые изменения политик безопасности в Root MG.

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

  • обновления в определениях настраиваемых ролей;

  • создание новых настраиваемых ролей.

• Пользовательские правила разделения обязанностей. Если в вашей организации установлены какие-либо правила разделения обязанностей, используйте пакеты доступа Microsoft Entra Entitlement Management для обеспечения их соблюдения и создайте оповещения или настройте регулярные проверки для выявления нарушений.

Другие рекомендации по мониторингу. Подписки Azure, содержащие ресурсы, используемые для управления журналами, следует рассматривать как критически важную инфраструктуру (уровень 0) и заблокировать для всех, кроме команды операций безопасности соответствующей среды. Рассмотрите возможность использования таких средств, как Политика Azure, для принудительного применения дополнительных элементов управления к этим подпискам.

Операционные средства

Рекомендации по проектированию средств для нескольких сред:

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

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

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

Средства управления ИТ-службами — организации, использующие системы УПРАВЛЕНИЯ ИТ-службами (ITSM), такие как ServiceNow, должны настроить параметры активации роли Microsoft Entra PIM для запроса номера билета в рамках целей активации.

Аналогичным образом Azure Monitor можно интегрировать с системами ITSM через Соединитель управления ИТ-услугами.

Операционные практики - Сократите до минимума операционные действия, требующие прямого доступа к среде для человеческих удостоверений. Вместо этого моделируйте их как Azure Pipelines, которые выполняют распространенные операции (например, добавьте емкость в решение PaaS, запустите диагностика и т. д.) и моделируйте прямой доступ к интерфейсам Azure Resource Manager для сценариев "разбиения стекла".

Проблемы с операциями

• Для некоторых сценариев действия мониторинга субъекта-службы ограничены.

• У оповещений Microsoft Entra PIM нет API. Смягчающей мерой является регулярная проверка этих оповещений PIM.

• Azure EA Portal не предоставляет возможности мониторинга. Для устранения рисков необходимо иметь выделенные учетные записи администрирования и отслеживать действия учетной записи.

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

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

• Нет полного покрытия API в Microsoft Online Services для полноценной реализации концепции инфраструктуры как кода. Для устранения рисков максимально широко используйте интерфейсы API, а для оставшейся части использовать порталы. Эта инициатива с открытым кодом поможет вам определить подход, который может подойти для вашей среды.

• Программная возможность обнаружения клиентов ресурсов с делегированным доступом из подписок к удостоверениям в управляемом клиенте отсутствует. Например, если адрес электронной почты позволил создать группу безопасности в клиенте contoso.com для управления подписками в клиенте fabrikam.com, среди администраторов tenant contoso.com нет API для обнаружения факта этого делегирования.

• Готовые средства для мониторинга конкретной активности учетных записей (например, аварийной учетной записи, учетной записи управления выставлением счетов) не предоставляются изначально. Для смягчения рисков заказчикам рекомендуется создавать собственные правила генерации оповещений.

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

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

• Общие сведения о делегированном администрировании и изолированных средах

• Основы Microsoft Entra

• Основы управления ресурсами Azure

• Изоляция ресурсов для одного арендатора

• Изоляция ресурсов с несколькими арендаторами