Privacidad, permisos y seguridad de los complementos de Outlook

  • Artículo

Los usuarios finales, los desarrolladores y los administradores pueden usar los niveles de permisos en capas del modelo de seguridad en los complementos de Outlook para controlar la privacidad y el rendimiento.

En este artículo se describen los posibles permisos que pueden solicitar los complementos de Outlook y se examina el modelo de seguridad desde las siguientes perspectivas:

  • AppSource: integridad del complemento

  • Usuarios finales: dudas sobre privacidad y rendimiento

  • Desarrolladores: opciones de permisos y límites del uso de recursos

  • Administradores: privilegios para establecer umbrales de rendimiento

Modelo de permisos

Dado que la percepción de los clientes sobre la seguridad de los complementos puede afectar a la adopción de complementos, la seguridad de complementos de Outlook se basa en un modelo de permisos por niveles. Un complemento de Outlook revelaría el nivel de permisos que necesita, identificando el posible acceso y las acciones que el complemento puede realizar en los datos del buzón del cliente.

Hay cuatro niveles de permisos, que se resumen a continuación.

Nombre canónico de nivel
de permiso		 Nombre del manifiesto XML manifiesto unificado para el nombre de Microsoft 365 Descripción de resumen
Restringido Restricted MailboxItem.Restricted.User Permite el acceso a propiedades y métodos que no pertenecen a información específica sobre el usuario o el elemento de correo.
leer elemento ReadItem MailboxItem.Read.User Además de lo que se permite en restringido, permite:
  • expresiones regulares
  • acceso de lectura a la API del complemento de Outlook
  • obtener las propiedades del elemento y el token de devolución de llamada
  • escribir propiedades personalizadas
elemento de lectura y escritura ReadWriteItem MailboxItem.ReadWrite.User Además de lo que se permite en el elemento de lectura, permite:
  • acceso completo a la API del complemento de Outlook, excepto makeEwsRequestAsync
  • configurar las propiedades del elemento
buzón de lectura y escritura ReadWriteMailbox Mailbox.ReadWrite.User Además de lo que se permite en el elemento de lectura y escritura, permite lo siguiente:
  • crear, leer y escribir en elementos y carpetas
  • enviar elementos
  • realizar llamadas a makeEwsRequestAsync

Los permisos se declaran en el manifiesto. El marcado varía en función del tipo de manifiesto.

  • Manifiesto XML: use el <elemento Permissions> .
  • Manifiesto unificado para Microsoft 365: use la propiedad "name" de un objeto en la matriz "authorization.permissions.resourceSpecific".

Nota:

Los cuatro niveles de permisos son acumulativos: el permiso buzón de lectura y escritura incluye los permisos de lectura y escritura de elemento, lectura de elemento y restringido; el permiso lectura y escritura de elemento incluye lectura de elemento y la opción restringido; y el permiso lectura de elemento incluye el permiso restringido.

En la figura siguiente se muestran los cuatro niveles de permisos y se describen las capacidades que se ofrecen al usuario final, al desarrollador y al administrador en cada nivel. Para más información sobre estos permisos, vea Usuarios finales: dudas sobre privacidad y rendimiento, Desarrolladores: opciones de permisos y límites de uso de recursos, y Comprender los permisos de los complementos de Outlook.

Diagrama del modelo de permisos de cuatro niveles para el esquema v1.1 de las aplicaciones de correo.

AppSource: integridad del complemento

La AppSource hospeda complementos que los usuarios finales y los administradores pueden instalar. AppSource aplica las siguientes medidas para mantener la integridad de estos complementos de Outlook:

  • Requiere que el servidor host de un complemento siempre use la capa de sockets seguros (SSL) para comunicarse.

  • Requiere que el desarrollador proporcione pruebas de identidad, un acuerdo contractual y una directiva de privacidad válida para enviar complementos.

  • Archiva los complementos en modo de solo lectura.

  • Admite un sistema de revisión del usuario para que los complementos disponibles promuevan una comunidad autocontrolada.

Experiencias conectadas opcionales

Los usuarios finales y los administradores de TI pueden deshabilitar las experiencias opcionales conectadas en los clientes móviles y de escritorio de Office. Para los complementos de Outlook, el impacto de deshabilitar la opción Experiencias conectadas opcionales depende del cliente, pero normalmente significa que no se permiten los complementos instalados por el usuario y el acceso a AppSource. Los complementos que implementó el administrador de TI de la organización en la Implementación centralizada seguirán estando disponibles.

Cliente Comportamiento cuando se desactivan las experiencias conectadas opcionales
La disponibilidad de los complementos y el acceso a AppSource no se ven afectados, por lo que los usuarios pueden seguir administrando sus complementos, incluidos los implementados por el administrador.
  • Windows (clásico)1
  • Mac
 No se muestra el botón Todas las aplicaciones2 o Obtener complementos , por lo que los usuarios no pueden administrar sus complementos ni acceder a AppSource.
  • Android
  • iOS
 El cuadro de diálogo Obtener complementos muestra solo los complementos implementados por el administrador.

