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

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

Управление разрешениями и ролями в средах Power Automate

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

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

Роли среды и безопасность

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

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

• Создатель среды: эта роль позволяет пользователям создавать новые ресурсы, такие как потоки, приложения и подключения в среде. Роль создателя среды не предоставляет доступ к существующим данным в Dataverse — она только дает возможность создавать артефакты и делиться ими. Microsoft придерживается модели минимальных привилегий для предопределенных ролей: Создатель среды имеет минимальный доступ, необходимый для создания приложений/потоков, не раскрывая данные, которые ему запрещено отображать. При необходимости создатели могут предоставлять общий доступ к созданным или приложениям/потокам другим сотрудникам организации, но они не могут повысить свои привилегии для чтения данных, если им не предоставлены дополнительные роли Dataverse.

• Пользователь среды (обычный пользователь): в средах с поддержкой Dataverse обычным конечным пользователям должна быть предоставлена роль безопасности "Базовый пользователь" (иногда называемая "Пользователь Common Data Service") для выполнения приложений или использования потоков, взаимодействующих с данными Dataverse. По умолчанию для добавления пользователя в среду, особенно если в среде есть база данных Dataverse, может потребоваться явное назначение такой роли. Это гарантирует, что они смогут запускать решения, но только с базовыми привилегиями на данные. В средах без Dataverse, если пользователю предоставляется доступ к потоку только для выполнения, он может не отображаться в списке пользователей среды, если не будет добавлен вручную. Их разрешения предоставляются исключительно через совместное использование потоков.

Разрешения на общий доступ на уровне потока

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

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

  Пример: если Алиса является совладельцем потока Боба, Алиса может изменить этот поток или удалить его, поэтому команда Боба должна добавлять Алису только в том случае, если такой доступ предусмотрен.

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

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

Роли безопасности для конкретных ресурсов и роли среды

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

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

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

Уровни разрешений в Power Automate — владельцы и пользователи только для выполнения

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

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

Снижение рисков, связанных с совместным использованием потоков за пределами их среды

Предоставление доступа к потокам пользователям, не являющимся членами среды, может привести к некоторым рискам:

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

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

• Обеспечение применения контроля доступа к среде: фундаментальной рекомендацией является ограничение членства в среде с помощью групп безопасности Microsoft Entra (Azure AD). Если связать группу безопасности со средой, в роли этой среды можно добавить только пользователей из этой группы. Это означает, что даже если автор попытается поделиться потоком с кем-то за пределами группы, этот человек не будет добавлен в среду автоматически. В средах со связанной группой безопасности любой пользователь, не входящий в эту группу, по сути является посторонним и имеет ограниченные возможности до тех пор, пока администратор не предоставит доступ. Эта настройка блокирует доступ посторонних к ресурсам среды, если только администратор явно не добавит их в группу безопасности в соответствии с политикой.

  Например, если среда Contoso HR Apps привязана к группе безопасности HR-Team, пользователь из отдела финансов не может стать совладельцем потока в HR Apps, если он не будет добавлен в группу HR-Team администратором. Использование групп безопасности таким образом помогает организациям поддерживать четкие границы для пользователей, которым разрешено использовать каждую среду.

• Пересмотрите и ограничьте совместное владение: предоставление доступа к потокам с использованием прав совладельца должно осуществляться с осторожностью. Каждый совладелец фактически становится полноправным владельцем потока, поэтому ограничьте количество совладельцев только необходимыми. Если поток был передан внешнему лицу, например разработчику или консультанту из другой команды, для устранения неполадок, убедитесь, что вы удалили его совместное владение после устранения проблемы. Делайте это, если в этом нет постоянной необходимости. В организациях могут быть реализованы процессы управления, в которых добавление совладельца за пределами среды вызывает появление оповещения или требует утверждения. Это можно сделать с помощью инструментов управления Power Automate (например, поток администрирования с помощью соединителей администрирования Power Platform для обнаружения добавления в поток нового владельца). Затем они уведомляют об этом ИТ-отдел или команду Центра передовых технологий Power Platform.

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

  Например, если поток отправляет данные клиента по электронной почте, пользователь только для выполнения может активировать эту отправку электронной почты, но не может открыть поток для получения сведений о клиенте, которые были обработаны вчера. Этот принцип согласуется с принципом «минимальные привилегии» — предоставьте минимальный доступ, необходимый для роли пользователя. Совместное использование только для выполнения часто выполняет бизнес-требование, позволяя кому-либо запускать или использовать потоки без передачи управления.

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

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

