Déploiements sécurisés
La sécurité est un élément clé de l’administration d’un déploiement de Power Platform. La sécurité est essentielle pour garantir que chacun n’ait accès qu’aux données dont il a besoin, mais aussi pour s’assurer que les personnes ou les applications qui ne doivent pas y avoir accès n’accèdent pas aux données.
Mise en place d’une stratégie DLP
L’une des premières choses à considérer lors du déploiement d’une solution Power Platform est d’établir une stratégie de protection contre la perte de données (DLP). Les stratégies DLP agissent comme des garde-fous conçus pour empêcher les utilisateurs d’exposer involontairement des données organisationnelles et pour protéger la sécurité des informations dans le locataire. Les stratégies DLP appliquent des règles concernant les connecteurs qui sont activés pour chaque environnement, et les connecteurs qui peuvent être utilisés ensemble. Les connecteurs sont classés comme suit : données métier uniquement, pas de données métier autorisées ou bloquées. Un connecteur dans le groupe de données métier uniquement ne peut être utilisé qu’avec d’autres connecteurs de ce groupe dans la même application ou le même flux. Par exemple, quelqu’un peut vouloir créer une application qui applique le connecteur Microsoft Dataverse et un connecteur tiers. Si vous classez le connecteur Microsoft Dataverse comme un connecteur de données métier, vous ne pouvez appliquer le connecteur tiers que s’il est également classé comme un connecteur de données métier.
L’établissement de vos stratégies DLP va de pair avec votre stratégie environnementale.
Classification des connecteurs
Les classifications commerciales et non commerciales délimitent les connecteurs qui peuvent être utilisés ensemble dans une application ou un flux donné. Les connecteurs peuvent être classés dans les groupes suivants à l’aide de stratégies DLP :
Entreprise : une ressource Power App ou Power Automate peut utiliser un ou plusieurs connecteurs d’un groupe d’entreprises. Si une ressource Power App ou Power Automate utilise un connecteur métier, elle ne peut pas utiliser de connecteur non métier.
Non métier : une ressource Power App ou Power Automate peut utiliser un ou plusieurs connecteurs d’un groupe non métier. Si une ressource Power App ou Power Automate utilise un connecteur non métier, elle ne peut pas utiliser de connecteur métier.
Bloqué : aucune ressource Power ou Power Automate ne peut utiliser un connecteur d’un groupe bloqué. Tous les connecteurs Premium appartenant à Microsoft et les connecteurs tiers (Standard et Premium) peuvent être bloqués. Tous les connecteurs standard appartenant à Microsoft et les connecteurs Common Data Service ne peuvent pas être bloqués.
Stratégies de création de stratégies DLP
Comme mentionné précédemment, en tant qu’administrateur prenant en charge un environnement ou commençant à prendre en charge l’utilisation de Power Apps et Power Automate, les stratégies DLP devraient être l’une des premières choses que vous mettez en place. Ainsi, un ensemble de stratégies de base est en place, et vous pouvez ensuite vous concentrer sur le traitement des exceptions et la création de stratégies DLP ciblées qui mettent en œuvre ces exceptions une fois approuvées.
Nous recommandons le point de départ suivant pour les stratégies DLP pour les utilisateurs partagés et les environnements de productivité d’équipe :
Créez une stratégie couvrant tous les environnements à l’exception de ceux sélectionnés (par exemple, vos environnements de production), limitez les connecteurs disponibles dans cette stratégie à Office 365 et à d’autres microservices standard, et bloquez l’accès à tout le reste. Cette stratégie s’applique à l’environnement par défaut, ainsi qu’aux environnements de formation dont vous disposez pour l’organisation d’événements de formation internes. En outre, cette stratégie s’applique également à tout nouvel environnement qui sera créé.
Créez des stratégies DLP appropriées et plus permissives pour vos environnements d’utilisateurs partagés et de productivité d’équipe. Ces stratégies peuvent permettre aux créateurs d’utiliser des connecteurs comme les services Azure en plus des services Office 365. Les connecteurs disponibles dans ces environnements dépendent de votre organisation et de l’endroit où elle stocke ses données métier.
Nous recommandons le point de départ suivant pour les politiques DLP des environnements de production (unités commerciales et projets) :
Exclure ces environnements des stratégies de productivité des utilisateurs partagés et des équipes.
Travailler avec l’unité commerciale et le projet pour déterminer les connecteurs et les combinaisons de connecteurs qu’ils utilisent et créer une stratégie des locataires pour inclure uniquement les environnements sélectionnés.
Les administrateurs de ces environnements peuvent utiliser les politiques d’environnement pour classer les connecteurs personnalisés dans la catégorie des données métier uniquement, si nécessaire.
En plus de ce qui précède, nous vous recommandons également :
De créer un nombre minimal de politiques par environnement. Il n’y a pas de hiérarchie stricte entre les politiques des locataires et celles de l’environnement, et lors de la conception et de l’exécution, toutes les politiques applicables à l’environnement dans lequel l’application ou le flux réside sont évaluées ensemble pour décider si la ressource est en conformité ou en violation des politiques DLP. Plusieurs politiques DLP appliquées à un seul environnement fragmentent votre espace de connexion de manière compliquée, et peuvent rendre difficile la compréhension des problèmes auxquels vos créateurs sont confrontés.
Une gestion centralisée des politiques DLP à l’aide de politiques au niveau des locataires, et utilisation des politiques d’environnement uniquement pour catégoriser les connecteurs personnalisés ou dans des cas exceptionnels.
Avec cela en place, planifiez comment gérer les exceptions. Vous pouvez :
Refuser la demande.
Ajouter le connecteur à la stratégie DLP par défaut.
Ajouter les environnements à la liste Tout sauf pour la DLP globale par défaut et créer une stratégie DLP spécifique au cas d’utilisation avec l’exception incluse.
Exemple : stratégie DLP de Contoso
Examinons comment Contoso Corporation, notre organisation modèle pour ce guide, a configuré ses politiques DLP. La mise en place de leurs politiques DLP est étroitement liée à leur stratégie environnementale. Les administrateurs de Contoso veulent prendre en charge les scénarios de productivité des utilisateurs et des équipes ainsi que les applications métier, en plus de la gestion des activités du Centre d’excellence (CoE).
L’environnement et la stratégie DLP appliqués ici par les administrateurs de Contoso sont les suivants :
Une stratégie DLP restrictive à l’échelle du locataire qui s’applique à tous les environnements du locataire, à l’exception de certains environnements spécifiques qu’ils ont exclus de la portée de la stratégie. Les administrateurs ont l’intention de limiter les connecteurs disponibles dans cette stratégie à Office 365 et à d’autres microservices standard en bloquant l’accès à tout le reste. Cette stratégie s’applique également à l’environnement par défaut.
Les administrateurs de Contoso ont créé un autre environnement partagé pour que les utilisateurs puissent créer des applications destinées à la productivité des utilisateurs et des équipes. Cet environnement est associé à une stratégie DLP au niveau du locataire qui n’est pas aussi peu risquée qu’une stratégie par défaut et qui permet aux responsables d’utiliser des connecteurs comme les services Azure en plus des services Office 365. Comme il s’agit d’un environnement par défaut, les administrateurs peuvent contrôler activement la liste des créateurs d’environnement pour cet environnement. Il s’agit d’une approche à plusieurs niveaux de l’environnement de productivité des utilisateurs et des équipes partagées et des paramètres DLP associés.
En outre, pour que les unités commerciales puissent créer des applications métier, elles ont créé des environnements de développement, de test et de production pour leurs filiales fiscales et d’audit dans divers pays. L’accès du créateur d’environnement est soigneusement géré, et les connecteurs appropriés de premier et de tiers sont mis à disposition à l’aide de politiques DLP au niveau du locataire, en consultation avec les parties prenantes de l’unité commerciale.
De même, les environnements de développement, de test et de production sont créés à l’usage de l’informatique centrale pour développer et déployer des applications pertinentes ou appropriées. Ces scénarios d’application métier comportent généralement un ensemble bien défini de connecteurs qui doivent être mis à la disposition des créateurs, des testeurs et des utilisateurs dans ces environnements. L’accès à ces connecteurs est géré par une stratégie dédiée au niveau des locataires.
Contoso dispose également d’un environnement spécialement dédié aux activités de son Centre d’excellence. À Contoso, la stratégie DLP pour l’environnement à usage spécial reste « high touch » étant donné la nature expérimentale du livre des équipes théoriques. Dans ce cas, les administrateurs des locataires ont délégué la gestion de la DLP pour cet environnement directement à un administrateur d’environnement de confiance de l’équipe CoE et l’ont exclu d’une école de toutes les stratégies au niveau des locataires. Cet environnement est géré uniquement par la stratégie DLP au niveau de l’environnement, ce qui constitue une exception plutôt que la règle chez Contoso.
Comme prévu, tous les nouveaux environnements créés dans Contoso sont mis en correspondance avec la stratégie originale de tous les environnements.
Cette configuration de stratégies DLP centrées sur les locataires n’empêche pas les administrateurs d’environnement de créer leurs propres stratégies DLP au niveau de l’environnement, s’ils souhaitent introduire d’autres restrictions ou classer des connecteurs personnalisés.
Vous pouvez en savoir plus sur la création de stratégies DLP ici : Planifier et gérer votre environnement Microsoft Power Platform.