Поделиться через

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

  • Статья

Применяется к следующей рекомендации по контрольному списку Well-Architected Security в Power Platform:

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

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

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

Типичные примеры удостоверений:

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

Определения

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

Заметка

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

Microsoft Entra в качестве поставщика удостоверений Power Platform

Все продукты Power Platform используют Microsoft Entra ID (ранее Azure Active Directory или Azure AD) для системы управления идентификацией и доступом. Entra ID позволяет организациям обеспечивать защиту удостоверений и управление ими в своих гибридных и мультиоблачных средах. Entra ID также необходим для управления бизнес-гостями, которым требуется доступ к ресурсам Power Platform. Power Platform также использует Entra ID для управления другими приложениями, которые необходимо интегрировать с Power Platform API, используя возможности субъекта-службы. Используя Entra ID, Power Platform может использовать более продвинутые функции безопасности Entra ID, такие как условный доступ и непрерывная оценка доступа.

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

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

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

Аутентификация Power Platform включает в себя последовательность запросов, ответов и перенаправлений между браузером пользователя и Power Platform или службами Azure. Последовательность следует за потоком предоставления кода Microsoft Entra ID.

Подключение и аутентификация в источнике данных выполняется отдельно от аутентификации в службе Power Platform. Дополнительную информацию см. в разделе Подключение и аутентификация в источниках данных.

Авторизация

Power Platform использует платформу удостоверений Microsoft Microsoft Entra ID для авторизации всех вызовов API с помощью стандартного отраслевого протокола OAuth 2.0.

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

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

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

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

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

Доступ извне. Аутентификация Power Platform включает в себя последовательность запросов, ответов и перенаправлений между браузером пользователя и Power Platform или службами Azure. Последовательность следует за потоком предоставления кода Microsoft Entra ID. Power Platform автоматически аутентифицирует всех пользователей, которые получают доступ к рабочей нагрузке для различных целей.

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

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

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

  • Доступ в плоскости данных. Действия, происходящие в плоскости данных, вызывают передачу данных. Например, приложение читает или записывает данные из Microsoft Dataverse или записывает журналы в Application Insights.

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

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

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

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

В частности, необходимо принимать во внимание следующее:

  • Должна ли рабочая нагрузка иметь доступ в плоскости данных к Dataverse как для чтения, так и для записи?
  • Нужен ли рабочей нагрузке доступ к свойствам среды?
  • Если удостоверение будет скомпрометировано злоумышленником, как это повлияет на систему с точки зрения конфиденциальности, целостности и доступности?
  • Нужен ли рабочей нагрузке постоянный доступ или можно рассмотреть возможность условного доступа?
  • Выполняет ли рабочая нагрузка действия, требующие административных или повышенных разрешений?
  • Как рабочая нагрузка будет взаимодействовать со сторонними службами?
  • Для рабочих нагрузок интеллектуальных приложений, таких как агенты, есть ли у вас требования к единому входу (SSO)?
  • Работает ли агент в режиме без аутентификации, в режиме с проверкой подлинности или в обоих режимах?

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

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

Задавайте подобные вопросы:

  • Достаточен ли доступ только для чтения?
  • Нужны ли удостоверению разрешения на удаление ресурсов?
  • Роли нужен только доступ к созданным ею записям?
  • Требуется ли иерархический доступ на основе бизнес-единицы, в которой находится пользователь?
  • Требуются ли для этой роли административные или повышенные разрешения?
  • Нужен ли роли постоянный доступ к этим разрешениям?
  • Что произойдет, если пользователь сменит работу?

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

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

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

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

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

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

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

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

Своевременность (JIT). Этот подход обеспечивает предоставление необходимых привилегий только тогда, когда они необходимы.

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

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

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

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

Учетные записи с критическим влиянием

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

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

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

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

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

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

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

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

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

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

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

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

Защитите секреты, не связанные с удостоверениями

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

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

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

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

