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
La fonctionnalité de connexions implicites sécurisées a été publiée en janvier 2024. Microsoft encourage fortement toutes les applications utilisant actuellement des connexions implicites à se convertir en connexions implicites sécurisées et à révoquer les connexions partagées avec les utilisateurs finaux.
Différence entre les connexions explicites, implicites et sûres
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.
- Une connexion implicitement partagée sûr fait référence au scénario où l’utilisateur final de l’application 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. Cela signifie que les informations d’identification de l’utilisateur final ne sont pas utilisées pour l’authentification. À la place, quand l’utilisateur final exécute l’application, il utilise les informations d’identification avec lesquelles l’auteur a créé l’application. Il est important de noter que l’utilisateur final ne dispose pas d’un accès direct à la connexion et que l’application permet uniquement d’accéder à un ensemble limité d’actions et de tableaux.
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 | Implicites / Implicites sécurisées |
| Authentification Windows | Implicites / Implicites sécurisées |
| Authentification Windows (non partagée) | Explicite |
Risques de partage de connexion implicite
Toutes les nouvelles applications utilisent automatiquement les nouvelles connexions implicites sécurisées. Toutesfoisn avec applications utilisant l'ancienne connexion Implicite, 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.
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 utilisateur final réutilise une connexion pour créer une nouvelle 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 permet des actions limitées (créer, lire, mettre à jour, supprimer) et accéder à des tables spécifiques dans l’application qui sont définies lors de la publication de l’application. Par conséquent, seules les actions et accès autorisés sont accordés à l’utilisateur final.
L’ancienne connexion implicite simple 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 voulez pas que les utilisateurs voient. Mais 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.
Avec les connexions Implicite simple ancien style, 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. Il est important d’utiliser les nouvelles connexions implicites sécurisées.
Important
Une fois qu’une ancienne 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. Par conséquent, lorsque vous convertissez une application pour utiliser des connexions implicites sécurisées, vous devez également révoquer les connexions que vous avez partagées avec votre application. Les administrateurs peuvent obtenir un rapport sur les applications avec des connexions implicitement partagées avec la boîte à outils COE.
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.