Comprendre les autorisations et les informations auxquelles accèdent les applications Teams

En fonction de leurs fonctionnalités, les applications Teams peuvent accéder aux informations de votre utilisateur ou de votre organization pour fonctionner comme prévu.

• Certaines applications ne cherchent pas à accéder aux informations de organization et ne nécessitent donc aucune approbation. Les utilisateurs peuvent utiliser ces applications sans l’approbation ou le consentement de l’administrateur, car les informations de organization sont sécurisées à partir de ces applications.
• Certaines applications nécessitent que les informations de votre organization ou de l’utilisateur fonctionnent ou traitent les informations. Ces applications ne peuvent pas fonctionner, sauf si vous autorisez une telle application à accéder aux informations de votre organisation.

Vous devez évaluer la conformité, la sécurité et les informations de gestion des données d’une application et comprendre les autorisations demandées par l’application avant d’autoriser l’utilisation d’une application par vos utilisateurs. Pour ce faire, vous devez comprendre les autorisations, le consentement et les contrôles disponibles. Pour plus d’informations sur la sécurité, la conformité et la confidentialité, consultez Programme de conformité des applications pour la sécurité, la gestion des données et la confidentialité.

Les autorisations permettent aux applications d’accéder à des ressources privilégiées et d’agir au nom de l’utilisateur. Cette fonctionnalité permet aux développeurs de créer des fonctionnalités enrichies dans les applications qui augmentent la productivité des utilisateurs. Vous devez comprendre clairement les autorisations, leur portée et leurs implications. Dans le Centre d’administration Microsoft Teams, vous pouvez passer en revue les risques d’autorisation d’application et les niveaux de privilèges. Vous voyez également des détails sur ce que chaque application peut faire dans Teams. Pour plus d’informations, consultez Afficher les risques d’autorisation d’application et les niveaux de privilège.

Comment les applications accèdent aux informations de organization à l’aide des autorisations

Teams fournit des protections afin que les informations de votre organization ou de l’utilisateur ne soient pas accessibles sans votre consentement. Pour qu’une application accède à des informations, les actions suivantes doivent se produire :

1. Les développeurs d’applications déclarent des autorisations et des fonctionnalités d’application lorsqu’ils créent des applications.
2. Les administrateurs comprennent et analysent les autorisations requises par l’application dans les portails d’administration.
3. L’accès aux données est accordé de deux manières. Lorsque vous ajoutez l’application à Teams, elle obtient l’accès à certaines fonctionnalités de base qui peuvent inclure l’accès aux informations de base. Lorsque vous accordez le consentement, l’application reçoit l’accès à certaines données de l’utilisateur et organization ou les deux, en fonction des autorisations d’application pour lesquelles elle a demandé le consentement.

Comprendre l’accès aux données par les applications et les autorisations requises

Une application peut accéder aux informations d’un organization de deux manières :

• Accès délégué : une application accède à la ressource au nom de l’utilisateur. Cet accès nécessite des autorisations déléguées. L’application peut accéder uniquement aux informations auxquelles l’utilisateur peut accéder.
• Accès à l’application : une application agit seule sans qu’aucun utilisateur ne soit connecté, lorsqu’il n’est pas souhaitable qu’un utilisateur spécifique se connecte ou que les données requises ne peuvent pas être étendues à un seul utilisateur. Cet accès nécessite des autorisations d’application. Si le consentement est accordé, une application peut accéder aux données associées à l’autorisation.

Pour chaque application, vous pouvez voir ses autorisations dans la page des détails de l’application dans le centre d’administration.

Utilisez un rôle à privilèges inférieurs pour accomplir des tâches dans la cas où cela est possible. Utilisez le rôle Administrateur général uniquement si nécessaire.

Où les administrateurs peuvent-ils voir toutes les autorisations d’une application

