Comprender los permisos y la información a la que acceden las aplicaciones de Teams

  • Artículo
  • Se aplica a:
    Microsoft Teams

Dependiendo de su funcionalidad, las aplicaciones de Teams pueden o no acceder a la información de su usuario o de su organización para funcionar como se pretende.

  • Algunas aplicaciones que no buscan acceso a la información de la organización y, por lo tanto, no requieren ninguna aprobación. Los usuarios pueden usar dichas aplicaciones sin la aprobación o el consentimiento de los administradores, ya que la información de la organización está protegida de dichas aplicaciones.
  • Algunas aplicaciones requieren la información de su organización o del usuario para trabajar o procesar la información. Estas aplicaciones no pueden funcionar a menos que permita que dicha aplicación tenga acceso a la información de su organización.

Debe evaluar la información de cumplimiento, seguridad y control de datos de una aplicación y comprender también los permisos solicitados por la aplicación antes de permitir que los usuarios usen una aplicación. Para ello, debe comprender los permisos, el consentimiento y los controles disponibles.

Cómo acceden las aplicaciones a la información de la organización

Teams proporciona medidas de seguridad para que no se pueda acceder a la información de su organización o del usuario sin su consentimiento. Para que una aplicación tenga acceso a cualquier información, deben realizarse las siguientes acciones:

  1. Los desarrolladores de aplicaciones declaran permisos y funcionalidades de aplicaciones al crear aplicaciones.
  2. Los administradores entienden y analizan los permisos requeridos por la aplicación en los portales de administración.
  3. El acceso a los datos se concede de dos maneras. Cuando la aplicación se agrega a Teams, se le concede acceso a algunas funcionalidades básicas que pueden incluir acceso a información básica. Tras conceder el consentimiento, una aplicación recibe acceso a algunos datos del usuario y la organización o a ambos, en función de los permisos de la aplicación para los que haya solicitado su consentimiento.

Tipos de permisos y su origen de declaración

Los permisos de las aplicaciones de Teams pueden ser de los tres tipos siguientes en función del ámbito.

  • Microsoft Entra ID permisos: Microsoft Graph permite a los desarrolladores acceder a la información y los datos de Microsoft 365 de su organización, pero solo con los permisos de Microsoft Entra ID adecuados. Una aplicación declara estos permisos por adelantado y los administradores deben dar su consentimiento a estos permisos para que la aplicación pueda acceder a la información. Si concede el consentimiento de administrador para dicho permiso en una aplicación de Teams, todos los usuarios permitidos de su organización pueden usar la aplicación y permitir que la aplicación acceda a la información de la organización. Estos permisos se definen en Microsoft Entra ID portal.

  • Permisos específicos de recursos (RSC): los recursos de Teams pueden ser un equipo, un chat o un usuario. El uso de estos permisos permite a las aplicaciones acceder a la información de solo un recurso específico. Con los permisos de RSC, una aplicación no tiene que solicitar acceso a información de toda la organización y puede limitar el ámbito de su acceso. Estos permisos RSC se definen en el archivo de manifiesto de la aplicación. Solo los usuarios que tienen acceso a los recursos pueden dar su consentimiento para estos permisos. Los desarrolladores definen estos permisos en la propia aplicación, en el archivo de manifiesto de la aplicación.

  • Capacidades básicas: Cuando los desarrolladores crean aplicaciones de Teams, usan algunas funcionalidades definidas en el marco de desarrollo. Estas funcionalidades son funcionalidades de alto nivel que las aplicaciones pueden tener. Por ejemplo, una aplicación puede contener un bot que converse con el usuario. Cuando una aplicación usa una funcionalidad, se conceden automáticamente algunos privilegios básicos. Por ejemplo, si la aplicación que contiene un bot está permitida para un usuario, entonces el bot puede enviar y recibir mensajes. Estos privilegios existen en las aplicaciones en función de la funcionalidad que el desarrollador de aplicaciones agregó a una aplicación y no son permisos que requieren consentimiento para ser efectivos. Los desarrolladores no definen explícitamente estos permisos, pero estos permisos se agregan implícitamente cuando los desarrolladores crean cualquier funcionalidad de la aplicación.

En función de las formas en que una aplicación puede acceder a la información de la organización, hay dos tipos de permisos:

  • Acceso delegado: una aplicación tiene acceso al recurso en nombre del usuario. Este acceso requiere permisos delegados. La aplicación solo puede acceder a la información a la que el usuario puede acceder por sí mismo.
  • Acceso solo a aplicaciones: una aplicación actúa por sí misma sin ningún usuario que haya iniciado sesión, cuando no es deseado tener un usuario específico conectado o cuando los datos requeridos no se pueden establecer en el ámbito de un solo usuario. Este acceso requería permisos de aplicaciones. Una aplicación, si se le concede el consentimiento, puede acceder a los datos con los que está asociado el permiso.
