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

Статья
11/15/2023

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

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

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

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

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

Определения

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

Примечание

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

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

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

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

Аутентификация

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

Имя пользователя и пароль.
Общий секрет, например ключ API, который предоставляет доступ.
Маркер подписанного URL-адреса (маркер SAS).
Сертификат, используемый во взаимной проверке подлинности TLS.

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

Авторизация

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

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

Ключевые стратегии проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задайте следующие вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JIT-подходы предоставляют необходимые привилегии только тогда, когда они необходимы.
Just Enough Access (JEA) предоставляет только необходимые привилегии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ведение журнала аудита

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

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

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

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

Упрощение поддержки Azure

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

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

идентификатор Microsoft Entra. Сотрудники и корпоративные ресурсы.
Внешняя идентификация Microsoft Entra. Партнеров.
Azure Active Directory B2C. Клиентов.
Microsoft Entra списке совместимости федерации. Сторонние решения федерации.

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

Вы можете оставаться в курсе новых версий в Microsoft Entra id.

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

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

Azure RBAC

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

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

Назначая пользователям роли, вы можете управлять доступом к ресурсам Azure. Дополнительные сведения см. в статье Общие сведения об управлении доступом на основе ролей в Microsoft Entra ID.
Вы можете использовать управление привилегированными пользователями для предоставления активации ролей на основе времени и утверждения для ролей, связанных с удостоверениями с высоким уровнем влияния. Дополнительные сведения см. в статье Что такое управление привилегированными пользователями?.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ведение журнала удостоверений

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

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

Пример

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

Компоненты удостоверений

Управляемые системой удостоверения. идентификатор Microsoft Entra предоставляет доступ к плоскостям данных служб, которые не сталкиваются с пользователями, такими как Key Vault Azure и хранилища данных. Эти удостоверения также управляют доступом через RBAC к плоскости управления Azure для компонентов рабочей нагрузки, агентов развертывания и участников команды.
Удостоверения рабочей нагрузки. Службы приложений в кластере Служба Azure Kubernetes (AKS) используют удостоверения рабочей нагрузки для проверки подлинности в других компонентах решения.
Управляемые удостоверения. Системные компоненты в роли клиента используют управляемые системой удостоверения, включая агенты сборки.
Человеческие личности. Аутентификация пользователей и операторов делегируется Microsoft Entra id или Microsoft Entra ID (native, B2B или B2C).

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

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

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

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

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

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

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