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

После идентификации архитектуры удостоверений необходимо управлять авторизацией и доступом к ресурсам в целевых зонах приложений и платформ. Рассмотрим, к каким ресурсам каждый субъект, прошедший проверку подлинности, имеет доступ и к которым требуется доступ, а также как снизить риск несанкционированного доступа к ресурсам. Дополнительные сведения см. в разделе "Архитектура удостоверений".

Обзор

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

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

Используйте управление доступом на основе ролей Azure (RBAC) для управления административным доступом к ресурсам Azure. Рассмотрите, требуются ли пользователи разрешения для узкой области, например администратор одного приложения или широкая область, например администратор сети в нескольких рабочих нагрузках приложений. В любом случае следуйте принципу достаточного доступа и убедитесь, что у пользователя есть только роли, необходимые для их обычных действий. Используйте пользовательские роли и Microsoft Entra управление привилегированными пользователями (PIM), если необходимо применить JIT-доступ. Хотя команда платформы отвечает за основу управления удостоверениями и доступом, обе группы платформ и приложений являются потребителями службы и должны соответствовать тем же принципам.

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

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

Рекомендации по проектированию

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

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

RBAC

Общие сведения о различиях между ролями идентификатора Microsoft Entra и ролями RBAC Azure.

• Роли идентификатора Microsoft Entra управляют правами администратора для служб на уровне клиента, таких как Идентификатор Microsoft Entra, и другие службы Майкрософт включая Microsoft Teams, Microsoft Exchange Online и Microsoft Intune.

• Роли Azure RBAC управляют правами администратора для ресурсов Azure, таких как виртуальные машины, подписки и группы ресурсов.

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

На следующей схеме показана связь между ролями идентификатора Microsoft Entra и ролями RBAC Azure:

• Вы можете создавать группы, назначаемые ролями, и назначать роли Microsoft Entra группам, если для свойства trueзадано isAssignableToRole значение . Защищены только группы с этим набором свойств. Единственными ролями, которые могут изменить членство в группе, являются глобальные администраторы, администраторы привилегированных ролей или владелец группы.

• Только некоторые роли могут сбрасывать параметры пароля или многофакторной проверки подлинности (MFA) для другого администратора. Это ограничение запрещает несанкционированным администраторам сбрасывать учетные данные более привилегированной учетной записи, чтобы получить дополнительные разрешения.

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

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

• Некоторые роли Azure RBAC поддерживают управление доступом на основе атрибутов (ABAC) или условия назначения ролей. При использовании условий администраторы могут динамически назначать роли на основе атрибутов ресурса. Например, можно назначить роль участника данных BLOB-объектов хранилища, но только для больших двоичных объектов с определенным тегом индекса, а не для всех BLOB-объектов в контейнере.

• Вы можете использовать встроенные и настраиваемые роли RBAC с Microsoft.Authorization/roleAssignments/write разрешениями Microsoft.Authorization/roleAssignments/delete для создания, удаления и обновления назначений ролей. Любой пользователь, имеющий эту роль, может решить, кто имеет разрешения на запись, чтение и удаление для любого ресурса в области назначения. Участники группы целевой зоны платформы или приложения должны учитывать, как делегировать привилегированные роли другим пользователям и группам, чтобы предоставить им необходимую автономию. Чтобы обеспечить соответствие принципам доступа с минимальными привилегиями, они могут использовать условия для делегирования пользователям.

Рекомендации по проектированию

Общие рекомендации

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

• Используйте политики условного доступа Microsoft Entra для пользователей, имеющих права на среду Azure. Условный доступ — это другая функция, которая помогает защитить контролируемую среду Azure от несанкционированного доступа. Администраторы приложений и платформ должны иметь политики условного доступа, которые отражают профиль риска их роли. Например, у вас могут быть требования к выполнению административных действий только из определенных расположений или определенных рабочих станций. Или вероятность риска входа для пользователей с административным доступом к ресурсам Azure может быть ниже, чем для стандартных пользователей идентификатора Microsoft Entra ID.

• Включите Microsoft Defender для удостоверений для защиты удостоверений пользователей и безопасных учетных данных пользователей. Defender для удостоверений является частью XDR в Microsoft Defender. Вы можете использовать Defender для удостоверений для выявления подозрительных действий пользователей и получения временных шкал инцидентов. Вы также можете использовать его с условным доступом для запрета попыток проверки подлинности с высоким риском. Разверните датчики Defender для удостоверений на локальных контроллерах домена и контроллерах домена в подписке удостоверения Azure.

