Considérations relatives à l’exfiltration des données et bonnes pratiques pour les dataflows

Les dataflows Fabric et Power Platform sont des services Microsoft 365 qui permettent aux utilisateurs de se connecter facilement à des centaines de sources de données prises en charge, d'extraire, de déplacer et de transformer facilement des données. Les dataflows s’appuient sur un service sous-jacent appelé Power Query Online, qui héberge le moteur de déplacement de données (Moteur Mashup) en tant que service cloud. Par défaut, la connectivité provient de cet emplacement cloud et dispose d’un accès illimité à Internet. Par conséquent, lors de l'utilisation des flux de données pour accéder aux données sensibles et les transférer, les organisations doivent envisager des stratégies pour empêcher les employés d'exfiltrer accidentellement ou malicieusement des données. Cet article décrit les facteurs de risque connus et les meilleures pratiques en matière de protection.

Considérations

Exécution de code arbitraire

Les travaux ETL de flux de données sont définis par le biais de programmes écrits dans un langage appelé Power Query M. Dans sa configuration par défaut, le moteur Mashup exécute ces programmes dans le cloud, en dehors de la limite réseau du locataire et avec un accès Internet illimité. Les utilisateurs peuvent créer des programmes qui se connectent à plusieurs sources de données et, par consentement, autorisent le flux de données entre ces sources.

Un utilisateur approuvé qui a accès aux données sensibles peut créer un programme pour envoyer (push) les données à un magasin de données non approuvé. Étant donné que le moteur Mashup s’exécute entièrement dans le cloud, il ne passe pas par les pare-feu d’entreprise et les serveurs proxy. Par conséquent, il n’est pas soumis à des stratégies de protection contre la perte de données (DLP) susceptibles d’être appliquées par ces réseaux. Étant donné que le point d’accès se trouve sur l’Internet public, les données peuvent se déplacer vers n’importe quelle destination à laquelle l’utilisateur a accès , via l’authentification ou l’accès anonyme. Voici quelques exemples de façons dont ces programmes peuvent exfiltrer des données sensibles :

• Demandes web anonymes : à l’aide de Web.Contents, les utilisateurs peuvent effectuer des requêtes web avec des données sensibles dans le corps de la requête.
• Filtrage et jointures de sources de données croisées : les données sensibles peuvent être utilisées comme conditions de filtrage ou de jointure sur une autre source de données non approuvée. Plus précisément, les données peuvent se déplacer vers la source de données non approuvée sous la forme de chaînes de requête ou de paramètres.
• Destinations de sortie : à l’aide de flux de données Fabric, les utilisateurs peuvent spécifier des destinations de sortie pour leurs requêtes, en transférant ainsi des données vers une liste de récepteurs de données pris en charge, qui incluent des bases de données et des entrepôts de données Azure SQL, Fabric Lakehouses, Warehouses et KQL.

Déplacement des données entre locataires

Le moteur Mashup nécessite que les sources de données soient définies explicitement avant d’établir des connexions. Les sources de données sont liées aux programmes avec une clé de type et de chemin d’accès (par exemple, SQL;contoso.database.windows.net). Cette liaison permet aux organisations de régir les sources de données autorisées, en filtrant en fonction des chemins de source de données. Toutefois, il existe certaines sources de données où le chemin d’accès est commun à toutes les connexions et les données sont segmentées uniquement par le compte des informations d'identification OAuth de l'utilisateur authentifié. Ce scénario crée un facteur de risque pour l’exfiltration des données, où un utilisateur se connecte à un locataire de sécurité plus élevé et un locataire de sécurité inférieur et déplace les données entre eux. En règle générale, cette exfiltration peut être effectuée de deux manières :

• Sortant : un utilisateur approuvé dans un locataire de sécurité plus élevé définit un flux de données dans cet environnement et crée une destination de sortie vers un récepteur de données autorisé, mais s’authentifie auprès du récepteur de données à l’aide d’un compte d’un locataire de sécurité inférieur.
• Flux entrant : un utilisateur d’un locataire avec un niveau de sécurité inférieur définit un flux de données qui accède à des données provenant d'une source de données sensible située dans un locataire avec un niveau de sécurité supérieur. Cette définition peut être obtenue en s’authentifiant auprès de la source de données sensible à l’aide d’un compte approuvé dans le locataire de sécurité supérieur.

Meilleures pratiques recommandées

Les stratégies DLP peuvent fonctionner à différentes couches OSI. En général, plus les données sont sensibles, plus la couche est inférieure à celle où les stratégies doivent être appliquées. Les protocoles de couche inférieure sont généralement plus coûteux à implémenter, plus difficiles à mettre à l’échelle et plus difficiles à utiliser. Par exemple, les organisations ayant des exigences de gouvernance inférieures peuvent uniquement avoir besoin d’appliquer des stratégies de couche Application. Toutefois, certaines organisations et entités qui traitent des données hautement sensibles peuvent nécessiter des mesures extrêmes telles que l’isolation physique. Nous vous recommandons que les organisations qui gèrent des données sensibles utilisent une combinaison de stratégies d’application et de niveau réseau pour se protéger contre les menaces internes.

Isolement réseau

Nous recommandons que tous les magasins de données contenant des données sensibles soient isolés du réseau pour autoriser l’accès uniquement à partir de réseaux sélectionnés. Cette restriction d’isolation doit être définie et exploitée au niveau de la couche réseau ou inférieure. Par exemple, les pare-feu de couche 3, les groupes de sécurité réseau (NSG) et les liaisons privées Azure sont de bons exemples de mécanismes qui peuvent être utilisés. Toutefois, les stratégies d’accès conditionnel basées sur l’emplacement dans Microsoft Entra ID fonctionnent au niveau de la couche application et sont considérées comme insuffisantes à cet effet.

