Compartilhar via

Compreender as permissões e as informações acedidas pelas aplicações do Teams

  • Artigo
  • Aplica-se a:
    Microsoft Teams

Consoante as respetivas funcionalidades, as aplicações do Teams podem ou não aceder às informações do utilizador ou da sua organização para funcionarem conforme pretendido.

  • Algumas aplicações não procuram acesso às informações da organização e, por conseguinte, não necessitam de aprovação. Os utilizadores podem utilizar essas aplicações sem aprovação ou consentimento do administrador, uma vez que as informações da organização estão protegidas a partir dessas aplicações.
  • Algumas aplicações requerem que as informações da sua organização ou do utilizador funcionem ou processem as informações. Estas aplicações não podem funcionar, a menos que permita que essa aplicação aceda às informações da sua organização.

Tem de avaliar as informações de conformidade, segurança e processamento de dados de uma aplicação e também compreender as permissões pedidas pela aplicação antes de permitir que uma aplicação seja utilizada pelos seus utilizadores. Para tal, tem de compreender as permissões, o consentimento e os controlos disponíveis para si.

Como as aplicações acedem às informações da organização através de permissões

O Teams fornece salvaguardas para que as informações da sua organização ou do utilizador não possam ser acedidas sem o seu consentimento. Para que uma aplicação aceda a qualquer informação, têm de ocorrer as seguintes ações:

  1. Os programadores de aplicações declaram permissões e capacidades de aplicações quando criam aplicações.
  2. Os administradores compreendem e analisam as permissões exigidas pela aplicação nos portais de administração.
  3. O acesso a dados é concedido de duas formas. Quando a aplicação é adicionada ao Teams, é concedido acesso a algumas funcionalidades básicas que podem incluir acesso a informações básicas. Após conceder consentimento, uma aplicação recebe acesso a alguns dados do utilizador e da organização ou a ambos, com base nas permissões da aplicação para as quais pediu consentimento.

Compreender o acesso a dados por aplicações e as permissões necessárias

Uma aplicação pode aceder às informações de uma organização das duas formas seguintes:

  • Acesso delegado: uma aplicação acede ao recurso em nome do utilizador. Este acesso requer permissões delegadas. A aplicação só pode aceder às informações a que o utilizador pode aceder.
  • Acesso à aplicação: uma aplicação age por si só sem qualquer utilizador com sessão iniciada, quando é indesejável ter um utilizador específico com sessão iniciada ou quando os dados necessários não podem ser confinados a um único utilizador. Este acesso requer permissões de aplicações. Uma aplicação, se for concedida autorização, poderá aceder aos dados aos quais a permissão está associada.
Consideração do administrador Permissões delegadas Permissões de aplicação
Como é que as aplicações podem aceder a informações Em nome de um utilizador com sessão iniciada. Por si só, com a sua própria identidade.
Que informações são acedidas As permissões às quais a aplicação tem consentimento e as informações associadas a essa permissão às quais o utilizador com sessão iniciada tem acesso. Todas as informações às quais uma permissão consentida está associada
Que funções podem consentir Administradores, utilizadores ou proprietários de grupos, consoante a configuração do ID do Microsoft Entra Apenas administradores
Os utilizadores podem consentir Os utilizadores podem consentir consoante a configuração do Microsoft Entra ID Apenas os administradores podem consentir

Para cada aplicação, as respetivas permissões são listadas na página de detalhes da aplicação no centro de administração.

Tipo de permissão de aplicação Contexto de acesso Origem da declaração Quando é necessário o consentimento? Quem pode consentir?
Microsoft Entra ID para Graph e acesso a pontos finais legados Delegado Microsoft Entra ID Início de sessão da aplicação Administrador Global, Administrador da Cloud e Administrador de Aplicações
Microsoft Entra ID para Graph e acesso a pontos finais legados Aplicativo Microsoft Entra ID Início de sessão da aplicação Administrador Global, Administrador da Cloud e Administrador de Aplicações
RSC para obter informações sobre equipas, conversas e utilizadores Delegado Ficheiro de manifesto da aplicação Adicionar uma aplicação a uma equipa, conversar por chat, reuniões Proprietário do recurso
RSC para obter informações sobre equipas, conversas e utilizadores Aplicativo Ficheiro de manifesto da aplicação Adicionar uma aplicação a uma equipa, conversar por chat, reuniões Proprietário do recurso
Outras permissões e acesso a dados Delegado através de SDKs As propriedades do manifesto definem-no Adicionar uma aplicação num cliente O consentimento está implícito na instalação

Onde podem os administradores ver todas as permissões de uma aplicação

Pode encontrar os detalhes de todos os tipos de permissões pedidos por uma aplicação no separador Permissões da página de detalhes da aplicação. Opcionalmente, também pode transferir todas as permissões num ficheiro de .csv para uma análise mais aprofundada.

Captura de ecrã a mostrar a página no centro de administração que lista e pede permissões para uma aplicação e também permite que os administradores concedam consentimento para essas permissões para todos os utilizadores da organização.

Para saber como pode permitir a utilização de uma aplicação, veja Conceder e gerir o consentimento das permissões da aplicação Teams.

