Utilisez Microsoft SQL Server en toute sécurité avec Power Apps

Il existe différentes manières de se connecter et s’authentifier auprès de SQL Server avec Power Apps. Cet article décrit les concepts qui peuvent être utiles pour choisir comment se connecter à SQL Server avec une approche de sécurité qui correspond aux exigences de votre application.

Important

Cet article s’applique à toutes les bases de données relationnelles et aux connexions implicites.

Différence entre les connexions explicites et implicites

Une connexion à SQL Server est créée chaque fois que vous créez une application en utilisant Power Apps pour vous connecter à SQL Server. Lorsque de telles applications sont publiées et partagées avec d’autres, l’application et la connexion sont déployées pour ces utilisateurs. En d’autres termes, l’application et la connexion—les deux sont visibles par les utilisateurs avec lesquels les applications sont partagées.

La méthode d’authentification utilisée pour de telles connexions peut être explicite ou implicite. On peut aussi dire qu’une telle connexion est partagée explicitement ou implicitement.

• Une connexion explicitement partagée signifie que l’utilisateur final de l’application doit s’authentifier auprès de SQL Server avec ses propres informations d’identification explicites. Habituellement, cette authentification se produit en coulisses dans le cadre de l’établissement de l’authentification Windows ou Microsoft Entra. L’utilisateur ne remarque même pas quand l’authentification a lieu.
• Une connexion implicitement partagée signifie que l’utilisateur utilise implicitement les informations d’identification du compte que le créateur de l’application a utilisé pour se connecter et s’authentifier à la source de données lors de la création de l’application. Les informations d’identification de l’utilisateur final ne sont pas utilisées pour s’authentifier. Chaque fois que l’utilisateur final exécute l’application, il utilise les informations d’identification avec lesquelles l’auteur a créé l’application.

Les quatre types d’authentification de connexion suivants peuvent être utilisés avec SQL Server pour Power Apps :

Type d’authentification	Méthode de connexion Power Apps
Microsoft Entra intégré	Explicite
Authentification SQL Server	Implicite
Authentification Windows	Implicite
Authentification Windows (non partagée)	Explicite

Risques de partage de connexion implicite

Étant donné que l’application et ses connexions sont déployées pour les utilisateurs finaux, cela signifie que les utilisateurs finaux peuvent créer de nouvelles applications basées sur ces connexions.

Par exemple, imaginez que vous avez créé une application qui a filtré les données que vous ne voulez pas que les utilisateurs voient. Les données filtrées sont présentes dans la base de données. Mais vous comptez sur le filtre que vous avez configuré pour vous assurer que les utilisateurs finaux ne verront pas certaines données.

Après avoir déployé cette application, les utilisateurs finaux peuvent utiliser la connexion déployée avec votre application dans toutes les nouvelles applications qu’ils créent. Dans les nouvelles applications, les utilisateurs peuvent voir les données que vous avez filtrées dans votre application.

Important

Une fois qu’une connexion implicitement partagée est déployée pour les utilisateurs finaux, les restrictions que vous avez peut-être mises dans l’application que vous avez partagée (telles que les filtres ou l’accès en lecture seule) ne sont plus valides pour les nouvelles applications créées par les utilisateurs finaux. Les utilisateurs finaux auront tous les droits que l’authentification autorise dans le cadre d’une connexion implicitement partagée.

Utilisations réelles de la connexion implicite

Il existe des cas d’utilisation valides pour les méthodes d’authentification implicites et explicites. Tenez compte du modèle de sécurité et de la facilité de développement lors du choix de votre approche. En règle générale, utilisez une méthode d’authentification explicite pour toute situation où vous avez un besoin commercial où les données doivent être restreintes sur une base de ligne ou de colonne.

Pour un exemple de cas d’utilisation de connexion explicite, considérons un directeur commercial qui ne devrait être autorisé à voir que les remises de prix ou les données de coût de base qui se trouvent dans la même table que celle où un autre professionnel de la vente a besoin de voir le produit et le prix.

Cependant, toutes les données ne peuvent pas être sécurisées de la même manière. Une application est partagée et déployée pour des utilisateurs ou des groupes d’utilisateurs spécifiques. Les personnes extérieures à ce groupe n’ont pas accès à l’application ou à la connexion. Ainsi, si tout le monde dans un groupe est autorisé à voir toutes les données d’une base de données, une méthode implicite de partage fonctionne bien.

