Privacidad y seguridad de complementos para Office

Artículo
10/10/2023

Seguridad de procesos

Los Complementos de Office están protegidas por un entorno de tiempo de ejecución de complemento, un modelo de permisos de varios niveles y reguladores de rendimiento. Este marco protege la experiencia del usuario de las siguientes maneras.

Se administra el acceso al marco de interfaz de usuario de la aplicación cliente de Office.
Solo se permite el acceso indirecto al subproceso de interfaz de usuario de la aplicación cliente de Office.
No se permiten interacciones modales: por ejemplo, las llamadas a JavaScript alert, confirmy prompt los métodos no se permiten porque son modales.

Además, el marco en tiempo de ejecución proporciona las siguientes ventajas para asegurarse de que un complemento de Office no puede dañar el entorno del usuario.

Aísla el proceso en el que se ejecuta el complemento.
No necesita reemplazar el archivo .dll o .exe ni los componentes ActiveX.
Facilita la instalación y desinstalación de los complementos.

Además, se puede controlar la memoria, la CPU y los recursos de red que usan los complementos de Office para garantizar un buen rendimiento y confiabilidad.

Nota:

En algunos escenarios, se ejecutan diferentes características de un complemento en tiempos de ejecución independientes. Por motivos de simplicidad, en este artículo se usa el singular "runtime". Para obtener más información, vea Runtimes in Office Add-ins.

En las secciones siguientes se describe brevemente cómo la arquitectura en tiempo de ejecución admite la ejecución de complementos en clientes de Office en dispositivos basados en Windows, en dispositivos Mac OS X y en exploradores web.

Clientes en dispositivos Windows y OS X

En los clientes admitidos para dispositivos de escritorio y tableta, como Excel en Windows y Outlook en Windows y en Mac, los complementos de Office se admiten mediante la integración de un componente en proceso, el entorno de ejecución de complementos de Office, que administra el ciclo de vida de los complementos y permite la interoperabilidad entre el complemento y la aplicación cliente. La página web del complemento se hospeda fuera del proceso. En un dispositivo de escritorio o tableta windows, la página web del complemento se hospeda dentro de un control de Internet Explorer o Microsoft Edge que, a su vez, se hospeda dentro de un proceso en tiempo de ejecución de complementos que proporciona aislamiento de seguridad y rendimiento.

En los escritorios de Windows, el modo protegido en Internet Explorer debe estar habilitado para la zona de sitio restringido. Suele estar habilitado de forma predeterminada. Si está deshabilitado, se producirá un error al intentar iniciar un complemento.

Diagrama del entorno en tiempo de ejecución de complementos de Office en clientes de escritorio y tabletas de Windows.

En un escritorio macOS, la página web del complemento se hospeda dentro de un proceso de host en tiempo de ejecución de WebKit de espacio aislado que ayuda a proporcionar un nivel similar de seguridad y protección del rendimiento.

Diagrama del entorno en tiempo de ejecución de complementos de Office en clientes de escritorio de macOS.

El tiempo de ejecución de complementos de Office administra la comunicación entre procesos, la conversión de eventos y llamadas API de JavaScript en nativos, así como la compatibilidad remota de interfaz de usuario para permitir que el complemento se represente dentro del documento, en un panel de tareas, o de forma adyacente a un mensaje de correo electrónico, una convocatoria de reunión o una cita.

Clientes web

En los clientes web admitidos, los complementos de Office se hospedan en un iframe que se ejecuta mediante el atributo de espacio aislado HTML5. No se admiten los componentes ActiveX ni se permite el desplazamiento por la página principal del cliente web. La integración de la API de JavaScript para Office habilita la compatibilidad con complementos de Office en los clientes web. De forma similar a las aplicaciones cliente de escritorio, la API de JavaScript administra el ciclo de vida del complemento y la interoperabilidad entre el complemento y el cliente web. Esta interoperabilidad se implementa mediante una infraestructura de comunicación de mensajes de publicación entre marcos especial. La misma biblioteca de JavaScript (Office.js) que se usa en los clientes de escritorio está disponible para interactuar con el cliente web. En la ilustración siguiente se muestra la infraestructura que admite complementos en Office que se ejecutan en el explorador y los componentes pertinentes (el cliente web, iframe, el entorno de ejecución de complementos de Office y la API de JavaScript para Office) necesarios para admitirlos.

