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

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

  • Статья

Применимо к этой рекомендации Power Platform контрольного списка хорошо спроектированной безопасности:

СЭ: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 Entra ID Microsoft Identity Platform для авторизации всех вызовов 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) предоставляют требуемые привилегии только тогда, когда они необходимы.

Just Enough Access (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, коннекторы и журналы активности предотвращения потери данных отслеживаются и просматриваются на портале соответствия требованиям Purview. Microsoft Для получения дополнительной информации см. Узнайте больше о Microsoft Purview.

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

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

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

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

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

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

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

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

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

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

Подробнее:

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

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

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

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

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