Nota:

1 En Windows, la compatibilidad con esta experiencia está disponible en la versión 2008 (compilación 13127.20296). Para obtener más información sobre la versión del cliente, consulte la página historial de actualizaciones de Microsoft 365 y cómo buscar la versión del cliente de Office y el canal de actualización.

2 A partir de Outlook en La versión 2303 de Windows (compilación 16215.10000), el botón Todas las aplicaciones se usa para administrar complementos y acceder a AppSource.

Para conocer el comportamiento general de los complementos, consulte la Privacidad y seguridad de complementos para Office.

Usuarios finales: dudas sobre privacidad y rendimiento

El modelo de seguridad aborda las dudas de los usuarios finales sobre seguridad, privacidad y rendimiento de las siguientes maneras:

  • Los mensajes del usuario final protegidos por Information Rights Management (IRM) de Outlook no interactuarán con complementos en las siguientes instancias.

    • Cuando se accede al mensaje protegido por IRM desde Outlook en dispositivos móviles.

    • Cuando el mensaje protegido por IRM contiene una etiqueta de confidencialidad con la opción Permitir el acceso mediante programación de directiva personalizada establecida en false.

    Para obtener más información sobre la compatibilidad con IRM en complementos, consulte Elementos de correo protegidos por IRM.

  • Antes de instalar un complemento de la AppSource, los usuarios finales pueden ver el acceso a los datos que puede realizar el complemento y las acciones que puede llevar a cabo con ellos, y deben confirmar de forma explícita que quieren continuar. Ningún complemento de Outlook se instala automáticamente en un equipo cliente sin que el usuario o el administrador validen la operación de forma manual.

  • La concesión del permiso restringido permite que el complemento de Outlook tenga un acceso limitado solo en el elemento actual. La concesión del permiso de elemento de lectura permite al complemento de Outlook acceder a información de identificación personal, como nombres de remitente y destinatario y direcciones de correo electrónico, solo en el elemento actual.

  • El usuario final puede instalar un complemento de Outlook de nivel de confianza bajo para uso personal. Los complementos de Outlook que afectan a una organización los instala un administrador.

  • Los usuarios finales pueden instalar complementos de Outlook que permitan escenarios contextuales que sean atractivos para los usuarios y que minimicen los riesgos de seguridad de los usuarios.

  • Los archivos de manifiesto de los complementos de Outlook instalados están protegidos en la cuenta de correo del usuario.

  • Los datos comunicados con servidores que hospedan Complementos de Office siempre se cifran de acuerdo con el protocolo de la capa de sockets seguros (SSL).

  • Outlook en Windows y en Mac supervisa el rendimiento de los complementos de Outlook instalados, ejerce el control de gobernanza y hace que los complementos no estén disponibles cuando superen los límites en las áreas siguientes.

    • Tiempo de respuesta para activarse

    • Número de errores para activarse o reactivarse

    • Uso de memoria

    • Uso de CPU

    Governance deters denial-of-service attacks and maintains add-in performance at a reasonable level. La Barra de negocios alerta a los usuarios finales sobre los complementos que Outlook en Windows y en Mac han dejado de estar disponibles en función de dicho control de gobernanza.

  • En cualquier momento, los usuarios finales pueden comprobar los permisos solicitados por los complementos de Outlook instalados y hacer que cualquier complemento esté disponible o no esté disponible en el Centro de Administración de Exchange.

Desarrolladores: opciones de permisos y límites de uso de recursos

El modelo de seguridad proporciona a los desarrolladores niveles pormenorizados de permisos entre los que pueden elegir y unas instrucciones estrictas sobre el rendimiento que es necesario cumplir.

Los permisos en niveles aumentan la transparencia