Administración conciencia Permisos delegados Permisos de aplicación
¿Cómo pueden las aplicaciones acceder a la información? En nombre de un usuario que ha iniciado sesión. Por sí mismos, usando su propia identidad.
A qué información se accede Permisos a los que se concede el consentimiento de la aplicación y la información asociada a ese permiso al que el usuario que ha iniciado sesión tiene acceso. Cualquier información con la que esté asociado un permiso consentido
¿Qué roles pueden dar su consentimiento? Administradores o usuarios o propietarios de grupos en función de Microsoft Entra ID configuración Solo administradores
¿Pueden los usuarios dar su consentimiento? Los usuarios pueden dar su consentimiento según Microsoft Entra ID configuración Solo los administradores pueden dar su consentimiento

Para cada aplicación, estos permisos se muestran en la página de detalles de la aplicación del centro de administración.

Tipo de permiso de aplicación Contexto de Access Origen de declaración ¿Cuándo se requiere consentimiento? ¿Quién puede dar su consentimiento? Notas
Microsoft Entra ID de Graph y acceso de extremo heredado Delegado Microsoft Entra ID Inicio de sesión de la aplicación Administración global, Administración en la nube y Administración de aplicaciones Consulte Microsoft Entra ID permisos requeridos por las aplicaciones de Teams.
Microsoft Entra ID de Graph y acceso de extremo heredado Aplicación Microsoft Entra ID Inicio de sesión de la aplicación Administración global, Administración en la nube y Administración de aplicaciones Consulte Permisos de Microsoft Graph requeridos por las aplicaciones de Teams.
RSC para obtener información sobre equipos, chats y usuarios Delegado Archivo de manifiesto de la aplicación Agregar una aplicación a un equipo, chatear y reuniones Propietario del recurso Consulte Permisos de RSC.
RSC para obtener información sobre equipos, chats y usuarios Aplicación Archivo de manifiesto de la aplicación Agregar una aplicación a un equipo, chatear y reuniones Propietario del recurso Consulte Permisos de RSC.
Otros permisos y acceso a datos Delegado a través de SDK Las propiedades de manifiesto lo definen Agregar una aplicación en un cliente El consentimiento está implícito en la instalación Disponible en la pestaña de la Permissions página de detalles de la aplicación de cada aplicación. Aquí encontrará más detalles.

¿Dónde pueden ver los administradores todos los permisos de una aplicación?

Puede encontrar los detalles de todos los tipos de permisos solicitados por una aplicación en la pestaña Permisos de la página de detalles de la aplicación.

Captura de pantalla que muestra la página del centro de administración que enumera y solicita permisos para una aplicación y también permite a los administradores conceder el consentimiento para dichos permisos a todos los usuarios de la organización.

Nota

Para saber cómo puede permitir el uso de una aplicación otorgando su consentimiento a sus permisos, consulte Conceder y administrar el consentimiento a los permisos de las aplicaciones de Teams.

Microsoft Entra ID permisos

Los desarrolladores de aplicaciones eligen los permisos adecuados de una amplia variedad de API de Graph para que las aplicaciones obtengan la información necesaria para funcionar. Antes de conceder el consentimiento a estos permisos, puede ver los permisos específicos solicitados por una aplicación. Te ayuda a evaluar el impacto de conceder consentimiento a los permisos de una aplicación. Para ver los permisos de Microsoft Entra ID, siga estos pasos:

  1. Acceda al Centro de administración de Teams y abra la páginaAdministrar aplicaciones de Teams>.

  2. Busca la aplicación necesaria y selecciona su nombre para abrir la página de detalles de la aplicación.

  3. Selecciona la pestaña Permisos y selecciona Revisar permisos y consentimiento.

  4. En el cuadro de diálogo, vea los permisos requeridos por la aplicación. Para obtener más información sobre la información disponible en el cuadro de diálogo, consulte la información disponible en la solicitud de consentimiento.

    Captura de pantalla de los permisos solicitados por una aplicación.

Una lista completa de todos los permisos posibles se documenta en la referencia de permisos de Microsoft Graph.

Los permisos de RSC permiten a los usuarios dar consentimiento a las aplicaciones para obtener información específica del ámbito. Dicho consentimiento permite a las aplicaciones acceder y modificar solo la información de un equipo o de un chat. Dicha aplicación no puede acceder a la información de un chat o un equipo en el que no se agrega. Algunos ejemplos de permisos de RSC incluyen la capacidad de crear y eliminar canales, obtener la configuración de un equipo y crear y eliminar pestañas de canal.

Los permisos de RSC limitan el ámbito de los permisos de la aplicación a un recurso específico en lugar de los permisos de Graph para toda la organización que pueden permitir que las aplicaciones accedan a información de toda la organización. Los recursos en los que se pueden aplicar permisos de RSC son chats y reuniones, equipos y canales, y usuarios.

