Partager via

Recommandations pour la gestion des identités et des accès

  • Article

S’applique à cette recommandation de liste de contrôle de sécurité bien conçue : Power Platform

SE:05 Mettez en œuvre une gestion des identités et des accès (IAM) stricte, conditionnelle et auditable pour tous les utilisateurs de la charge de travail, les membres de l’équipe et les composants du système. Limitez l’accès exclusivement à si nécessaire. Utilisez les normes modernes du secteur pour toutes les implémentations de l’authentification et de l’autorisation. Restreignez et auditez rigoureusement l’accès qui n’est pas basé sur l’identité.

Ce guide décrit les recommandations pour authentifier et autoriser les identités susceptibles de tenter d’accéder aux ressources de la charge de travail.

Du point de vue du contrôle technique, l’identité est toujours le périmètre principal. Cette portée n’inclut pas seulement les limites de votre charge de travail. Il comprend également des composants individuels faisant partie de votre charge de travail.

Parmi les identités standard on trouve :

  • Les humains. Utilisateurs d’applications, administrateurs, opérateurs, auditeurs et acteurs malveillants.
  • Systèmes. Identités de charge de travail, identités managées, clés API, principaux de service et ressources Azure.
  • Anonyme. Des entités qui n’ont fourni aucune preuve de leur identité.

Définitions

Conditions Définition
Authentification (AuthN) Processus qui vérifie qu’une identité est bien celle ou ce qu’elle prétend être.
Autorisation (AuthZ) Processus qui vérifie si une identité est autorisée à effectuer une action demandée.
Accès conditionnel Un ensemble de règles qui autorisent des actions basées sur des critères spécifiés.
Fournisseur d’identité Fournisseurs d’identité, tel que Microsoft Entra ID.
Personne Une fonction ou un titre qui comporte un ensemble de responsabilités et d’actions.
Clés prépartagées Type de secret partagé entre un fournisseur et un consommateur et utilisé via un mécanisme sécurisé et convenu.
Identité de la ressource Identité définie pour les ressources cloud gérées par la plateforme.
Role Un ensemble d’autorisations qui définissent ce qu’un utilisateur ou un groupe peut faire.
Portée Différents niveaux de hiérarchie organisationnelle où un rôle est autorisé à fonctionner. Également un groupe de fonctionnalités dans un système.
Principal de sécurité Une identité qui fournit des autorisations. Il peut s’agir d’un utilisateur, d’un groupe ou d’un principal de service. Tous les membres du groupe bénéficient du même niveau d’accès.
Identité de l’utilisateur Une identité pour une personne, comme un employé ou un utilisateur externe.
Identités charges de travail Identité système pour une application, un service, un script, un conteneur ou un autre composant d’une charge de travail utilisée pour s’authentifier auprès d’autres services et ressources.

Note

Une identité peut être regroupée avec d’autres identités similaires sous un parent appelé principal de sécurité. Un groupe de sécurité est un exemple d’entité de sécurité. Cette relation hiérarchique simplifie la maintenance et améliore la cohérence. Étant donné que les attributs d’identité ne sont pas gérés au niveau individuel, les risques d’erreurs sont également réduits. Dans cet article, le terme identité inclut les principes de sécurité.

Microsoft Entra ID le fournisseur d'identité pour Power Platform

Tous Power Platform utilisation des produits Microsoft Entra ID (anciennement Azure Active Directory ou Azure AD) pour la gestion des identités et des accès. Entra ID permet aux organisations de sécuriser et de gérer l’identité de leurs environnements hybrides et multicloud. Entra ID est également essentiel pour gérer les invités professionnels nécessitant un accès à Power Platform ressources. Power Platform utilise également Entra ID pour gérer d’autres applications qui doivent s’intégrer à Power Platform API utilisant les fonctionnalités du principal de service. En utilisant Entra ID, Power Platform peut exploiter les fonctionnalités de sécurité plus avancées d’Entra ID telles que l’accès conditionnel et l’évaluation continue de l’accès.