Accédez à l’onglet Autorisations de la page détails de l’application pour afficher tous les niveaux d’autorisations, d’accès et de privilèges requis. Vous pouvez également télécharger toutes les autorisations dans un fichier .csv pour une analyse plus approfondie.

Pour comprendre ce que les applications peuvent faire dans Teams, consultez Fonctionnalités de base et interactions avec les utilisateurs et les données auxquels les applications accèdent. Pour savoir comment autoriser l’utilisation d’une application, consultez Accorder et gérer le consentement aux autorisations d’application Teams.

Afficher les risques d’autorisation d’application et les niveaux de privilèges

Pour afficher les informations de privilège d’autorisation, procédez comme suit :

1. Connectez-vous au Centre d’administration Microsoft Teams.

2. Accédez à Gérer les applications pour afficher et régir les applications dans le catalogue de votre organization, puis sélectionnez une application particulière.

3. Utilisez la colonne Niveau de privilège pour afficher le niveau de privilège de chaque application. Triez les applications par niveau souhaité.

   

   Les trois types de niveaux de privilège d’application sont les suivants :

   • Élevé : l’application dispose d’au moins une autorisation à privilèges élevés.
   • Moyen : l’application a au moins une autorisation à privilèges moyens et aucune autorisation à privilèges élevés.
   • Faible : l’application n’a pas de privilèges élevés ou moyens.

   Le niveau de privilège global d’une application est calculé à l’aide du même principe que la gouvernance des applications dans MDA.

   Vous pouvez également sélectionner une application sous la section Toutes les applications et accéder à l’onglet Autorisations pour afficher et examiner les autorisations requises.

   

   Remarque

   Les niveaux de risque d’autorisation et les améliorations de niveau de privilège ne s’appliquent pas aux applications internes (Microsoft).

autorisations Microsoft Entra ID

Microsoft Graph permet aux développeurs d’accéder aux informations et données Microsoft 365 de votre organization, mais uniquement avec les autorisations de Microsoft Entra ID appropriées. Une application déclare ces autorisations à l’avance et les administrateurs doivent consentir à ces autorisations avant que l’application puisse accéder aux informations. Si vous accordez le consentement administrateur à une telle autorisation dans une application Teams, tous les utilisateurs autorisés de votre organisation peuvent utiliser l’application et permettre à l’application d’accéder aux informations de l’organisation. Ces autorisations sont définies dans Microsoft Entra ID portail.

Les développeurs d’applications choisissent les autorisations appropriées à partir d’un large éventail d’API Microsoft Graph afin que les applications obtiennent les informations nécessaires pour fonctionner. Avant d’accorder votre consentement à ces autorisations, vous pouvez afficher les autorisations spécifiques demandées par une application. Il vous aide à évaluer l’impact de l’octroi du consentement aux autorisations d’une application. Pour afficher les autorisations Microsoft Entra ID, procédez comme suit :

1. Accédez au Centre d’administration Teams et ouvrez la pageGérer les applicationsTeams>.

2. Recherchez l’application requise et sélectionnez son nom pour ouvrir la page des détails de l’application.

3. Sélectionnez l’onglet Autorisations et sélectionnez Vérifier les autorisations et le consentement.

4. Dans la boîte de dialogue, affichez les autorisations requises par l’application. Pour plus d’informations sur les informations disponibles dans la boîte de dialogue, consultez les informations disponibles dans l’invite de consentement.

   

Une liste complète de toutes les autorisations possibles est documentée dans la référence des autorisations Microsoft Graph.

Autorisations de consentement spécifiques à la ressource

Les ressources dans Teams peuvent être une équipe, une conversation ou un utilisateur. Utilisez ces autorisations pour permettre aux applications d’accéder uniquement aux informations d’une ressource spécifique. Avec les autorisations RSC, une application n’a pas besoin de demander l’accès aux informations à l’échelle de l’organisation et peut limiter l’étendue de son accès. Définissez ces autorisations RSC dans le fichier manifeste de l’application. Seuls les utilisateurs qui ont accès aux ressources peuvent donner leur consentement à ces autorisations. Les développeurs définissent ces autorisations dans l’application elle-même, dans le fichier manifeste de l’application.

