Stratégies de données

La protection contre la perte de données (DLP) est un aspect critique pour maintenir la sécurité et la conformité des données au sein de l’écosystème Microsoft Power Platform.

Vous pouvez créer des stratégies de données qui peuvent servir de protections pour aider à réduire le risque que les utilisateurs exposent involontairement les données de l’organisation. Un composant central de Power Apps, Power Automate, et Microsoft Copilot Studio est l’utilisation de connecteurs pour énumérer, compléter, transmettre et extraire des données. Les stratégies de données dans le centre d’administration Power Platform permettent aux administrateurs de contrôler l’accès à ces connecteurs de différentes manières pour aider à réduire le risque dans votre organisation.

Cette vue d’ensemble décrit certains concepts de haut niveau liés aux connecteurs et plusieurs considérations importantes à prendre en compte lorsque vous configurez vos stratégies ou y apportez des modifications.

Connecteurs

Les connecteurs, à leur niveau le plus élémentaire, sont des représentations fortement typées d’interfaces de programmation d’applications RESTful, également appelées API. Par exemple, l’API Power Platform fournit plusieurs opérations liées aux fonctionnalités dans le centre d’administration Power Platform.

Lors de l’encapsulage de l’API Power Platform dans un connecteur, il devient plus facile pour les créateurs et les développeurs citoyens d’utiliser l’API dans leurs applications, workflows et chatbots low-code. Par exemple, le connecteur Power Platform for Admins V2 est la représentation de l’API Power Platform et nous voyons que l’action « Obtenir des recommandations » est simplement glissée et déplacée dans le flux :

Plusieurs types de connecteurs sont mentionnés dans cet article et chacun a des fonctionnalités au sein des stratégies de données.

Connecteurs certifiés

Les connecteurs certifiés font référence à des connecteurs qui ont été soumis à des processus de test et de certification rigoureux pour garantir qu’ils répondent aux normes Microsoft en matière de sécurité, de fiabilité et de conformité. Ces connecteurs offrent aux utilisateurs un moyen fiable d’intégration à d’autres services Microsoft et services externes, tout en maintenant l’intégrité et la sécurité des données.

Pour plus d’informations sur les connecteurs certifiés, consultez Directives pour la soumission de certifications.

Connecteurs personnalisés

Les connecteurs personnalisés permettent aux créateurs de créer leurs propres connecteurs pour les intégrer à des systèmes ou services externes non couverts par l’ensemble standard de connecteurs certifiés. Tout en offrant des options de flexibilité et de personnalisation, les connecteurs personnalisés nécessitent un examen attentif pour garantir qu’ils sont conformes aux stratégies de données et ne compromettent pas la sécurité des données.

En savoir plus sur la création et la gestion des connecteurs personnalisés.

Connecteurs virtuels

Les connecteurs virtuels sont des connecteurs affichés dans les stratégies de données que les administrateurs peuvent contrôler ; toutefois, ils ne sont pas basés sur une API RESTful. La prolifération des connecteurs virtuels est due au fait que les stratégies de données sont l’un des contrôles de gouvernance les plus populaires dans Power Platform. Un plus grand nombre de ces types de fonctionnalités « activées/désactivées » devraient apparaître sous forme de règles au sein des groupes d’environnements.

Plusieurs connecteurs virtuels sont fournis pour la gouvernance de Microsoft Copilot Studio. Ces connecteurs facilitent la possibilité de désactiver diverses fonctionnalités de Copilot et de chatbots.

Explorez les connecteurs virtuels et leur rôle dans la protection contre la perte de données dans Microsoft Copilot Studio.

Connexions

Lorsqu’un créateur crée une application ou un flux et doit se connecter aux données, il peut utiliser l’un des types de connecteurs ci-dessus. Lorsqu’un connecteur est ajouté pour la première fois à une application, une connexion est établie à l’aide des protocoles d’authentification pris en charge par ce connecteur particulier. Ces connexions représentent des informations d’identification enregistrées et sont stockées dans l’environnement qui héberge l’application ou le flux. Pour plus d’informations sur l’authentification aux connecteurs, consultez Connexion et authentification aux sources de données.

Temps de conception et temps d’exécution

Lorsqu’un administrateur choisit de limiter l’accès à un connecteur entier ou à des actions spécifiques d’un connecteur, cela a des impacts à la fois l’expérience du créateur et l’exécution des applications, flux et chatbots précédemment créés.

Les expériences des créateurs, souvent appelées expériences au moment de la conception, limitent les connecteurs avec lesquels les créateurs peuvent interagir. Si une stratégie de données bloque l’utilisation du connecteur MSN Météo, le créateur ne peut pas enregistrer son flux ou l’application qui l’utilise et reçoit à la place un message d’erreur indiquant que le connecteur a été bloqué par la stratégie.

Les expériences dans lesquelles une application ou un flux s’exécute selon un calendrier prédéfini, par exemple tous les jours à 3h00, sont souvent appelées des expériences au moment de l’exécution. En continuant avec l’exemple précédent, si la connexion a été désactivée par le processus en arrière-plan décrit ci-dessous, le résultat est que l’application ou le flux fournit un message d’erreur indiquant que la connexion à MSN Météo est interrompue et doit être résolue. Lorsque le créateur tente de mettre à jour sa connexion pour la corriger, il obtient une erreur dans l’expérience au moment de la conception indiquant que le connecteur est bloqué par la stratégie.

Processus pour les changements de stratégies

À mesure que de nouvelles stratégies de données sont créées ou lorsque les stratégies existantes sont mises à jour, un processus spécifique est déclenché au sein de l’écosystème de services Power Platform qui aide à ce que ces stratégies soient appliquées à l’ensemble des ressources dont dispose un client dans son locataire. Ce processus comporte les étapes suivantes.

1. La configuration de la stratégie de données est enregistrée au niveau de la gestion des clients.
2. Les configurations sont appliquées en cascade à chaque environnement dans le locataire du client.
3. Les ressources de chaque environnement (telles que les applications, flux et chatbots) vérifient régulièrement les configurations de stratégies mises à jour.
4. Lorsqu’une modification de configuration est détectée, chaque application, flux et chatbot est évalué pour voir s’il viole la stratégie.
5. Si une violation se produit, l’application, le flux ou le chatbot est mis dans un état suspendu ou quarantaine afin qu’il ne puisse pas fonctionner.
6. Les connexions sont analysées. Si la stratégie bloque l’ensemble du connecteur, la connexion est définie sur un état désactivé afin qu’elle ne puisse pas fonctionner.
7. Toutes les ressources en cours d’exécution qui tentent d’utiliser une connexion inactive échouent au moment de l’exécution.

Important

L’application du runtime dépend de l’état de la connexion. Si elle n’est pas encore désactivée ou n’a pas encore été analysée, la connexion peut toujours être exécutée au moment de l’exécution sans erreur.

Considérations relatives à la latence

Le temps nécessaire à la mise en œuvre efficace des stratégies de données varie d’un client à l’autre en fonction du volume d’environnements et de ressources au sein de ces environnements. Plus un client dispose d’applications, de flux et de chatbots, plus il faudra du temps pour que les changements de stratégies prennent pleinement effet. Pour les cas les plus extrêmes, la latence pour une application complète est de 24 heures. Dans la plupart des cas, c’est dans l’heure.

Voir aussi

Gérer les stratégies de prévention contre la perte de données