Информацию о политиках смены секретов см. в разделах Автоматическая смена секрета для ресурсов, имеющих два набора учетных данных для аутентификации и Руководство: обновление частоты автоматического смены сертификата в Key Vault.

Сохраняйте безопасность сред разработки

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

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

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

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

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

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

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

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

Возможности в Power Platform

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

ИД Microsoft Entra

Все продукты Power Platform используют Microsoft Entra ID (ранее Azure Active Directory или Azure AD) для системы управления идентификацией и доступом. Entra ID позволяет организациям обеспечивать защиту удостоверений и управление ими в своих гибридных и мультиоблачных средах. Entra ID также необходим для управления бизнес-гостями, которым нужен доступ к ресурсам Power Platform. Power Platform также использует Entra ID для управления другими приложениями, которые необходимо интегрировать с Power Platform API, используя возможности субъекта-службы. Используя Entra ID, Power Platform может использовать более продвинутые функции безопасности Entra ID, такие как условный доступ и непрерывная оценка доступа.

Схема системы облачных вычислений.

Назначение лицензий

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

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

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

Дополнительные сведения:

Непрерывный доступ

Непрерывный доступ ускоряется, когда определенные события оцениваются, чтобы определить, следует ли отозвать право доступа. Традиционно при проверке подлинности OAuth 2.0 срок действия маркера доступа истекает во время проверки во время обновления маркера. При непрерывном доступе критические события пользователя и изменения местоположения в сети постоянно оцениваются, чтобы определить, следует ли пользователю по-прежнему сохранять доступ. Эти оценки могут привести к досрочному завершению активных сеансов или к необходимости повторной аутентификации. Например, если учетная запись пользователя отключена, он должен потерять доступ к приложению. Местоположение также важно; например, токен мог быть авторизован из доверенного местоположения, но пользователь изменил свое подключение на ненадежную сеть. Непрерывный доступ вызовет оценку политики условного доступа, и пользователь потеряет доступ, поскольку он больше не подключается из утвержденного местоположения.

В настоящее время в Power Platform только Dataverse поддерживает оценку непрерывного доступа. Microsoft работает над добавлением поддержки для других служб и клиентов Power Platform. Дополнительные сведения см. в разделе Оценка непрерывного доступа.

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

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

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

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

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

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

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

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

Журналы действий Power Apps, Power Automate, Copilot Studio, соединителей и защиты от потери данных отслеживаются и просматриваются на портале соответствия требованиям Microsoft Purview. Дополнительные сведения см. Подробнее о Microsoft Purview.

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

Роли администратора службы

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

Использование технологии управления привилегированными пользователями Microsoft Entra для управления ролями администраторов с высокими привилегиями в Центре администрирования Power Platform.

Обеспечение безопасности данных Dataverse

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

Настройка проверки подлинности пользователя в Copilot Studio

Microsoft Copilot Studio поддерживает несколько вариантов аутентификации. Выберите, который подходит под ваши требования. Аутентификация позволяет пользователям входить в систему, предоставляя таким образом вашему агенту доступ к ограниченным ресурсам или информации. Пользователи могут войти в систему с помощью Microsoft Entra ID или с любым поставщиком удостоверений OAuth 2.0, например Google или Facebook. Дополнительные сведения см. в статье Настройка проверки подлинности пользователей в Copilot Studio.

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

Copilot Studio поддерживает единый вход (SSO), что означает, что агенты могут авторизовать пользователя. Единый вход должен быть реализован на ваших веб-страницах и в мобильных приложениях. Для Microsoft Teams единый вход выполняется без проблем, если вы выберете параметр проверки подлинности "Только в Teams". Его также можно настроить вручную в Azure AD версии 2, однако в этом случае приложение Teams должно быть развернуто в виде ZIP-файла, а не путем развертывания Teams в Copilot Studio одним щелчком мыши.

Подробнее:

Безопасный доступ к данным с помощью Защищенного хранилища

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

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

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

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