La Power Platform permet de créer de nombreuses applications pour répondre à une infinité de besoins. Cependant, des applications mal conçues ou peu sécurisées peuvent exposer l’entreprise / l’organisation à des fuites de données, à des modifications ou à des destructions non souhaitées. Hacker son application et se mettre dans la peau d’un utilisateur malveillant ou étourdi peut révéler des failles importantes.
Filtrer dans l’interface, ce n’est pas sécuriser
Les fonctionnalités de filtre dans l’interface, qui permettent d’afficher uniquement les informations nécessaires, ne constituent pas un moyen de sécuriser vos données. Les filtres doivent simplement apporter du confort et de l’ergonomie à l’usage de l’application. Avec ou sans filtre, il faut s’assurer que l’utilisateur a bien les droits de lecture / écriture sur la source des données affichées et filtrées. Si ce n’est pas le cas, vous avez un problème de confidentialité ou de corruption de données. Un utilisateur averti pourrait, via le navigateur ou des outils spécifiques, voir toutes les données et corrompre votre base de données.
Liste SharePoint = souvent open bar
Il est facile de créer des applications avec des listes SharePoint. Il faut juste que les listes SharePoint soient disponibles en lecture ou en écriture pour tous les utilisateurs de l’application. Cependant, si j’accède directement aux listes SharePoint, je peux accéder sans filtre à toutes les données. La gestion des droits est limitée dans les listes SharePoint : soit je peux voir et modifier tous les éléments, soit je peux éventuellement choisir l’option « Lire / modifier ses éléments ». Cela réduit l’impact potentiel mais pas le risque. Plutôt que de partager le site SharePoint complet ou de mettre ses listes dans un site SharePoint grand public, il est préférable de créer un site SharePoint dédié et de partager uniquement les listes. Cela réduit le risque qu’un utilisateur trouve trop facilement les listes. Cependant, si le besoin de confidentialité est total, ce n’est pas SharePoint qu’il faut utiliser mais Dataverse ou une base de données permettant de gérer finement l’accès à la donnée, par ligne et par profil utilisateur.
Compte de service générique : vive l’anonymat
Si vous avez besoin d’une traçabilité forte des actions faites dans l’application, de la lecture à la suppression, et que vous utilisez un compte de service unique pour faire la liaison avec vos sources de données, vous ne gardez que les traces de l’activité de ce compte de service. Il ne sera pas possible de retracer parfaitement qui fait quoi dans l’application. Dans ce cas, il faut privilégier l’authentification intégrée Azure AD, de manière à savoir qui manipule les données.
Gérer des rôles, c’est primordial
Dès la conception de l’application, il faut penser à la gestion des rôles. Si tout le monde peut tout faire et que l’interface facilite juste l’usage, il n’y a pas de débat. Sinon, il faut se pencher sur « qui peut faire quoi » et commencer par identifier ce qui est critique / confidentiel. Cette analyse aura des conséquences sur les choix technologiques et de base de données. Il est recommandé d’utiliser Dataverse pour gérer finement les droits. Il est possible de créer des rôles de sécurité affectés aux utilisateurs pour leur donner juste le bon niveau d’autorisation. Que ce soit via l’interface ou directement en base de données, l’utilisateur doit avoir les mêmes possibilités et autorisations.
Sécuriser l’identité
La Power Platform fait partie de Microsoft 365 et hérite de toutes les stratégies de sécurité d’identité de l’organisation ou de l’entreprise. Il est recommandé de mettre en place l’accès conditionnel, qui permet d’interdire l’accès à l’environnement Microsoft 365 si la personne qui se présente (saisie login / MDP) ne respecte pas certaines conditions (PC d’entreprise, hors réseau de l’entreprise, protocole interdit, absence de double authentification…). Toutes les organisations devraient déployer l’accès conditionnel, qui sécurise les accès à la messagerie, SharePoint, Teams, Power Platform… Il est même possible de créer des règles spécifiques à des applications et de demander par exemple une double authentification pour des applications sensibles (SMS / code).
Sécuriser les postes de l’entreprise
Un utilisateur lambda ne devrait pas être administrateur de son poste. Que ce soit pour la Power Platform ou pour d’autres usages, l’installation d’outils sur un poste client peut permettre de contourner / déchiffrer les informations HTTPS dans les navigateurs internet. Seules les applications autorisées doivent être déployées sur le poste de l’utilisateur, au risque d’exposer des données via des outils malveillants.
En synthèse
Tester / hacker son application peut se révéler très judicieux avant de la déployer. L’idéal est d’appliquer un certain nombre de bonnes pratiques dès la conception de l’application. En fonction de la criticité / confidentialité des données, il faut avoir une approche adaptée. La sécurisation passe par l’identité, la base de données et le poste de l’utilisateur pour diminuer le risque.
Rédigé par David VACHALA