DLP v Teams: zpráva není soubor

Správce vloží do Teams odkaz na testovací dokument a externí příjemce ho nedokáže otevřít. Pilot označí za úspěšný. Stejný citlivý údaj ale kolega napíše přímo do chatu a zpráva projde. První test ověřil ochranu souboru v SharePointu nebo OneDrivu, nikoli DLP nad textem zpráv Teams.

DLP pro e-maily a soubory a DLP pro zprávy Teams mají jiný licenční i technický rozsah. Office 365 nebo Microsoft 365 E3 může pokrývat příslušné DLP pro SharePoint, OneDrive a Exchange; z toho neplyne právo chránit také obsah chatových a kanálových zpráv. A ani správná licence nepomůže, když zásada míří na nesprávný typ konverzace nebo populace.

Článek vychází z dokumentace Teams DLP a aktuálního popisu Purview služeb, ověřených 20. října 2026. Příklady se týkají interního firemního pilotu; číselný model není nabídkou konkrétního SKU ani výpočtem licencí externích organizací.

Začněte objektem, který má být chráněný

Uživatel vidí jedno okno Teams, ale data za ním nejsou jedna služba. Text zprávy prochází jinou DLP kontrolou než dokument, ke kterému zpráva obsahuje odkaz. Microsoft v návodu DLP pro Teams tyto scénáře výslovně rozlišuje.

Ochranu koncového zařízení ani pravidla pro všechny prohlížeče nepřidávejte do závěru pilotu jen proto, že se podařilo zablokovat jednu Teams zprávu. Nejdřív zakreslete cestu, kterou mají data odcházet. Jedna dobře pojmenovaná testovací akce je hodnotnější než obecný výsledek „DLP funguje“.

Licence se počítají podle příjemců funkce

Aktuální Purview service description popisuje u Teams DLP přínos pro odesílatele, jejichž odchozí zprávy jsou kontrolovány. Funkce může být technicky dostupná na úrovni tenantu; licence správce proto sama nepokrývá všechny kontrolované zaměstnance.

Mezi uvedené možnosti patří Office 365 E5, Microsoft 365 E5 a příslušné vyšší Purview nabídky. Přesný doplněk a jeho předpoklady ověřte v řádku DLP for Teams, nikoli podle podobnosti názvu s jiným DLP produktem. Jde o příklady, ne uzavřený seznam všech komerčních, školských či veřejnosprávních variant.

Samotné Business Premium nepovažujte za důkaz práv k DLP zpráv Teams. Popis služby jej uvádí u DLP pro e-maily a soubory, což je jiná část tabulky. A právo používat samotné Teams je další otázka: varianta Microsoft 365 bez Teams musí mít odpovídající přístup ke službě vyřešený samostatně.

Hypotetický příklad: 100 interních pracovníků má Microsoft 365 E3 a odpovídající práva k Teams. Dvanáct z nich má pilotně používat DLP pro odchozí zprávy. Předpokládáme, že vybrané vyšší licence či doplňky jejich scénář skutečně pokrývají.

Tento model nevypočítává každou další Purview funkci ani automaticky nepožaduje licenci za každého externího příjemce. Základní otázka zní: čí zprávy tato konkrétní funkce skutečně kontroluje a z čeho plyne jeho oprávnění?

Výběr uživatele neověřuje kanály

Dokumentace Teams DLP obsahuje důležité rozlišení cílení. Jednotlivé uživatelské účty mají podle tabulky podporu pro individuální a skupinové chaty, ale nikoli pro zprávy standardních, privátních a sdílených kanálů. U podporovaných skupin je uvedený rozsah širší.

Pro dvanáctičlenný pilot proto nestačí vybrat dvanáct účtů, vyzkoušet chat a stejný závěr přenést na kanály. Zvolte podporované skupinové cílení, ověřte skutečné členství a zvlášť otestujte požadovaný kanálový scénář. Název skupiny „DLP pilot“ není důkaz jejího obsahu.