Authentification

L’authentification est un processus qui vérifie les identités. L’identité qui demande l’identité doit fournir une certaine forme d’identification vérifiable. Par exemple :

  • Nom d’utilisateur et Mot de passe.
  • Un secret pré-partagé, comme une clé API qui accorde l’accès.
  • Jeton Signature d’accès partagé (SAS).
  • Un certificat utilisé dans l’authentification mutuelle Transport Layer Security (TLS).

L’authentification de Power Platform implique une séquence de requêtes, de réponses et de redirections entre le navigateur de l’utilisateur et Power Platform ou les services Azure. La séquence suit le flux d’octroi de code d’authentification Microsoft Entra ID.

La connexion et l’authentification à une source de données se font de manière distincte de l’authentification à un service Power Platform. Pour plus d’informations, reportez-vous à la rubrique Se connecter et authentifier à la source de données.

l’autorisation,

Power Platform utilise Microsoft Entra ID Microsoft Identity Platform pour l’autorisation de tous les appels d’API avec le protocole standard de l’industrie OAuth 2.0.

Stratégies de conception clés

Pour comprendre les besoins en matière d’identité d’une charge de travail, vous devez répertorier les flux utilisateur et système, les actifs de la charge de travail et les personnages, ainsi que les actions qu’ils entreprendront.

Chaque cas d’utilisation aura probablement son propre ensemble de contrôles que vous devrez concevoir dans un état d’esprit d’hypothèse de violation. En fonction des exigences d’identité du cas d’utilisation ou des personas, identifiez les choix conditionnels. Évitez d’utiliser une seule solution pour tous les cas d’utilisation. À l’inverse, les contrôles ne doivent pas être si précis que vous introduisiez une surcharge de gestion inutile.

Vous devez enregistrer la piste d’accès à l’identité. Cela permet de valider les contrôles et vous pouvez utiliser les journaux pour les audits de conformité.

Déterminer toutes les identités pour l’authentification

Accès de l’extérieur vers l’intérieur. L’authentification de Power Platform implique une séquence de requêtes, de réponses et de redirections entre le navigateur de l’utilisateur et Power Platform ou les services Azure. La séquence suit le flux d’octroi de code d’authentification Microsoft Entra ID. Power Platform authentifie automatiquement tous les utilisateurs qui accèdent à la charge de travail à diverses fins.

Accès de l’intérieur vers l’extérieur. Votre charge de travail devra accéder à d’autres ressources. Par exemple, lire ou écrire sur la plate-forme de données, récupérer des secrets du magasin de secrets et enregistrer la télémétrie auprès des services de surveillance. Il se peut même qu’il ait besoin d’accéder à des services tiers. Ce sont toutes des exigences en matière d’identité de charge de travail. Cependant, vous devez également prendre en compte les exigences en matière d’identité des ressources ; par exemple, comment les pipelines de déploiement seront exécutés et authentifiés.

Déterminer les actions pour autorisation

Ensuite, vous devez savoir ce que chaque identité authentifiée essaie de faire pour que ces actions puissent être autorisées. Les actions peuvent être divisées selon le type d’accès qu’elles nécessitent :

  • Accès au plan de données. Les actions qui ont lieu dans le plan de données provoquent un transfert de données. Par exemple, une application lisant ou écrivant des données depuis Microsoft Dataverse, ou écrivant des journaux dans Application Insights.

  • Accès au plan de contrôle. Les actions qui ont lieu dans le plan de contrôle entraînent la création, la modification ou la suppression d’une Power Platform ressource. Par exemple, modifier les propriétés de l’environnement ou créer une stratégie de données.

Les applications ciblent généralement les opérations du plan de données, tandis que les opérations accèdent souvent aux plans de contrôle et de données.

Fournir une autorisation basée sur les rôles

