Un plan de bi-connexion mal architecturé expose les rapports Power BI à des fuites de données que ni le chiffrement au repos ni l’authentification multifacteur ne suffisent à contenir. Nous observons que la majorité des incidents sur des rapports sensibles Power BI surviennent non pas lors de l’accès initial, mais au moment où les données quittent le périmètre du service, par export ou par connexion croisée entre workspaces.
Héritage automatique des étiquettes Purview dans un plan bi connexion multi-modèles
Un plan de bi-connexion repose souvent sur des modèles sémantiques partagés entre plusieurs équipes (finance, RH, risques). Chaque modèle alimente plusieurs rapports, parfois dans des workspaces distincts avec des niveaux de sensibilité différents.
A lire également : Durée de cotisation pour le chômage : vos droits en question!
Microsoft Purview permet d’appliquer une étiquette de sensibilité (Confidentiel, Très sensible) directement au modèle sémantique. Les rapports qui s’y connectent héritent alors automatiquement de la même politique de protection, même si leurs auteurs disposent d’un accès complet au workspace. Ce mécanisme d’héritage automatique des étiquettes de sensibilité constitue la première ligne de défense dans une architecture bi-connexion.
Sans cet héritage, un rapport créé par un analyste dans un workspace secondaire pourrait exposer des données classifiées sans qu’aucune restriction ne s’applique à l’export ou au partage. Nous recommandons de systématiser l’étiquetage au niveau du modèle avant toute publication de rapport.
Lire également : Droits de propriété intellectuelle : Protéger l'innovation et ses processus
Export en fichiers plats : la rupture de périmètre que le cloud Microsoft ne couvre pas
La faille la plus sous-estimée dans un environnement Power BI sécurisé concerne l’export. Les contrôles Power BI ne survivent pas à l’export en .csv ou .txt. Une fois les données extraites dans un fichier plat, les étiquettes Purview ne garantissent plus une gouvernance complète.
Purview gère la classification et certaines protections sur les formats Office (Excel, PowerPoint, PDF), mais les fichiers texte échappent à ce cadre. Pour un plan de bi-connexion qui manipule des rapports financiers ou des données RH, cela signifie qu’un utilisateur autorisé peut légitimement accéder à un rapport, exporter les données sous-jacentes, et les transférer hors de tout contrôle.
Traiter l’export comme une rupture de périmètre de cybersécurité
Nous traitons systématiquement l’export comme un changement de zone de confiance. Cela implique de mettre en place des mesures complémentaires en dehors de Power BI :
- Restreindre les droits d’export dans les paramètres du tenant Power BI pour les workspaces contenant des données classifiées Très sensible, en ne conservant que l’export vers des formats protégeables (Excel, PDF)
- Déployer des politiques DLP (Data Loss Prevention) sur les terminaux et les serveurs de fichiers pour détecter et bloquer les fichiers plats contenant des données sensibles identifiées par les métadonnées Purview
- Intégrer les événements d’export Power BI dans le SIEM de l’entreprise pour corréler les exports massifs ou inhabituels avec d’autres signaux de compromission
Sans ces couches supplémentaires, le plan de bi-connexion reste protégé en amont mais perméable en aval.
Authentification conditionnelle et segmentation des accès aux rapports Power BI
L’authentification multifacteur (MFA) via Entra ID est un prérequis, pas une stratégie. Dans un plan bi connexion, la granularité des accès doit descendre au niveau du rapport et du modèle, pas seulement du workspace.
Les stratégies d’accès conditionnel permettent d’imposer des contraintes contextuelles : type d’appareil, localisation réseau, niveau de risque de la session. Un utilisateur qui accède à un rapport classifié Confidentiel depuis un appareil non géré peut se voir refuser l’accès ou être limité à une consultation sans export.
Row-Level Security et Object-Level Security combinées
Le RLS seul ne protège pas la structure du modèle. Un utilisateur soumis à un filtre RLS voit uniquement les lignes qui le concernent, mais il accède à l’intégralité des colonnes et des tables visibles. L’Object-Level Security (OLS) complète le dispositif en masquant des tables ou des colonnes entières selon le rôle.
Pour un plan de bi-connexion servant plusieurs directions métier, la combinaison RLS/OLS est la seule approche qui garantit que chaque connexion au modèle partagé ne révèle que le périmètre strictement nécessaire. Un directeur financier verra les marges par entité, tandis qu’un responsable RH accédant au même modèle ne verra que les données sociales, sans même savoir que les colonnes financières existent.
Surveillance des accès et détection des schémas anormaux sur Power BI
Les logs d’audit Power BI enregistrent chaque consultation, export et modification de rapport. Ces journaux, accessibles via le portail d’administration ou l’API Activity Events, constituent la matière première de toute stratégie de cybersécurité appliquée à la BI.
Un accès légitime peut devenir suspect par son volume ou sa fréquence. Un compte utilisateur qui consulte plusieurs dizaines de rapports classifiés en quelques minutes, ou qui exporte des données depuis des workspaces auxquels il n’accède habituellement pas, génère un signal qui doit déclencher une investigation.
Corrélation avec le SIEM et Cloud App Security
L’intégration des événements Power BI dans Microsoft Cloud App Security (rebaptisé Defender for Cloud Apps) permet de définir des politiques de détection automatisée. Les alertes peuvent être corrélées avec d’autres signaux : connexion depuis une géolocalisation inhabituelle, tentative de contournement MFA, élévation de privilèges récente dans Entra ID.
Nous recommandons de configurer des alertes spécifiques pour les exports de données depuis les workspaces Premium, où sont généralement hébergés les rapports les plus sensibles. La capacité Premium offre des fonctionnalités de gestion avancées, mais elle concentre aussi les actifs à plus forte valeur pour un attaquant.
Gouvernance du tenant et politique de partage dans un environnement bi-connexion
La configuration du tenant Power BI détermine les possibilités de partage externe. Par défaut, certains paramètres autorisent le partage de rapports avec des utilisateurs externes à l’organisation, ce qui représente un risque direct pour les rapports sensibles dans un plan de bi-connexion.
Trois paramètres du portail d’administration méritent une révision systématique :
- La publication sur le web, qui rend un rapport accessible sans authentification, doit être désactivée pour tous les workspaces contenant des données classifiées
- Le partage externe via Entra B2B doit être restreint aux domaines partenaires identifiés, avec une approbation manuelle pour chaque invitation
- L’intégration dans des applications tierces (embed) doit être limitée aux applications enregistrées dans le registre d’applications de l’entreprise, avec un contrôle OAuth strict
Un tenant Power BI mal configuré annule toutes les protections appliquées en aval. La gouvernance du tenant précède logiquement la mise en place du RLS, de l’OLS et des étiquettes Purview. Sans elle, ces mécanismes protègent des rapports que n’importe qui peut partager d’un clic.