Diagrama de la infraestructura que admite complementos de Office en clientes Office en la Web.

Integridad del complemento en AppSource

Si quiere que sus complementos de Office estén disponibles para el público, publíquelos en AppSource. AppSource aplica las siguientes medidas para mantener la integridad de los complementos.

Necesita que el servidor host de un complemento de Office siempre use SSL (capa de sockets seguros) para comunicarse.
Pide que el desarrollador proporcione pruebas de identidad, un acuerdo contractual y una directiva de privacidad válida para enviar complementos.
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. En el caso de los complementos de Office, el impacto de deshabilitar la opción Experiencias conectadas opcionales es que los usuarios ya no pueden acceder a los complementos ni al almacén de Microsoft 365 y Copilot a través de estos clientes. Sin embargo, algunos complementos de Microsoft que se consideran esenciales o críticos para la empresa, y los complementos implementados por el administrador de TI de una organización a través de la implementación centralizada seguirán estando disponibles. Además, los complementos y la tienda Microsoft 365 y Copilot permanecen disponibles en Outlook en la Web, independientemente del estado de la configuración.

Para obtener más información sobre el comportamiento específico de Outlook, vea Privacidad, permisos y seguridad para complementos de Outlook.

Tenga en cuenta que si un administrador de TI deshabilita el uso de experiencias conectadas en Office, tiene el mismo efecto en los complementos que desactivar solo las experiencias conectadas opcionales.

Solucionar las dudas sobre privacidad de los usuarios finales

En esta sección, se describe la protección que ofrece la plataforma de complementos de Office desde la perspectiva del cliente (usuario final), y se proporcionan instrucciones sobre cómo cumplir las expectativas de los usuarios y cómo administrar de forma segura la información de identificación personal (DCP) de estos.

Perspectiva del usuario final

Los complementos de Office se diseñan con tecnologías web que se ejecutan en un control del explorador o iframe. Por este motivo, el uso de los complementos resulta muy similar a la exploración de sitios web en Internet o en una intranet. Los complementos pueden ser externos a una organización (si adquiere el complemento desde AppSource) o internos (si adquiere el complemento desde un catálogo de complementos de Exchange Server, un catálogo de aplicaciones de SharePoint o un recurso compartido de archivos en la red de una organización). Los complementos tienen acceso limitado a la red y la mayoría de ellos puede escribir o leer en el elemento de correo o documento activo. La plataforma del complemento aplicará ciertas restricciones antes de que un usuario o un administrador instale o inicie un complemento. Pero, al igual que ocurre con cualquier modelo de extensibilidad, los usuarios tienen que tomar precauciones antes de iniciar un complemento desconocido.

Nota:

Es posible que los usuarios vean un mensaje de seguridad para confiar en el dominio la primera vez que se carga un complemento. Esto ocurrirá si el host de dominio del complemento está fuera del dominio de Exchange local o Office Online Server.

La plataforma de complementos aborda los problemas de privacidad de los usuarios finales de las siguientes maneras.