Permissões de ID do Microsoft Entra

O Microsoft Graph permite que os programadores acedam às informações e dados do Microsoft 365 da sua organização, mas apenas com as permissões adequadas do Microsoft Entra ID. Uma aplicação declara estas permissões antecipadamente e os administradores têm de dar consentimento a estas permissões para que a aplicação possa aceder às informações. Se conceder consentimento do administrador a essa permissão numa aplicação do Teams, todos os utilizadores permitidos da sua organização podem utilizar a aplicação e permitir que a aplicação aceda às informações da organização. Estas permissões são definidas no portal do Microsoft Entra ID.

Os programadores de aplicações escolhem as permissões adequadas de uma grande variedade de Graph APIs para que as aplicações obtenham as informações necessárias para funcionarem. Antes de conceder consentimento a estas permissões, pode ver as permissões específicas pedidas por uma aplicação. Ajuda-o a avaliar o impacto da concessão de consentimento às permissões de uma aplicação. Para ver as permissões do ID do Microsoft Entra, siga estes passos:

  1. Aceda ao centro de administração do Teams e abra a páginaGerir aplicações das aplicações> do Teams.

  2. Procure a aplicação necessária e selecione o respetivo nome para abrir a página de detalhes da aplicação.

  3. Selecione o separador Permissões e selecione Rever permissões e consentimento.

  4. Na caixa de diálogo, veja as permissões exigidas pela aplicação. Para obter mais informações sobre as informações disponíveis na caixa de diálogo, veja as informações disponíveis no pedido de consentimento.

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

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

Os recursos no Teams podem ser uma equipa, uma conversa ou um utilizador. A utilização destas permissões permite que as aplicações acedam às informações de apenas um recurso específico. Com as permissões RSC, uma aplicação não tem de pedir acesso a informações ao nível da organização e pode limitar o âmbito do respetivo acesso. Estas permissões RSC são definidas no ficheiro de manifesto da aplicação. Apenas os utilizadores que têm acesso aos recursos podem consentir estas permissões. Os programadores definem estas permissões na própria aplicação, no ficheiro de manifesto da aplicação.

As permissões RSC permitem que os utilizadores dêem consentimento às aplicações para obterem informações específicas do âmbito. Este consentimento permite que as aplicações acedam e modifiquem apenas as informações de uma equipa ou de uma conversa. Esta aplicação não consegue aceder às informações de um chat ou de uma equipa na qual não é adicionada. 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 âmbito das permissões da aplicação a um recurso específico em oposição às permissões do Graph em toda a organização que podem permitir que as aplicações acedam a informações ao nível da organização. Os recursos nos quais as permissões RSC podem ser aplicadas são chats e reuniões, equipas e canais e utilizadores.

As permissões RSC são definidas no manifesto da aplicação e não no ID do Microsoft Entra. 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. Aceda ao centro de administração do Teams e aceda a Aplicações> do TeamsGerir aplicações.
  2. Procure a aplicação que pretende, selecione o nome da aplicação para aceder à página de detalhes da aplicação e, em seguida, selecione o separador Permissões .
  3. Em Permissões de consentimento específico do recurso (RSC), reveja as permissões RSC pedidas pela aplicação.

O que as aplicações podem fazer no Teams

Quando os programadores criam aplicações do Teams, utilizam algumas capacidades definidas na arquitetura de desenvolvimento. Estas capacidades são funcionalidades de alto nível que as aplicações podem ter. Por exemplo, uma aplicação pode conter um bot que converse com o utilizador. Quando uma aplicação utiliza uma capacidade, são-lhe concedidos automaticamente alguns privilégios básicos. Por exemplo, se a aplicação que contém um bot for permitida para um utilizador, o bot pode enviar e receber mensagens. Estes privilégios existem em aplicações com base na funcionalidade que o programador da aplicação adicionou a uma aplicação e não são permissões que requerem consentimento para serem eficazes. Os programadores não definem explicitamente estas permissões, mas estas permissões são adicionadas implicitamente quando os programadores criam qualquer funcionalidade de aplicação.

Enquanto administrador, gere as aplicações do Teams e não as respetivas capacidades. As aplicações do Teams têm capacidades que permitem que as aplicações realizem o seu caso de utilização principal e realizem algumas tarefas. As capacidades são fornecidas pelos SDKs e o consentimento está implícito quando a aplicação é instalada. As tarefas que as aplicações podem realizar que estão associadas a capacidades são diferentes das permissões que requerem consentimento de um administrador. Enquanto administrador, tem de considerar o que uma aplicação pode fazer e como interage com os utilizadores com base nas seguintes capacidades.

Nota

As aplicações podem não utilizar todas as funcionalidades abaixo, a menos que a aplicação seja uma aplicação complexa que serve vários casos de utilização. As tarefas que a aplicação pode fazer dependem das capacidades utilizadas pelo programador da aplicação.