En fonction de la responsabilité de chaque identité, autorisez les actions qui devraient être autorisées. Une identité ne doit pas être autorisée à faire plus que ce qu’elle doit faire. Avant de définir des règles d’autorisation, vous devez bien comprendre qui ou quoi fait des demandes, ce que ce rôle est autorisé à faire et dans quelle mesure il peut le faire. Ces facteurs conduisent à des choix qui combinent identité, rôle et portée.

Prenez en compte les éléments suivants :

  • La charge de travail doit-elle avoir accès au plan de données Dataverse pour un accès en lecture et en écriture ?
  • La charge de travail doit-elle également accéder aux propriétés de l’environnement ?
  • Si l’identité est compromise par un acteur malveillant, quel serait l’impact sur le système en termes de confidentialité, d’intégrité et de disponibilité ?
  • La charge de travail nécessite-t-elle un accès permanent ou un accès conditionnel peut-il être envisagé ?
  • La charge de travail effectue-t-elle des actions qui nécessitent des autorisations administratives/élevées ?
  • Comment la charge de travail interagira-t-elle avec les services tiers ?
  • Pour les copilotes, avez-vous des exigences en matière d’authentification unique (SSO) ?
  • Le copilote fonctionne-t-il en mode non authentifié, en mode authentifié ou les deux ?

Attribution de rôle

Un rôle est un ensemble d’autorisations attribuées à une identité. Attribuez des rôles qui permettent uniquement à l’identité d’accomplir la tâche, et pas plus. Lorsque les autorisations des utilisateurs sont limitées aux exigences de leur travail, il est plus facile d’identifier un comportement suspect ou non autorisé dans le système.

Posez ces questions :

  • L’accès en lecture seule est-il suffisant ?
  • L’identité a-t-elle besoin d’autorisations pour supprimer des ressources ?
  • Le rôle a-t-il uniquement besoin d’accéder aux enregistrements qu’il a créés ?
  • L’accès hiérarchique basé sur l’unité commerciale dans laquelle se trouve l’utilisateur est-il requis ?
  • Le rôle nécessite-t-il des autorisations administratives ou élevées ?
  • Le rôle nécessite-t-il un accès permanent à ces autorisations ?
  • Que se passe-t-il si l’utilisateur change de travail ?

Limiter le niveau d’accès dont disposent les utilisateurs, les applications ou les services réduit la surface d’attaque potentielle. Si vous accordez uniquement les autorisations minimales requises pour effectuer des tâches spécifiques, le risque d’attaque réussie ou d’accès non autorisé est considérablement réduit. Par exemple, les développeurs n’ont besoin que d’un accès maker à l’environnement de développement, mais pas à l’environnement de production ; ils n’ont besoin d’un accès que pour créer des ressources mais pas pour modifier les propriétés de l’environnement ; et ils peuvent uniquement avoir besoin d’accéder aux données en lecture/écriture de Dataverse mais pas de modifier le modèle de données ou les attributs de la Dataverse table.

Évitez les autorisations qui ciblent des utilisateurs individuels. Les autorisations granulaires et personnalisées créent de la complexité et de la confusion et peuvent devenir difficiles à maintenir à mesure que les utilisateurs changent de rôle et se déplacent au sein de l’entreprise, ou que de nouveaux utilisateurs ayant des exigences d’authentification similaires rejoignent l’équipe. Cette situation peut créer une configuration existante complexe, difficile à maintenir et avoir un impact négatif sur la sécurité et la fiabilité.

Compromis : une approche de contrôle d’accès granulaire permet un meilleur audit et une meilleure surveillance des activités des utilisateurs.

Attribuez des rôles qui commencent avec le moins de privilèges et ajoutez-en d’autres en fonction de vos besoins opérationnels ou d’accès aux données. Vos équipes techniques doivent disposer de conseils clairs pour mettre en œuvre les autorisations.

Choix l’accès conditionnel

