Стратегии архитектуры для управления удостоверениями и доступом

Это относится к рекомендации по безопасности Azure Well-Architected Framework:

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

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

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

• Системы. Удостоверения рабочей нагрузки, управляемые удостоверения, ключи API, субъекты-службы и ресурсы Azure.

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

Терминология 

Роль поставщика удостоверений

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

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

Проверка подлинности

Проверка подлинности — это процесс проверки удостоверений. Для запрашивающей стороны требуется предоставить некоторую форму проверяемой идентификации. Например:

• Имя пользователя и пароль.

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

• Токен SAS (токен общей доступа).

• Сертификат, используемый в взаимной проверке подлинности TLS.

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

Авторизация

Авторизация — это процесс, который разрешает или запрещает действия, запрашиваемые проверенным удостоверением. Действие может быть операционным или связанным с управлением ресурсами.

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

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

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

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

Определите все идентичности для аутентификации

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

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

  Оба являются примерами идентификационных данных пользователей, имеющих разные персоны.

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

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

Все эти идентичности должны быть подтверждены вашим поставщиком удостоверений.

Ниже приведен пример реализации идентичности в архитектуре:

Определение действий для авторизации

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

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

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

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

Предоставление авторизации на основе ролей

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

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

Назначение ролей

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

Задайте такие вопросы:

• Достаточно ли доступ только для чтения?
• Нужны ли разрешения для идентификации для удаления ресурсов?

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

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

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

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

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

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

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

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

Если требуется точное управление RBAC, добавьте условия назначения ролей на основе контекста, таких как действия и атрибуты.

Выбор условного доступа

Не предоставляйте всем идентичностям одинаковый уровень доступа. Основывайте свои решения на двух основных факторах:

• Время. Как долго удостоверение может иметь доступ к вашей среде.

• Привилегии. Уровень разрешений.

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

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

• Только достаточно доступа (JEA) предоставляет только необходимые привилегии.

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

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

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

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

Защита учетных записей критического значения

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

Для защиты привилегированного доступа от злоумышленников необходима комплексная стратегия изолирования этих систем от рисков. Вот некоторые стратегии:

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

• Используйте отдельные роли вместо повышения привилегий для существующих идентичностей.

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

• Используйте современные протоколы доступа, такие как проверка подлинности без пароля или многофакторная проверка подлинности. Внедрите эти механизмы в идентификатор поставщика удостоверений.

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

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

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

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

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

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

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

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

Защита секретов, не связанных с идентичностью

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

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

В следующем списке представлен сводка рекомендаций. Более подробную информацию см. в рекомендациях по секретам приложений.

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

• Убедитесь, что у вас есть возможность отзыва секретов.

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

Сведения о политиках поворота см. в статье "Автоматизация смены секрета для ресурсов с двумя наборами учетных данных проверки подлинности" и "Руководство. Обновление частоты автоматического поворота сертификата в Key Vault".

Безопасность сред разработки

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

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

Поддерживайте журнал аудита.

Одним из аспектов управления удостоверениями является обеспечение аудита системы. Аудиты проверяют, эффективны ли стратегии имитации взлома. Ведение журнала аудита поможет вам:

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

• Обнаружение слабых или отсутствующих протоколов проверки подлинности и получение сведений о входах пользователей и приложений.

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

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

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

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

Упрощение функций Azure

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

Эти возможности изначально интегрируются в ту же модель удостоверений и разрешений Microsoft Entra для сегментов пользователей:

• Microsoft Entra ID. Сотрудники и корпоративные ресурсы.

• Microsoft Entra внешний идентификатор Партнёры.

• Список совместимости федерации Microsoft Entra. Сторонние федеративные решения.

Вы можете использовать идентификатор Microsoft Entra для проверки подлинности и авторизации пользовательских приложений с помощью библиотеки проверки подлинности Майкрософт (MSAL) или функций платформы, таких как проверка подлинности для веб-приложений. Он охватывает плоскость управления Azure, плоскости данных большинства служб Azure и возможности интеграции для приложений.

Вы можете оставаться в курсе, посетив раздел "Что нового в Microsoft Entra ID".

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