Ces stratégies d’isolation réseau doivent obstruer la ligne de vue du moteur d’exécution cloud des flux de données vers des magasins de données sensibles (étant donné que le moteur cloud s’exécute sur l’Internet public). La connectivité des dataflows à ces magasins de données est alors contrainte de provenir de l’un des réseaux autorisés en liant les connexions à une passerelle de données sur site ou à une passerelle de données de réseau virtuel (VNet). Une caractéristique d’exécution importante des flux de données est que l’évaluation basée sur le cloud et l’évaluation basée sur la passerelle ne sont jamais fusionnées. Si un flux de données doit accéder à un magasin de données isolé du réseau (et est donc lié à une passerelle), tous les accès aux données sont nécessaires pour passer par la passerelle. En outre, étant donné que les passerelles résident physiquement dans des réseaux contrôlés par le locataire utilisateur, elles respectent les restrictions au niveau du réseau telles que les pare-feu et les solutions de protection DLP. Ces restrictions rendent les environnements de passerelle aussi sécurisés et sécurisés que tous les appareils gérés par l’entreprise et atténuent les risques associés à l’exécution arbitraire du code dans un environnement cloud.

Il est important de noter que l’isolation réseau doit être appliquée à tous les magasins de données susceptibles de contenir des données sensibles. Prenons un exemple où un utilisateur crée un dataflow pour lire des données à partir de OneDrive Entreprise dans Power BI. L’utilisateur crée ensuite un flux de données lié pour transformer les données dans Power BI en entités en aval. Dans ce scénario, il n’est pas suffisant d’isoler simplement OneDrive pour Entreprise aux réseaux de confiance. Étant donné que les données sensibles peuvent également résider dans Power BI, il est important d’isoler ces données en activant des liens privés et en désactivant l’accès à Internet public pour Power BI. En savoir plus sur l’accès sécurisé à Power BI à l’aide de points de terminaison privés.

Forcer l'exécution d'une passerelle

L'objectif de l'isolation du magasin de données sensibles sur des réseaux sélectionnés est de forcer l'origine de l'accès vers des réseaux approuvés, afin que les stratégies existantes régissant les appareils gérés puissent être utilisées pour encadrer le transfert de données à partir des flux de données. Dans certains cas, une solution d’isolation réseau complète peut prendre du temps pour développer, tester et déployer. En guise d’alternative, vous pouvez créer un ticket de support pour flux de données afin d'appliquer une stratégie à l’échelle du client qui désactive le moteur Mashup. Cette stratégie affecte toutes les évaluations de requête qui utilisent le moteur Mashup Power Query Online. Les fonctionnalités affectées sont les suivantes :

• Flux de données Fabric
• Flux de données Power Platform
• Azure Data Factory, flux de données de préparation
• Dataflows dans Dynamics 365 (Customer Insights, Intelligent Order Management, et ainsi de suite)
• Power BI Datamart
• Importation rapide Power BI à partir de SharePoint

Après l'application de la politique, l'exécution basée sur le cloud échoue avec l’erreur suivante : Cloud evaluation request denied based on tenant policies. Please use a data gateway and try again. cette erreur oblige efficacement toutes les évaluations de requête dans le tenant à se produire sur les passerelles, sans avoir préalablement déployé une solution complète d'isolement réseau. Notez que la stratégie est appliquée à l’ensemble du locataire et non à un sous-ensemble de charges de travail. Cette politique signifie que les charges de travail existantes sont immédiatement mises en échec et nécessitent une intervention manuelle pour être converties à un fonctionnement sur des passerelles. Les organisations appliquant cette stratégie doivent également s’assurer qu’elles disposent d’une capacité suffisante dans leurs clusters de passerelle pour prendre en charge toutes leurs charges de travail.

Isolation des locataires

Pour la plupart des magasins de données de couche SaaS (Software-as-a-Service), tels que Fabric Lakehouse et Power Platform Dataverse, il existe généralement un point de terminaison multi-locataire avec lequel on communique pour accéder aux données. Ces points de terminaison sont communs à tous les utilisateurs du service. Ils peuvent donc être difficiles à isoler et à protéger uniquement à l’aide de techniques d’isolation réseau (couche 3). L’approche recommandée pour ce type de magasin de données consiste à utiliser des stratégies de couche 7, généralement fournies par l’ID Microsoft Entra :

• Autorisez uniquement l’authentification d’ID Microsoft Entra. Supprimez les schémas d’authentification anonyme et de nom d’utilisateur/mot de passe du magasin de données.
• Utilisez des politiques de localisation pour permettre la connexion au locataire sécurisé uniquement depuis des appareils gérés. En savoir plus.
• Interdire les connexions de locataire inconnues à partir d’appareils gérés à l’aide des restrictions de locataire Microsoft Entra ID. Utilisez des restrictions de locataire pour gérer l’accès aux applications SaaS. En savoir plus.

Cette approche limite l’accès aux magasins de données sensibles du locataire à un ensemble d’appareils gérés où la connexion à un autre locataire n’est pas autorisée, isolant efficacement le déplacement des données entre les locataires.

Feuille de route

La liste suivante contient certaines des fonctionnalités actuellement planifiées pour aider les organisations à mieux gérer les risques d’exfiltration des données dans Fabric :

• Liste verte de connexion de source de données : permet aux administrateurs de locataires Fabric de contrôler les types de connecteurs qui peuvent être utilisés dans le locataire et les points de terminaison auxquels les connecteurs peuvent se connecter.
• Audit de l’utilisation des connexions : prise en charge des journaux d’audit qui effectuent le suivi de la création, de la mise à jour, de la suppression et de l’utilisation de la connexion.