Entender as permissões de e as informações acessadas pelos aplicativos do Teams

  • Artigo
  • Aplica-se a:
    Microsoft Teams

Dependendo da funcionalidade, os aplicativos do Teams podem ou não acessar as informações do usuário ou da sua organização para funcionar conforme o planejado.

  • Alguns aplicativos que não buscam acesso às informações da organização e, portanto, não exigem nenhuma aprovação. Os usuários podem usar esses aplicativos sem aprovação de administrador ou consentimento, pois as informações da organização são protegidas desses aplicativos.
  • Alguns aplicativos exigem que as informações da sua organização ou do usuário funcionem ou processem as informações. Esses aplicativos não podem funcionar a menos que você permita que esse aplicativo acesse as informações da organização.

Você deve avaliar as informações de conformidade, segurança e tratamento de dados de um aplicativo e também entender as permissões solicitadas pelo aplicativo antes de permitir que um aplicativo seja usado por seus usuários. Para fazer isso, você precisa entender sobre permissões, consentimento e os controles disponíveis para você.

Como os aplicativos acessam as informações da organização

O Teams fornece proteções para que as informações da sua organização ou do usuário não possam ser acessadas sem o seu consentimento. Para que um aplicativo acesse qualquer informação, as seguintes ações devem acontecer:

  1. Os desenvolvedores de aplicativos declaram permissões e recursos de aplicativo quando criam aplicativos.
  2. Os administradores entendem e analisam as permissões exigidas pelo aplicativo em portais de administração.
  3. O acesso a dados é concedido de duas maneiras. Quando o aplicativo é adicionado ao Teams, ele recebe acesso a alguns recursos básicos que podem incluir acesso a informações básicas. Ao conceder o consentimento, um aplicativo recebe acesso a alguns dados de usuário e organização ou ambos, com base nas permissões de aplicativo para as quais ele solicitou consentimento.

Tipos de permissões e sua fonte de declaração

As permissões de aplicativo do Teams podem ser dos três tipos a seguir com base no escopo.

  • Microsoft Entra ID permissões: o Microsoft Graph permite que os desenvolvedores acessem as informações e dados do Microsoft 365 da sua organização, mas apenas com as permissões de Microsoft Entra ID apropriadas. Um aplicativo declara essas permissões antecipadamente e os administradores devem consentir com essas permissões antes que o aplicativo possa acessar as informações. Se você conceder o consentimento do administrador a essa permissão em um aplicativo do Teams, todos os usuários permitidos da sua organização poderão usar o aplicativo e permitir que o aplicativo acesse as informações da organização. Essas permissões são definidas no portal Microsoft Entra ID.

  • RSC (permissões específicas do recurso): os recursos no Teams podem ser uma equipe, um chat ou um usuário. O uso dessas permissões permite que os aplicativos acessem as informações de apenas um recurso específico. Usando permissões RSC, um aplicativo não precisa solicitar acesso a informações de toda a organização e pode limitar o escopo de seu acesso. Essas permissões RSC são definidas no arquivo de manifesto do aplicativo. Somente os usuários que têm acesso aos recursos podem consentir com essas permissões. Os desenvolvedores definem essas permissões no próprio aplicativo, no arquivo de manifesto do aplicativo.

  • Recursos básicos: quando os desenvolvedores criam aplicativos do Teams, eles usam alguns recursos definidos na estrutura de desenvolvimento. Essas funcionalidades são funcionalidades de alto nível que os aplicativos podem ter. Por exemplo, um aplicativo pode conter um bot que conversa com o usuário. Quando um aplicativo usa uma funcionalidade, ele recebe automaticamente alguns privilégios básicos. Por exemplo, se o aplicativo que contém um bot for permitido para um usuário, o bot poderá enviar e receber mensagens. Esses privilégios existem em aplicativos com base em qual funcionalidade o desenvolvedor de aplicativos adicionou a um aplicativo e não são permissões que exigem consentimento para serem eficazes. Os desenvolvedores não definem explicitamente essas permissões, mas essas permissões são adicionadas implicitamente quando os desenvolvedores criam qualquer funcionalidade de aplicativo.

Com base nas maneiras pelas quais um aplicativo pode acessar as informações da organização, há dois tipos de permissões:

  • Acesso delegado: um aplicativo acessa o recurso em nome do usuário. Esse acesso requer permissões delegadas. O aplicativo pode acessar apenas as informações que o usuário pode acessar por conta própria.
  • Acesso somente aplicativo: um aplicativo atua por conta própria sem que nenhum usuário entre, quando é indesejável ter um usuário específico conectado ou quando os dados necessários não podem ser escopo para um único usuário. Esse acesso exigia permissões de aplicativos. Um aplicativo, se concedido o consentimento, poderá acessar dados aos quais a permissão está associada.
