Sécuriser votre portail Power Pages : plongée en profondeur dans les autorisations de table et les niveaux de portée

By Mirko Peters · 2026-08-11

Bienvenue de nouveau sur le blog du podcast ! Lorsque vous créez des applications web destinées à vos clients sur Microsoft Power Platform, la sécurité ne peut pas être une réflexion après coup. Power Pages est un outil remarquable pour déployer rapidement des portails externes robustes, connectés directement à Dataverse. Toutefois, un grand pouvoir implique de grandes responsabilités, en particul

Automatically translated with AI from the original post. Read the English original

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

Dans cet article, nous allons approfondir les concepts fondamentaux d’architecture de sécurité que nous avons abordés dans notre épisode récent. Si vous ne l’avez pas encore écouté, n’hésitez pas à consulter l’épisode Build Customer Portals with Power Pages and Dataverse, qui présente en détail la configuration de votre environnement, la gestion des identités externes et le déploiement de votre première solution de portail.

Plongeons-nous dans le fonctionnement de la sécurité de Power Pages, en commençant par la manière de planifier les frontières de vos données et de maîtriser les autorisations de table.

Introduction à la sécurité de Power Pages

Lorsque vous créez un premier site Power Pages, la plateforme vous offre un espace flexible et hautement personnalisable. Mais sous cet espace se trouve un canal direct vers votre environnement Microsoft Dataverse. Si vos configurations de sécurité sont mal gérées, chaque enregistrement de votre base de données peut potentiellement être exposé via un point de terminaison non sécurisé ou une vue de liste mal délimitée.

La sécurité dans Power Pages repose sur une stratégie de défense à plusieurs couches. Sur la couche externe, vous disposez de mécanismes d’authentification, comme Azure AD B2C, les comptes locaux ou les fournisseurs d’identité externes, qui permettent de vérifier l’identité des utilisateurs. Sur la couche interne, vous trouvez les rôles web et les autorisations de table Dataverse. Ces autorisations déterminent précisément ce que les identités authentifiées peuvent voir, créer, modifier ou supprimer. Bien maîtriser ce point fait toute la différence entre un portail d’entreprise sécurisé et une fuite de données massive qui n’attend que de se produire.

Planifier vos frontières de données et vos autorisations de table

Avant de toucher au moindre bouton dans Power Pages Studio, prenez un tableau blanc et cartographiez méticuleusement les frontières de vos données. C’est sans doute le moment le plus critique de tout le cycle de vie de votre projet de portail, et il ne dure que 15 minutes.

Commencez par établir un inventaire complet de chaque table Dataverse que vous prévoyez d’exposer à vos utilisateurs externes. Pour chaque table, définissez le minimum absolu d’actions CRUD requises. Un client a-t-il vraiment besoin de pouvoir supprimer une facture, ou doit-il seulement disposer d’un accès en lecture et en ajout ? Une fois vos actions définies, vous devez déterminer la portée des lignes pour chaque table :

Portée Contact : l’utilisateur ne peut interagir qu’avec les enregistrements directement associés à son enregistrement Contact.
Portée Compte : l’utilisateur peut interagir avec les enregistrements associés à l’ensemble de son entreprise ou de son compte.
Portée globale : l’utilisateur peut voir tous les enregistrements de la table (généralement réservé aux articles publics de la base de connaissances ou aux métadonnées).

En cartographiant ces frontières dès le départ, vous établissez une base de privilège minimal avant même que la moindre configuration ne soit réalisée dans votre environnement de développement.

Comprendre les portées Contact et Compte

L’une des sources de confusion les plus fréquentes pour les créateurs qui découvrent Power Pages réside dans la nuance entre les portées Contact et Compte. Choisir la mauvaise portée peut soit dégrader complètement l’expérience utilisateur en masquant des données pertinentes de l’entreprise, soit exposer involontairement des données confidentielles à des personnes non autorisées.

La portée Contact est conçue pour les portails de type grand public, orientés individus. Si un utilisateur se connecte et soumet une demande d’assistance, une autorisation à portée Contact garantit qu’il ne peut consulter que les dossiers dans lesquels il est explicitement désigné comme contact principal ou créateur. Si un autre utilisateur de la même entreprise se connecte, il ne verra pas les demandes d’assistance personnelles de son collègue.

En revanche, la portée Account est conçue pour les architectures de portail B2B. Dans un scénario B2B, vous souhaitez qu’un responsable de compte ou un acheteur principal puisse consulter l’ensemble des dossiers, commandes et factures associés à son compte parent d’entreprise. Lorsque vous attribuez une portée Account à une autorisation de table, le portail évalue le compte parent lié à l’enregistrement Contact de l’utilisateur connecté, puis affiche tous les enregistrements enfants rattachés à cette organisation. Il est essentiel de bien mapper cette relation dans Dataverse pour réussir un projet B2B.