Les autorisations RSC permettent aux utilisateurs de donner leur consentement aux applications pour obtenir des informations spécifiques à l’étendue. Ce consentement permet aux applications d’accéder et de modifier uniquement les informations d’une équipe ou d’une conversation. Une telle application ne peut pas accéder aux informations d’une conversation ou d’une équipe dans laquelle elle n’est pas ajoutée. Parmi les exemples d’autorisations RSC, citons la possibilité de créer et de supprimer des canaux, d’obtenir les paramètres d’une équipe et de créer et de supprimer des onglets de canal.

Les autorisations RSC limitent l’étendue des autorisations d’application à une ressource spécifique, par opposition aux autorisations Graph à l’échelle de l’organisation qui peuvent permettre aux applications d’accéder aux informations à l’échelle de l’organisation. Les ressources sur lesquelles les autorisations RSC peuvent s’appliquer sont les conversations et les réunions, les équipes et les canaux et les utilisateurs.

Définissez les autorisations RSC dans le manifeste de l’application et non dans Microsoft Entra ID. Vous accordez le consentement aux autorisations RSC lorsque vous ajoutez l’application à une équipe. Pour plus d’informations, consultez Consentement spécifique à la ressource (RSC).

Pour afficher les autorisations RSC pour une application, procédez comme suit :

1. Accédez au Centre d’administration Teams et accédez à Applications> TeamsGérer les applications.
2. Recherchez l’application souhaitée, sélectionnez le nom de l’application pour accéder à la page des détails de l’application, puis sélectionnez l’onglet Autorisations .
3. Sous Autorisations de consentement spécifique à la ressource (RSC), passez en revue les autorisations RSC demandées par l’application.

Que peuvent faire les applications dans Teams

Lorsque les développeurs créent des applications Teams, ils utilisent certaines fonctionnalités définies dans l’infrastructure de développement. Ces fonctionnalités sont des fonctionnalités de haut niveau que les applications peuvent avoir. Par exemple, une application peut contenir un bot qui converse avec l’utilisateur. Lorsqu’une application utilise une fonctionnalité, elle obtient automatiquement des privilèges de base. Par exemple, si l’application contenant un bot est autorisée pour un utilisateur, le bot peut envoyer et recevoir des messages. Ces privilèges existent dans les applications en fonction des fonctionnalités que le développeur d’applications a ajoutées à une application et ne sont pas des autorisations qui nécessitent le consentement pour être effectives. Les développeurs ne définissent pas explicitement ces autorisations, mais ces autorisations sont implicitement ajoutées lorsque les développeurs créent des fonctionnalités d’application.

En tant qu’administrateur, vous gérez les applications Teams et non leurs fonctionnalités. Les applications Teams ont des fonctionnalités qui permettent aux applications d’accomplir leur cas d’usage principal et d’accomplir certaines tâches. Les fonctionnalités sont fournies par des Kits de développement logiciel (SDK) et le consentement est implicite lorsque l’application est installée. Les tâches que les applications peuvent accomplir et associées à des fonctionnalités sont différentes des autorisations qui nécessitent le consentement d’un administrateur. En tant qu’administrateur, vous devez réfléchir à ce qu’une application peut faire et à la façon dont elle interagit avec les utilisateurs en fonction des fonctionnalités suivantes.

• Bots et extensions de messagerie
• Onglets
• Connecteurs
• Webhooks sortants

Bots et extensions de messagerie

Considérez les types suivants d’interaction utilisateur, les autorisations requises et l’accès aux données par les bots et les extensions de messagerie :

• Un bot peut recevoir des messages d’utilisateurs et y répondre. Les bots reçoivent uniquement des messages dans les conversations où les utilisateurs mention explicitement un bot par son nom. Ces données quittent le réseau d’entreprise.

