Modelos de governação e administração

Para manter a segurança e o controlo ao implementar agentes no Microsoft 365, deve compreender os modelos subjacentes de governação e administração. O Microsoft 365 oferece duas abordagens arquitetónicas distintas, cada uma com diferentes controlos de segurança, mecanismos de consentimento e capacidades administrativas.

Pode implementar agentes como bots do Teams, no Microsoft 365 Copilot e no Copilot Chat. Além disso, pode autoalojar agentes em plataformas suas, como portais web ou aplicações móveis.

A escolha entre estes modelos afeta a forma como a sua organização gere o acesso aos dados, as permissões dos utilizadores e as integrações com serviços externos. Este artigo compara o modelo da aplicação Teams e o modelo do agente Copilot para o ajudar a compreender as suas implicações de segurança e determinar qual a abordagem que melhor se adequa às necessidades da sua organização.

Modelo da aplicação Teams

As aplicações existentes do Teams e Power Platform fornecem controlo ao nível de cada aplicação e por conector, o que significa que o consentimento do administrador ocorre no momento da aquisição. Por exemplo, as aplicações do Teams pedem consentimento na instalação, e não pode adquirir conectores Power Platform se for bloqueado por políticas de dados.

O modelo de aplicação Teams implementa controlos de segurança externos para dentro onde ocorre consentimento administrativo no momento da aquisição da aplicação. Este modelo fornece controlo granular sobre o acesso a serviços externos aos limites dos tenants do Microsoft 365.

Este modelo permite definir conteúdo e carga de trabalho como objetos granulares, como mensagens do Teams, emails e dados externos bloqueados pelo Microsoft Entra, como o Service Now.

Neste modelo, os serviços externos requerem permissão explícita para aceder aos dados do inquilino, mesmo quando não utilizam ativamente as permissões concedidas. Esta abordagem permite definições granulares de conteúdo e carga de trabalho, incluindo mensagens do Teams, emails e fontes de dados externas controladas pelo Entra.

O mecanismo de autenticação serviço-a-serviço reduz os riscos de envenenamento DNS (Sistema de Nomes de Domínio) ou ataques de sequestro de domínio, pois é necessário comprometer o próprio serviço da aplicação para obter credenciais da aplicação. No entanto, alcançar a granularidade adequada do conteúdo para as diversas necessidades dos clientes (por caixa de correio, por site, etc.) pode ser um desafio.

Modelo de agente copiloto

Neste modelo, os utilizadores dão consentimento no momento da invocação. Cada vez que a aplicação envia dados, o utilizador é solicitado a permitir o acesso ao endpoint especificado. Não se pode isolar conteúdo ou carga de trabalho neste modelo porque todo o conteúdo é do tipo Copilot Chat uma vez sintetizado. O URL externo torna-se o objeto granular ou âmbito de controlo, com a inclusão de links e a inspeção dos pacotes da aplicação.

O modelo do agente Copilot utiliza controlos de segurança de dentro para fora, onde os utilizadores dão consentimento no momento da invocação. Os utilizadores recebem avisos para permitir a partilha de dados sempre que a informação sai do limite do inquilino para serviços externos.

Este modelo não inclui credenciais de autenticação ao nível de serviço, por isso aplique o reforço adequado da API. Os administradores só conseguem impedir que os tipos de conteúdo saiam do tenant bloqueando totalmente o seu consumo no Copilot através de rótulos de prevenção de perda de dados.

O modelo permite consentimento granular ao nível de mensagem ou invocação, mas depende inteiramente das decisões do utilizador sem capacidades administrativas de intervenção.

Próximo passo

Compreender os fluxos de dados dos agentes para identificar limites de segurança, requisitos de confiança e potenciais vulnerabilidades nos sistemas dos agentes.