Vet avec Protection des données dans les connecteurs
Article
Cet article aborde les sujets les plus importants que vous devez comprendre pour garantir une expérience réussie et sûre avec un connecteur Power Platform utilisant un service externe. Cela peut simplifier votre processus de vérification des connecteurs, ce qui pourrait vous faire gagner du temps.
Après avoir lu cet article, vous devriez être en mesure de répondre à ces questions :
Quels contrôles de validation sont effectués pour un connecteur faisant appel au service d’une entreprise externe ?
Comment la conformité au Règlement général sur la protection des données (RGPD) est-elle gérée par Microsoft par rapport à un éditeur externe ?
Validation du connecteur
Les connecteurs publiés par Microsoft peuvent se connecter à des services internes ou externes. Par exemple, des connecteurs tels que SharePoint ou Excel se connectent toujours aux services en interne.
Cependant, Microsoft publie également des connecteurs qui utilisent des services externes. Par exemple, le connecteur Salesforce utilise le service Salesforce. Chaque fois qu’un connecteur quitte l’infrastructure Microsoft, Microsoft exécute une série de contrôles de validation pour assurer la protection des données.
Important
C’est le service, et non le connecteur lui-même, qui dicte qui est responsable de la protection des données. La raison en est que c’est le service auquel vous êtes connecté qui stocke les données, pas le connecteur.
N’oubliez pas que si vos données résident sur l’infrastructure Microsoft, Microsoft a le contrôle. Dès qu’il migre vers une infrastructure externe, l’éditeur vérifié prend le contrôle.
Connaître la différence vous permettra de prendre les mesures appropriées et peut assurer la sécurité de vos données tout au long de la connexion. Les détails sont dans les sections ci-dessous.
Microsoft applique ses politiques de protection pour toutes les données qui résident sur l’infrastructure Microsoft. Dès que les données se déplacent vers une infrastructure externe, comme dans le cas de l’utilisation d’un service de connecteur vérifié, les politiques définies par cette entreprise prennent le relais.
Politique de confidentialité de l’entreprise externe
Notes
Il existe des limites à l’application de la stratégie de Microsoft lorsque les services de connecteur résident sur une infrastructure externe. Une fois que vous vous connectez à leur service, Microsoft n’a aucun contrôle sur la destination de vos données ; c’est à la société externe de décider. C’est votre responsabilité de rechercher leurs conditions générales, ou pour travailler directement avec eux pour fournir des conseils.
Voici des exemples de questions que vous pourriez avoir pour le service de connecteur d’une entreprise externe :
Le service de l’entreprise stocke-t-il vos données ?
Si oui, comment l’entreprise détermine-t-elle quand supprimer les données ?
Le connecteur présente-t-il des vulnérabilités ou une opportunité pour un attaquant de contrôler ou d’intercepter des données ?
Le service de l’entreprise applique-t-il l’authentification unique ou l’authentification à deux facteurs ?
Lorsqu’un service de connecteur s’exécute sur l’infrastructure Microsoft, Microsoft régit les règles de conformité RGPD. Une fois que les données sont transférées vers l’infrastructure externe d’une entreprise, Microsoft n’enfreint pas ses règles RGPD.
Important
La plate-forme de connecteurs Microsoft est conforme au RGPD. Elle traite uniquement vos données sans les stocker. Lors du traitement, elle respecte les politiques de confidentialité et le RGPD de Microsoft.
Par exemple, si vous créez un flux en Europe, Microsoft n’envoie pas de demande aux États-Unis, n’y traite pas les données, puis ne les renvoie pas au service d’une société externe. Dans ce cas, Microsoft respecte les limites géographiques.
Conformité RGPD de l’entreprise externe
Lorsqu’un service de connecteur s’exécute sur l’infrastructure de l’entreprise externe, la société régit les règles de conformité RGPD.
Notes
Lorsque le service s’exécute sur l’infrastructure d’une entreprise externe, il est de votre responsabilité de comprendre leurs exigences RGPD. Microsoft n’a aucun contrôle. Les connecteurs externes de l’entreprise peuvent être conformes ou non au RGPD.
Si vous utilisez le connecteur d’une entreprise externe, il est conseillé d’effectuer vos propres étapes de recherche, de modélisation, d’audit des fournisseurs et de stratégie dans votre entreprise pour vous assurer que vous comprenez le RGPD tel qu’il s’applique à votre entreprise. Vous pourriez peut-être commencer par leur documentation sur les conditions générales.
Des exemples de questions auxquelles seule la société externe peut répondre peuvent impliquer le déplacement ou le traitement géographique de données, telles que :
Pour les entreprises basées dans l’UE :
Les données quittent-elles l’UE à un moment donné ?
Les données sont-elles envoyées à l’UE à un moment donné ?
Pour les entreprises basées aux États-Unis :
Les données sont-elles envoyées à l’UE à un moment donné ?
Vérifier le point de terminaison
Lorsque vos données sont traitées sur l’infrastructure Microsoft, Microsoft vérifie le point de terminaison pour s’assurer que certaines barres de qualité sont respectées. Azure Logic Apps applique des limites régionales, mais Power Automate et Power Apps appliquent des limites géographiques.
Par exemple, USA Ouest est une région, mais les États-Unis sont une géographie. Dans Logic Apps, si un utilisateur sélectionne USA Ouest, Microsoft s’assure que les données ne sortent pas des limites du centre de données, même pas vers USA Centre ou USA Est. Cependant, pour Power Automate et Power Apps, Microsoft garantit uniquement la limite géographique. Cela signifie que si l’utilisateur sélectionne les États-Unis, les données peuvent être traitées n’importe où aux États-Unis, y compris USA Ouest ou USA Est. Microsoft garantit que les données ne sortent pas des États-Unis, comme vers l‘Europe ou l‘Asie.
Une fois que les données quittent Microsoft et se déplacent vers la zone géographique sélectionnée par l’utilisateur, l’utilisation et le stockage des données sont alors régis par la politique définie par la société externe. Microsoft agit uniquement en tant que proxy pour la plate-forme de l’entreprise et envoie des demandes au point de terminaison.
Si vous utilisez un connecteur externe vérifié, vous devez comprendre les conditions générales proposées par l’entreprise pour comprendre comment et où vos données sont traitées.
Validation swagger
La validation swagger mesure la barre d’égalité des connecteurs. Microsoft exécute cette validation pour s’assurer que le connecteur respecte les normes Open API, les contraintes et les directives du connecteur et inclut les extensions Microsoft personnalisées appropriées (x-ms).
Validation des changements cassants
Lorsqu’un connecteur est mis à jour, Microsoft applique un test de validation pour s’assurer que rien ne casse. Les règles de validation détecteront tout changement cassant en comparant la version actuelle de swagger par rapport aux versions précédentes de swagger. Par exemple, un paramètre qu’une entreprise a marqué comme facultatif et qui est désormais obligatoire.
Contrôles de qualité et de vérification
Microsoft effectue des contrôles de qualité sur tous les connecteurs. Les contrôles de qualité incluent la vérification fonctionnelle après le déploiement et les tests pour s’assurer que la fonctionnalité fonctionne comme prévu. Microsoft effectue également des contrôles de vérification. Un type consiste à s’assurer que l’éditeur est autorisé à créer un connecteur. Un autre type consiste à analyser tout le code du connecteur à la recherche de logiciels malveillants ou de virus.
Méthodes de communication et d’authentification
Au moment de l’exécution, une validation a lieu pour vérifier si l’utilisateur est autorisé à passer l’appel, puis les jetons/secrets sont récupérés pour l’appel vers le back-end.
Microsoft n’impose aucune restriction aux sociétés externes quant au type d’authentification à utiliser. Il est défini par l’authentification prise en charge par l’API fournie par le service de connecteur sous-jacent. Les connecteurs prendront en charge différents types d’authentification (par exemple, Microsoft Entra ID, Authentification de base ou OAuth).
Exemples
Si le type d’authentification utilisé est :
Microsoft Entra ID : l’utilisateur est invité à se connecter à Microsoft Entra ID (et si la politique de l’entreprise impose à un utilisateur d’avoir une authentification multifacteur, des certificats ou une carte à puce, cela peut également être appliqué ici). Cette exécution a lieu entre l’utilisateur et Microsoft Entra ID, qui est indépendant du connecteur lui-même. De nombreux services, notamment ceux fournis par Microsoft, utilisent Microsoft Entra ID.
Authentification de base : le nom d’utilisateur et le mot de passe sont envoyés dans la requête API. Ces secrets sont stockés et chiffrés dans un magasin de jetons interne accessible uniquement par Microsoft Power Platform.
OAuth—L’URL de redirection du connecteur est récupérée dans les paramètres et renvoyée à l’utilisateur pour se connecter directement au service et donner son consentement. Les informations d’identification de l’utilisateur ne sont pas stockées. Une fois la connexion réussie et l’utilisateur autorisé à accéder aux données en son nom, un code d’autorisation est renvoyé à Microsoft Power Platform. Avec ce code d’autorisation, un token est ensuite récupéré et stocké en interne. Ce token est accessible uniquement par Microsoft Power Platform.
Nous apprécions grandement les commentaires sur les problèmes liés à notre plateforme de connecteurs ou les idées de nouvelles fonctionnalités. Pour fournir des commentaires, accédez à Soumettre des problèmes ou obtenir de l’aide avec les connecteurs et sélectionnez votre type de commentaire.