Bots e extensões de mensagens

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

  • Um bot pode receber mensagens de utilizadores e responder às mesmas. Os bots só recebem mensagens em conversas em que os utilizadores mencionam explicitamente um bot pelo respetivo nome. Esses dados saem da rede corporativa.

  • Depois de um utilizador enviar uma mensagem para um bot, o bot pode enviar mensagens diretas ou proativas ao utilizador em qualquer altura.

  • Alguns bots só enviam mensagens. São denominados bots apenas de notificação e o bot não oferece uma experiência de conversação.

  • Um bot adicionado às equipas pode obter uma lista de nomes e IDs dos canais numa equipa.

  • Ao utilizá-lo num canal, numa conversa pessoal ou num chat de grupo, o bot da aplicação pode aceder a informações de identidade básicas dos membros da equipa. As informações incluem o nome próprio, o apelido, o nome principal de utilizador (UPN) e o endereço de e-mail.

  • É possível que o bot de uma aplicação envie mensagens diretas ou proativas aos membros da equipa, mesmo que não tenham interagido com o bot.

  • Consoante as definições e o funcionamento de uma aplicação que seja um bot, pode enviar e receber ficheiros apenas no chat pessoal. Não é suportado para chats ou canais de grupo.

  • Os bots só têm acesso às equipas às quais os bots são adicionados ou aos utilizadores que adicionam a aplicação 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 utilizador ou um administrador pode bloquear um bot. A Microsoft também pode remover um bot da loja. As verificações de verificação e validação de aplicações garantem que as aplicações de alta qualidade estão disponíveis na Loja Teams e que os bots não fazem spam aos seus utilizadores.

  • Um bot pode obter e armazenar informações de identidade básicas para os membros da equipa aos quais a aplicação é adicionada ou para utilizadores individuais em conversas pessoais ou de grupo. Para obter mais informações sobre estes utilizadores, o bot tem de exigir que iniciem sessão no Microsoft Entra ID.

  • Os bots podem obter e armazenar a lista de canais numa equipa. Esses dados saem da rede corporativa.

  • Por predefinição, os bots não têm a capacidade de agir em nome do utilizador, mas os bots podem pedir aos utilizadores para iniciarem sessão; assim que o utilizador iniciar sessão, o bot tem um token de acesso com o qual pode realizar outras tarefas. As tarefas dependem do bot e do local onde o utilizador inicia sessão: um bot é uma aplicação microsoft Entra registada em https://apps.dev.microsoft.com/ e pode ter o 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. (Existe uma exceção: se um bot implementar a sua própria experiência de início de sessão, a IU de início de sessão verá os endereços IP dos utilizadores e as informações do referenciador.)

  • Por outro lado, as extensões de mensagens podem ver os endereços IP dos utilizadores e as informações do referenciador.

Nota

  • Se um bot tiver o seu próprio início de sessão, existe uma experiência de consentimento diferente na primeira vez que o utilizador inicia sessão.
  • Os utilizadores podem procurar aplicações com as botId que estavam disponíveis na aplicação. Embora os utilizadores possam ver o nome da aplicação, mas não podem interagir com esses bots.

Guias

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

Considere os seguintes tipos de interação do utilizador ou acesso a dados para Separadores:

  • Os utilizadores que abriam um separador num browser ou no Teams são exatamente os mesmos. O site em si não pode ter acesso às informações de nenhuma organização por si só.

  • Um separador também obtém o contexto em que está em execução, incluindo o nome de início de sessão e UPN do utilizador atual, o ID de Objeto do Microsoft Entra para o utilizador atual, o ID do grupo do Microsoft 365 no qual reside (se for uma equipa), o ID do inquilino e a região atual do utilizador. No entanto, para mapear estes IDs para as informações de um utilizador, o separador teria de fazer com que o utilizador iniciasse sessão no ID do Microsoft Entra.

Conectores

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

  • O sistema que publica mensagens do conector não sabe em quem está a publicar ou quem recebe as mensagens. Não são divulgadas informações sobre o destinatário. A Microsoft é o destinatário real e não a organização. A Microsoft faz a publicação real no canal.

  • Nenhum dados sai da rede empresarial quando os Conectores publicam mensagens num canal.

  • Os conectores que suportam mensagens acionáveis também não veem informações do endereço IP e do referenciador; estas informações são enviadas para a Microsoft e, em seguida, encaminhadas para pontos finais HTTP que foram anteriormente registados na Microsoft no portal dos Conectores.

  • Sempre que um Conector é configurado para um canal, é criado um URL exclusivo para essa instância do conector. 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.

  • O URL da instância do Conector deve ser tratado como secreto ou confidencial. Qualquer pessoa que tenha o URL pode publicá-lo. Se necessário, os proprietários da equipa podem eliminar a instância do conector.

  • Se necessário, um administrador pode impedir a criação de novas instâncias do Conector e a Microsoft pode bloquear toda a utilização de uma aplicação do Conector.

Webhooks de saída

Os proprietários da equipa ou os membros da equipa criam webhooks de envio. Os webhooks de saída podem receber mensagens dos utilizadores e responder às mesmas. Considere os seguintes tipos de interação do utilizador, as permissões necessárias e o acesso aos dados por Webhooks de envio:

  • 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.