Azure поддерживает открытые протоколы, такие как OAuth2 и OpenID Connect. Мы рекомендуем использовать эти стандартные механизмы проверки подлинности и авторизации вместо разработки собственных потоков.

Azure RBAC

Azure RBAC представляет объекты безопасности в Microsoft Entra ID. Все назначения ролей выполняются с помощью Azure RBAC. Воспользуйтесь встроенными ролями, которые предоставляют большую часть необходимых разрешений. Дополнительные сведения см. в статье Встроенные роли Microsoft Entra.

Ниже приведены некоторые варианты использования:

• Назначив пользователей ролям, вы можете управлять доступом к ресурсам Azure. Дополнительные сведения см. в разделе "Обзор управления доступом на основе ролей" в идентификаторе Microsoft Entra.

• Вы можете использовать управление привилегированными идентичностями для предоставления активации ролей на основе времени и утверждения для ролей, связанных с удостоверениями с высоким уровнем воздействия. Дополнительные сведения см. в разделе "Что такое управление привилегированными пользователями?".

Дополнительные сведения о RBAC см. в рекомендациях по Azure RBAC.

Сведения об элементах управления на основе атрибутов см. в статье "Что такое Azure ABAC?".

Идентификация рабочей нагрузки

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

Дополнительные сведения см. в разделе "Что такое удостоверения рабочей нагрузки?".

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

Не все службы поддерживают управляемые удостоверения. Если вы не можете использовать управляемые удостоверения, можно использовать учетные записи службы. Однако использование субъектов-служб увеличивает затраты на управление. См. сведения об управляемых удостоверениях для ресурсов Azure.

Идентификатор ресурса

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

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

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

Дополнительные сведения см. в разделе Условный доступ: пользователи, группы и удостоверения рабочей нагрузки.

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

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

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

Обнаружение угроз

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

Обнаружение угроз может принимать форму реагирования на оповещение о подозрительной активности или заранее искать аномальные события в журналах действий. Аналитика поведения пользователей и сущностей (UEBA) в Microsoft Sentinel упрощает обнаружение подозрительных действий. Дополнительные сведения см. в статье "Определение расширенных угроз с помощью UEBA".

Гибридные системы

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

Сведения о фильтрации в идентификаторе Microsoft Entra см. в разделе Microsoft Entra Connect Sync: настройка фильтрации.

Ведение журнала идентификации

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

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

Пример

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

Компоненты идентичности

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

• Идентичности рабочей нагрузки. Службы приложений в кластере Azure Kubernetes Service (AKS) используют удостоверения рабочей нагрузки для аутентификации с другими компонентами в решении.

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

• Человеческие личности. Проверка подлинности пользователей и операторов делегируется Microsoft Entra ID или Microsoft Entra ID (коренной, B2B или B2C).

Безопасность предварительно общих секретов важна для любого приложения. Azure Key Vault предоставляет безопасный механизм хранения этих секретов, включая Redis и сторонние секреты.

Механизм поворота используется для обеспечения того, чтобы секреты не скомпрометировались. Токены для реализации платформы идентификации Майкрософт в рамках OAuth 2 и OpenID Connect используются для аутентификации пользователей.

Политика Azure используется для обеспечения того, чтобы компоненты удостоверений, такие как Key Vault, использовали RBAC вместо политик доступа. JIT и JEA предоставляют традиционные постоянные разрешения для человеческих операторов.

Журналы доступа включены во всех компонентах посредством Azure Diagnostics или через код для кодовых компонентов.

Дополнительные ссылки

• Руководство. Автоматизация смены секрета для ресурсов с двумя наборами учетных данных проверки подлинности
• Руководство. Обновление частоты автоматического поворота сертификата в Key Vault
• Что нового в идентификаторе Microsoft Entra ID?
• Встроенные роли Microsoft Entra
• Обзор управления доступом на основе ролей в Microsoft Entra ID
• Что такое идентификаторы рабочих нагрузок?
• Что такое управляемые удостоверения для ресурсов Azure?
• Условный доступ: пользователи, группы и идентификации рабочих процессов
• Синхронизация Microsoft Entra Connect: настройка фильтрации

Контрольный список по безопасности

Ознакомьтесь с полным набором рекомендаций.