• Используйте Microsoft Sentinel для предоставления возможностей аналитики угроз и расследований. Sentinel использует журналы из журналов Azure Monitor, идентификатора Microsoft Entra, Microsoft 365 и других служб для обеспечения упреждающего обнаружения угроз, исследования и реагирования.

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

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

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

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

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

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

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

  Дополнительные сведения см. в разделе "Безопасный доступ" для администраторов в идентификаторе Microsoft Entra.

Рекомендации по идентификаторам Microsoft Entra

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

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

• Используйте встроенные роли Microsoft Entra для управления следующими параметрами удостоверений на уровне клиента:

  Роль	Description	Примечание.
  Глобальный администратор	Управляет всеми аспектами идентификатора Microsoft Entra и службы Майкрософт, использующих удостоверения Microsoft Entra.	Не назначайте более пяти человек этой роли.
  Администратор гибридных удостоверений	Управляет облачной подготовкой из Active Directory в идентификатор Microsoft Entra ID, а также управляет Microsoft Entra Connect, сквозной проверкой подлинности Microsoft Entra, синхронизацией хэша паролей Microsoft Entra, простым единым входом (SSO) Microsoft Entra и параметрами федерации.
  Администратор безопасности	Считывает сведения о безопасности и отчеты и управляет конфигурациями в идентификаторе Microsoft Entra и Microsoft 365.
  Администратор приложений	Создает и управляет всеми аспектами регистрации приложений и корпоративных приложений.	Вы не можете предоставить согласие администратора на уровне клиента.

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

• Используйте административные единицы для ограничения набора администраторов, чтобы они могли управлять только определенными объектами в клиенте. Административные единицы можно использовать для делегирования администрирования подмножества каталога. Например, можно делегировать администрирование службы в одну бизнес-единицу в более широкой организации.

  Административные единицы также могут помочь устранить необходимость отдельных клиентов Идентификатора Microsoft Entra в качестве границы безопасности, где отдельные команды управляют платформой Microsoft 365 и платформой Azure в той же организации. Например, можно использовать административные единицы для делегирования управления субъектами безопасности приложений Azure команде приложений без предоставления привилегий для всего клиента Идентификатора Microsoft Entra.

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

Рекомендации по Azure RBAC

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

• При возможности используйте Azure RBAC для управления доступом к ресурсам уровня данных. Примерами конечных точек плоскости данных являются Azure Key Vault, учетная запись хранения или база данных SQL.

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

Встроенные роли

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

