Partager via

Sécuriser l’environnement par défaut

  • Article

Tous les employés d’une organisation utilisant Power Platform ont accès à l’environnement par défaut. En tant qu’administrateur Power Platform, vous devez envisager des moyens de sécuriser cet environnement tout en le gardant accessible pour les utilisations de productivité personnelles des créateurs. Cet article fournit des suggestions.

Attribuer judicieusement des rôles administrateur

Demandez-vous si vos utilisateurs administrateurs doivent disposer du rôle administrateur Power Platform. Le rôle d’administrateur d’environnement ou d’administrateur système serait-il plus approprié ? Dans tous les cas, limitez le rôle d’administrateur Power Platform le plus puissant à quelques utilisateurs seulement. En savoir plus sur l’administration des environnements Power Platform .

Communiquer l’intention

L’un des principaux défis pour l’équipe du Center of Excellence (CoE) Power Platform est de communiquer les utilisations prévues de l’environnement par défaut. Voici quelques recommandations.

Renommer l’environnement par défaut

L’environnement par défaut est créé avec le nom : TenantName (par défaut). Vous pouvez changer le nom de l’environnement en quelque chose de plus descriptif, comme Environnement de productivité personnel, pour rappeler clairement l’intention.

Utiliser le centre Power Platform

Le Centre Microsoft Power Platform est un modèle de site de communication SharePoint. Il fournit un point de départ à une source centrale d’informations pour les décideurs concernant l’utilisation de Power Platform. Le contenu de démarrage et les modèles de page permettent d’offrir facilement aux créateurs des informations telles que :

  • Cas d’utilisation de la productivité personnelle
  • Comment créer des applications et des flux ?
  • Où créer des applications et des flux ?
  • Comment contacter l’équipe du support technique du CoE ?
  • Règles relatives à l’intégration avec des services externes

Ajoutez des liens vers toute autre ressource interne que vos créateurs pourraient trouver utile.

Limitez le partage avec tout le monde

Les créateurs peuvent Partager leurs applications avec d’autres utilisateurs individuels et groupes de sécurité. Par défaut, le partage avec l’ensemble de votre organisation, ou Tout le monde, est désactivé. Envisagez d’utiliser un processus fermé autour des applications largement utilisées pour appliquer des politiques et des exigences telles que celles-ci :

  • Stratégie de révision de la sécurité
  • Stratégie d’examen de l’entreprise
  • Exigences de la gestion du cycle de vie des applications (ALM)
  • Exigences en matière d’expérience utilisateur et de personnalisation

La fonctionnalité Partager avec tout le monde est désactivée par défaut dans Power Platform. Nous vous recommandons de conserver ce paramètre désactivé pour limiter la surexposition des applications canevas à des utilisateurs indésirables. Le groupe Tout le monde de votre organisation contient tous les utilisateurs qui se sont déjà connectés à votre locataire, ce qui inclut les invités et les membres internes. Il ne s’agit pas uniquement de tous les employés internes de votre locataire. De plus, les membres du groupe Tout le monde ne peuvent pas être modifiés ni affichés. Pour en savoir plus sur le groupe Tout le monde , accédez à /windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone.

Si vous souhaitez partager Partager avec tous les employés internes ou un grand groupe de personnes, envisagez de partager avec un groupe de sécurité existant de ces membres ou de créer un groupe de sécurité et de partager votre application avec ce groupe de sécurité.

Lorsque Partager avec tout le monde est désactivé, seul un petit groupe d’administrateurs peut Partager une application avec tout le monde dans le groupe environnement. Si vous êtes un Administrateur, vous pouvez exécuter la commande PowerShell suivante si vous devez activer le partage avec Tout le monde.

  1. Tout d’abord, ouvrez PowerShell en tant que Administrateur et connectez-vous à votre compte en exécutant cette commande. Power Apps 

    Add-PowerAppsAccount

  2. Exécutez l’applet de commande Get-TenantSettings pour récupérer la liste des paramètres de client pour votre organisation en tant qu’objet.

    L’objet powerPlatform.PowerApps comprend trois indicateurs :

    Capture d’écran de trois indicateurs dans l’objet $settings.powerPlatform.PowerApps.

  3. Exécutez les commandes PowerShell suivantes pour obtenir l’objet de paramètres et définissez la variable disableShareWithEveryone sur $false.

    $settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$false

  4. Exécutez l’applet de commande avec l’objet paramètres pour permettre aux créateurs de Partager leurs applications avec tout le monde dans le locataire. Set-TenantSettings 

      Set-TenantSettings $settings

    Pour désactiver le partage avec Tout le monde, suivre suivez les mêmes étapes mais définissez $settings.powerPlatform.powerApps.disableShareWithEveryone = $true.