Los permisos RSC se definen en el manifiesto de la aplicación y no en Microsoft Entra ID. Concede el consentimiento a los permisos RSC cuando agrega la aplicación a un equipo. Para obtener más información, consulte Consentimiento específico del recurso (RSC).

Para ver los permisos de RSC para una aplicación, siga estos pasos:

  1. Acceda al Centro de administración de Teams y vaya a Aplicaciones >de TeamsAdministrar aplicaciones.

  2. Busca la aplicación que quieras, selecciona el nombre de la aplicación para ir a la página de detalles de la aplicación y, a continuación, selecciona la pestaña Permisos .

  3. En Permisos de consentimiento específico de recursos (RSC), revise los permisos de RSC solicitados por la aplicación.

    Captura de pantalla que muestra un ejemplo de cómo ver los permisos RSC de una aplicación.

¿Qué pueden hacer las aplicaciones en Teams?

Como administrador, puede administrar las aplicaciones de Teams y no sus capacidades. Las aplicaciones de Teams tienen capacidades que permiten a las aplicaciones cumplir con su caso de uso principal y llevar a cabo algunas tareas. Las funcionalidades las proporcionan los SDK y el consentimiento está implícito cuando se instala la aplicación. Las tareas que las aplicaciones pueden realizar asociadas a funcionalidades son diferentes de los permisos que requieren el consentimiento de un administrador. Como administrador, debe tener en cuenta lo que puede hacer una aplicación y cómo interactúa con los usuarios en función de las siguientes capacidades.

Nota

Es posible que las aplicaciones no usen todas las funcionalidades siguientes, a menos que la aplicación sea una aplicación compleja que se ajuste a varios casos de uso. Las tareas que puede realizar la aplicación dependen de las capacidades que use el desarrollador de la aplicación.

Bots y extensiones de mensajería

Tenga en cuenta los siguientes tipos de interacción del usuario, permisos necesarios y acceso a datos por parte de bots y extensiones de mensajería:

  • Un bot puede recibir mensajes de los usuarios y responder a ellos. Los bots solo reciben mensajes en chats en los que los usuarios mencionan explícitamente un bot por su nombre. Estos datos abandonan la red corporativa.

  • Después de que un usuario envía un mensaje a un bot, el bot puede enviar al usuario mensajes directos o proactivos en cualquier momento.

  • Algunos bots solo envían mensajes. Se denominan bots solo de notificación y el bot no ofrece una experiencia conversacional.

  • Un bot agregado a los equipos puede obtener una lista de nombres e identificadores de los canales de un equipo.

  • Al usarlo en un canal, en un chat personal o en un chat grupal, el bot de la aplicación puede acceder a información básica de identidad de los miembros del equipo (nombre, apellidos, nombre principal de usuario [UPN] y dirección de correo electrónico).

  • Es posible que el bot de una aplicación envíe mensajes directos o proactivos a los miembros del equipo incluso si no han interactuado con el bot.

  • Según la configuración y el funcionamiento de una aplicación que sea un bot, solo puede enviar y recibir archivos en chat personal. No es compatible con chats grupales o canales.

  • Los bots solo tienen acceso a los equipos a los que se agregan los bots o a los usuarios que agregan la aplicación de bots.

  • Cuando un usuario habla con un bot, si el bot almacena el id. de usuario, puede enviar al usuario mensajes directos en cualquier momento.

  • Si es necesario, un usuario o un administrador puede bloquear un bot. Microsoft también puede quitar un bot de la tienda. Las comprobaciones de validación y verificación de aplicaciones garantizan que las aplicaciones de alta calidad están disponibles en la tienda de Teams y que los bots no envían correo no deseado a sus usuarios.

  • Un bot puede recuperar y almacenar información de identidad básica para los miembros del equipo a los que se agrega la aplicación, o para usuarios individuales en chats personales o grupales. Para obtener más información sobre estos usuarios, el bot debe requerir que inicien sesión en Microsoft Entra ID.

  • Los bots pueden recuperar y almacenar la lista de canales en un equipo. Estos datos abandonan la red corporativa.

  • De forma predeterminada, los bots no tienen la capacidad de actuar en nombre del usuario, pero los bots pueden pedir a los usuarios que inicien sesión; tan pronto como el usuario inicia sesión, el bot tiene un token de acceso con el que puede realizar otras tareas. Las tareas dependen del bot y del lugar donde el usuario inicia sesión: un bot es una aplicación Microsoft Entra registrada en https://apps.dev.microsoft.com/ y puede tener su propio conjunto de permisos.

  • Cuando se envía un archivo a un bot, el archivo abandona la red corporativa. El envío y la recepción de archivos requiere la aprobación del usuario para cada archivo.

  • Los bots se informan siempre que se agregan a los usuarios o se eliminan de un equipo.

  • Los bots no ven las direcciones IP de los usuarios ni otra información de referencia. Toda la información proviene de Microsoft. (Hay una excepción: si un bot implementa su propia experiencia de inicio de sesión, la interfaz de usuario de inicio de sesión ve las direcciones IP y la información de referencia de los usuarios).

  • Las extensiones de mensajería, por otro lado, pueden ver las direcciones IP y la información de referencia de los usuarios.