Los datos que se comunican a un servidor web que hospeda un complemento de panel de tareas, Outlook o contenido, al igual que las comunicaciones entre el complemento y cualquier servicio web que este use, deben cifrarse mediante el protocolo de capa de sockets seguros (SSL).
Antes de instalar un complemento desde AppSource, el usuario puede ver los requisitos y la directiva de privacidad de dicho complemento. Además, los complementos de Outlook que interactúan con los buzones de los usuarios exponen los permisos específicos que necesitan, de modo que, antes de instalar uno de estos complementos, el usuario puede revisar las condiciones de uso, los permisos que se han solicitado y la directiva de privacidad.
Cuando los usuarios comparten un documento, también comparten los complementos que se han insertado en él o se han asociado con él. Si un usuario abre un documento que contiene un complemento que el usuario no ha usado antes, la aplicación cliente de Office solicita al usuario que conceda permiso para que el complemento se ejecute en el documento. En un entorno organizativo, la aplicación cliente de Office también pregunta al usuario si el documento procede de un origen externo.
Los usuarios pueden habilitar o deshabilitar el acceso a AppSource. En el caso de los complementos de contenido y panel de tareas, los usuarios administran el acceso a complementos y catálogos de confianza desde el Centro de confianza en el cliente host de Office (abierto desdeOpciones> de archivo>Del Centrodeconfianza Configuración> del Centro > de confianzaCatálogos de complementos de confianza).

En Outlook, el acceso para administrar complementos depende del cliente de Outlook del usuario. Para obtener más información, consulte Uso de complementos en Outlook.

Los administradores también pueden administrar el acceso a AppSource a través del centro de administración.
El diseño de la plataforma del complemento proporciona seguridad y rendimiento a los usuarios finales de las siguientes maneras.
- Un complemento de Office se ejecuta en un control de explorador web hospedado en un entorno en tiempo de ejecución de complemento independiente de la aplicación cliente de Office. Este diseño proporciona aislamiento de seguridad y rendimiento de la aplicación cliente.
- La ejecución en un control del explorador web permite al complemento realizar prácticamente todas las acciones que puede realizar una página web común en un explorador y, al mismo tiempo, controla el comportamiento del complemento para que cumpla la directiva del mismo origen en lo que respecta al aislamiento de dominios y las zonas de seguridad.

Los complementos de Outlook proporcionan características adicionales de seguridad y rendimiento con la supervisión del uso de recursos específica de complementos de Outlook. Para más información, vea Privacidad, permisos y seguridad para complementos de Outlook.

Recomendaciones para desarrolladores sobre el tratamiento de PII

A continuación se enumeran algunas directrices de protección de PII específicas para usted como desarrollador de complementos de Office.

Aunque el objeto Settings está destinado a conservar los datos de estado y la configuración de un complemento de panel de tareas o de contenido entre sesiones, no se recomienda almacenar datos de DCP confidenciales o contraseñas en el objeto Settings. Aunque los datos del objeto Settings no resultan visibles para los usuarios finales, forman parte del formato de archivo del documento al que sí se puede acceder con facilidad. Limite el uso de datos de DCP en el complemento y almacene todos los datos de este tipo que necesite el complemento en el servidor donde este se hospeda, como recursos protegidos por el usuario.
El uso de ciertas aplicaciones puede revelar datos de DCP. Asegúrese de almacenar de un modo seguro los datos de identidad, ubicación, horas de acceso y otras credenciales de los usuarios, de modo que no se encuentren disponibles para otros usuarios del complemento.
Si el complemento se encuentra disponible en AppSource, el requisito de AppSource de HTTPS protegerá los datos de PII que se transmitan entre el servidor web y el dispositivo o equipo cliente. No obstante, si vuelve a transmitir los datos a otros servidores, asegúrese de mantener el mismo nivel de protección.
Si almacena datos de PII de los usuarios, asegúrese de comunicárselo y de ofrecer una vía para que puedan revisarlos y eliminarlos si así lo desean. Si envía el complemento a AppSource, puede explicar brevemente cuáles son los datos que recopila y el uso que realiza de ellos en la declaración de privacidad.

Opciones de permisos y procedimientos de seguridad para desarrolladores

Siga estas directrices generales para disfrutar de la compatibilidad con el modelo de seguridad de complementos de Office y obtenga información detallada sobre cada tipo de complemento.

Opciones de permisos