Définir les rôles web et éviter le piège des utilisateurs authentifiés

Les rôles web font le lien entre vos utilisateurs authentifiés et vos autorisations de table Dataverse. Par défaut, Power Pages inclut un rôle prédéfini nommé « Utilisateurs authentifiés ». C’est là que de nombreux administrateurs tombent dans un piège dangereux pour la sécurité.

Par défaut, tout utilisateur qui se connecte à votre portail avec succès est automatiquement intégré au rôle Utilisateurs authentifiés. Si vous attachez à ce rôle par défaut des autorisations de table étendues, voire pire, des autorisations à portée globale, chaque personne qui s’inscrit sur votre site héritera instantanément de ces privilèges trop larges. Il s’agit d’un antipattern de sécurité majeur.

Créez plutôt des rôles web personnalisés et granulaires, adaptés à vos profils d’utilisateurs spécifiques. Par exemple :

CustomerUser : associé à une portée Contact pour les tables opérationnelles comme Cases et Orders, afin que les utilisateurs puissent suivre leurs propres interactions.
AccountManager : associé à une portée Account, donnant aux responsables désignés de l’organisation une visibilité sur les ressources de l’entreprise.
KnowledgeBaseViewer : associé à une portée globale, mais strictement limité à des actions en lecture seule sur les articles de support destinés au public.

Supprimez systématiquement les accès par défaut inutiles et assurez-vous que les utilisateurs sont explicitement affectés à des rôles conçus pour leur usage, en fonction de leur relation avec l’organisation.

Renforcer la visibilité au niveau des champs et protéger les données personnelles

Contrôler l’accès au niveau des lignes grâce aux portées de table ne représente que la moitié du travail. Vous devez aussi veiller de près aux données visibles dans chaque ligne et chaque liste. Exposer des données personnelles identifiables (PII) telles que les numéros de téléphone, les adresses personnelles, les informations financières ou les notes internes sur les employés peut entraîner de graves manquements à la conformité (par exemple au RGPD ou au CCPA).

Lorsque vous créez des listes et des formulaires de base dans Power Pages, veillez à épurer vos vues des colonnes sensibles. Le fait qu’un champ soit masqué dans la mise en page du formulaire côté utilisateur ne signifie pas qu’il est impossible de l’inspecter ou de l’extraire via les API web sous-jacentes si les autorisations sont trop larges. Utilisez des vues dédiées et renforcées (par exemple une vue « PublicView » spécifique) qui ne contiennent que des colonnes sûres et assainies. Si certaines colonnes doivent rester dans la table de la base de données, envisagez de mettre en œuvre la sécurité au niveau des colonnes dans Dataverse afin de restreindre totalement l’accès au niveau du moteur de base de données.

Réaliser des tests d’intrusion sur les autorisations de votre portail

Vous ne pouvez jamais simplement supposer que votre modèle de sécurité fonctionne : vous devez en apporter la preuve. Avant de déployer une solution de portail dans un environnement de test ou de production, vous devez mener des tests d’intrusion rigoureux sur vos autorisations de table et votre logique de routage.

Créez des comptes de test pour chacun de vos rôles web définis. Connectez-vous avec un profil CustomerUser standard et tentez de consulter les données appartenant à un autre contact ou à un autre compte. Essayez de manipuler directement les URL et de falsifier les GUID en remplaçant les identifiants d’enregistrement dans la barre d’adresse du navigateur, afin de vérifier que le serveur bloque correctement les requêtes non autorisées. Par ailleurs, examinez les journaux de diagnostic et d’audit de votre portail pour vérifier que les tentatives d’élévation de privilèges déclenchent des réponses 403 Forbidden appropriées.

Conclusion et bonnes pratiques

Sécuriser un portail Power Pages exige une planification réfléchie, le strict respect du principe de moindre privilège et une compréhension approfondie des autorisations et portées de tables Dataverse. En renonçant à des paramètres par défaut dangereux comme le rôle Utilisateurs authentifiés, en limitant avec précision l’accès à vos tables aux niveaux Contact ou Account, et en renforçant la visibilité au niveau des champs, vous pouvez construire un portail client à la fois très fonctionnel et exceptionnellement sécurisé.

Pour approfondir ce sujet et découvrir un guide de mise en œuvre complet, de bout en bout, incluant la configuration des identités externes, la conception de votre architecture de solution et la préparation de la mise en production, n’hésitez pas à écouter notre épisode de podcast associé : Build Customer Portals with Power Pages and Dataverse. Merci pour votre lecture, et restez à l’écoute pour d’autres conseils d’experts sur la maîtrise de Microsoft Power Platform !