Administração conscientização Permissões delegadas Permissões de aplicativo
Como os aplicativos podem acessar informações Em nome de um usuário conectado. Por conta própria, usando sua própria identidade.
Quais informações são acessadas Permissões às quais o aplicativo recebe consentimento e as informações associadas a essa permissão às quais o usuário conectado tem acesso. Qualquer informação com a qual uma permissão consentida está associada
Quais funções podem consentir Administradores ou usuários ou proprietários de grupo, dependendo da configuração de Microsoft Entra ID Somente administradores
Os usuários podem consentir Os usuários podem consentir dependendo Microsoft Entra ID configuração Somente administradores podem consentir

Para cada aplicativo, essas permissões são listadas na página de detalhes do aplicativo no centro de administração.

Tipo de permissão do aplicativo Contexto de acesso Fonte de declaração Quando o consentimento é necessário? Quem pode consentir? Comentários
Microsoft Entra ID para o Graph e o acesso ao ponto de extremidade herdado Delegada Microsoft Entra ID Entrada do aplicativo Administração global, Administração de nuvem e Administração de aplicativos Consulte Microsoft Entra ID permissões necessárias pelos aplicativos do Teams.
Microsoft Entra ID para o Graph e o acesso ao ponto de extremidade herdado Aplicativo Microsoft Entra ID Entrada do aplicativo Administração global, Administração de nuvem e Administração de aplicativos Consulte as permissões do Microsoft Graph exigidas pelos aplicativos do Teams.
RSC para informações de equipes, chats e usuários Delegada Arquivo de manifesto do aplicativo Adicionar aplicativo a uma equipe, chat, reuniões Proprietário do recurso Consulte permissões RSC.
RSC para informações de equipes, chats e usuários Aplicativo Arquivo de manifesto do aplicativo Adicionar aplicativo a uma equipe, chat, reuniões Proprietário do recurso Consulte permissões RSC.
Outras permissões e acesso a dados Delegado por meio de SDKs Propriedades de manifesto definem Adicionar aplicativo em um cliente O consentimento está implícito na instalação Disponível na guia na página de detalhes do Permissions aplicativo de cada aplicativo. Mais detalhes estão aqui.

Onde os administradores podem ver todas as permissões de um aplicativo

Você pode encontrar os detalhes de todos os tipos de permissões solicitadas por um aplicativo na guia Permissões da página de detalhes do aplicativo.

Captura de tela mostrando a página no centro de administração que lista e solicita permissões para um aplicativo e também permite que os administradores concedam consentimento para essas permissões para todos os usuários da organização.

Nota

Para saber como você pode permitir o uso de um aplicativo concedendo consentimento às suas permissões, confira conceder e gerenciar o consentimento para permissões de aplicativo do Teams.

Microsoft Entra ID permissões

Os desenvolvedores de aplicativos escolhem permissões apropriadas de uma ampla variedade de APIs do Graph para que os aplicativos obtenham as informações necessárias para funcionar. Antes de conceder o consentimento a essas permissões, você pode exibir as permissões específicas solicitadas por um aplicativo. Ele ajuda você a avaliar o impacto da concessão de consentimento para as permissões de um aplicativo. Para exibir as permissões de Microsoft Entra ID, siga estas etapas:

  1. Acesse o centro de administração do Teams e abra a páginaGerenciar aplicativos> do Teams.

  2. Pesquise o aplicativo necessário e selecione seu nome para abrir a página de detalhes do aplicativo.

  3. Selecione Guia Permissões e selecione Examinar permissões e consentimento.

  4. Na caixa de diálogo, exiba as permissões necessárias pelo aplicativo. Para obter mais informações sobre as informações disponíveis na caixa de diálogo, consulte informações disponíveis no prompt de consentimento.

    Captura de tela das permissões solicitadas por um aplicativo.

Uma lista completa de todas as permissões possíveis está documentada na referência de permissões do Microsoft Graph.

As permissões RSC permitem que os usuários dêem consentimento aos aplicativos para obter informações específicas do escopo. Esse consentimento permite que os aplicativos acessem e modifiquem apenas as informações de uma equipe ou de um chat. Esse aplicativo não pode acessar as informações de um chat ou de uma equipe na qual não é adicionado. Exemplos de permissões RSC incluem a capacidade de criar e excluir canais, obter as configurações de uma equipe e criar e remover guias de canal.