La plataforma de complemento proporciona un modelo de permisos que tu complemento utiliza para declarar el nivel de acceso a los datos de un usuario que requiere para sus caracter?sticas. Cada nivel de permiso se corresponde con el subconjunto de la API de JavaScript para Office que el complemento puede usar para sus funciones. Por ejemplo, el permiso WriteDocument para complementos de contenido y panel de tareas permite el acceso al método Document.setSelectedDataAsync que permite a un complemento escribir en el documento del usuario, pero no permite el acceso a ninguno de los métodos para leer datos del documento. Este nivel de permiso es apropiado para los complementos que solo necesitan escribir en un documento, como un complemento en el que el usuario puede buscar datos para insertar en su documento.

El procedimiento recomendado es solicitar los permisos basándose en el principio de privilegio mínimo. Es decir, debería solicitar permisos para tener acceso únicamente al subconjunto mínimo de la API que el complemento necesite para funcionar correctamente. Por ejemplo, si un complemento solo necesita leer datos en el documento de un usuario según sus características, solo tiene que solicitar el permiso ReadDocument. (Pero tenga en cuenta que, si no solicita los permisos suficientes, la plataforma del complemento bloqueará el uso que esta pueda realizar de algunas API y generará errores en tiempo de ejecución).

Los permisos se especifican en el manifiesto del complemento, como se muestra en el ejemplo de esta sección siguiente, y los usuarios finales pueden ver el nivel de permiso solicitado de un complemento antes de que decidan instalar o activar el complemento por primera vez. Además, los complementos de Outlook que solicitan el permiso ReadWriteMailbox requieren privilegios de administrador explícitos para instalar.

En el ejemplo siguiente se muestra cómo un complemento de panel de tareas especifica el permiso ReadDocument en su manifiesto. Para que los permisos sigan constituyendo el tema central, no se mostrarán otros elementos del manifiesto.

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xmlns:ver="http://schemas.microsoft.com/office/appforoffice/1.0"
           xsi:type="TaskPaneApp">

... <!-- To keep permissions as the focus, not displaying other elements. -->
  <Permissions>ReadDocument</Permissions>
...
</OfficeApp>

Para obtener más información sobre los permisos para los complementos de panel de tareas y contenido, consulte Solicitar permisos para el uso de la API en los complementos.

Para obtener más información sobre los permisos para complementos de Outlook, vea los temas siguientes.

Directiva de mismo origen

Dado que los complementos de Office son páginas web que se ejecutan en un control de explorador web, deben seguir la directiva del mismo origen aplicada por el explorador. De forma predeterminada, una página web de un dominio no puede hacer que el servicio web XmlHttpRequest llame a otro dominio distinto del que se hospeda.

Una manera de superar esta limitación es usar JSON/P: proporcionar un proxy para el servicio web mediante la inclusión de una etiqueta de script con un atributo src que apunte a algún script hospedado en otro dominio. Puede crear las etiquetas script mediante programación: cree de forma dinámica la URL a la que tiene que apuntar el atributo src y pase los parámetros a la URL a través de los parámetros de consulta de URI. Los proveedores de servicios web crean y hospedan código JavaScript en URL específicas y devuelven scripts diferentes, en función de los parámetros de consulta de URI. Después, estos scripts se ejecutan donde se encuentran insertados y funcionan según lo esperado.

A continuación se muestra un ejemplo de JSON/P en el ejemplo de complemento de Outlook.

// Dynamically create an HTML SCRIPT element that obtains the details for the specified video.
function loadVideoDetails(videoIndex) {
    // Dynamically create a new HTML SCRIPT element in the webpage.
    const script = document.createElement("script");
    // Specify the URL to retrieve the indicated video from a feed of a current list of videos,
    // as the value of the src attribute of the SCRIPT element. 
    script.setAttribute("src", "https://gdata.youtube.com/feeds/api/videos/" + 
        videos[videoIndex].Id + "?alt=json-in-script&amp;callback=videoDetailsLoaded");
    // Insert the SCRIPT element at the end of the HEAD section.
    document.getElementsByTagName('head')[0].appendChild(script);
}