Ne donnez pas à toutes les identités le même niveau d’accès. Basez vos décisions sur deux facteurs principaux :

  • Durée. Combien de temps l’identité peut accéder à votre environnement.
  • Privilège. Niveau d’autorisation.

Ces facteurs ne s’excluent pas mutuellement. Une identité compromise qui dispose de davantage de privilèges et d’une durée d’accès illimitée peut obtenir davantage de contrôle sur le système et les données ou utiliser cet accès pour continuer à modifier l’environnement. Limitez ces facteurs d’accès à la fois à titre préventif et pour contrôler le rayon de l’explosion.

Les approches juste-à-temps (JIT) fournissent les privilèges requis uniquement lorsqu’ils sont nécessaires.

Just Enough Access (JEA) fournit uniquement les privilèges requis.

Bien que le temps et le privilège soient les principaux facteurs, d’autres conditions s’appliquent. Par exemple, vous pouvez également utiliser l’appareil, le réseau et l’emplacement à partir desquels l’accès provient pour définir des stratégies.

Utilisez des contrôles puissants qui filtrent, détectent et bloquent les accès non autorisés, y compris des paramètres tels que l’identité et l’emplacement de l’utilisateur, l’état de l’appareil, le contexte de la charge de travail, la classification des données et les anomalies.

Par exemple, des identités tierces telles que des fournisseurs, des partenaires et des clients devront peut-être accéder à votre charge de travail. Ils ont besoin du niveau d’accès approprié plutôt que des autorisations par défaut que vous accordez aux employés à temps plein. Une différenciation claire des comptes externes facilite la prévention et la détection des attaques provenant de ces vecteurs.

Comptes à Impact critique

Les identités administratives introduisent certains des risques de sécurité les plus importants, car les tâches qu’elles effectuent nécessitent un accès privilégié à un large éventail de ces systèmes et applications. Une compromission ou une mauvaise utilisation peut avoir un effet néfaste sur votre entreprise et ses systèmes d’information. La sécurité de l’administration est l’un des domaines de sécurité les plus critiques.

Protéger les accès privilégiés contre des adversaires déterminés nécessite que vous adoptiez une approche complète et réfléchie pour isoler ces systèmes des risques. En voici quelques stratégies :

  • Réduisez le nombre de comptes à impact critique.

  • Utilisez des rôles distincts au lieu d’élever les privilèges des identités existantes.

  • Évitez les accès permanents ou permanents en utilisant les fonctionnalités JIT de votre IdP. En cas de bris de vitre, suivez un processus d’accès d’urgence.

  • Utilisez des protocoles d’accès modernes comme l’authentification sans mot de passe ou l’authentification multifacteur. Externalisez ces mécanismes vers votre IdP.

  • Appliquez les attributs de sécurité clés en utilisant politiques d’accès conditionnel.

  • Désactivez les comptes administratifs qui ne sont pas utilisés.

Établir des processus pour gérer le cycle de vie des identités

L’accès aux identités ne doit pas durer plus longtemps que les ressources auxquelles les identités accèdent. Assurez-vous de disposer d’un processus permettant de désactiver ou de supprimer des identités en cas de modifications dans la structure de l’équipe ou dans les composants logiciels.

Ces conseils s’appliquent au contrôle de source, aux données, aux plans de contrôle, aux utilisateurs de charge de travail, à l’infrastructure, aux outils, à la surveillance des données, aux journaux, aux métriques et à d’autres entités.

Établir un processus de gouvernance des identités pour gérer le cycle de vie des identités numériques, des utilisateurs hautement privilégiés, des utilisateurs externes/invités et des utilisateurs de la charge de travail. Mettez en œuvre des examens d’accès pour garantir que lorsque les identités quittent l’organisation ou l’équipe, leurs autorisations de charge de travail sont supprimées.

Protéger les secrets non basés sur l’identité