Los desarrolladores deben seguir el modelo de permisos en niveles para proporcionar transparencia y disipar las dudas de los usuarios sobre lo que los complementos pueden hacer en sus datos y buzones. De hacerlo así, estarán promoviendo, indirectamente, que los usuarios instalen el complemento.

  • Los desarrolladores solicitan un nivel de permiso apropiado para un complemento de Outlook en función de cómo debe activarse el complemento de Outlook y su necesidad de leer o escribir ciertas propiedades de un elemento, o bien de crear y enviar un elemento.

  • Como se indicó anteriormente, los desarrolladores solicitan permiso en el manifiesto.

    En el ejemplo siguiente se solicita el permiso de elemento de lectura en el manifiesto XML.

    <Permissions>ReadItem</Permissions>

    En el ejemplo siguiente se solicita el permiso de elemento de lectura en el manifiesto unificado para Microsoft 365.

    "authorization": {
  "permissions": {
    "resourceSpecific": [
      ...
      {
        "name": "MailboxItem.Read.User",
        "type": "Delegated"
      },
    ]
  }
},

  • Los desarrolladores pueden solicitar el permiso restringido si el complemento de Outlook se activa en un tipo específico de elemento de Outlook (cita o mensaje) o en entidades extraídas específicas (número de teléfono, dirección, dirección URL) que están presentes en el asunto o el cuerpo del elemento.

    Importante

    Los complementos contextuales de Outlook basados en entidades se retirarán en el segundo trimestre de 2024. El trabajo para retirar esta característica comenzará en mayo y continuará hasta finales de junio. Después de junio, los complementos contextuales ya no podrán detectar entidades en elementos de correo para realizar tareas en ellos. También se retirarán las siguientes API.

    Para ayudar a minimizar las posibles interrupciones, se seguirá admitiendo lo siguiente después de que se retiren los complementos contextuales basados en entidades.

    • Se está desarrollando una implementación alternativa del botón Unirse a la reunión , que se activa mediante complementos de reunión en línea. Una vez finalizada la compatibilidad con complementos contextuales basados en entidades, los complementos de reunión en línea pasarán automáticamente a la implementación alternativa para activar el botón Unirse a la reunión .
    • Las reglas de expresión regular seguirán siendo compatibles después de retirar los complementos contextuales basados en entidades. Se recomienda actualizar el complemento contextual para usar reglas de expresión regular como solución alternativa. Para obtener instrucciones sobre cómo implementar estas reglas, vea Usar reglas de activación de expresiones regulares para mostrar un complemento de Outlook.

    Para obtener más información, vea Retirada de complementos contextuales de Outlook basados en entidades.

  • Los desarrolladores deben solicitar el permiso de elemento de lectura si el complemento de Outlook necesita leer propiedades del elemento actual distintas de las entidades extraídas predeterminadas, o escribir propiedades personalizadas establecidas por el complemento en el elemento actual, pero no requiere leer ni escribir en otros elementos, ni crear o enviar un mensaje en el buzón del usuario. Por ejemplo, sería necesario que un desarrollador solicitara el permiso lectura de elemento si, para su activación, un complemento de Outlook necesita buscar en el tema o en el cuerpo de un elemento una entidad como una sugerencia de reunión, una sugerencia de tarea, una dirección de correo electrónico o un nombre de contacto, o bien si usa una expresión regular.

  • Los desarrolladores deben solicitar el permiso lectura y escritura de elemento si el complemento de Outlook debe escribir en las propiedades del elemento redactado, como nombres de destinatarios, direcciones de correo electrónico, cuerpo y tema, o necesita agregar o quitar datos adjuntos.

  • Los desarrolladores solicitan el permiso buzón de lectura y escritura solo si el complemento de Outlook necesita llevar a cabo una o varias de las siguientes acciones con el método mailbox.makeEWSRequestAsync:

    • Leer o escribir en las propiedades de los elementos del buzón de correo.
    • Crear, enviar, leer o escribir en elementos del buzón de correo.
    • Crear, leer o escribir en carpetas del buzón de correo.

Ajuste del uso de recursos

Los desarrolladores deben estar al tanto de los límites del uso de recursos para la activación e incorporar el ajuste del rendimiento en su flujo de trabajo de desarrollo a fin de reducir las posibilidades de un complemento con bajo rendimiento que deniega el servicio del host. Los desarrolladores deben seguir las instrucciones para diseñar reglas de activación como se describe en Límites de activación y API de JavaScript para complementos de Outlook. Si un complemento de Outlook está diseñado para ejecutarse en Outlook en Windows o en Mac, los desarrolladores deben comprobar que el complemento se realiza dentro de los límites de uso de recursos.

Otras medidas para promover la seguridad del usuario

Los desarrolladores deben conocer y planear lo siguiente:

  • Los desarrolladores no pueden usar controles ActiveX en complementos porque no se admiten.

  • Es necesario que los desarrolladores hagan lo siguiente cuando envíen un complemento de Outlook a AppSource:

    • Presentar un certificado SSL de validación extendida (EV) como prueba de identidad.

    • Hospedar el complemento que van a enviar en un servidor web que admita SSL.

    • Presentar una directiva de privacidad compatible.

    • Firmar un acuerdo contractual al enviar el complemento.

Administradores: privilegios

El modelo de seguridad proporciona a los administradores los siguientes derechos y responsabilidades:

  • Posibilidad de impedir que los usuarios finales instalen algún complemento de Outlook, incluidos los complementos de AppSource.

  • Puede hacer que cualquier complemento de Outlook esté disponible o no esté disponible a través del Centro de Administración de Exchange.

  • Solo aplicable a Outlook en Windows: posibilidad de invalidar la configuración del umbral de rendimiento con la configuración del Registro de GPO.

Vea también