Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Чтобы поддерживать безопасность и контроль при развертывании агентов в Microsoft 365, необходимо понимать базовые модели управления и администрирования. Microsoft 365 предлагает два различных архитектурных подхода, каждый из которых включает разные системы контроля безопасности, механизмы согласия и административные возможности.
Вы можете развернуть агентов в виде ботов Teams в Microsoft 365 Copilot и Copilot Chat. Кроме того, вы можете самостоятельно размещать агентов на своих платформах, таких как веб-портал или мобильное приложение.
Выбор между этими моделями влияет на то, как ваша организация управляет доступом к данным, правами пользователей и интеграциями внешних сервисов. В этой статье мы сравниваете модель приложения Teams и модель агент Copilot, чтобы помочь вам понять их последствия для безопасности и определить, какой подход лучше всего соответствует вашим требованиям организации.
Модель приложений Teams
Существующие приложения Teams и Power Platform обеспечивают контроль на уровне каждого приложения и каждого коннектора, что означает, что согласие администратора происходит в момент приобретения. Например, приложения Teams запрашивают согласие при установке, и вы не можете получить разъёмы Power Platform, если они заблокированы политикой по данным.
Модель приложения Teams реализует внешние системы контроля безопасности, где административное согласие происходит в момент приобретения приложения. Эта модель обеспечивает точный контроль доступа внешних служб в пределах границ арендатора Microsoft 365.
Эта модель позволяет определять контент и нагрузку как детализированные объекты, такие как сообщения Teams, электронные письма и внешние данные с ограничением Microsoft Entra, такие как Service Now.
В этой модели внешние сервисы требуют явного разрешения для доступа к данным арендаторов, даже если они не используют предоставленные разрешения. Такой подход позволяет детализировать определения контента и рабочей нагрузки, включая сообщения Teams, электронные письма и внешние источники данных, связанные с Entra.
Механизм межсервисной аутентификации снижает риски атак типа DNS poisoning (Domain Name System) или перехвата домена, поскольку для получения учетных данных приложения необходимо скомпрометировать сам сервис приложения. Однако достижение нужной детализации контента для различных потребностей клиентов (на почтовый ящик, на каждый сайт и так далее) может быть сложно.
Модель агента Copilot
В этой модели пользователи дают согласие в момент вызова. Каждый раз, когда приложение отправляет данные, пользователю предлагается разрешить доступ к указанной конечной точке. В этой модели нельзя изолировать контент или нагрузку, потому что весь контент после синтеза относится к типу Copilot Chat. Внешний URL становится детальным объектом или областью контроля с использованием списка разрешённых ссылок и проверкой пакета приложения.
Модель агента Copilot использует механизмы безопасности, работающие по принципу «изнутри наружу», при которой пользователи дают согласие в момент вызова. Пользователи каждый раз получают запрос на разрешение передачи данных, когда информация покидает границы клиента и передаётся во внешние сервисы.
Эта модель не включает учётные данные аутентификации на уровне сервиса, поэтому применяйте соответствующее усиление API. Администраторы могут не допустить выхода типов содержимого за пределы арендатора, только полностью блокируя их использование в Copilot с помощью меток предотвращения потери данных.
Модель обеспечивает детализированное согласие на уровне каждого сообщения или вызова, но полностью опирается на решения пользователя без административного вмешательства.
Следующий шаг
Понимание потоков данных агентов для выявления границ безопасности, требований доверия и потенциальных уязвимостей в агентных системах.