• Реализация политик защиты от потери данных (DLP): хотя политики защиты от потери данных в большей степени направлены на управление использованием соединителей, они косвенно помогают снизить риск, предотвращая использование запрещенных соединителей общими потоками. Например, если постороннему пользователю предоставлен доступ к потоку только для выполнения, строгая политика защиты от потери данных гарантирует, что поток не сможет внезапно начать передачу данных в неавторизованную службу. Защита от потери данных не останавливает сам общий доступ, но ограничивает потенциальный ущерб в случае случайного или преднамеренного неправильного использования потока. Рекомендуется классифицировать соединители по категориям Бизнес и Не бизнес и блокировать любые опасные сочетания. Таким образом, даже если потоки будут широко распространены, они не будут передавать данные в неутвержденные конечные точки.

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

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

• Просвещайте создателей и применяйте политики: иногда риск возникает из-за недостаточной осведомленности. Задокументируйте и сообщите четкую политику в отношении общего доступа, например, Не добавляйте пользователей, не входящих в среду X, в качестве совладельцев без утверждения. Используйте доступ только для выполнения, если это необходимо, для пользователей, не входящих в рабочую группу. Обучая создателей Power Automate этим рекомендациям, вы уменьшаете вероятность случайного раскрытия данных. Если в вашей организации есть внутреннее сообщество Power Platform или сеть лидеров, поделитесь напоминаниями о последствиях совместного использования потоков в широком масштабе. В конечном счете, пользователи должны понимать, что, несмотря на простоту совместного использования в Power Automate, существуют меры по обеспечению соответствия требованиям и безопасности, которые необходимо соблюдать для любого сотрудничества между средами.

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

• Рассмотрите возможность копирования потоков вместо прямого общего доступа: если пользователям в другой среде нужны функции потока, другой подход заключается в экспорте потока в виде пакета и предоставлении общего доступа к пакету вместо предоставления общего доступа к рабочему потоку. Microsoft рекомендует использовать этот подход в случаях, когда пользователь не является членом вашей среды Power Automate — вы можете отправить ему копию потока, которую он импортирует в свою среду. Затем получатель настраивает собственные подключения и самостоятельно запускает поток. Это снижает риск, избегая прямого доступа к потоку исходной среды. По сути, он дает им решение, не давая им закрепиться в вашей среде. Компромисс заключается в том, что любые обновления потока не будут синхронизироваться автоматически, так как это отдельная копия. Тем не менее, для разовых нужд или совместного использования с внешними командами этот метод обеспечивает чистое разделение.

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

Следующий раздел посвящен конкретному аспекту управления: использованию ролей и групп для определения того, кто является создателем, а кто просто исполнителем потоков.

Использование ролей и групп безопасности: управление создателями и пользователями с правами только на выполнение

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

Как отличить создателей от несоздателей

В корпоративном сценарии не каждый пользователь с лицензией Power Automate должен обязательно создавать потоки в каждой среде. По замыслу создатель среды может создавать потоки и другие ресурсы в этой среде. Для выделенных сред следует намеренно назначать роль Environment Maker только тем пользователям или группам, которые отвечают за создание решений. Например, вы можете решить, что в среде Автоматизация финансов разрешения создателя есть только у ИТ-группы Finance и нескольких опытных пользователей.

Реализуйте это, выполнив следующие действия:

