Правила за данни

Предотвратяването на загуба на данни (DLP) е критичен аспект на поддържането на сигурността и съответствието на данните в рамките на екосистемата Microsoft Power Platform .

Можете да създадете правила за данни, които могат да действат като мантинели, за да помогнат за намаляване на риска потребителите от неволно излагане на организационни данни. Основен компонент на Power Apps, Power Automate, и е използването на конектори Microsoft Copilot Studio за изброяване, попълване, бутане и изтегляне на данни. Правилата за данни в Power Platform центъра за администриране позволяват на администраторите да контролират достъпа до тези конектори по различни начини, за да помогнат за намаляване на риска във вашата организация.

Този преглед описва някои концепции на високо ниво, свързани с конекторите, и няколко важни съображения, които трябва да вземете предвид при настройването на вашите политики или извършването на промени в правилата.

Конектори

Конекторите, на най-основното си ниво, са силно типизирани представяния на спокойни, приложно-програмни интерфейси, известни също като API. Например, API предоставя няколко операции, Power Platform свързани с функционалността в Power Platform центъра за администриране.

Когато опаковате Power Platform API в конектор, става по-лесно за производителите и гражданските разработчици да използват API в своите приложения с нисък код, работни потоци и чатботове. Например, конекторът Power Platform for Admins V2 е представянето на Power Platform API и виждаме, че действието "Получаване на препоръки" е просто плъзгане и пускане в потока:

Има няколко типа конектори, споменати в тази статия, и всеки от тях има възможности в рамките на правилата за данни.

Сертифицирани конектори

Сертифицираните конектори се отнасят до конектори, които са преминали строги процеси на тестване и сертифициране, за да се гарантира, че отговарят на стандартите на Microsoft за сигурност, надеждност и съответствие. Тези конектори предоставят на потребителите надеждно средство за интегриране с други услуги на Microsoft и външни услуги, като същевременно поддържат целостта и сигурността на данните.

За повече информация относно сертифицираните конектори вижте Указания за подаване на сертификати.

Персонализирани конектори

Персонализираните конектори позволяват на производителите да създават свои собствени конектори, за да се интегрират с външни системи или услуги, които не са обхванати от стандартния набор от сертифицирани конектори. Докато предлагат гъвкавост и опции за персонализиране, персонализираните конектори изискват внимателно обмисляне, за да се гарантира, че те спазват правилата за данни и не компрометират сигурността на данните.

Научете повече за създаването и управлението на конектори поизбор.

Виртуални конектори

Виртуалните конектори са конектори, които се показват в правилата за данни, които администраторите могат да контролират, но те не се основават на спокоен API. Разпространението на виртуални конектори произтича от това, че политиките за данни са един от най-популярните контроли за Power Platform управление. Повече от тези видове възможности за "включване / изключване" се очаква да се появят като правила в рамките на групите на околната среда.

За управление Microsoft Copilot Studio са предвидени няколко виртуални конектора. Тези конектори улесняват възможността за изключване на различни функции на Copilots и чатботове.

Разгледайте виртуалните конектори и тяхната роля в предотвратяването на загуба на данни в Microsoft Copilot Studio.

Връзки

Когато даден производител изгражда приложение или поток и трябва да се свърже с данни, той може да използва един от горните типове конектори. Когато конекторът се добави за първи път към приложение, връзката се установява с помощта на протоколите за удостоверяване, поддържани от този конкретен конектор. Тези връзки представляват запазени идентификационни данни и се съхраняват в средата, в която се хоства приложението или потока. За повече информация относно удостоверяването към съединители вижте Свързване и удостоверяване към източници на данни.

Време за проектиране спрямо време на изпълнение

Когато администраторът избере да ограничи достъпа до цял конектор или конкретни действия на конектор, има въздействие както върху опита на производителя, така и върху изпълнението на предварително създадени приложения, потоци и чатботове.

Опитът на производителя, често наричан опит с времето за проектиране, ограничава това, с което производителите на конектори могат да взаимодействат. Ако правилата за данни блокират използването на конектора MSN Weather, производителят не може да запише своя поток или приложение, което използва това, а вместо това получава съобщение за грешка, че конекторът е блокиран от правилата.

Преживяванията, при които се изпълнява приложение или поток се изпълнява по предварително определен график, като например всеки ден в 3:00 ч., често се наричат преживявания по време на изпълнение. Продължавайки с примера по-рано, ако връзката е била деактивирана от фоновия процес, описан по-долу, резултатът е, че приложението или потокът предоставя съобщение за грешка, че връзката MSN Weather е прекъсната и се нуждае от резолюция. Когато производителят се опита да актуализира връзката си, за да я поправи, той получава грешка във времето за проектиране, че конекторът е блокиран от правилата.

Процес на промени в политиката

Тъй като се създават нови правила за данни или когато съществуващите правила се актуализират, има специфичен процес, който се задейства в екосистемата Power Platform от услуги, който помага тези правила да бъдат приложени в целия набор от ресурси, които клиентът има в своя клиент. Този процес включва следните стъпки.

1. Конфигурацията на правилата за данни се записва на ниво управление на клиенти.
2. Конфигурациите са каскадни надолу към всяка среда в клиентския клиент.
3. Ресурсите във всяка среда (като приложения, потоци и чатботове) периодично проверяват за актуализирани конфигурации на правилата.
4. Когато се открие промяна в конфигурацията, всяко приложение, поток и чатбот се оценяват, за да се види дали нарушава правилата.
5. Ако възникне нарушение, приложението, потокът или чатботът се поставят в спряно или карантинно състояние, така че да не могат да работят.
6. Връзките се сканират. Ако правилата блокират целия конектор, връзката е настроена на забранено състояние, така че да не може да работи.
7. Всички ресурси, които се изпълняват и се опитват да използват неактивна връзка, се провалят по време на изпълнение.

Важно

Изпълнението по време на изпълнение зависи от състоянието на връзката. Ако все още не е инактивирана или все още не е сканирана, връзката все още може да бъде изпълнена по време на изпълнение без грешка.

Съображения за латентност

Времето, необходимо за ефективно прилагане на политиките за данни, варира от клиент до клиент въз основа на техния обем от среди и ресурси в тези среди. Колкото повече приложения, потоци и чатботове има клиентът, толкова по-дълго време е необходимо, за да влязат промените в правилата в пълна сила. За най-екстремните случаи латентността за пълно изпълнение е 24 часа. В повечето случаи това е в рамките на един час.

Вижте също

Управление на правилата за защита от загуба на данни (DLP)