As permissões RSC limitam o escopo das permissões do aplicativo a um recurso específico em oposição às permissões do Graph em toda a organização que podem permitir que os aplicativos acessem informações em toda a organização. Os recursos nos quais as permissões RSC podem ser aplicadas são chats e reuniões, equipes e canais e usuários.

As permissões RSC são definidas no manifesto do aplicativo e não em Microsoft Entra ID. Você concede consentimento a permissões RSC ao adicionar o aplicativo a uma equipe. Para saber mais, confira RSC (consentimento específico de recurso).

Para exibir as permissões RSC para um aplicativo, siga estas etapas:

  1. Acesse o centro de administração do Teams e acesse aplicativos >do TeamsGerenciar aplicativos.

  2. Pesquise o aplicativo desejado, selecione o nome do aplicativo para acessar a página de detalhes do aplicativo e selecione a guia Permissões .

  3. Em permissões RSC (consentimento específico do recurso), examine as permissões RSC solicitadas pelo aplicativo.

    Captura de tela mostrando um exemplo de como exibir permissões RSC de um aplicativo.

O que os aplicativos podem fazer no Teams

Como administrador, você gerencia aplicativos do Teams e não suas funcionalidades. Os aplicativos do Teams têm recursos que permitem que os aplicativos realizem seu caso de uso principal e realizem algumas tarefas. Os recursos são fornecidos por SDKs e o consentimento é implícito quando o aplicativo é instalado. As tarefas que os aplicativos podem realizar associadas aos recursos são diferentes das permissões que exigem consentimento de um administrador. Você como administrador deve considerar o que um aplicativo pode fazer e como ele interage com os usuários com base nos recursos a seguir.

Nota

Os aplicativos podem não usar todos os recursos abaixo, a menos que o aplicativo seja um aplicativo complexo que atende a vários casos de uso. As tarefas que o aplicativo pode fazer dependem dos recursos usados nele pelo desenvolvedor do aplicativo.

Bots e extensões de mensagens

Considere os seguintes tipos de interação do usuário, permissões necessárias e acesso a dados por bots e extensões de mensagens:

  • Um bot pode receber mensagens dos usuários e responder a eles. Os bots só recebem mensagens em chats em que os usuários menção explicitamente um bot pelo nome. Esses dados saem da rede corporativa.

  • Depois que um usuário envia uma mensagem para um bot, o bot pode enviar mensagens diretas ou proativas ao usuário a qualquer momento.

  • Alguns bots só enviam mensagens. Eles são chamados de bots somente notificação e o bot não oferece uma experiência de conversa.

  • Um bot adicionado às equipes pode obter uma lista de nomes e IDs dos canais em uma equipe.

  • Ao usá-lo em um canal, em um chat pessoal ou em um chat em grupo, o bot do aplicativo pode acessar informações básicas de identidade dos membros da equipe (nome, sobrenome, nome da entidade de usuário [UPN]e endereço de email).

  • É possível que o bot de um aplicativo envie mensagens diretas ou proativas aos membros da equipe, mesmo que eles não tenham interagido com o bot.

  • Dependendo das configurações e do funcionamento de um aplicativo que é um bot, ele pode enviar e receber arquivos somente em chat pessoal. Não há suporte para chats ou canais de grupo.

  • Os bots só têm acesso às equipes às quais os bots são adicionados ou aos usuários que adicionam o aplicativo de bots.

  • Quando um usuário conversa com um bot, se o bot armazena a ID do usuário, ele pode enviar mensagens diretas ao usuário a qualquer momento.

  • Se necessário, um usuário ou um administrador pode bloquear um bot. A Microsoft também pode remover um bot da loja. Verificações de verificação e validação de aplicativo garantem que aplicativos de alta qualidade estejam disponíveis na loja do Teams e que os bots não spam seus usuários.

  • Um bot pode recuperar e armazenar informações básicas de identidade para os membros da equipe aos quais o aplicativo é adicionado ou para usuários individuais em chats pessoais ou em grupo. Para obter mais informações sobre esses usuários, o bot deve exigir que eles entrem no Microsoft Entra ID.

  • Os bots podem recuperar e podem armazenar a lista de canais em uma equipe. Esses dados saem da rede corporativa.

  • Por padrão, os bots não têm a capacidade de agir em nome do usuário, mas os bots podem pedir aos usuários para entrar; assim que o usuário entra, o bot tem um token de acesso com o qual pode fazer outras tarefas. As tarefas dependem do bot e de onde o usuário entra: um bot é um aplicativo Microsoft Entra registrado https://apps.dev.microsoft.com/ e pode ter seu próprio conjunto de permissões.

  • Quando um arquivo é enviado para um bot, o arquivo sai da rede corporativa. Enviar e receber arquivos requer aprovação do usuário para cada arquivo.

  • Os bots são informados sempre que os usuários são adicionados ou excluídos de uma equipe.

  • Os bots não veem os endereços IP dos usuários ou outras informações do referenciador. Todas as informações são provenientes da Microsoft. (Há uma exceção: se um bot implementar sua própria experiência de entrada, a interface do usuário de entrada verá os endereços IP dos usuários e as informações do referenciador.)

  • As extensões de mensagens, por outro lado, podem ver os endereços IP dos usuários e as informações do referenciador.

