Нотатка
Доступ до цієї сторінки потребує авторизації. Можна спробувати ввійти або змінити каталоги.
Доступ до цієї сторінки потребує авторизації. Можна спробувати змінити каталоги.
Якщо ви адміністратор середовища або адміністратор Microsoft Power Platform, ви можете керувати додатками, створеними у вашій організації.
У Центрі адміністрування Power Platform можна виконувати такі дії:
- додавати або змінювати користувачів, які мають доступ до програми;
- видаляти програми, які зараз не використовуються;
вимоги
- Або план Power Apps, або план Power Automate. Альтернативно, ви можете зареєструватися на пробний період free Power Apps.
- Права адміністратора середовища Power Apps або адміністратора Power Platform. Для детальнішої інформації див. Environment administration у Power Apps.
Керування Power Apps
- Увійдіть у Центр адміністрування Power Platform.
- В області переходів виберіть Керування .
- В області «Керування » виберіть «Середовища».
- На сторінці Середовища виберіть середовище.
- У панелі Resources виберіть Power Apps.
- Виберіть програму, якою хочете керувати.
- На панелі команд виберіть потрібну дію: Поділитися або Видалити.
Керуйте тим, хто може надавати спільний доступ до компонованих програм
Power Apps поважає привілей додатку Canvas Share у Dataverse. Користувач не зможе надавати спільний доступ до програм на полотні в середовищі, якщо він не має ролі безпеки з привілеєм спільного доступу до програми Canvas, встановленим на значення, відмінне від вибраного «Немає». Це право надання спільного доступу до компонованої програми в Dataverse також передбачено в середовищі за промовчанням. Читайте «Редагувати налаштування ролі безпеки», щоб дізнатися більше.
Нотатка
Задля наявності спроможності детального керування правом надання спільного доступу до компонованої програми в ролі безпеки в середовищі, де передбачається змінювати права, має бути програма Dataverse. Power Apps не розпізнає інші привілеї сутності додатку Dataverse Canvas, встановлені для цього середовища.
Оновлення системи можуть видаляти настроювання для попередньо визначених ролей безпеки, зокрема для розробника середовища. Це означає, що видалення прав на спільний доступ до компонованої програми може бути повторно виконано під час оновлення системи. Доки настроювання прав на спільний доступ до компонованої програми буде збережено в системних оновленнях, потрібно повторно застосувати настроювання прав спільного доступу.
Surface вміст помилок управління вашої організації
Якщо ви вкажете, що вміст повідомлення про помилку управління з'являтиметься у повідомленнях про помилки, він додається до повідомлення про помилку, яке з'являється, коли користувачі бачать, що не мають дозволу на спільне використання додатків у певному середовищі. Дізнайтеся більше в статті Команди вмісту повідомлень про помилки керування PowerShell.
Відрізнити розробники власних форм Microsoft SharePoint від загальних створювачів середовищ
Окрім можливості зберігати ресурси власних форм SharePoint у нестандартному середовищі, також можливо обмежити привілеї maker лише створювати та редагувати власні форми SharePoint у нестандартному середовищі. Поза стандартним середовищем адміністратор може зняти роль безпеки Environment Maker для користувачів і призначити роль безпеки SharePoint для створення форм для користувачів.
Нотатка
Можливість відрізнити розробників власних форм SharePoint від загальних створювачів середовища вимагає використання Dataverse у тому середовищі, де має бути змінено привілей.
Користувач із роллю SharePoint кастомного формотворця в цьому середовищі не побачить середовище у списку Power Apps або Power Automate.
Зробіть наступне, щоб обмежити привілеї maker лише створювати та редагувати власні форми SharePoint у нестандартному середовищі.
Нехай адміністратор призначить середовище для SharePoint кастомних форм яке відрізняється від стандартного.
Нехай адміністратор встановить SharePoint рішення для створення кастомних форм з Marketplace у ваше середовище, призначене для SharePoint кастомних форм.
У центрі адміністрування Power Platform оберіть середовище, яке ви визначили для кастомних форм SharePoint на першому кроці, і призначте роль безпеки SharePoint для розробника кастомних форм користувачам, від яких очікується створення власних форм SharePoint. Перегляньте розділ Призначення ролей безпеки користувачам у середовищі з базою Dataverse даних.
Запитання й відповіді
Чи можу я редагувати привілеї в ролі безпеки SharePoint для створення кастомних форм?
Ні, роль безпеки SharePoint для розробника кастомних форм додається до середовища шляхом імпорту неналаштовуваного рішення. Зверніть увагу, що створення власних форм у SharePoint вимагає наявності прав у SharePoint та Power Platform. Платформа перевіряє, що користувач має права на запис для цільового списку, створеного за допомогою Microsoft Lists, а користувач має дозвіл у Power Platform створювати або оновлювати власну форму SharePoint. Щоб кастомний формогенератор SharePoint виконав перевірку Power Platform, користувач повинен мати роль безпеки власної форми SharePoint або роль безпеки Environment Maker.
Чи побачить користувач, який має лише SharePoint роль кастомного формотворця, середовище у виборі make.powerapps.com середовища?
Ні, виробник, у якого немає ролі безпеки, зазначеної в документації Choose середовищ , не побачить середовище у вибірці середовища в https://make.powerapps.com. Користувач із роллю кастомного формотворця SharePoint може спробувати перейти до середовища, маніпулюючи URI. Якщо користувач намагається створити окремий додаток, він побачить помилку дозволу.
Керування станом карантину програми
Як доповнення до політик запобігання втраті даних Power Platform, Power Platform дозволяє адміністраторам «карантинувати» ресурс, створюючи обмеження для low-code розробки. Стан карантину ресурсу управляється адміністраторами і контролює, чи є ресурс доступним для кінцевих користувачів. У Power Apps ця можливість дозволяє адміністраторам безпосередньо обмежувати доступність додатків, які потребують уваги для виконання вимог організації щодо відповідності.
Нотатка
Додаток на карантині буде недоступний користувачам, які раніше його не запускали.
Програма на карантині може бути доступна на мить користувачам, які грали в неї до того, як її було поміщено на карантин. Ці користувачі можуть використовувати програму на карантині протягом кількох секунд, якщо вони використовували її раніше. Але після цього вони отримають повідомлення про те, що програму закрито на карантин, якщо вони спробують відкрити її знову.
У наведеній нижче таблиці зазначено, як карантинний стан впливає на роботу адміністраторів, авторів і кінцевих користувачів.
| Портрет | Взаємодія |
|---|---|
| Адміністрування | Незалежно від карантинного стану додатку, додаток видимий адміністраторам у Power Platform Admin Center та командлах PowerShell. |
| Відповідальна особа | Незалежно від карантинного стану додатку, додаток видно у https://make.powerapps.com і може бути відкритий для редагування в Power Apps Studio. |
| Користувач | Карантинний додаток надає кінцевим користувачам, які запускають додаток, повідомлення про те, що вони не можуть отримати доступ до додатку. |
Кінцеві користувачі бачитимуть повідомлення про помилку, коли запускатимуть додаток, який було поміщено в карантин.
У наведеній нижче таблиці відображається підтримка карантину:
| тип Power Apps | Підтримка карантину |
|---|---|
| Компонована програма | Загально доступно |
| Модельна програма | Ще не підтримується |
Карантин програми
Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Виведення програми з карантину
Set-AppAsUnquarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Отримання програмою статусу карантину
Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>
Керовані середовища: умовний доступ до окремих додатків
Окрім дотримання політик умовного доступу, застосованих до сервісу Power Apps, у керованих середовищах можливо застосовувати політики умовного доступу Microsoft Entra до окремих додатків, створених за допомогою Power Apps. Наприклад, адміністратор може застосувати політику умовного доступу, яка вимагає багатофакторної автентифікації лише до додатків із конфіденційними даними. Power Apps використовує контекст автентифікації умовного доступу як механізм для таргетування політик умовного доступу до детальних додатків. Адміністратори можуть додавати та видаляти контексти автентифікації для програм. Розробники не можуть редагувати контексти автентифікації в додатку.
Нотатка
- Контексти автентифікації, встановлені в програмі, не переміщуються разом із програмами в рішеннях і не переміщуються між середовищами. Це дозволяє застосовувати для програм різні контексти автентифікації у різних середовищах. Крім того, коли програма переміщується між середовищами за допомогою рішень, контекст автентифікації, заданий у середовищі, буде збережено. Наприклад, якщо контекст автентифікації встановлено для програми в середовищі UAT, такий контекст автентифікації зберігається.
- Для кожної програми можна встановити кілька контекстів автентифікації. Кінцевий користувач повинен пройти об’єднання політик умовного доступу, що застосовуються кількома контекстами автентифікації.
- Умовний доступ до окремих додатків — це функція керованих середовищ.
У наведеній нижче таблиці описано, як застосування умовного доступу до певного додатка впливає на роботу адміністраторів, виробників і кінцевих користувачів.
| Портрет | Взаємодія |
|---|---|
| Адміністрування | Незалежно від політик умовного доступу, пов’язаних із програмою, вона відображається адміністраторам у Power Platform командлетах Admin Center і PowerShell. |
| Відповідальна особа | Незалежно від політик умовного доступу, пов'язаних із додатком, додаток видно у https://make.powerapps.com і може бути відкритий для редагування в Power Apps Studio. |
| Користувач | Політики умовного доступу, застосовані до додатка, застосовуються, коли кінцеві користувачі запускають додаток. Користувач, який не проходить умовні перевірки доступу, отримує діалог у досвіді автентифікації, що вказує, що йому не дозволено отримати доступ до ресурсу. |
Після того, як адміністратори пов’язують контексти автентифікації з політиками умовного доступу, https://portal.azure.com вони можуть встановити ідентифікатор контексту автентифікації в програмі. На зображенні нижче показано, де можна отримати ідентифікатор контексту автентифікації.
Кінцеві користувачі, які не відповідають вимогам політики умовного доступу, отримують повідомлення про помилку про те, що вони не мають доступу.
У наведеній нижче таблиці описано підтримку умовного доступу для окремих програм.
| тип Power Apps | Умовний доступ до підтримки окремих додатків |
|---|---|
| Компонована програма | Доступна підготовча версія |
| Модельна програма | Не підтримується |
Додавання контекстних ідентифікаторів автентифікації умовного доступу до програми
Set-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName> -AuthenticationContextIds <id1, id2, etc...>
Отримання ідентифікаторів контексту автентифікації умовного доступу, встановлених у програмі
Get-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>
Видалення контекстних ідентифікаторів автентифікації умовного доступу в додатку
Remove-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>