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

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

Общие рекомендации по настройке клиентов 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. Этот доступ можно контролировать внутренними сотрудниками с помощью потоков утверждения в Azure управление привилегированными пользователями (PIM). Такой подход может значительно сократить количество угроз. Это подход, который можно использовать для удовлетворения требований к соответствию для клиентов, которых волнует этот вопрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежные учетные данные

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

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

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

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

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

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

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

Пароли внешних удостоверений

С помощью совместной работы 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 управление привилегированными пользователями (PIM). PIM обеспечивает JIT-активацию, определяемую шлюзами безопасности, такими как многофакторная проверка подлинности, рабочий процесс утверждения и ограниченная длительность.

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

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

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

  • Настраиваемые роли 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, относясь к нескольким изолированным средам. Ознакомьтесь с 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.

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

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

• серверы AD FS и прокси веб-приложения;

• Microsoft Entra Connect

• агенты Application Proxy;

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

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

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

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

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

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

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

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

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

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

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

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

  • Все обновления членства в группах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • назначения ролей RBAC в группе управления;

  • Политики Azure, применяемые в группе управления;

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

  • любые изменения политик безопасности в корневой группе управления.

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

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

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

• Пользовательское разделение правил обязанностей. Если организации установили любое разделение правил обязанностей, используйте пакеты несовместимого доступа Microsoft Entra Access 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, администраторы в contoso.com не имеют API для обнаружения такого делегирования.

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

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

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

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

• Основы Microsoft Entra

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

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

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