Les secrets d’application tels que les clés pré-partagées doivent être considérés comme des points vulnérables du système. Dans la communication bidirectionnelle, si le fournisseur ou le consommateur est compromis, des risques de sécurité importants peuvent être introduits. Ces clés peuvent également être lourdes car elles introduisent des processus opérationnels.

Traitez ces secrets comme des entités qui peuvent être extraites dynamiquement d’un magasin de secrets. Ils ne doivent pas être codés en dur dans vos applications, flux, pipelines de déploiement ou dans tout autre artefact.

Assurez-vous d’avoir le possibilité de révoquer les secrets.

Appliquer des pratiques opérationnelles qui gèrent des tâches telles que rotation et expiration des clés.

Pour plus d’informations sur les politiques de rotation, voir Automatisez la rotation d’un secret pour les ressources disposant de deux ensembles d’informations d’identification d’authentification et Tutoriel : Mise à jour de la fréquence de rotation automatique des certificats dans Key Vault.

Environnement de développement sûrs

L’accès en écriture aux environnements de développement doit être sécurisé et l’accès en lecture au code source doit être limité aux rôles en fonction du besoin de connaître. Vous devez mettre en place un processus qui analyse régulièrement les ressources et identifie les dernières vulnérabilités.

Maintenir une piste d’audit

Un aspect de la gestion des identités consiste à garantir que le système est auditable. Les audits valident si les stratégies d’hypothèse-violation sont efficaces. Le maintien d’une piste d’audit vous aide à :

  • Vérifiez que l’identité est authentifiée avec une authentification forte. Toute action doit être traçable pour éviter les attaques de répudiation.

  • Détectez les protocoles d’authentification faibles ou manquants et obtenez une visibilité et des informations sur les connexions des utilisateurs et des applications.

  • Évaluez l’accès des identités à la charge de travail en fonction des exigences de sécurité et de conformité et tenez compte du risque lié au compte utilisateur, de l’état de l’appareil ainsi que d’autres critères et politiques que vous définissez.

  • Suivre les progrès ou les écarts par rapport aux exigences de conformité.

La plupart des ressources ont accès au plan de données. Vous devez connaître les identités qui accèdent aux ressources et les actions qu’elles effectuent. Vous pouvez utiliser ces informations pour les diagnostics de sécurité.

Facilitation de Power Platform

Power Platform le contrôle d’accès est un élément essentiel de son architecture de sécurité globale. Les points de contrôle d’accès peuvent garantir que les bons utilisateurs ont accès aux Power Platform ressources. Dans cette section, nous explorerons les différents points d’accès que vous pouvez configurer et leur rôle dans votre stratégie de sécurité globale.

ID Microsoft Entra

Tous Power Platform utilisation des produits Microsoft Entra ID (anciennement Azure Active Directory ou Azure AD) pour la gestion des identités et des accès. Entra ID permet aux organisations de sécuriser et de gérer l’identité de leurs environnements hybrides et multicloud. Entra ID est également essentiel pour gérer les invités professionnels nécessitant un accès à Power Platform ressources. Power Platform utilise également Entra ID pour gérer d’autres applications qui doivent s’intégrer à Power Platform API utilisant les fonctionnalités du principal de service. En utilisant Entra ID, Power Platform peut exploiter les fonctionnalités de sécurité plus avancées d’Entra ID telles que l’accès conditionnel et l’évaluation continue de l’accès.

Schéma d’un système de cloud computing.

Attribution de licences

L’accès à Power Apps et Power Automate commence par obtenir une licence. Les actifs et les données auxquels il peut accéder type de licence dont dispose un utilisateur. La tableau suivant décrit, d’un point de vue global, les différences entre les ressources disponibles pour un utilisateur en fonction de son type de plan. Les détails de licence granulaire se trouvent dans la Vue d’ensemble de licence.

Stratégies d’accès conditionnel

L’accès conditionnel décrit votre politique pour une décision d’accès. Pour utiliser l’accès conditionnel, vous devez comprendre les restrictions requises pour le cas d’utilisation. Configurez Microsoft Entra l’accès conditionnel en définissant une stratégie d’accès basée sur vos besoins opérationnels.