• Une fois qu’un utilisateur a envoyé un message à un bot, celui-ci peut lui envoyer des messages directs ou proactifs à tout moment.

• Certains bots envoient uniquement des messages. Ils sont appelés bots de notification uniquement et le bot n’offre pas d’expérience de conversation.

• Un bot ajouté aux équipes peut obtenir une liste de noms et d’ID des canaux d’une équipe.

• Lorsque vous l’utilisez dans un canal, dans une conversation personnelle ou une conversation de groupe, le bot de l’application peut accéder aux informations d’identité de base des membres de l’équipe. Les informations incluent le prénom, le nom, le nom d’utilisateur principal (UPN) et l’adresse e-mail.

• Il est possible que le bot d’une application envoie des messages directs ou proactifs aux membres de l’équipe, même s’ils n’interagissent pas avec le bot.

• Selon les paramètres et le fonctionnement d’une application qui est un bot, elle peut envoyer et recevoir des fichiers uniquement dans une conversation personnelle. Il n’est pas pris en charge pour les conversations de groupe ou les canaux.

• Les bots ont uniquement accès aux équipes auxquelles les bots sont ajoutés ou aux utilisateurs qui ajoutent l’application bots.

• Lorsqu’un utilisateur discute avec un bot, s’il stocke l’ID de l’utilisateur, il peut envoyer les messages directs de l’utilisateur à tout moment.

• Si nécessaire, un utilisateur ou un administrateur peut bloquer un bot. Microsoft peut également supprimer un bot du store. La vérification et les vérifications de validation des applications garantissent que les applications de haute qualité sont disponibles dans le magasin Teams et que les bots ne spammentent pas leurs utilisateurs.

• Un bot peut récupérer et stocker des informations d’identité de base pour les membres de l’équipe auxquels l’application est ajoutée, ou pour des utilisateurs individuels dans des conversations personnelles ou de groupe. Pour obtenir plus d’informations sur ces utilisateurs, le bot doit exiger qu’ils se connectent à Microsoft Entra ID.

• Les bots peuvent récupérer et stocker la liste des canaux dans une équipe. Ces données quittent le réseau d’entreprise.

• Par défaut, les bots n’ont pas la possibilité d’agir au nom de l’utilisateur, mais les bots peuvent demander aux utilisateurs de se connecter. Dès que l’utilisateur se connecte, le bot dispose d’un jeton d’accès avec lequel il peut effectuer d’autres tâches. Les tâches dépendent du bot et de l’emplacement où l’utilisateur se connecte : un bot est une application Microsoft Entra inscrite sur https://apps.dev.microsoft.com/ et peut avoir son propre ensemble d’autorisations.

• Lorsqu’un fichier est envoyé à un bot, le fichier quitte le réseau d’entreprise. L’envoi et la réception de fichiers nécessitent l’approbation de l’utilisateur pour chaque fichier.

• Les bots sont informés chaque fois que des utilisateurs sont ajoutés ou supprimés d’une équipe.

• Les bots ne voient pas les adresses IP des utilisateurs ou d’autres informations de référence. Toutes les informations proviennent de Microsoft. (Il existe une exception : si un bot implémente sa propre expérience de connexion, l’interface utilisateur de connexion voit les adresses IP des utilisateurs et les informations de référence.)

• En revanche, les extensions de messagerie peuvent voir les adresses IP des utilisateurs et les informations de référence.

Onglets

Un onglet est un site web s’exécutant dans Teams. Il peut s’agir d’un onglet dans une réunion, d’une conversation ou d’un canal.

Considérez les types suivants d’interaction utilisateur ou d’accès aux données pour les onglets :

• Les utilisateurs qui ouvrent un onglet dans un navigateur ou dans Teams sont exactement identiques. Le site web lui-même ne peut accéder à aucune information de organization seul.