• Назначьте роль безопасности Environment Maker непосредственно конкретным пользователям в параметрах среды.
• Используйте группу безопасности Azure Active Directory. Добавьте всех предполагаемых создателей в группу (например, Группа создателей Finance) и, если в среде нет Dataverse, назначьте всей этой группе роль "Создатель среды". В средах с поддержкой Dataverse может потребоваться добавить участников группы по отдельности или использовать групповые команды с ролями безопасности.
• Для обеспечения широкого контроля свяжите среду с группой безопасности, чтобы в среде могли находиться только ее участники. Затем, в рамках этого, предоставьте роли создателей соответствующему подмножеству. Такой двухуровневый подход означает, что посторонние не могут быть привлечены незамеченными в качестве создателей, и среди сотрудников только некоторые имеют роль создателей. Авторитетное руководство рекомендует применять функцию группы безопасности среды ко всем рабочим и конфиденциальным средам, чтобы предотвратить присутствие нежелательных пользователей.

Использование групп безопасности для доступа только на выполнение

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

Потоки Power Automate не должны отображать 50 пользователей как пользователей с правами только на выполнение; в них указывается одна группа, а ваш администратор Azure AD или Microsoft 365 обрабатывает членство в ней.

Назначение ролей для создателей и исполнителей

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

• Создатели: как минимум, им нужна роль "Создатель среды" для создания потоков. Если их потоки взаимодействуют с таблицами Dataverse, им также могут потребоваться дополнительные роли Dataverse, такие как настройщик системы, или привилегии для определенных таблиц, чтобы правильно их спроектировать и протестировать. Сочетание Environment Maker и роли, предоставляющей доступ к данным (при необходимости), позволяет создавать полноценные решения. Рекомендуется предоставлять создателям только те привилегии, которые им необходимы. Например, если создатель автоматизирует только SharePoint и электронную почту, ему может вообще не понадобиться роль Dataverse, кроме присутствия в среде. Однако если создатель создает поток для обновления записи Dataverse, ему требуется разрешение на эту таблицу. Спланируйте свои роли безопасности таким образом, чтобы при необходимости создатели получали отдельную роль для данных создателей, вместо того, чтобы давать им слишком широкие роли.
• Пользователи с правами только на выполнение: этим пользователям не требуется роль создателя среды. Если в среде есть база данных Dataverse и поток затрагивает данные Dataverse, им может потребоваться роль обычного пользователя (или другая роль), чтобы иметь доступ на чтение и запись к базовым данным при выполнении потока в их контексте. Например, поток ручного триггера может создать запись Dataverse от имени исполнителя. Если это так, средству выполнения требуется разрешение на создание этой записи. При использовании параметра Подключение предоставляется пользователем с правами только на выполнение поток выполняется в контексте учетных данных пользователя с правами только на выполнение. В таких случаях необходимо убедиться, что эти пользователи обладают минимальными необходимыми правами, с помощью ролей Dataverse или соответствующих системных разрешений, для выполнения действий, выполняемых потоком. Если поток всегда использует подключение владельца, пользователю с правами только на выполнение может не потребоваться какая-либо особая роль в Dataverse — он нажимает кнопку, а поток использует привилегии владельца. Этот нюанс следует тщательно продумать. Безопасный подход заключается в том, чтобы предоставить пользователям с правами только на выполнение доступ на чтение к данным, которые они могут отображать, и не более того. Многие компании создают настраиваемую роль Dataverse или используют базового пользователя с минимальными правами на чтение и назначают ее всем конечным пользователям, чтобы удовлетворить этому требованию к запуску приложений и потоков.

Управление ролями с учетом принципов регулирования

Отслеживайте, кто какую роль имеет. Администратор Power Platform может получить список всех пользователей в среде и назначенных им ролей безопасности в центре администрирования или с помощью PowerShell. Это может быть сопоставлено с ожидаемым списком создателей. Это лучшая практика управления, чтобы поддерживать инвентаризацию, например, Создатели среды X: Алиса, Боб, Кэрол; Пользователи с правами только на выполнение/ исполнители в среде X: все пользователи в отделе маркетинга. Имея четкое представление об этом, когда приходит запрос на добавление нового создателя, вы можете проверить, одобрен ли он группой, или получить необходимые одобрения для расширения круга.

Сценарии и примеры

В следующем списке описаны некоторые сценарии и примеры их решений.