Pour en savoir plus, consultez :

Accès continu

L’accès continu s’accélère lorsque certains événements sont évalués pour déterminer si l’accès doit être révoqué. Traditionnellement, avec l’authentification OAuth 2.0, l’expiration se produit lorsqu’une vérification est effectuée lors du renouvellement du jeton. Avec un accès continu, les événements critiques d’un utilisateur et les changements d’emplacement réseau sont évalués en permanence pour déterminer si l’utilisateur doit toujours conserver son accès. Ces évaluations peuvent entraîner une interruption anticipée des sessions actives ou nécessiter une nouvelle authentification. Par exemple, si un compte utilisateur est désactivé, il devrait perdre l’accès à l’application. L’emplacement est également important ; par exemple, le jeton peut avoir été autorisé à partir d’un emplacement approuvé, mais l’utilisateur a modifié sa connexion vers un réseau non approuvé. L’accès continu appellerait l’évaluation de la politique d’accès conditionnel et l’utilisateur perdrait l’accès car il ne se connecte plus à partir d’un emplacement approuvé.

Actuellement, avec Power Platform, seul Dataverse prend en charge l’évaluation continue des accès. Microsoft travaille à ajouter du support à d’autres Power Platform services et clients. Pour plus d’informations, Voir Contrôler l’accès aux formulaires.

Avec l’adoption continue de modèles de travail hybrides et l’utilisation d’applications cloud, Entra ID est devenu un périmètre de sécurité principal crucial pour la protection des utilisateurs et des ressources. L’accès conditionnel étend ce périmètre au-delà du périmètre du réseau pour inclure l’identité de l’utilisateur et de l’appareil. L’accès continu garantit qu’à mesure que les événements ou les emplacements des utilisateurs changent, l’accès est réévalué. Power Platform L’utilisation d’Entra ID par vous permet de mettre en œuvre une gouvernance de sécurité au niveau de l’organisation que vous pouvez appliquer de manière cohérente dans l’ensemble de votre portefeuille d’applications. Consultez ces bonnes pratiques de gestion des identités pour obtenir plus de conseils sur la création de votre propre plan d’utilisation d’Entra ID avec Power Platform.

Gestion des accès groupe

Au lieu d’accorder des autorisations à des utilisateurs spécifiques, attribuez l’accès aux groupes dans Microsoft Entra ID. Si aucun groupe n’existe, travaillez avec votre équipe chargée de l’identité pour en créer. Vous pouvez ensuite ajouter et supprimer des membres du groupe en dehors d’Azure et vous assurer que les autorisations sont à jour. Vous pouvez également utiliser le groupe à d’autres fins, comme des listes de diffusion.

Pour plus d’informations, consultez Contrôle d’accès sécurisé à l’aide de groupes dans Microsoft Entra ID.

Détection de menaces

Microsoft Entra ID Protection peut vous aider à détecter, enquêter et remédier aux risques liés à l’identité. Pour plus d’informations, consultez Qu'est-ce que la protection identité.

La détection des menaces peut prendre la forme d’une réaction à une alerte d’activité suspecte ou d’une recherche proactive d’événements anormaux dans les journaux d’activité. L’analyse du comportement des utilisateurs et des entités (UEBA) dans Microsoft Sentinel facilite la détection des activités suspectes. Pour plus d’informations, consultez Identifier les menaces avancées avec UEBA dans Microsoft Sentinel.

Journalisation des identités

Power Apps, Power Automate, Copilot Studio, Les connecteurs et la journalisation des activités de données réponse sont suivis et visualisés à partir du portail de conformité Purview. Microsoft Pour plus d’informations, consultez En savoir plus sur Microsoft Purview.

