Modely řízení a správy

Pokud chcete zachovat zabezpečení a kontrolu při nasazování agentů v Microsoft 365, musíte porozumět základním modelům zásad správného řízení a správy. Microsoft 365 nabízí dva různé přístupy k architektuře, z nichž každá má různé mechanismy zabezpečení, mechanismy souhlasu a možnosti správy.

Agenty můžete nasadit jako roboty Teams v Microsoft 365 Copilot a Copilot Chatu. Navíc můžete agenty hostovat sami na platformách, které vlastníte, například na webovém portálu nebo v mobilní aplikaci.

Volba mezi těmito modely ovlivňuje, jak vaše organizace spravuje přístup k datům, uživatelská oprávnění a integrace externích služeb. Tento článek porovnává model aplikace Teams a model agenta Copilot, aby vám pomohl porozumět jejich dopadům na zabezpečení a určit, který přístup nejlépe vyhovuje požadavkům vaší organizace.

Model aplikace Teams

Stávající aplikace Teams a Power Platform poskytují kontrolu na úrovni jednotlivých aplikací i konektorů, což znamená, že vyžadují souhlas administrátora při pořízení. Například aplikace Teams žádají souhlas při instalaci a nelze získat konektory Power Platform, pokud jsou blokovány datovými politikami.

Model aplikace Teams implementuje bezpečnostní kontroly zvenčí dovnitř tam, kde administrátorský souhlas probíhá při akvizici aplikace. Tento model poskytuje podrobnou kontrolu nad přístupem externích služeb k hranicím klienta Microsoft 365.

Tento model umožňuje definovat obsah a pracovní zatížení jako podrobné objekty, jako jsou zprávy Teams, e-maily a chráněná externí data Microsoft Entra jako Service Now.

V tomto modelu externí služby vyžadují explicitní povolení k přístupu k datům tenantů, i když aktivně nevyužívají udělená oprávnění. Tento přístup umožňuje detailní definice obsahu a zátěže včetně zpráv v Microsoft Teams, e-mailů a externích datových zdrojů spravovaných pomocí Entra.

Mechanismus ověřování služby snižuje rizika otravy DNS (Domain Name System) nebo útoků na únos domény, protože je nutné kompromitovat samotnou aplikační službu k získání přihlašovacích údajů. Dosažení odpovídající obsahové granularity pro různé požadavky zákazníků (na jednu schránku, na web atd.) však může být náročné.

Model agenta Copilota

V tomto modelu uživatelé dávají souhlas v okamžiku vyvolání. Pokaždé, když aplikace odešle data, je uživatel vyzván, aby povolil přístup k určenému cíli. V tomto modelu nelze izolovat obsah ani pracovní zátěž, protože po syntetizaci je veškerý obsah typu Copilot Chat. Externí adresa URL se stává granulárním objektem nebo rozsahem řízení, se zařazením odkazů na seznam povolených a inspekcí aplikačních balíčků.

Model agenta Copilot používá vnitřní kontrolní mechanismy zabezpečení, ve kterých uživatelé udělí souhlas v okamžiku vyvolání. Uživatelé dostávají výzvy k povolení sdílení dat pokaždé, když informace opustí hranici tenantu k externím službám.

Tento model nezahrnuje přihlašovací údaje na úrovni služby, proto aplikujte odpovídající zpevnění API. Správci můžou zabránit tomu, aby typy obsahu opustily tenanta tím, že jejich spotřebu v Copilot zcela zablokují prostřednictvím popisků ochrany před únikem informací.

Model umožňuje granulární souhlas na úrovni pro každou zprávu nebo na volání, ale zcela spoléhá na rozhodnutí uživatelů bez administrativních zásahů.

Další krok

Pochopte datové toky agentů a identifikujte bezpečnostní hranice, požadavky na důvěru a potenciální zranitelnosti v agentních systémech.

Referenční datové toky a modely hrozeb pro hodnocení bezpečnosti