Exchange y SharePoint proporcionan servidores proxy del lado cliente para permitir el acceso entre dominios. En general, una directiva de mismo origen en una intranet no es tan estricta como en Internet. Para más información, vea Directiva de mismo origen parte 1: Sin inspección y Solución para limitaciones de directiva de mismo origen en complementos de Office.

Consejos para evitar scripting malintencionado entre sitios

Un actor incorrecto podría atacar el origen de un complemento escribiendo un script malintencionado a través del documento o los campos del complemento. Un desarrollador debe procesar la entrada del usuario para evitar ejecutar el JavaScript de un usuario malintencionado dentro de su dominio. A continuación se indican algunos procedimientos recomendados que se deben seguir para controlar la entrada del usuario desde un documento o mensaje de correo, o a través de campos de un complemento.

En lugar de la propiedad DOM innerHTML, use las propiedades innerText y textContent cuando corresponda. Haga lo siguiente para la compatibilidad entre exploradores de Internet Explorer y Firefox.
```
 var text = x.innerText || x.textContent
```
Para obtener información sobre las diferencias entre innerText y textContent, vea Node.textContent. Para más información sobre la compatibilidad de DOM entre exploradores comunes, vea Compatibilidad de DOM de W3C: HTML.
Si debe usar innerHTML, asegúrese de que la entrada del usuario no contenga contenido malintencionado antes de pasarlo a innerHTML. Para obtener más información y un ejemplo de cómo usar innerHTML de forma segura, vea innerHTML (propiedad).
Si usa jQuery, use el método .text() en lugar del método .html().
Use el método toStaticHTML para quitar todos los atributos y elementos HTML dinámicos de las entradas de usuario antes de pasarlas a innerHTML.
Use las funciones encodeURIComponent o encodeURI para codificar texto que pretende ser una URL que contiene entradas de usuario o procede de ellas.
Vea Desarrollo de complementos seguros para conocer otros procedimientos recomendados para crear soluciones web más seguras.

Sugerencias para evitar el "secuestro de clics"

Dado que los complementos de Office se representan en un iframe cuando se ejecutan en un explorador con aplicaciones cliente de Office, use las siguientes sugerencias para minimizar el riesgo de hacer clic , una técnica que usan los hackers para engañar a los usuarios para que revelen información confidencial.

Primero, identifique las acciones confidenciales que puede realizar el complemento. Entre ellas se incluyen las acciones que podría llevar a cabo un usuario no autorizado con malas intenciones, como iniciar una transacción financiera o publicar datos confidenciales. Por ejemplo, el complemento puede permitir al usuario enviar un pago a un destinatario que define el usuario.

En segundo lugar, el complemento tendría que pedir confirmación al usuario antes de ejecutar acciones confidenciales. Esta confirmación tiene que detallar el efecto que tendrá la acción. También tiene que explicar al usuario cómo puede evitar la acción, si es necesario, ya sea con un botón específico marcado como "No permitir" o ignorando la confirmación.

En tercer lugar, para asegurarse de que ningún actor de amenazas puede ocultar o enmascarar la confirmación, debe mostrarla fuera del contexto del complemento (es decir, no en un cuadro de diálogo HTML).

A continuación se muestran algunos ejemplos de cómo puede obtener confirmación.

Envíe un correo al usuario que contenga un vínculo de confirmación.
Envíe un mensaje de texto al usuario que incluya un código de confirmación que este pueda escribir en el complemento.
Abra un diálogo de confirmación en una ventana del explorador nueva a una página que no pueda incorporar con IFrame. Suele ser el patrón que se utiliza en las páginas de inicio de sesión. Use la API de cuadros de diálogo para crear un cuadro de diálogo.

Además, asegúrese de que un actor de amenazas no pudo proporcionar la dirección que usa para ponerse en contacto con el usuario. Por ejemplo, para confirmaciones de pago, use la dirección que aparece en el archivo de la cuenta autorizada del usuario.