Pokud později někdo rozšíří členství skupiny nebo změní umístění zásady, může změnit také licenční rozsah. Do provozního předání přidejte vlastníka skupiny, zásady a evidence licencí. Tato vazba je podstatnější než jednorázový screenshot všech zelených nastavení.

Sdílený kanál a externí chat se nechovají stejně

U sdíleného kanálu přes B2B direct connect současná dokumentace popisuje vyhodnocení podle domovské organizace odesílatele. Zprávy pracovníka firmy A podléhají zásadám A, zprávy pracovníka firmy B zásadám B, bez ohledu na vlastnictví sdíleného kanálu. Firma A tím nezískává možnost vynucovat svou zásadu na zprávách pracovníka B.

U federovaného externího chatu dokumentace naopak rozlišuje hosting tenant, který chat nebo vlákno založil. V popsaném scénáři se zásady A uplatní na zprávy jejích lidí tehdy, když je hostitelem A; zásady B se na zprávy uživatelů B v tomto chatu automaticky neuplatní. Domovská DLP zásada tedy nemá být považována za ochranu, která uživatele automaticky následuje do každé konverzace.

Při testování založte konverzaci z obou stran a zaznamenejte, kdo ji inicioval. Sdílený kanál nezapisujte do stejného řádku jako běžný externí chat nebo hostovský účet. Jde o různé modely identity a komunikace, nikoli tři názvy jedné funkce. Přístupovou část řeší také návod ke sdíleným kanálům s externisty.

Ochrana připojeného souboru zůstává samostatnou kontrolou podle jeho skutečného umístění a pravidel SharePointu či OneDrivu. Ani správný výsledek pro zprávu externího účastníka nedokazuje shodný výsledek pro všechny dokumenty v kanálu.

Simulace není důkaz blokace

Simulation mode vyhodnocuje zásadu bez skutečného vynucení a poskytuje samostatné výsledky. U Teams se v tomto režimu vyhodnocují nové položky vzniklé během simulace. Odeslaná zpráva, která projde, proto může být očekávaným výsledkem testovacího režimu; starý obsah bez nové testovací akce zase nestačí pro ověření pravidla.

Použijte syntetický obsah, který podle dokumentace odpovídá vybranému typu citlivé informace. Neověřujte ochranu skutečnými osobními údaji. Zaznamenejte také prahovou hodnotu, výjimky a možnost uživatelského přepsání: zásada s povoleným override má jiný očekávaný výsledek než bezvýjimečné blokování.

Po simulaci následuje omezený test vynucení. Od uživatelského upozornění rozlišujte skutečné znepřístupnění zprávy nebo souboru příjemci. DLP pro Teams navíc nepoužívá stejné e-mailové notifikace uživatelům jako Exchange, SharePoint a OneDrive; absence e-mailu sama neprokazuje, že pravidlo neproběhlo.

Testovací matice před předáním do provozu

Každý řádek potřebuje předem napsaný očekávaný výsledek podle konkrétní zásady. Pokud aplikace zprávu zablokuje, ale udělala to jiná zásada, tento test ještě nepotvrdil nový návrh.

1. Určete chráněná data a cesty jejich předání, nikoli pouze seznam používaných aplikací.
2. Oddělte DLP pro soubory, zprávy a případná koncová zařízení; pro každou funkci zkontrolujte práva.
3. Sjednoťte licenci a skutečnou populaci zásady. Ověřte službu Microsoft Communications DLP v příslušném plánu podle service description.
4. Vyberte podporované cílení pro chaty i požadované kanály a ověřte členství.
5. Proveďte simulaci s novými testovacími zprávami, potom omezený test vynucení.
6. Do dokumentace připojte výsledky příjemců a externích směrů, ne pouze zobrazení portálu správce.

Pro výběr širšího bezpečnostního balíčku navazuje porovnání Microsoft 365 E3, E5 a doplňků. Rozhodnutí o balíčku má vycházet z ověřených funkcí a populace, ne nahrazovat jejich popis.