Établir une stratégie de protection contre la perte de données

Une autre façon de sécuriser l’environnement par défaut consiste à créer une stratégie de protection des pertes de données (DLP) pour cela. Avoir une stratégie DLP en place est particulièrement critique pour l’environnement par défaut puisque tous les employés d’une organisation y ont accès. Voici quelques recommandations pour vous aider à appliquer la stratégie.

Personnaliser le message de gouvernance DLP

Personnalisez le message d’erreur qui s’affiche si un créateur crée une application qui enfreint la stratégie DLP de votre organisation. Dirigez le fabricant vers le centre Power Platform de votre organisation et fournissez l’adresse électronique de votre équipe CoE.

À mesure que l’équipe CoE affine la stratégie DLP, vous risquez de casser par inadvertance certaines applications. Assurez-vous que le message de violation de la stratégie DLP contient des coordonnées ou un lien vers plus d’informations pour fournir une voie à suivre aux créateurs.

Utilisez les applets de commande PowerShell suivantes pour personnaliser le message de la stratégie de gouvernance :

Command Description
Set-PowerAppDlpErrorSettings Définir le message de gouvernance
Set-PowerAppDlpErrorSettings Mettre à jour le message de gouvernance

Bloquer les nouveaux connecteurs dans l’environnement par défaut

Par défaut, tous les nouveaux connecteurs sont placés dans le groupe Non professionnel de votre politique DLP. Vous pouvez toujours modifier le groupe par défaut en Métier ou Bloqué. Pour une stratégie DLP appliquée à l’environnement par défaut, nous vous recommandons de configurer le groupe Bloqué par défaut pour garantir que les nouveaux connecteurs restent inutilisables jusqu’à ce qu’ils aient été examinés par l’un de vos administrateurs.

Limiter les fabricants aux connecteurs prédéfinis

Limitez les fabricants aux seuls connecteurs de base non blocables pour empêcher l’accès au reste.

  1. Déplacez tous les connecteurs qui ne peuvent pas être bloqués vers le groupe de données commerciales.

  2. Déplacez tous les connecteurs pouvant être bloqués vers le groupe de données bloquées.

Limiter les connecteurs personnalisés

Les connecteurs personnalisés intègrent une application ou un flux avec un service développé en interne. Ces services sont destinés aux utilisateurs techniques comme les développeurs. Il est préférable de réduire l’empreinte des API (créées par l’organisation) qui peuvent être appelées à partir d’applications ou de flux dans l’environnement par défaut. Pour vous assurer que les créateurs ne peuvent pas créer et utiliser des connecteurs personnalisés pour les API dans l’environnement par défaut, créez une règle pour bloquer tous les modèles d’URL.

Pour permettre aux créateurs d’accéder à certaines API (par exemple, un service qui renvoie une liste des jours fériés de l’entreprise), configurez plusieurs règles qui classent différents modèles d’URL dans les groupes de données professionnelles et non professionnelles. Assurez-vous que les connexions utilisent toujours le protocole HTTPS. En savoir plus sur la politique DLP pour les connecteurs personnalisés.

Sécuriser l’intégration avec Exchange

Le connecteur Office 365 Outlook est l’un des connecteurs standard qui ne peuvent pas être bloqués. Ce connecteur permet à un employé d’envoyer, de supprimer et de répondre à des messages électroniques dans les boîtes aux lettres auxquelles il a accès. Le risque avec ce connecteur est également l’une de ses capacités les plus puissantes : la possibilité d’envoyer un courrier électronique. Par exemple, un créateur peut créer un flux qui envoie une explosion d’e-mails.

L’administrateur Exchange de votre organisation peut configurer des règles sur Exchange Server pour empêcher l’envoi de courriers électroniques à partir d’applications. Il est également possible d’exclure des flux ou des applications spécifiques des règles définies pour bloquer les courriers électroniques sortants. Vous pouvez combiner ces règles avec une « liste autorisée » d’adresses e-mail pour vous assurer que les courriers électroniques des applications et des flux ne peuvent être envoyés qu’à partir d’un petit groupe de boîtes aux lettres.

Chaque fois qu’une application ou un flux envoie un courrier électronique via le connecteur Office 365 Outlook, il insère des en-têtes SMTP spécifiques dans le courrier électronique. Vous pouvez utiliser les phrases réservées dans les en-têtes qui peuvent être utilisées pour identifier si le courrier électronique provient d’un flux ou d’une application.

