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

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

SE:05	Реализация строгого, условного и аудита управления удостоверениями и доступом (IAM) для всех пользователей рабочей нагрузки, членов группы и системных компонентов. При необходимости ограничить доступ исключительно. Используйте современные отраслевые стандарты для всех реализаций проверки подлинности и авторизации. Ограничение и строгое аудит доступа, не основанное на удостоверении.

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

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

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

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

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

Определения 

Условия	Определение
Проверка подлинности (AuthN)	Процесс, который проверяет, является ли удостоверение кем или что он говорит.
Авторизация (AuthZ)	Процесс, который проверяет, имеет ли удостоверение разрешение на выполнение запрошенного действия.
Условный доступ	Набор правил, который позволяет выполнять действия на основе указанных критериев.
IdP	Поставщик удостоверений, например идентификатор Microsoft Entra.
Пользователь	Функция задания или название с набором обязанностей и действий.
Предварительные ключи	Тип секрета, который предоставляется поставщику и потребителю и используется с помощью безопасного и согласованного механизма.
Удостоверение ресурса	Удостоверение, определенное для облачных ресурсов, управляемых платформой.
Роль	Набор разрешений, определяющих, что может сделать пользователь или группа.
Область	Различные уровни иерархии организации, где роль разрешена для работы. Кроме того, группа функций в системе.
Субъект безопасности	Удостоверение, предоставляющее разрешения. Это может быть пользователь, группа или субъект-служба. Все члены группы получают тот же уровень доступа.
Удостоверение пользователя	Удостоверение для человека, например сотрудника или внешнего пользователя.
Удостоверение рабочей нагрузки	Системное удостоверение для приложения, службы, скрипта, контейнера или другого компонента рабочей нагрузки, которая используется для проверки подлинности в других службах и ресурсах.

Примечание.

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

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

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

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

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

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

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

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

• Маркер подписанного URL-адреса (маркер SAS).

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

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

Авторизация

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

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

Основные стратегии проектирования

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

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

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

Определение всех удостоверений для проверки подлинности

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

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

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

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

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

Все эти удостоверения должны проходить проверку подлинности у поставщика удостоверений.

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

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

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

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

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

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

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

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

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

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

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

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

• Достаточно ли доступ только для чтения?
• Требуется ли удостоверение разрешения на удаление ресурсов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Защита секретов на основе неидентности

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

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

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

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

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

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

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

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

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

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

Обслуживание тропы аудита

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

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

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

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

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

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

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

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

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

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

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

• Внешняя идентификация Microsoft Entra. Партнеров.

• Azure Active Directory B2C. Customers.

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

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

Вы можете оставаться в курсе, перейдя к новым сведениям в идентификаторе Microsoft Entra ID.

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

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

Azure RBAC

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

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

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

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

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

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

Удостоверение рабочей нагрузки

Идентификатор Microsoft Entra может обрабатывать удостоверение приложения. Субъект-служба, связанный с приложением, может диктовать область доступа.

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

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

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

Удостоверение ресурса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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