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

Il existe différentes façons de se connecter et de s’authentifier auprès de SQL Server avec Power Apps. Cet article décrit les concepts qui peuvent être utiles pour faire un choix sur la façon de se connecter à SQL Server avec une approche de sécurité qui correspond aux exigences de votre application.

Différence entre les connexions implicites explicites, implicites et sécurisées

Une connexion à SQL Server est créée chaque fois que vous créez une application à l’aide de Power Apps se connectant à SQL Server. Lorsque ces applications sont publiées et partagées avec d’autres utilisateurs, l’application et la connexion sont déployées sur ces utilisateurs. En d’autres termes, l’application et la connexion sont visibles pour les utilisateurs avec utilisant les applications.

La méthode d’authentification utilisée pour ces connexions peut être explicite ou implicite. Nous pouvons également dire que cette connexion est partagée explicitement ou implicitement.

• Une connexion partagée explicitement signifie que l’utilisateur final de l’application doit s’authentifier auprès de SQL Server avec ses propres informations d’identification explicites. En règle générale, cette authentification se produit en arrière-plan dans le cadre de l’établissement d’une liaison d’authentification Microsoft Entra ou Windows. 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 utilisé par le créateur d’application pour se connecter et s’authentifier auprès de la source de données pendant 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.
• Une connexion partagée sécurisée fait référence à un scénario où l’utilisateur final de l’application utilise implicitement les informations d’identification du compte utilisé par le créateur d’application pour se connecter et s’authentifier auprès de la source de données lors de la création de l’application. Cela signifie que les propres informations d’identification de l’utilisateur final ne sont pas utilisées pour s’authentifier. Au lieu de cela, lorsque l’utilisateur exécute l’application, il utilise les informations d’identification avec lesquelles l’auteur de l’application l’a créée. Il est important de noter que l’utilisateur final n’est pas fourni avec un accès direct à la connexion, et que l’application autorise uniquement l’accès à un ensemble limité d’actions et de tables.

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

Risques de partage de connexions implicites

Toutes les nouvelles applications utilisent automatiquement les nouvelles connexions implicites sécurisées. Toutefois, avec les applications qui utilisent les anciennes « connexions implicites », 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 en fonction de ces connexions.

Lorsqu’un auteur utilise des connexions implicites sécurisées, cela signifie qu’aucune connexion n’est partagée et qu’aucun utilisateur final ne reçoit l’objet de connexion. Cela élimine le risque qu’un auteur final réutilise une connexion pour créer une application. Au lieu de cela, l’application fonctionne avec une connexion proxy qui connaît l’application et communique uniquement avec cette application spécifique. La connexion proxy autorise des actions limitées (créer, lire, mettre à jour, supprimer) et accéder à des tables spécifiques de l’application qui sont définies lors de la publication de l’application. Par conséquent, seules les actions autorisées et l’accès sont accordés à l’utilisateur final.

La connexion implicite simple de style plus ancien distribue en fait un objet de connexion à l’utilisateur final. Par exemple, si vous créez une application qui filtre les données que vous ne souhaitez pas que les utilisateurs voient. Toutefois, les données filtrées sont présentes dans la base de données. Toutefois, vous vous appuyez sur le filtre que vous avez configuré pour vous assurer que les utilisateurs finaux ne verront pas certaines données.

Là encore, avec des connexions implicites simples de style plus anciennes, après avoir déployé l’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. Il est important d’utiliser les nouvelles connexions implicites sécurisées.

Sécurité du client et du serveur

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

Utilisez des services tels que l’ID Microsoft Entra au lieu de compter sur les filtres conçus dans les applications lorsqu’il s’agit 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 comment 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é cliente, [1] l’utilisateur s’authentifie uniquement auprès de l’application côté client. Ensuite, [2] l’application demande des informations du service, et [3] le service retourne les informations uniquement en fonction 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. Ensuite, [2] lorsqu’un appel est effectué à partir de 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] retourne les données.

Les scénarios implicites de partage des services décrits ci-dessus sont la combinaison de ces deux modèles. L’utilisateur doit se connecter au service Power Apps à l’aide des informations d’identification Microsoft Entra. Ce comportement est le modèle d’application de sécurité serveur. L’utilisateur est connu à l’aide de l’identité Microsoft Entra sur le service. Par conséquent, l’application est limitée à l’ensemble d’utilisateurs auxquels Power Apps a officiellement partagé l’application.

Toutefois, la connexion partagée implicite à SQL Server est le modèle d’application de sécurité cliente. 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 à l’aide du même nom d’utilisateur et du 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 dans SQL Server, telles que la sécurité au niveau des lignes pour les lignes, et les autorisations de refus pour des objets spécifiques (tels que des colonnes) à des utilisateurs spécifiques. Cette approche utilise l’identité de l’utilisateur Microsoft Entra pour filtrer les données sur le serveur.

Certains services d’entreprise existants ont utilisé une approche dans laquelle l’identité utilisateur est capturée dans une couche de données métiers beaucoup de la même façon que Microsoft Dataverse. Dans ce cas, la couche métier 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, la sécurité est souvent activée à l’aide de procédures stockées ou de vues.

La couche métier (côté serveur) utilise une identité Microsoft Entra connue pour appeler une procédure stockée en tant que principal SQL Server et filtrer les données. Toutefois, Power Apps ne se connecte actuellement pas aux procédures stockées. Une couche métier peut également appeler une vue qui utilise l’identité Microsoft Entra en tant que 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 de vues uniquement aux utilisateurs peut avoir besoin de flux Power Automate pour les mises à jour.

Voir aussi

Vue d’ensemble des connecteurs pour les applications de canevas