Présentation

Effectué

Microsoft Power Platform propose de nombreuses fonctionnalités de sécurité différentes dans le cadre du déploiement d’environnements, de données et d’applications. La sécurité est un élément fondamental de la conception d’une solution Microsoft Power Platform. Souvent, les besoins de sécurité sont pris en compte tardivement dans un projet. En intégrant la modélisation de la sécurité à la conception de la solution, vous pouvez éviter des modifications importantes à un stade ultérieur du projet.

Important

La sécurité doit être prise en compte en amont, et non en aval, avant le déploiement.

La stratégie de sécurité adéquate permet de trouver le juste équilibre entre les exigences de sécurité légitimes et le besoin d’accès au système et de collaboration intersociétés. Lors de l’implémentation de solutions Microsoft Power Platform, l’architecte de solution doit trouver le juste équilibre entre deux préoccupations : l’accès utilisateur et la sécurité du système.

Trouvez le juste équilibre entre l’accès utilisateur et la sécurité du système.

La sécurité des données et du système est importante. Les données sont le moteur de l’entreprise et certaines d’entre elles ne doivent pas être communiquées à un concurrent. Dans le cadre de la règlementation relative aux données personnelles, les organisations peuvent être tenues responsables si une violation de données affecte des données personnelles.

La convivialité du système et l’adoption utilisateur sont d’autres considérations importantes. Si le modèle de sécurité est trop laxiste, les utilisateurs peuvent consulter et modifier des données auxquelles ils ne devraient pas avoir accès. Cela donne l’impression que les données contenues dans le système ne sont pas fiables. Si le modèle de sécurité est trop strict et que vous verrouillez tout de sorte que les utilisateurs ne puissent voir qu’un petit sous-ensemble des données du système ou effectuer que des opérations limitées, vous diminuerez la valeur de la solution. Par conséquent, les utilisateurs retourneront à leurs anciens silos de données et l’adoption utilisateur, principal aspect de la mesure du succès d’une solution, finira par en souffrir.

En tant que consultant fonctionnel ou développeur, vous n’avez peut-être pas expérimenté les fonctionnalités de sécurité de Microsoft Power Platform. Cependant, en tant qu’architecte de solution, vous devez comprendre chaque fonctionnalité de sécurité et quand l’appliquer dans différents scénarios. Ce module présente de manière approfondie les aspects de la sécurité des solutions Microsoft Power Platform. Il contient des informations importantes introuvables dans les modules concernant d’autres rôles.

Processus lié à l’architecture de la sécurité

Pour définir la sécurité d’une solution, les architectes de solution doivent décomposer les besoins et clarifier ce à quoi la solution doit ressembler. Ils doivent comprendre l’environnement de l’organisation et ses besoins dans les domaines suivants :

  • Authentification
  • Sécurité réseau
  • Autorisation

Découverte

La découverte consiste à découvrir l’environnement, les procédures et les politiques de l’organisation.

Les architectes de solution doivent découvrir les solutions d’authentification utilisées par une organisation en se posant les questions suivantes :

  • A-t-elle recours à l’authentification unique (SSO) ?
  • Utilise-t-elle des produits provenant d’autres sources ou uniquement Microsoft Entra ID ?
  • A-t-elle recours à l’authentification multifacteur ?
  • Utilise-t-elle l’accès conditionnel ?

Il est peu probable qu’un seul projet Microsoft Power Platform change l’approche d’authentification de l’organisation. Par conséquent, l’architecte de solution doit :

  • adapter la conception aux politiques et besoins de sécurité ;
  • créer un blueprint d’authentification initial ;
  • examiner la conception avec les représentants de la sécurité de l’organisation.

Les architectes de solution doivent comprendre comment le système d’autorisation sera appliqué à la solution et :

  • extraire les besoins liés à la sécurité ;
  • clarifier les besoins de sécurité à des fins de simplification ;
  • créer un blueprint d’autorisation initial ;
  • consulter les analystes métier et les équipes de sécurité.

Pour mieux comprendre comment l’organisation gère la sécurité, les architectes de solution doivent se poser les questions suivantes :

  • Comment la sécurité est-elle gérée ?
  • Quelles politiques de sécurité doivent être suivies ?
  • Quel est le processus d’approbation de l’architecture de sécurité ?
  • Comment les droits d’accès au niveau de l’application sont-ils gérés ?
  • Quelle équipe va modifier la sécurité de Microsoft Power Platform ?
  • Comment les utilisateurs sont-ils affectés aux applications ?

Lors de la découverte de l’environnement utilisateur, l’architecte de solution doit également découvrir :

  • l’influence de la structure organisationnelle sur la sécurité ;
  • si les collaborateurs travaillent dans des équipes qui dépassent les limites de l’organisation ;
  • si un système de classification des données est en place ;
  • les politiques de conservation des données et de confidentialité ;
  • les règlementations en vigueur relatives à l’accès aux données.

Rôle de l’architecte de solution dans la modélisation de la sécurité

Les architectes de solution dirigent les initiatives visant à créer un modèle de sécurité complet allant de l’authentification à l’accès au niveau de la colonne de données.

Le rôle de l’architecte de solution en matière de sécurité consiste à :

  • diriger les initiatives visant à créer un modèle de sécurité complet ;
  • communiquer les options d’architecture de sécurité à un niveau général et contribuer à guider les membres de l’équipe à travers les choix de conception d’architecture ;
  • prôner la simplicité et éviter que la sécurité ne soit trop compliquée, tout en garantissant les protections nécessaires.

Un architecte de solution doit également déterminer si des besoins de sécurité, des exigences règlementaires ou des exigences de conformité impacteront la conception de la solution.

Besoins de sécurité

Le modèle de sécurité est différent pour chaque solution, mais tenez compte des instructions suivantes lors de la modélisation de la sécurité :

  • Restreindre : les utilisateurs doivent être en mesure de modifier uniquement les données pertinentes pour leur rôle. Cependant, il est logique d’être moins restrictif sur les données que les utilisateurs peuvent lire, car cela les aide à voir leurs données en contexte. Un architecte de solution doit éliminer la possibilité de supprimer des données, sauf si cela s’avère nécessaire.
  • Simplifier : Microsoft Power Platform offre de nombreuses fonctionnalités de sécurité. Un architecte de solution doit tenir compte de l’impact de la conception de la sécurité sur la complexité de la gestion du système et la difficulté à apporter des modifications.
  • Utiliser : souvent, les besoins de sécurité fournis découlent d’une appréhension ou d’idées fausses au sujet des fonctionnalités Microsoft Power Platform. Un architecte de solution doit s’assurer que la conception de la sécurité est fondée sur des besoins métier légitimes. Cette approche peut exiger que l’architecte de solution comprenne l’origine des besoins de sécurité et qu’il discute d’autres approches. Il peut s’avérer difficile, voire coûteux, de tenter de verrouiller une solution Microsoft Power Platform afin d’empêcher les utilisateurs d’effectuer certaines actions, si cette possibilité n’est pas offerte par la plateforme. L’architecte de solution doit utiliser les fonctionnalités de sécurité de la plateforme lors de la conception de la sécurité de sa solution.
  • Niveau : Microsoft Power Platform offre des fonctionnalités de sécurité sur les applications, les données et les processus. Dans l’idéal, la sécurité doit être implémentée au niveau de la plateforme, afin de faciliter l’implémentation et la gestion.
  • Évaluer : l’utilisation de la solution, une fois implémentée, ne sera pas celle initialement envisagée et les habitudes des utilisateurs évolueront au fil du temps. Parfois, les décisions de conception de sécurité initiales cessent d’être valables et doivent être ajustées.