Les journaux enregistrent les modifications apportées aux enregistrements des clients dans un environnement avec une base de données Dataverse. Les audits Dataverse enregistrent également l’accès des utilisateurs via une application ou via le Kit de développement logiciel (SDK) dans un environnement. Cet audit est activé au niveau de l’environnement et une configuration supplémentaire est requise pour les tables et colonnes individuelles.

Rôles administrateur de service

Entra ID contient un ensemble de rôles préétablis qui peuvent être attribués aux administrateurs pour leur donner l’autorisation d’effectuer des tâches administratives. Vous pouvez consulter la matrice d’autorisations pour une répartition détaillée des privilèges de chaque rôle.

Utilisez Microsoft Entra Privileged Identity Management (PIM) gérer les rôles d’administrateur avec privilèges élevés dans le centre d’administration Power Platform.

Sécurité des données Dataverse

L’une des fonctionnalités clés de Dataverse est son modèle de sécurité enrichi qui peut être adapté en fonction de nombreux scénarios d’utilisation commerciale. Ce modèle de sécurité est disponible seulement si une base de données Dataverse est disponible dans l’environnement. En tant que professionnel de la sécurité, vous ne créerez probablement pas vous-même l’intégralité du modèle de sécurité, mais vous devrez peut-être veiller à ce que l’utilisation des fonctionnalités de sécurité soit cohérente avec les exigences de sécurité des données de l’organisation. Dataverse utilise la sécurité basée sur les rôles pour regrouper une collection de privilèges. Ces rôles de sécurité peuvent être associés directement aux utilisateurs, ou peuvent être associés à des équipes et des divisions Dataverse. Pour en savoir plus, consultez Concepts de sécurité dans Microsoft Dataverse.

Configurer l’authentification des utilisateurs dans Copilot Studio

Copilot Studio prend en charge plusieurs options d’authentification. Choisissez-en un répondant à vos besoins. L’authentification permet aux utilisateurs de se connecter, accordant ainsi à votre copilote l’accès à des ressources ou informations restreintes. Les utilisateurs peuvent se connecter à l’aide d’un identifiant ou de tout fournisseur d’identité 2.0, tel que Google ou. Microsoft Entra OAuth Facebook Pour en savoir plus, consultez Configurer l’authentification utilisateur dans Copilot Studio.

Grâce à la sécurité basée sur Direct Line, vous pouvez restreindre l’accès aux emplacements que vous contrôlez en activant l’accès sécurisé avec dessecrets ou des jetons. Direct Line

Copilot Studio prend en charge l’authentification unique (SSO), ce qui signifie que les copilotes peuvent connecter l’utilisateur. L’authentification unique doit être implémentée sur vos pages Web et vos applications mobiles. Pour Microsoft Teams, l’authentification unique est transparente si vous Sélectionner l’option d’authentification "Uniquement dans Teams". Il peut également être configuré manuellement avec Azure AD v2 ; toutefois, dans ce cas, l’application Teams doit être déployée sous forme de fichier zip, et non via le déploiement Teams en 1 clic depuis Copilot Studio.

En savoir plus :

Accéder en toute sécurité aux données à l’aide de Customer Lockbox

La plupart des opérations, de l’assistance et du dépannage effectués par le personnel (y compris les sous-traitants) ne nécessitent pas d’accès aux données client. Microsoft Avec Power Platform Customer Lockbox, nous offrons aux clients une interface pour qu’ils puissent examiner et approuver (ou rejeter) les demandes d’accès aux données dans les rares occasions où l’accès aux données des clients est nécessaire. Par exemple, il est utilisé lorsqu’un ingénieur doit accéder aux données client, que ce soit dans le cadre d’un ticket d’assistance initié par le client ou d’un problème identifié par. Microsoft Microsoft Pour plus d’informations, voir Accéder en toute sécurité aux données client via Customer Lockbox dans Power Platform et Dynamics 365.

Liste de contrôle de sécurité

Référez-vous à l’ensemble complet des recommandations.

Liste de contrôle de sécurité