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

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

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

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

Типичные идентичности включают:

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

Определения

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

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

Authentication

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

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

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

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

Authorization

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 как для чтения, так и для записи?
• Нужен ли рабочей нагрузке доступ к свойствам среды?
• Если удостоверение будет скомпрометировано злоумышленником, как это повлияет на систему с точки зрения конфиденциальности, целостности и доступности?
• Нужен ли рабочей нагрузке постоянный доступ или можно рассмотреть возможность условного доступа?
• Выполняет ли рабочая нагрузка действия, требующие административных или повышенных разрешений?
• Как рабочая нагрузка будет взаимодействовать со сторонними службами?
• Для агентов у вас есть требования к единому входу?
• Работает ли агент в режиме без аутентификации, в режиме с проверкой подлинности или в обоих режимах?

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

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

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

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

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

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

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

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

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

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

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

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

Just in Time (JIT) подходы обеспечивают предоставление необходимых привилегий только в момент их необходимости.

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

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

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

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

Критически важные учетные записи

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

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

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

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

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

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

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

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

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

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

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

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

Защитите секреты, не связанные с идентификацией

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Майкрософт Ентра айди

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

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

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

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

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

Подробнее:

• Настройка условного доступа Microsoft Entra
• Кондициональный доступ и многофакторная проверка подлинности в Power Automate

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

Непрерывный доступ ускоряется, когда определенные события оцениваются, чтобы определить, следует ли отозвать право доступа. Традиционно при аутентификации 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.

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

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

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

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

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

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

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

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

Используйте Microsoft Entra управление привилегированными пользователями (PIM) для управления ролями администратора с высоким уровнем привилегий в Центре администрирования 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-файла, а не с помощью 1 щелчка по развертыванию Teams из Copilot Studio.

Подробнее:

• Настройка единого входа с помощью Microsoft Entra ID
• Настройка единого входа с Microsoft Entra ID для агентов в Microsoft Teams
• Настройка единого входа с помощью универсального поставщика OAuth

Безопасный доступ к данным с помощью Customer Lockbox

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

Управление гостевыми пользователями

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

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

Связанные сведения

• Настройка управления удостоверениями и доступом
• Подключение и аутентификация в источниках данных
• Аутентификация в службах Power Platform
• Основные понятия безопасности в Microsoft Dataverse
• Вопросы и ответы по безопасности Power Platform
• Матрица разрешений для администратора служб
• Оценка непрерывного доступа
• Настройка условного доступа Microsoft Entra
• Рекомендации по условному доступу и многофакторной аутентификации в Microsoft Power Automate
• Платформа идентификации Microsoft и поток кода авторизации в OAuth 2.0
• Что нового в Microsoft Entra ID?
• Встроенные роли Microsoft Entra
• Обзор управления доступом на основе ролей в Microsoft Entra ID

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

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