Pour un exemple de cas d’utilisation de connexion implicite, considérons un service qui dispose d’une petite base de données de projets qu’il suit. La base de données peut inclure des informations telles que des fiches de travail départementales ou un calendrier d’entreprise pour l’ensemble de l’entreprise. Dans ce scénario, la création de plus d’applications en plus de la connexion implicitement partagée peut être encouragée tant que toutes les données doivent être accessibles par tous les utilisateurs qui y ont accès.

Les applications créées à l’aide Power Apps sont conçues pour être accessibles par les utilisateurs finaux. Ce type de scénario est courant, car le coût de développement associé aux connexions implicites est faible.

Les applications départementales peuvent devenir des applications critiques à l’échelle de l’entreprise. Dans ces scénarios, il est important de comprendre qu’au fur et à mesure qu’une application départementale évolue vers l’ensemble de l’entreprise, elle devra intégrer la sécurité d’entreprise traditionnelle. Cette approche est plus coûteuse pour les efforts de création d’applications, mais elle est importante dans les scénarios à l’échelle de l’entreprise.

Sécurité client et serveur

Vous ne pouvez pas compter sur la sécurité des données via le filtrage ou d’autres opérations côté client pour être en sécurité. Les applications qui nécessitent un filtrage sécurisé des données doivent garantir que l’identification de l’utilisateur et le filtrage se produisent sur le serveur.

Utiliser des services, tels que Microsoft Entra ID, au lieu de s’appuyer sur les filtres conçus dans les applications en matière d’identité et de sécurité des utilisateurs. Cette configuration garantit que les filtres côté serveur fonctionnent comme prévu.

Les illustrations suivantes expliquent en quoi les modèles de sécurité au sein des applications diffèrent entre les modèles de sécurité côté client et côté serveur.

Dans un modèle d’application de sécurité client, [1] l’utilisateur s’authentifie uniquement auprès de l’application côté client. Puis, [2] l’application demande des informations sur le service, et [3] le service renvoie les informations uniquement sur la base de la demande de données.

Dans un modèle de sécurité côté serveur, [1] l’utilisateur s’authentifie d’abord auprès du service afin que l’utilisateur soit connu du service. Puis, [2] lorsqu’un appel est passé depuis l’application, le service [3] utilise l’identité connue de l’utilisateur actuel pour filtrer les données de manière appropriée et [4] renvoie les données.

Les scénarios implicites de partage départemental décrits ci-dessus sont une combinaison de ces deux modèles. L’utilisateur doit se connecter au service Power Apps en utilisant les informations d’identification Microsoft Entra. Ce comportement est le modèle d’application de sécurité du serveur. L’utilisateur est connu grâce à l’identité Microsoft Entra sur le service. Par conséquent, l’application est limitée à l’ensemble d’utilisateurs avec lesquels Power Apps a officiellement partagé l’application.

Cependant, la connexion partagée implicite à SQL Server est le modèle d’application de sécurité client. SQL Server sait uniquement qu’un nom d’utilisateur et un mot de passe spécifiques sont utilisés. Tout filtrage côté client, par exemple, peut être contourné avec une nouvelle application utilisant le même nom d’utilisateur et le même mot de passe.

Pour filtrer en toute sécurité les données côté serveur, utilisez des fonctionnalités de sécurité intégrées à SQL Server, telles que la sécurité au niveau des lignes pour les lignes et les autorisations Refuser sur des objets spécifiques (tels que des colonnes) pour des utilisateurs spécifiques. Cette approche utilise l’identité Microsoft Entra de l’utilisateur pour filtrer les données sur le serveur.

Certains services d’entreprise existants ont utilisé une approche où l’identité de l’utilisateur est capturée dans une couche de données commerciales de la même manière que Microsoft Dataverse procède. Dans ce cas, la couche commerciale peut ou non utiliser la sécurité au niveau des lignes de SQL Server et refuser directement les fonctionnalités. Si ce n’est pas le cas, il arrive souvent que la sécurité soit activée à l’aide de procédures stockées ou de vues.

La couche commerciale (côté serveur) utilise l’identité Microsoft Entra d’un utilisateur connu pour appeler une procédure stockée en tant que principal SQL Server et filtrer les données. Cependant, Power Apps ne se connecte pas actuellement aux procédures stockées. Une couche commerciale peut également appeler une vue qui utilise l’identité Microsoft Entra comme principal SQL Server. Dans ce cas, utilisez Power Apps pour vous connecter aux vues afin que les données soient filtrées côté serveur. L’exposition des vues uniquement aux utilisateurs peut avoir besoin de flux Power Automate pour les mises à jour.

Voir aussi

Présentation des connecteurs pour les applications canevas