• Многие встроенные роли Azure предоставляют предопределенные назначения ролей на уровне платформы и ресурса. При объединении нескольких назначений ролей учитывайте общие эффекты.

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

  Административная роль или область	Description	Действия	NotActions
  Владелец платформы Azure (например, встроенная роль владельца)	Управление группами управления и жизненным циклом подписки	*
  Владелец подписки	Делегированная роль владельца подписки	*	Microsoft.Authorization/*/write, , Microsoft.Network/vpnGateways/* Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnSites/*
  Владелец приложения (DevOps, операции приложений)	Роль участника для группы приложений или операций в области подписки	*	Microsoft.Authorization/*/write, , Microsoft.Network/publicIPAddresses/write Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Управление сетью (NetOps)	Управляет глобальным подключением на уровне платформы, например виртуальными сетями, определяемых пользователем, группами безопасности сети, NVAs, виртуальными сетями, Azure ExpressRoute и другими пользователями	*/read, Microsoft.Network/*, Microsoft.Resources/deployments/*, Microsoft.Support/*
  Информационная безопасность (SecOps)	Роль администратора безопасности с горизонтальным представлением во всем пространстве Azure и политике очистки Key Vault	*/read, */register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, Microsoft.PolicyInsights/*, Microsoft.Authorization/policyAssignments/*, Microsoft.Authorization/policyDefinitions/*, Microsoft.Authorization/policyExemptions/*, Microsoft.Authorization/policySetDefinitions/*, Microsoft.Insights/alertRules/*, Microsoft.Resources/deployments/*, Microsoft.Security/*, Microsoft.Support/*

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

Назначения ролей и группы

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

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

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

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

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

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

• При делегировании административной ответственности другим пользователям, таким как команды приложений, рассмотрите, требуется ли полный набор привилегий или только подмножество. Следуйте принципу наименьших привилегий (PoLP). Например, вы можете назначить роль администратора доступа пользователей или роль администратора RBAC пользователю, которому требуется управлять доступом к ресурсам Azure, но не нужно управлять ресурсами самостоятельно. Чтобы ограничить удостоверения, типы удостоверений и роли, которыми пользователи могут делегировать и назначать назначения RBAC Azure, используйте делегированные назначения ролей с условиями. Команды приложений могут использовать условия для управления собственными субъектами безопасности в пределах ограничений, заданных командой платформы. Более привилегированные назначения ролей требуют эскалации в команде платформы. При использовании условий для делегирования ролей RBAC следует учитывать следующие факторы:

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

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

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

    

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

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

  Ресурс	User	Назначение ролей	Целевой объект назначения	Область назначения
  Целевая зона Application X	Владельцы приложений X	Владелец приложения (настраиваемый, включенный в акселератор целевой зоны Azure)	Application X Admins группа безопасности	Рабочие и тестовые подписки приложений X
  Целевая зона Application X	Владельцы приложений X	Администратор доступа к приложениям (настраиваемые условия назначения ролей для управления доступом к собственному приложению)	Application X Admins группа безопасности	Рабочие и тестовые подписки приложений X
  Целевая зона Application X	Администратор данных Application X	Администратор данных (настраиваемый с разрешениями на необходимые ресурсы данных)	Application X Data Team группа безопасности	Рабочие и тестовые подписки приложений X
  Целевая зона Application Y	Владельцы приложений Y	Владелец приложения (настраиваемый, включенный в акселератор целевой зоны Azure)	Application Y Admins группа безопасности	Рабочие и тестовые подписки приложения Y
  Целевая зона Application Y	Команда тестирования приложений Y	Участник тестирования (настраиваемый, с разрешениями, необходимыми для тестирования приложений)	Application Y Test Team группа безопасности	Подписка на разработку и тестирование приложения Y
  Песочница	Команда разработчиков Application Z	Владелец (встроенная)	Application Z developers группа безопасности	Группы ресурсов Application Z в подписке песочницы
  Ресурсы платформы	Команда управления платформами	Участник (встроенная)	Platform Admins Группа PIM	Platform группа управления
  Целевые зоны платформы	Команда управления платформами	Читатель (встроенная)	Platform Team группа безопасности	Группа управления верхнего уровня организации
  На уровне клиента	Отдел безопасности	Операции безопасности (пользовательские, включенные в акселератор целевой зоны Azure)	Security Ops группа безопасности	Группа управления верхнего уровня организации
  На уровне клиента	Отдел безопасности	Администратор условного доступа (встроенный с включенными защищенными действиями)	Security administrators группа безопасности	Клиент идентификатора Microsoft Entra
  На уровне клиента	Группа по сетям	Сетевые операции (настраиваемые, включенные в акселератор целевой зоны Azure)	Network Ops группа безопасности	Все подписки
  На уровне клиента	Команда FinOps	Средство чтения выставления счетов (встроенное)	FinOps Team группа безопасности	Группа управления верхнего уровня организации

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

Рекомендации Microsoft Entra PIM

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

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

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

• Управление ролями Azure RBAC с высоким уровнем привилегий, такими как "Владелец" или "Администраторы доступа пользователей", назначенные членам группы платформы или целевой зоны приложений в подписке или группе управления. Используйте Microsoft Entra PIM для групп , чтобы настроить роли RBAC Azure, чтобы они требовали того же процесса повышения прав, что и роли идентификатора Microsoft Entra.

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

• Используйте защищенные действия с Microsoft Entra PIM, чтобы добавить дополнительные уровни защиты. В идентификаторе Microsoft Entra защищенные действия — это разрешения, назначенные политиками условного доступа. Когда пользователь пытается выполнить защищенное действие, он должен сначала удовлетворить политики условного доступа, назначенные необходимым разрешениям. Например, чтобы разрешить администраторам обновлять параметры доступа между клиентами, вам может потребоваться, чтобы они сначала соответствовали политике MFA, устойчивой к фишингу.

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

Управление удостоверениями и доступом являются основными функциями реализации акселератора целевой зоны Azure. Развертывание включает в себя подписку, предназначенную для удостоверений, где организации могут развертывать контроллеры домена AD DS или другие службы удостоверений, такие как серверы Microsoft Entra Connect, необходимые для их среды. Не все организации требуют служб в подписке. Например, в некоторых организациях могут быть приложения, которые уже полностью интегрированы с идентификатором Microsoft Entra.

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

Реализация акселератора целевой зоны Azure также включает следующие варианты:

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

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