Nota

  • Si un bot tiene su propio inicio de sesión, hay una experiencia de consentimiento diferente la primera vez que el usuario inicia sesión.
  • Los usuarios pueden buscar aplicaciones con la botId que estaba disponible en la aplicación. Aunque los usuarios pueden ver el nombre de la aplicación, pero no pueden interactuar con estos bots.

Pestañas

Una pestaña es un sitio web que se ejecuta dentro de Teams. Puede ser como una pestaña en una reunión, un chat o un canal.

Tenga en cuenta los siguientes tipos de interacción del usuario o acceso a datos para pestañas:

  • Los usuarios que abren una pestaña en un explorador o en Teams son exactamente iguales. El sitio web en sí no puede tener acceso a la información de ninguna organización por sí mismo.

  • Una pestaña también obtiene el contexto en el que se ejecuta, incluidos el nombre de inicio de sesión y el UPN del usuario actual, el Microsoft Entra id. de objeto del usuario actual, el identificador del grupo de Microsoft 365 en el que reside (si es un equipo), el id. de inquilino y la configuración regional actual del usuario. Sin embargo, para asignar estos identificadores a la información de un usuario, la pestaña tendría que hacer que el usuario inicie sesión en Microsoft Entra ID.

Conectores

Un conector publica mensajes en un canal cuando se producen eventos en un sistema externo. El permiso necesario para conectores es poder publicar mensajes en el canal. Un permiso opcional para Conectores es el permiso para responder a un mensaje. Algunos conectores admiten mensajes accionables, que permiten a los usuarios publicar respuestas dirigidas al mensaje del conector. Por ejemplo, agregando una respuesta a un problema de GitHub o agregando una fecha a una tarjeta trello. Tenga en cuenta los siguientes tipos de interacción del usuario, permisos necesarios y acceso a datos por parte de los conectores:

  • El sistema que publica los mensajes del conector no sabe a quién se va a publicar ni quién recibe los mensajes. No se divulga ninguna información sobre el destinatario. Microsoft es el destinatario real y no la organización. Microsoft realiza la publicación real en el canal.

  • Ningún dato abandona la red corporativa cuando los conectores publican mensajes en un canal.

  • Los conectores que admiten mensajes accionables tampoco ven la información de referencia ni la dirección IP; esta información se envía a Microsoft y, a continuación, se redirige a los puntos de conexión HTTP previamente registrados con Microsoft en el portal conectores.

  • Cada vez que se configura un conector para un canal, se crea una dirección URL única para esa instancia del conector. Si se elimina esa instancia del conector, la dirección URL ya no se puede usar.

  • Los mensajes del conector no pueden contener archivos adjuntos.

  • La dirección URL de la instancia del conector debe tratarse como secreta o confidencial. Cualquier persona que tenga la dirección URL puede publicar en ella. Si es necesario, los propietarios del equipo pueden eliminar la instancia del conector.

  • Si es necesario, un administrador puede impedir la creación de nuevas instancias de Conector y Microsoft puede bloquear todo el uso de una aplicación conector.

Webhooks salientes

Los propietarios de equipo o los miembros del equipo crean webhooks salientes. Los webhooks salientes pueden recibir mensajes de los usuarios y responder a ellos. Tenga en cuenta los siguientes tipos de interacción del usuario, permisos necesarios y acceso a datos por parte de webhooks salientes:

  • Los webhooks salientes son similares a los bots, pero tienen menos privilegios. Deben mencionarse explícitamente, al igual que los bots.

  • Cuando se registra un webhook saliente, se genera un secreto, que permite al webhook saliente comprobar que el remitente es Microsoft Teams en lugar de un atacante malintencionado. Este secreto debe seguir siendo un secreto; cualquier persona que tenga acceso a ella puede hacerse pasar por Microsoft Teams. Si el secreto está en peligro, elimine y vuelva a crear el webhook saliente para generar un nuevo secreto.

  • Aunque es posible crear un webhook saliente que no valide el secreto, le recomendamos que lo haga.

  • Aparte de recibir y responder mensajes, los webhooks salientes no pueden hacer mucho: no pueden enviar mensajes de forma proactiva, no pueden enviar o recibir archivos, no pueden hacer nada más que los bots pueden hacer excepto recibir y responder mensajes.