• Un onglet obtient également le contexte dans lequel il s’exécute, y compris le nom de connexion et l’UPN de l’utilisateur actuel, l’ID d’objet Microsoft Entra de l’utilisateur actuel, l’ID du groupe Microsoft 365 dans lequel il réside (s’il s’agit d’une équipe), l’ID de locataire et les paramètres régionaux actuels de l’utilisateur. Toutefois, pour mapper ces ID aux informations d’un utilisateur, l’onglet doit faire en sorte que l’utilisateur se connecte à Entra ID.

Connecteurs

Un connecteur publie des messages sur un canal lorsque des événements se produisent dans un système externe. L’autorisation requise pour les connecteurs est la possibilité de publier des messages dans un canal. Une autorisation facultative pour les connecteurs est l’autorisation de répondre à un message. Certains connecteurs prennent en charge les messages actionnables, qui permettent aux utilisateurs de publier des réponses ciblées au message du connecteur. Par exemple, en ajoutant une réponse à un problème GitHub ou en ajoutant une date à un carte Trello. Considérez les types suivants d’interaction utilisateur, les autorisations requises et l’accès aux données par les connecteurs :

• Le système qui publie des messages de connecteur ne sait pas à qui il publie ou qui reçoit les messages. Aucune information sur le destinataire n’est divulguée. Microsoft est le destinataire réel et non le organization. Microsoft effectue la publication réelle sur le canal.

• Aucune donnée ne quitte le réseau d’entreprise lorsque les connecteurs publient des messages dans un canal.

• Les connecteurs qui prennent en charge les messages actionnables ne voient pas non plus les informations d’adresse IP et de référent ; Microsoft reçoit ces informations, puis les achemine vers des points de terminaison HTTP précédemment inscrits auprès de Microsoft dans le portail Connecteurs.

• Chaque fois qu’un connecteur est configuré pour un canal, une URL unique pour ce connecteur instance est créée. Si vous supprimez ce connecteur instance, vous ne pouvez pas utiliser l’URL.

• Les messages du connecteur ne peuvent pas contenir de pièces jointes.

• Traitez l’URL du connecteur instance comme étant secrète ou confidentielle. Toute personne disposant de l’URL peut publier sur celle-ci. Si nécessaire, les propriétaires d’équipe peuvent supprimer le connecteur instance.

• Si nécessaire, un administrateur peut empêcher la création de nouvelles instances de connecteur et Microsoft peut bloquer toute utilisation d’une application Connecteur.

Webhooks sortants

Les propriétaires d’équipe ou les membres de l’équipe créent des webhooks sortants. Les webhooks sortants reçoivent des messages des utilisateurs et y répondent. Considérez les types suivants d’interaction utilisateur, les autorisations requises et l’accès aux données par les webhooks sortants :

• Les webhooks sortants sont similaires aux bots, mais ont moins de privilèges. Ils doivent être mentionnés explicitement, tout comme les bots.

• Lorsque vous inscrivez un webhook sortant, le processus génère un secret. Ce secret permet au webhook sortant de vérifier que l’expéditeur est Teams par opposition à un attaquant malveillant. Gardez ce secret ; Toute personne qui y a accès peut emprunter l’identité de Teams. Si le secret est compromis, supprimez et recréez le webhook sortant pour générer un nouveau secret.

• Bien qu’il soit possible de créer un webhook sortant qui ne valide pas le secret, nous vous recommandons de le faire.

• Outre la réception et la réponse aux messages, les webhooks sortants ne peuvent pas faire grand-chose : ils ne peuvent pas envoyer de messages de manière proactive, ils ne peuvent pas envoyer ou recevoir des fichiers, et ils ne peuvent rien faire d’autre que les bots peuvent faire, sauf recevoir et répondre aux messages.

Articles connexes

• Accordez et gérez le consentement aux autorisations d’application Teams.
• Informations de référence sur les autorisations Microsoft Graph, y compris les autorisations RSC.