Comprendre les autorisations des applications Teams et les informations auxquelles elles accèdent
En fonction de leurs fonctionnalités, les applications Teams peuvent ou non 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.
Les autorisations permettent aux applications d’accéder à des ressources privilégiées et d’agir au nom de l’utilisateur. Cela 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 étendue et leurs implications. Nous fournissons toutes les autorisations d’une application et ses informations détaillées dans la page détails de l’application dans le Centre d’administration Teams.
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 :
- Les développeurs d’applications déclarent des autorisations et des fonctionnalités d’application lorsqu’ils créent des applications.
- Les administrateurs comprennent et analysent les autorisations requises par l’application dans les portails d’administration.
- L’accès aux données est accordé de deux manières. Lorsque l’application est ajoutée à Teams, elle a accès à certaines fonctionnalités de base qui peuvent inclure l’accès aux informations de base. Lors de l’octroi du consentement, une application reçoit l’accès à certaines données d’utilisateur et de 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 lui-même.
- 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écessitait des autorisations d’application. Une application si le consentement est accordé est en mesure d’accéder aux données auxquelles l’autorisation est associée.
| Administration considération | Autorisations déléguées | Autorisations d’application |
|---|---|---|
| Comment les applications peuvent-elles accéder aux informations ? | Au nom d’un utilisateur connecté. | Par eux-mêmes, en utilisant leur propre identité. |
| Quelles informations sont accessibles | Autorisations auxquelles l’application reçoit le consentement et informations associées à cette autorisation auxquelles l’utilisateur connecté a accès. | Toutes les informations auxquelles une autorisation consentée est associée |
| Quels rôles peuvent donner leur consentement | Administrateurs ou utilisateurs ou propriétaires de groupes selon Microsoft Entra ID configuration | Uniquement les administrateurs |
| Les utilisateurs peuvent-ils donner leur consentement ? | Les utilisateurs peuvent donner leur consentement en fonction de la configuration Microsoft Entra ID | Seuls les administrateurs peuvent donner leur consentement |
Pour chaque application, ses autorisations sont répertoriées dans la page détails de l’application dans le centre d’administration.
| Type d’autorisation d’application | Contexte d’accès | Source de déclaration | Quand le consentement est-il requis ? | Qui peut donner son consentement ? |
|---|---|---|---|---|
| Microsoft Entra ID pour l’accès à Graph et aux points de terminaison hérités | Délégué | Microsoft Entra ID | Connexion à l’application | Administration globale, Administration cloud et Administration d’application |
| Microsoft Entra ID pour l’accès à Graph et aux points de terminaison hérités | Application | Microsoft Entra ID | Connexion à l’application | Administration globale, Administration cloud et Administration d’application |
| RSC pour les informations sur les équipes, les conversations et les utilisateurs | Délégué | Fichier manifeste de l’application | Ajout d’une application à une équipe, conversation, réunions | Propriétaire de la ressource |
| RSC pour les informations sur les équipes, les conversations et les utilisateurs | Application | Fichier manifeste de l’application | Ajout d’une application à une équipe, conversation, réunions | Propriétaire de la ressource |
| Autres autorisations et accès aux données | Délégué via des kits SDK | Les propriétés du manifeste le définissent | Ajouter une application dans un client | Le consentement est implicite lors de l’installation |
Nous vous recommandons d’utiliser un rôle de privilège inférieur 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
Vous trouverez les détails de tous les types d’autorisations demandées par une application sous l’onglet Autorisations de la page détails de l’application. Si vous le souhaitez, vous pouvez également télécharger toutes les autorisations dans un fichier .csv pour une analyse plus approfondie.
- R : Toutes les autorisations d’application de l’application.
- B : Toutes les autorisations déléguées de l’application.
- C : Fonctionnalités de base et interactions avec les utilisateurs et les données auxquels les applications accèdent
Pour savoir comment vous pouvez autoriser l’utilisation d’une application, consultez Accorder et gérer le consentement aux autorisations d’application Teams.
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 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 :
Accédez au Centre d’administration Teams et ouvrez la pageGérer les applicationsTeams>.
Recherchez l’application requise et sélectionnez son nom pour ouvrir la page des détails de l’application.
Sélectionnez l’onglet Autorisations et sélectionnez Vérifier les autorisations et le consentement.
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. L’utilisation de ces autorisations permet aux applications d’accéder uniquement aux informations d’une ressource spécifique. En utilisant des 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. Ces autorisations RSC sont définies dans le fichier manifeste de l’application. Seuls les utilisateurs qui ont accès aux ressources peuvent donner leur consentement pour 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.
Les autorisations RSC sont définies 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 le consentement spécifique à la ressource (RSC).
Pour afficher les autorisations RSC pour une application, procédez comme suit :
- Accédez au Centre d’administration Teams et accédez à Applications> TeamsGérer les applications.
- 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 .
- 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é, certains privilèges de base lui sont automatiquement accordés. 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.
Remarque
Les applications peuvent ne pas utiliser toutes les fonctionnalités ci-dessous, sauf s’il s’agit d’une application complexe répondant à plusieurs cas d’usage. Les tâches que l’application peut effectuer dépendent des fonctionnalités utilisées par le développeur de l’application.
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’ont pas interagi 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.
Remarque
- Si un bot a sa propre connexion, il existe une expérience de consentement différente la première fois que l’utilisateur se connecte.
- Les utilisateurs peuvent rechercher des applications avec le
botIdqui était disponible dans l’application. Les utilisateurs peuvent afficher le nom de l’application, mais ils ne peuvent pas interagir avec ces bots.
Onglets
Un onglet est un site web s’exécutant dans Teams. Il peut s’agir d’un onglet dans une réunion, une conversation ou 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 pas avoir accès à des informations 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 à Microsoft 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 de pouvoir publier des messages dans le 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 ; Ces informations sont envoyées à Microsoft, puis acheminées 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 cette instance de connecteur est supprimée, l’URL ne peut plus être utilisée.
Les messages du connecteur ne peuvent pas contenir de pièces jointes.
L’URL instance connecteur doit être traitée comme 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 peuvent recevoir des messages d’utilisateurs et y répondre. 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.
Lorsqu’un webhook sortant est inscrit, un secret est généré, ce qui permet au webhook sortant de vérifier que l’expéditeur est Microsoft Teams par opposition à un attaquant malveillant. Ce secret doit rester un secret ; toute personne qui y a accès peut emprunter l’identité de Microsoft 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 de fichiers, ils ne peuvent rien faire d’autre que recevoir et répondre aux messages.