• Сценарий: среда отдела, в которой потоки должны создаваться только небольшой командой, но их запускают многие сотрудники отдела.
• Решение: руководителю отдела ИТ назначается роль администратора среды. Группа Azure AD Создатели отдела состоит из пяти человек, которые создают приложения и потоки. Эта группа добавляется в роль Environment Maker. Это делается либо напрямую, либо назначаются отдельные пользователи, если групповое назначение недоступно. Все сотрудники отдела входят в группу Пользователи отдела, связанную со средой, поэтому все они имеют право быть пользователями. Доступ к созданным в среде потокам, которые должны выполняться всем отделом, предоставляется группе Пользователи отдела только для выполнения. Таким образом, создатели создают и делятся. Сотрудник отдела может выполнять, но люди, не работающие в отделе, не могут получить доступ, так как они не входят в группу среды.
• Сценарий: рабочая среда с конфиденциальными потоками, которые не должны изменяться никем, кроме двух владельцев решения.
• Решение: только эти два человека являются создателями среды. Ни у кого больше нет роли создателя. Если другим пользователям необходимо активировать потоки, им предоставляется доступ только для выполнения. Возможно, выделенная учетная запись службы или субъект-служба на самом деле является владельцем потоков для обеспечения стабильности, а два владельца — совладельцами для обслуживания. Использование субъекта-службы в качестве основного владельца улучшает управление критически важными потоками. Все обычные сотрудники либо не находятся в этой среде, либо имеют только роль пользователя. Среда может быть привязана к группе безопасности, содержащей только необходимые учетные записи для дальнейшего обеспечения эксклюзивности.
• Сценарий: среда центра передовых технологий, в которой группы управления создают потоки мониторинга во всех средах.
• Решение: доступ есть только у команды центра передовых технологий. По ролям они являются создателями среды. Совместное использование только для выполнения не требуется, так как эти потоки являются более внутренними. В этом случае сотрудники Центра передового опыта, возможно, имеют роль администратора Power Platform на уровне клиента, что неявно дает им права во всех средах.

Преимущества ролевой сегрегации

Четко разграничивая создателя и исполнителя, вы достигаете следующего:

• Минимальные привилегии: пользователи получают только те разрешения, которые им необходимы. Пользователь с правами только на выполнение не может внезапно начать создавать потоки в обход надзора со стороны ИТ-отдела, потому что у него нет этой роли. Создатели получают свободу творчества, но, поскольку эта популяция меньше и известна, вам будет легче обучать их и следить за ними.
• Упрощенное управление жизненным циклом: когда сотрудник увольняется или меняет роли, проще обновить доступ. Например, если Джо был создателем и покидает команду, он удаляется из группы безопасности "Создатели". Он мгновенно теряет возможность создавать и редактировать в этой среде, сохраняя при этом доступ к запуску, если он остается в группе пользователей. Затем вы можете добавить его замену в группу Создатели. Такое групповое обслуживание проще, чем добавление и удаление десятков разрешений на потоки вручную.
• Соответствие нормативным требованиям: многие нормативные акты требуют контролируемого доступа. Возможность показать аудитору, что только эти конкретные люди могут модифицировать автоматизацию в этой среде, а все остальные могут просто запускать утвержденные потоки, может помочь продемонстрировать сильный внутренний контроль. Аудиторам также может быть предоставлен экспорт назначений ролей среды в качестве доказательства соблюдения.
• Избегайте путаницы: если бы у всех были права создателя, меньшее количество технических пользователей могли бы непреднамеренно создавать или изменять потоки или запутаться в интерфейсе Power Automate. Ограничивая роль создателя, вы гарантируете, что потоки будут разрабатываться только обученным персоналом, что может уменьшить количество ошибок.

Эти меры следует периодически пересматривать. По мере того, как потребности бизнеса меняются, кому-то, кто является потребителем, может потребоваться стать создателем (например, опытный пользователь появляется в новой команде), или создателю может потребоваться стать потребителем. Модель управления должна быть достаточно гибкой, чтобы учесть это при наличии надлежащих утверждений. Задокументируйте критерии предоставления привилегий Environment Maker и процесс запроса, чтобы обеспечить прозрачность и согласованность. Точно так же определите, при каких условиях может быть отозван доступ создателя, например, при переходе в другой отдел.

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

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

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