Modelos de gobernanza y administración

Para mantener la seguridad y el control al desplegar agentes en Microsoft 365, debes comprender los modelos subyacentes de gobernanza y administración. Microsoft 365 ofrece dos enfoques arquitectónicos distintos, cada uno con diferentes controles de seguridad, mecanismos de consentimiento y capacidades administrativas.

Puedes desplegar agentes como bots de Teams en Microsoft 365 Copilot y Copilot Chat. Además, puedes autoalojar agentes en plataformas que poseas, como un portal web o una aplicación móvil.

La elección entre estos modelos afecta a cómo tu organización gestiona el acceso a los datos, los permisos de usuario y las integraciones de servicios externos. Este artículo compara el modelo de la app de Teams y el modelo de agente Copilot para ayudarte a entender sus implicaciones de seguridad y determinar qué enfoque se adapta mejor a los requisitos de tu organización.

Modelo de la app de Teams

Las aplicaciones existentes de Teams y Power Platform proporcionan control a nivel de aplicación y conector, lo que significa que el consentimiento del administrador ocurre en el momento de la adquisición. Por ejemplo, las aplicaciones de Teams solicitan consentimiento para la instalación, y no puedes adquirir conectores de Power Platform si estás bloqueado por políticas de datos.

El modelo de la app de Teams implementa controles de seguridad externos donde el consentimiento administrativo ocurre en el momento de la adquisición de la aplicación. Este modelo proporciona un control granular sobre el acceso a servicios externos hasta los límites de los inquilinos de Microsoft 365.

Este modelo permite definir contenido y carga de trabajo como objetos granulares, como mensajes de Teams, correos electrónicos y datos externos bloqueados por Microsoft Entra como Service Now.

En este modelo, los servicios externos requieren permiso explícito para acceder a los datos del inquilino, incluso cuando no utilizan activamente los permisos concedidos. Este enfoque permite definiciones granulares de contenido y carga de trabajo, incluyendo mensajes de Teams, correos electrónicos y fuentes de datos externas con acceso a Entra.

El mecanismo de autenticación de servicio a servicio reduce los riesgos de envenenamiento DNS (Sistema de Nombres de Dominio) o ataques de secuestro de dominio, ya que es necesario comprometer el propio servicio de aplicación para obtener las credenciales de la aplicación. Sin embargo, lograr la granularidad adecuada del contenido para los diversos requisitos del cliente (por buzón, por sitio, etc.) puede ser un reto.

Modelo de agente copiloto

En este modelo, los usuarios dan su consentimiento en el momento de la invocación. Cada vez que la aplicación envía datos, se solicita al usuario que permita el acceso al punto final especificado. No puedes aislar contenido ni carga de trabajo en este modelo porque todo el contenido es del tipo Copilot Chat una vez sintetizado. La URL externa se convierte en el objeto granular o ámbito de control, con la inclusión de enlaces y la inspección del paquete de la app.

El modelo de agente Copilot utiliza controles de seguridad inside-out donde los usuarios dan su consentimiento en el momento de la invocación. Los usuarios reciben avisos para permitir el intercambio de datos cada vez que la información sale del límite del inquilino hacia servicios externos.

Este modelo no incluye credenciales de autenticación a nivel de servicio, así que aplica el endurecimiento adecuado de la API. Los administradores solo pueden evitar que los tipos de contenido salgan del inquilino bloqueando su consumo en Copilot completamente mediante etiquetas de prevención de pérdida de datos.

El modelo permite el consentimiento granular a nivel de mensaje o invocación, pero depende completamente de decisiones del usuario sin capacidades de intervención administrativa.

Paso siguiente

Comprender los flujos de datos de los agentes para identificar límites de seguridad, requisitos de confianza y posibles vulnerabilidades en los sistemas de los agentes.