Zásady ochrany před ztrátou dat (DLP).

Prevence ztráty dat (DLP) je kritickým aspektem zachování bezpečnosti dat a dodržování předpisů v rámci ekosystému Microsoft Power Platform.

Můžete vytvořit zásady pro data, které mohou sloužit jako svodidla, která sníží riziko neúmyslného odhalení organizačních dat. Základní součást Power Apps, Power Automate a Microsoft Copilot Studio je použití konektorů pro výčet, naplnění, nabídky a vyžádání dat. Zásady pro data v centru pro správu Power Platform umožňují správcům řídit přístup k těmto konektorům různými způsoby, aby pomohli snížit rizika ve vaší organizaci.

Tento přehled popisuje některé základní koncepty související s konektory a několik důležitých aspektů, které je třeba vzít v úvahu při nastavování zásad nebo provádění změn zásad.

Spojnice

Konektory na své nejzákladnější úrovni jsou silně typované reprezentace klidných rozhraní pro programování aplikací, známých také jako API. Například rozhraní Power Platform API poskytuje několik operací souvisejících s funkčností v centru pro správu Power Platform.

Když zabalíte Power Platform API do konektoru, je pro tvůrce a vývojáře pro občany snazší používat API ve svých aplikacích, pracovních postupech a chatbotech s minimálním psaním kódu. Například konektor Power Platform for Admins V2 představuje rozhraní Power Platform API a vidíme, že akce „Získat doporučení“ je jednoduše přetažením do toku:

V tomto článku je uvedeno několik typů konektorů a každý z nich má funkce v rámci datových zásad.

Certifikované konektory

Certifikované konektory označují konektory, které prošly přísným testováním a certifikačními procesy, aby bylo zajištěno, že splňují standardy společnosti Microsoft pro zabezpečení, spolehlivost a dodržování předpisů. Tyto konektory poskytují uživatelům spolehlivé prostředky pro integraci s dalšími službami společnosti Microsoft a externími službami, to vše při zachování integrity a zabezpečení dat.

Další informace o certifikovaných konektorech naleznete v části Pokyny k předložení certifikace.

Vlastní konektory

Vlastní konektory umožňují výrobcům vytvářet vlastní konektory pro integraci s externími systémy nebo službami, na které se nevztahuje standardní sada certifikovaných konektorů. Vlastní konektory sice nabízejí flexibilitu a možnosti přizpůsobení, ale vyžadují pečlivé zvážení, aby bylo zajištěno, že budou v souladu s datovými zásadami a neohrozí zabezpečení dat.

Přečtěte si další informace o vytváření a správě vlastních konektorů.

Virtuální konektory

Virtuální konektory jsou konektory, které se zobrazují v zásadách dat, které mohou správci ovládat, ale nejsou založeny na rozhraní API restful. Šíření virtuálních konektorů pramení z toho, že datové zásady jsou jedním z nejoblíbenějších ovládacích prvků řízení v Power Platform. Očekává se, že více těchto typů funkcí „on/off“ se objeví jako pravidla v rámci skupin prostředí.

Pro řízení je k dispozici několik virtuálních konektorů Microsoft Copilot Studio. Tyto konektory usnadňují možnost vypnout různé funkce Copilotů a chatbotů.

Prozkoumejte virtuální konektory a jejich roli v prevenci ztráty dat v Microsoft Copilot Studio.

Propojení

Když tvůrce vytváří aplikaci nebo tok a potřebuje se připojit k datům, může použít jeden z výše uvedených typů konektorů. Když je konektor poprvé přidán do aplikace, je navázáno připojení pomocí ověřovacích protokolů podporovaných tímto konkrétním konektorem. Tato připojení představují uložená pověření a jsou uložena v prostředí, které je hostitelem aplikace nebo toku. Další informace o ověřování konektorů viz Připojení a ověřování zdrojů dat.

Design-time versus runtime

Když se správce rozhodne omezit přístup buď k celému konektoru, nebo ke konkrétním akcím konektoru, bude to mít dopad jak na prostředí tvůrce, tak na spouštění dříve vytvořených aplikací, toků a chatbotů.

Zkušenosti tvůrců, často označované jako zkušenosti doby návrhu, omezují, s jakými konektory mohou tvůrci komunikovat. Pokud zásady dat zablokovaly použití konektoru počasí MSN, pak tvůrce nemůže uložit svůj tok nebo aplikaci, která toto využívá, a místo toho obdrží chybovou zprávu, že konektor byl zablokován zásadou.

Zkušenosti, kdy je aplikace spuštěna nebo tok probíhá podle předem definovaného plánu, například každý den ve 3:00, se často označují jako zkušenosti runtime. Pokračujeme v předchozím příkladu, pokud bylo připojení deaktivováno procesem na pozadí popsaným níže, výsledkem je, že aplikace nebo tok zobrazí chybovou zprávu, že připojení MSN Weather je přerušeno a vyžaduje vyřešení. Když se tvůrce pokusí aktualizovat své připojení, aby jej opravil, zobrazí se v průběhu návrhu chyba, že konektor je blokován zásadou.

Proces změn zásad

Při vytváření nových zásad dat nebo při aktualizaci stávajících zásad se v rámci ekosystému služeb Power Platform spouští specifický proces, který pomáhá tyto zásady prosazovat napříč celou sadou zdrojů, které má zákazník ve svém klientovi. Proces zahrnuje následující kroky.

1. Konfigurace zásad dat se ukládá na úrovni správy zákazníka.
2. Konfigurace jsou kaskádovitě převedeny do každého prostředí v klientovi zákazníka.
3. Prostředky v každém prostředí (jako jsou aplikace, toky a chatboti) pravidelně kontrolují aktualizované konfigurace zásad.
4. Když je zjištěna změna konfigurace, každá aplikace, tok a chatbot jsou vyhodnoceny, aby se zjistilo, zda neporušuje zásady.
5. Pokud dojde k porušení, aplikace, tok nebo chatbot jsou zařazeny do stavu pozastaveno nebo karanténa tak, aby nemohly fungovat.
6. Spojení jsou skenována. Pokud zásada blokuje celý konektor, pak je připojení nastaveno na stav zakázáno tak, aby nemohl fungovat.
7. Všechny prostředky, které jsou spuštěny a pokoušejí se použít neaktivní připojení, za běhu selžou.

Důležité

Vynucení za běhu závisí na stavu připojení. Pokud ještě není deaktivováno nebo ještě nebylo zkontrolováno, může být připojení stále spuštěno za běhu bez chyby.

Aspekty latence

Doba potřebná k efektivní implementaci datových zásad se u jednotlivých zákazníků liší v závislosti na jejich objemu prostředí a zdrojů v těchto prostředích. Čím více aplikací, toků a chatbotů má zákazník, tím déle trvá, než se změny zásad plně projeví. V nejextrémnějších případech je latence plného vymáhání 24 hodin. Ve většině případů je to do hodiny.

Viz také

• Správa zásad ochrany před únikem informací
• Zásady DLP pro Power Automate