Otros procedimientos de seguridad

Los desarrolladores también deben tomar nota de las siguientes prácticas de seguridad.

Los desarrolladores no tienen que usar controles ActiveX en los complementos de Office, ya que estos controles no son compatibles con la naturaleza multiplataforma de la plataforma del complemento.
Los complementos de contenido y panel de tareas asumen la misma configuración SSL que el explorador usa de forma predeterminada y permiten que la mayoría del contenido solo se entregue mediante SSL. Los complementos de Outlook obligan a que todo el contenido se entregue a través de SSL. Los desarrolladores deben especificar en el <elemento SourceLocation> del manifiesto del complemento una dirección URL que use HTTPS para identificar la ubicación del archivo HTML del complemento.

Para asegurarse de que los complementos no entregan contenido mediante HTTP, al probar los complementos, los desarrolladores deben asegurarse de que se selecciona la siguiente configuración en Opciones de Internet en Panel de control y que no aparecen advertencias de seguridad en sus escenarios de prueba.
- Asegúrese de que la opción de seguridad Mostrar contenido mixto de la zona Internet está establecida en Pedir datos. Para ello, seleccione lo siguiente en Opciones de Internet: en la pestaña Seguridad , seleccione la zona Internet , seleccione Nivel personalizado, desplácese para buscar Mostrar contenido mixto y seleccione Preguntar si aún no está seleccionado.
- Asegúrese de que la opción Avisar si se cambia entre los modos seguro y no seguro esté seleccionada en la pestaña Opciones avanzadas del cuadro de diálogo Opciones de Internet.
Para asegurarse de que los complementos no realizan un uso excesivo del núcleo de CPU o los recursos de memoria y no provocan una denegación de servicio en un equipo cliente, la plataforma del complemento establece límites de uso de recursos. Como parte de las pruebas, los desarrolladores deben verificar si un complemento respeta dichos límites.
Antes de publicar un complemento, los desarrolladores deben asegurarse de que cualquier información identificable personal que expongan en los archivos de su complemento está protegido.
Los desarrolladores no deben insertar claves que usen para acceder a las API o servicios de Microsoft y otros (como Bing, Google o Facebook) directamente en las páginas HTML de su complemento. En su lugar, pueden crear un servicio web personalizado o almacenar las claves con otro tipo de almacenamiento web seguro, al que puedan llamar para pasar al complemento los valores de las claves.
Los desarrolladores deben hacer lo siguiente al enviar un complemento a AppSource.
- Hospedar el complemento que van a enviar en un servidor web que admita SSL
- Elaborar una declaración que describa una directiva de privacidad válida.
- Firmar un acuerdo contractual al enviar el complemento

Al margen de las reglas de uso de recursos, los desarrolladores de complementos de Outlook también tienen que asegurarse de que los complementos cumplen los límites a la hora de especificar las reglas de activación y usar la API de JavaScript. Para más información, vea Límites de activación y API de JavaScript para complementos de Outlook.

Control de administradores de TI

En un entorno corporativo, los administradores de TI tienen la máxima autoridad para habilitar o deshabilitar el acceso a AppSource y a los catálogos privados.

La administración y el cumplimiento de los ajustes de Office se realiza con la configuración de directivas de grupo. Estos son configurables a través de la Herramienta de implementación de Office, junto con la Herramienta de personalización de Office.

Nombre de la opción	Descripción
Permitir complementos web y catálogos no seguros	Permite a los usuarios ejecutar complementos de Office no seguros, que son complementos de Office que tienen páginas web o ubicaciones de catálogo que no están protegidas por SSL (https://) y no están en las zonas de Internet de los usuarios.
Bloquear complementos web	Permite impedir que los usuarios ejecuten complementos de Office que usan tecnologías web.
Bloquear Tienda Office	Permite impedir que los usuarios obtengan o ejecuten complementos de Office que proceden de AppSource.