L’en-tête SMTP inséré dans un courrier électronique envoyé à partir d’un flux ressemble à l’exemple ci-dessous :

 x-ms-mail-application: Microsoft Power Automate; 
 User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
 x-ms-mail-operation-type: Send
 x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b

Détails de l’en-tête

La table suivante décrit les valeurs qui peuvent s’afficher dans l’en-tête x-ms-mail-application peut avoir les valeurs suivantes selon le service utilisé :

Service active
Power Automate Microsoft Power Automate ; User-Agent: azure-logic-apps/1.0 (workflow <GUID> ; version <numéro de version>) microsoft-flow/1.0
Power Apps Microsoft Power Apps ; User-Agent: PowerApps/ (; AppName= <app name>)

La table suivante décrit les valeurs qui peuvent s’afficher dans l’en-tête x-ms-mail-operation-type en fonction de l’action en cours d’exécution :

active Description
Réponse Pour les opérations de réponses aux courriers électroniques
Transférer Pour les opérations de transfert de courriers électroniques
Envoi Pour les opérations d’envoi de courriers électroniques, notamment SendEmailWithOptions et SendApprovalEmail

L’en-tête x-ms-mail-environment-id contient la valeur de l’ID d’environnement. La présence de cet en-tête dépend du produit que vous utilisez :

  • Dans Power Apps, il est toujours présent.
  • Dans Power Automate, il n’est présent que dans les connexions créées après juillet 2020.
  • Dans Logic Apps, il n’est jamais présent.

Règles Exchange possibles pour l’environnement par défaut

Voici quelques actions de courrier électronique que vous pourriez vouloir bloquer à l’aide des règles Exchange.

  • Bloquer les e-mails sortants vers des destinataires externes : bloquez tous les e-mails sortants envoyés à des destinataires externes depuis Power Automate et Power Apps. Cette règle empêche les créateurs d’envoyer des e-mails aux partenaires, fournisseurs ou clients à partir de leurs applications ou flux.

  • Bloquer tous les courriers électroniques sortants : bloquez tous les courriers électroniques sortants transférés à des destinataires externes depuis Power Automate et Power Apps dont l’expéditeur ne figure pas dans une liste autorisée de boîtes aux lettres Cette règle évite que les créateurs génèrent un flux qui transfère automatiquement les courriers électroniques entrants vers un destinataire externe.

Exceptions à prendre en compte avec les règles de blocage des courriers électroniques

Voici quelques exceptions possibles aux règles Exchange pour bloquer les courriers électroniques afin d’ajouter de la flexibilité :

  • Exempter les applications et flux spécifiques : ajoutez une liste d’exemptions aux règles suggérées précédemment afin que les applications ou les flux approuvés puissent envoyer des courriers électroniques à des destinataires externes.

  • Liste d’autorisation au niveau de l’organisation : dans ce scénario, il est logique de déplacer la solution dans un environnement dédié. Si plusieurs flux de l’environnement doivent envoyer des courriers électroniques sortants, vous pouvez créer une règle d’exception générale pour autoriser les courriers électroniques sortants de cet environnement. L’autorisation de créateur et d’administrateur sur cet environnement doit être étroitement contrôlée et limitée.

Pour plus d’informations sur la manière de configurer les règles d’exfiltration appropriées pour le trafic de courrier électronique associé, accédez à Power Platform Contrôles d’exfiltration de courrier électronique pour les connecteurs .

Appliquer l’isolation entre les clients

Power Platform dispose d’un système de connecteurs basé sur Microsoft Entra qui permet aux utilisateurs Microsoft Entra autorisés de connecter des applications et des flux à des magasins de données. L’isolation du client régit le mouvement des données depuis des sources de données autorisées Microsoft Entra vers et depuis leur client.

L’isolation du client est appliquée au niveau du client et a un impact sur tous les environnements du client, y compris l’environnement par défaut. Étant donné que tous les employés sont des créateurs dans l’environnement par défaut, la configuration d’une stratégie robuste d’isolation du client est critique pour sécuriser l’environnement. Il est recommandé de configurer explicitement les clients auxquels vos employés peuvent se connecter. Tous les autres clients doivent être couverts par des règles par défaut qui bloquent les flux de données entrants et sortants.

Notez que l’isolement client Power Platform est différent de la restriction du client au niveau de Microsoft Entra ID. Il n’affecte pas l’accès basé sur Microsoft Entra ID en dehors de Power Platform. Il fonctionne uniquement pour les connecteurs utilisant l’authentification basée sur Microsoft Entra ID, comme les connecteurs Office 365 Outlook et SharePoint.

Voir aussi

Restreindre l’accès entrant et sortant entre locataires (version préliminaire)

Obtenir-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)