Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Si vous êtes administrateur d'environnement ou administrateur de Microsoft Power Platform, vous pouvez gérer les applications créées dans votre organisation.
Les administrateurs peuvent effectuer les tâches suivantes depuis le centre d’administration Power Platform :
- Ajout ou modification des utilisateurs avec lesquels une application est partagée
- Suppression des applications qui ne sont actuellement pas en cours de utilisation
Configuration requise
- Plan Power Apps ou plan Power Automate. Vous pouvez également vous inscrire à une version d’évaluation Power Apps gratuite.
- Autorisations d'administrateur d'environnement Power Apps ou d'administrateur Power Platform. Pour plus d’informations, consultez Environments administration dans Power Apps.
Gérer Power Apps
- Connectez-vous au Centre d’administration Power Platform.
- Dans le volet de navigation, sélectionnez Gérer.
- Dans le volet Gérer, sélectionnez Environnements.
- Sur la page Environnements, sélectionnez un environnement.
- Dans le volet Resources, sélectionnez Power Apps.
- Sélectionnez l'application que vous souhaitez gérer.
- Dans la barre de commandes, choisissez l’action souhaitée : Partager ou Supprimer.
Gérer qui peut partager des applications canevas
Power Apps respecte le privilège Share de l'application de type canevas dans Dataverse. Un utilisateur ne pourra pas partager des applications canevas dans un environnement s’il ne dispose pas de rôle de sécurité avec le privilège de partage d’application canevas défini sur une valeur autre que Aucune sélection. Ce privilège de partage de l’application canevas dans Dataverse est également respecté dans l’environnement par défaut. Pour en savoir plus, consultez Modifier les paramètres d’un rôle de sécurité.
Note
La possibilité de contrôler de manière granulaire le privilège de partage d’application canevas dans un rôle de sécurité nécessite que Dataverse soit présent dans l’environnement où ce privilège doit être modifié. Power Apps ne reconnaît pas discrètement les autres privilèges d'entité d'application Dataverse Canvas définis pour l'environnement.
Les mises à jour du système peuvent supprimer les personnalisations des rôles de sécurité prédéfinis, y compris le créateur d’environnement. Cela signifie que la suppression du privilège de partage d’application canevas peut être réintroduite lors d’une mise à jour du système. Jusqu’à ce que la personnalisation du privilège de partage de l’application canevas soit préservée lors des mises à jour du système, la personnalisation du privilège de partage peut devoir être réappliquée.
Mettre en évidence le contenu des erreurs de gouvernance de votre organisation
Si vous spécifiez le contenu du message d’erreur de gouvernance à afficher dans les messages d’erreur, il est inclus dans le message d’erreur affiché lorsque les utilisateurs observent qu’ils n’ont pas l’autorisation de partager des applications dans un environnement. Pour en savoir plus, voir Commandes de contenu des messages d’erreur de gouvernance PowerShell.
Distinguer les créateurs de formulaires personnalisés de Microsoft SharePoint des créateurs d'environnement généraux
Outre la possibilité d'enregistrer SharePoint ressources de formulaire personnalisées dans un environnement non défini, il est également possible de limiter les privilèges de créateur pour pouvoir uniquement créer et modifier des formulaires personnalisés SharePoint dans un environnement non défini. En dehors de l’environnement par défaut, un administrateur peut annuler l’attribution du rôle de sécurité Environment Maker à partir d’utilisateurs et attribuer le rôle de sécurité SharePoint de créateur de formulaires personnalisé.
Note
La capacité de distinguer les créateurs de formulaires personnalisés de SharePoint des créateurs d'environnement général nécessite l'utilisation de Dataverse dans l'environnement dans lequel le privilège doit être modifié.
Un utilisateur disposant uniquement du rôle de créateur de formulaires personnalisé SharePoint dans un environnement ne voit pas l'environnement dans la liste des environnements dans Power Apps ou Power Automate.
Procédez comme suit pour limiter les privilèges de créateur à pouvoir uniquement créer et modifier des formulaires personnalisés SharePoint dans un environnement non par défaut.
Faites en sorte qu’un administrateur désigne un environnement pour les formulaires personnalisés SharePoint différent de l’environnement par défaut.
Faites installer par un administrateur la solution de création de formulaires personnalisés SharePoint depuis le Marketplace dans votre environnement désigné pour les formulaires personnalisés SharePoint.
Dans le Centre d’administration Power Platform, sélectionnez l’environnement que vous avez désigné pour SharePoint formulaires personnalisés à l’étape 1 et attribuez le rôle de sécurité SharePoint créateur de formulaires personnalisé aux utilisateurs censés créer SharePoint formulaires personnalisés. Consultez Attribution de rôles de sécurité à des utilisateurs dans un environnement avec base de données Dataverse.
Forums aux questions
Puis-je modifier les privilèges dans le rôle de sécurité SharePoint de créateur de formulaires personnalisé ?
Non, le rôle de sécurité du fabricant de formulaires personnalisé SharePoint est ajouté à un environnement en important une solution noncustomizable. Notez que SharePoint création de formulaire personnalisée nécessite qu’un utilisateur dispose d’autorisations dans SharePoint et Power Platform. La plateforme vérifie qu’un utilisateur dispose d’autorisations d’écriture pour la liste ciblée créée à l’aide de Listes Microsoft et que l’utilisateur dispose d’autorisations dans Power Platform pour créer ou mettre à jour le formulaire personnalisé SharePoint. Pour qu’un fabricant de formulaires personnalisé SharePoint réponde à la vérification Power Platform, l’utilisateur doit avoir le rôle de sécurité de formulaire personnalisé SharePoint ou le rôle de sécurité Environment Maker.
Un utilisateur disposant uniquement du rôle de créateur de formulaires personnalisé SharePoint voit-il un environnement dans le sélecteur d’environnement make.powerapps.com ?
Non, un créateur qui n'a pas de rôle de sécurité mentionné dans la documentation Choisir des environnements ne verra pas l’environnement dans le sélecteur d’environnements dans https://make.powerapps.com. Un utilisateur disposant du rôle de créateur de formulaires personnalisé SharePoint peut tenter d’accéder à l’environnement en manipulant l’URI. Si l’utilisateur tente de créer une application autonome, une erreur d’autorisation s’affiche.
Gérer l’état de mise en quarantaine de l’application
En complément des stratégies de protection contre la perte de données de Power Platform, Power Platform permet aux administrateurs de « mettre en quarantaine » une ressource, en définissant des garde-fous pour le développement à faible code. L’état de quarantaine d’une ressource est géré par les administrateurs et contrôle si une ressource est accessible aux utilisateurs finaux. Dans Power Apps, cette fonctionnalité permet aux administrateurs de limiter directement la disponibilité des applications qui peuvent avoir besoin d'attention pour répondre aux exigences de conformité d'une organisation.
Note
Une application mise en quarantaine ne sera pas accessible aux utilisateurs qui ne l’ont jamais lancée auparavant.
Une application mise en quarantaine peut être accessible, momentanément, aux utilisateurs qui ont lancé l’application avant qu’elle ne soit mise en quarantaine. Ces utilisateurs peuvent utiliser l’application mise en quarantaine pendant quelques secondes s’ils l’ont déjà utilisée. Mais après cela, ils reçoivent un message les informant que l’application est mise en quarantaine s’ils essaient de l’ouvrir à nouveau.
Le tableau suivant décrit l’impact de l’état de mise en quarantaine sur les expériences des administrateurs, des décideurs et des utilisateurs finaux.
| Personnage | Expérience |
|---|---|
| Admin | Quel que soit l’état de quarantaine d’une application, une application est visible par les administrateurs dans le Centre d’administration Power Platform et les applets de commande PowerShell. |
| Créateur | Quel que soit l'état de quarantaine d'une application, une application est visible dans https://make.powerapps.com et peut être ouverte pour modification dans Power Apps Studio. |
| Utilisateur final | Une application mise en quarantaine présente aux utilisateurs finaux qui lancent l’application un message indiquant qu’elles ne peuvent pas accéder à l’application. |
Les utilisateurs finaux verront un message d’erreur lorsqu’ils lancent une application qui a été mise en quarantaine.
Le tableau suivant reflète le support de la mise en quarantaine :
| type de Power Apps | Support de mise en quarantaine |
|---|---|
| Application canevas | Généralement disponible |
| Application pilotée par modèle | Non pris en charge à ce jour |
Mettre une application en quarantaine
Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Annuler la quarantaine d’une application
Set-AppAsUnquarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Obtenir l’état de mise en quarantaine d’une application
Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>
Environnements gérés : accès conditionnel sur des applications individuelles
Outre le respect des stratégies d'accès conditionnel appliquées au service Power Apps, dans les environnements managés, il est possible d'appliquer Microsoft Entra stratégies d'accès conditionnel à des applications individuelles créées à l'aide de Power Apps. Par exemple, un administrateur peut appliquer une stratégie d’accès conditionnel nécessitant une authentification multifacteur uniquement sur les applications contenant des données sensibles. Power Apps utilise contexte d’authentification d’accès conditionnel comme mécanisme de ciblage des stratégies d’accès conditionnel sur des applications granulaires. Les administrateurs sont la personne autorisée à ajouter et à supprimer des contextes d’authentification sur une application. Les créateurs ne peuvent pas modifier les contextes d’authentification sur une application.
Note
- Les contextes d’authentification définis sur une application ne sont pas déplacés avec les applications dans les solutions ni déplacés entre les environnements. Cela permet d’appliquer différents contextes d’authentification aux applications dans différents environnements. De plus, lorsqu’une application se déplace d’un environnement à l’autre via des solutions, le contexte d’authentification défini dans un environnement est préservé. Par exemple, si un contexte d’authentification est défini sur une application dans un environnement UAT, ce contexte d’authentification est conservé.
- Plusieurs contextes d’authentification peuvent être définis sur une application. Un utilisateur final doit réussir l’union des stratégies d’accès conditionnel appliquées par plusieurs contextes d’authentification.
- L’accès conditionnel à des applications individuelles est une fonctionnalité des environnements gérés.
Le tableau suivant décrit l’impact de l’application de l’accès conditionnel à une application spécifique sur les expériences des administrateurs, des créateurs et des utilisateurs finaux.
| Personnage | Expérience |
|---|---|
| Admin | Quelles que soient les stratégies d’accès conditionnel associées à une application, une application est visible pour les administrateurs dans le Centre d’administration Power Platform et les applets de commande PowerShell. |
| Créateur | Quelles que soient les stratégies d’accès conditionnel associées à une application, une application est visible dans https://make.powerapps.com et peut être ouverte pour modification dans Power Apps Studio. |
| Utilisateur final | Les stratégies d’accès conditionnel appliquées à une application sont appliquées lorsque les utilisateurs finaux lancent l’application. Un utilisateur qui ne passe pas les vérifications d’accès conditionnel voit apparaître une boîte de dialogue pendant le processus d’authentification, indiquant qu’il n’est pas autorisé à accéder à la ressource. |
Une fois que les administrateurs ont associé les contextes d’authentification aux stratégies d’accès conditionnel dans https://portal.azure.com, ils peuvent définir l’ID de contexte d’authentification sur une application. L’image suivante montre où obtenir l’ID de contexte d’authentification.
Les utilisateurs finaux qui ne répondent pas aux exigences de la stratégie d’accès conditionnel reçoivent un message d’erreur indiquant qu’ils n’ont pas accès.
Le tableau suivant reflète la prise en charge de l’accès conditionnel sur des applications granulaires :
| type de Power Apps | Prise en charge de l’accès conditionnel sur des applications individuelles |
|---|---|
| Application canevas | Disponibilité en version préliminaire |
| Application pilotée par modèle | Non pris en charge |
Ajouter des ID de contexte d’authentification de l’accès conditionnel à une application
Set-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName> -AuthenticationContextIds <id1, id2, etc...>
Obtenir les ID de contexte d’authentification de l’accès conditionnel définis sur une application
Get-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>
Supprimer les ID de contexte d’authentification de l’accès conditionnel sur une application
Remove-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>
Contenu associé
Prise en charge de PowerShell par l'administrateur de Power Apps