Nota

  • Se um bot tiver sua própria entrada, haverá uma experiência de consentimento diferente na primeira vez que o usuário entrar.
  • Os usuários podem pesquisar aplicativos com o botId que estava disponível no aplicativo. Enquanto os usuários podem exibir o nome do aplicativo, mas não podem interagir com esses bots.

Guias

Uma guia é um site em execução no Teams. Pode ser como uma guia em uma reunião, um chat ou um canal.

Considere os seguintes tipos de interação do usuário ou acesso de dados para Guias:

  • Os usuários que abriram uma guia em um navegador ou no Teams são exatamente os mesmos. O próprio site não pode ter acesso às informações de qualquer organização por conta própria.

  • Uma guia também obtém o contexto em que está em execução, incluindo o nome de entrada e UPN do usuário atual, a ID do objeto Microsoft Entra para o usuário atual, a ID do grupo Microsoft 365 no qual ele reside (se for uma equipe), a ID do locatário e a localidade atual do usuário. No entanto, para mapear essas IDs para as informações de um usuário, a guia teria que fazer com que o usuário entre no Microsoft Entra ID.

Conectores

Um conector posta mensagens em um canal quando ocorrem eventos em um sistema externo. A permissão necessária para Conectores é poder postar mensagens no canal. Uma permissão opcional para Conectores é a permissão para responder a uma mensagem. Alguns conectores dão suporte a mensagens acionáveis, que permitem que os usuários postem respostas direcionadas à mensagem do conector. Por exemplo, adicionando uma resposta a um problema do GitHub ou adicionando uma data a um cartão do Trello. Considere os seguintes tipos de interação do usuário, permissões necessárias e acesso a dados por Conectores:

  • O sistema que posta mensagens do conector não sabe para quem está postando ou quem recebe as mensagens. Nenhuma informação sobre o destinatário é divulgada. A Microsoft é o destinatário real e não a organização. A Microsoft faz a postagem real no canal.

  • Nenhum dado sai da rede corporativa quando conectores postam mensagens em um canal.

  • Os conectores que dão suporte a mensagens acionáveis também não veem informações de endereço IP e de referenciador; essas informações são enviadas para a Microsoft e roteada para pontos de extremidade HTTP que foram registrados anteriormente com a Microsoft no portal conectores.

  • Sempre que um Conector é configurado para um canal, uma URL exclusiva para essa instância do conector é criada. Se essa instância do conector for excluída, a URL não poderá mais ser usada.

  • As mensagens do conector não podem conter anexos de arquivo.

  • A URL da instância do Conector deve ser tratada como secreta ou confidencial. Qualquer pessoa que tenha a URL pode postar nela. Se necessário, os proprietários da equipe podem excluir a instância do conector.

  • Se necessário, um administrador pode impedir que novas instâncias do Conector sejam criadas e a Microsoft poderá bloquear todo o uso de um aplicativo Connector.

Webhooks de saída

Proprietários de equipe ou membros da equipe criam webhooks de saída. Webhooks de saída podem receber mensagens dos usuários e responder a eles. Considere os seguintes tipos de interação do usuário, permissões necessárias e acesso a dados por webhooks de saída:

  • Os webhooks de saída são semelhantes aos bots, mas têm menos privilégios. Eles devem ser mencionados explicitamente, assim como os bots.

  • Quando um webhook de saída é registrado, um segredo é gerado, o que permite que o webhook de saída verifique se o remetente é o Microsoft Teams em vez de um invasor mal-intencionado. Esse segredo deve permanecer um segredo; qualquer pessoa que tenha acesso a ele pode representar o Microsoft Teams. Se o segredo estiver comprometido, exclua e recrie o webhook de saída para gerar um novo segredo.

  • Embora seja possível criar um webhook de saída que não valide o segredo, não recomendamos isso.

  • Além de receber e responder a mensagens, os webhooks de saída não podem fazer muito: eles não podem enviar mensagens proativamente, não podem enviar ou receber arquivos, não podem fazer mais nada que os bots possam fazer, exceto receber e responder a mensagens.