Politici de date

Prevenirea pierderii datelor (DLP) este un aspect critic al menținerii securității și conformității datelor în cadrul Microsoft Power Platform ecosistemului.

Puteți crea politici de date care pot acționa ca balustrade pentru a ajuta la reducerea riscului utilizatorilor de a expune neintenționat datele organizaționale. O componentă de bază a Power Apps, Power Automate și Microsoft Copilot Studio este utilizarea conectorilor pentru a enumera, popula, împinge și extrage date. Politicile de date din Power Platform centrul de administrare permit administratorilor să controleze accesul la acești conectori în diferite moduri pentru a ajuta la reducerea riscurilor în organizația dvs.

Această prezentare generală descrie câteva concepte de nivel înalt legate de conectori și câteva considerații importante de luat în considerare atunci când configurați politicile dvs. sau faceți modificări de politică.

Conectori

Conectorii, la nivelul lor cel mai de bază, sunt reprezentări puternic tipizate ale interfețelor de programare a aplicațiilor odihnitoare, cunoscute și sub numele de API. De exemplu, Power Platform API oferă mai multe operațiuni legate de funcționalitatea în Power Platform centrul de administrare.

Când împachetați Power Platform API-ul într-un conector, devine mai ușor pentru producători și dezvoltatorii cetățeni să utilizeze API-ul în aplicațiile, fluxurile de lucru și chatbot-urile lor low-code. De exemplu, conectorul Power Platform for Admins V2 este reprezentarea Power Platform API și vedem că acțiunea „Obțineți recomandări” este pur și simplu trageți și plasați în flux:

Există mai multe tipuri de conectori menționate în acest articol și fiecare are capabilități în cadrul politicilor de date.

Conectori certificati

Conectorii certificați se referă la conectorii care au fost supuși unor procese riguroase de testare și certificare pentru a se asigura că respectă standardele Microsoft de securitate, fiabilitate și conformitate. Acești conectori oferă utilizatorilor un mijloc fiabil de integrare cu alte servicii Microsoft și servicii externe, toate menținând integritatea și securitatea datelor.

Pentru mai multe informații despre conectorii certificați, consultați Instrucțiunile de transmitere a certificării.

Conectori particularizați

Conectorii personalizați permit producătorilor să-și creeze propriii conectori pentru a se integra cu sisteme sau servicii externe care nu sunt acoperite de setul standard de conectori certificati. Deși oferă flexibilitate și opțiuni de personalizare, conectorii personalizați necesită o atenție atentă pentru a se asigura că respectă politicile de date și nu compromit securitatea datelor.

Aflați mai multe despre crearea și gestionarea conectorilor personalizați.

Conectori virtuali

Conectorii virtuali sunt conectori care sunt afișați în politicile de date pentru ca administratorii să îi controleze, dar nu se bazează pe un API odihnitor. Proliferarea conectorilor virtuali a rezultat din politicile de date, fiind unul dintre cele mai populare controale de guvernare din Power Platform. Se așteaptă ca mai multe dintre aceste tipuri de capabilități „pornit/oprit” să apară ca reguli în cadrul grupurilor de mediu.

Sunt furnizați mai mulți conectori virtuali pentru guvernarea Microsoft Copilot Studio. Acești conectori facilitează capacitatea de a dezactiva diverse funcții ale Copiloților și chatbot-urilor.

Explorați conectorii virtuali și rolul acestora în prevenirea pierderii datelor în Microsoft Copilot Studio.

Conexiuni

Când un producător creează o aplicație sau un flux și trebuie să se conecteze la date, poate folosi unul dintre tipurile de conector de mai sus. Când un conector este adăugat pentru prima dată la o aplicație, o conexiune este stabilită folosind protocoalele de autentificare acceptate de acel conector. Aceste conexiuni reprezintă o acreditare salvată și sunt stocate în mediul care găzduiește aplicația sau fluxul. Pentru mai multe informații despre autentificarea la conectori, consultați Conectarea și autentificarea la sursele de date.

Timpul de proiectare versus timpul de rulare

Când un administrator alege să limiteze accesul fie la un conector întreg, fie la acțiuni specifice ale unui conector, există impact atât asupra experienței producătorului, cât și asupra execuției aplicațiilor, fluxurilor și chatbot-urilor create anterior.

Experiențele creatorilor, deseori denumite experiențe în timpul designului , limitează cu ce pot interacționa producătorii de conectori. Dacă o politică de date a blocat utilizarea conectorului MSN Weather, atunci un producător nu își poate salva fluxul sau aplicația care utilizează acest lucru și, în schimb, primește un mesaj de eroare că conectorul a fost blocat de politică.

Experiențele în care se rulează o aplicație sau se execută un flux într-un program predefinit, cum ar fi în fiecare zi la ora 3:00, sunt adesea denumite experiențe execuție . Continuând cu exemplul de mai devreme, dacă conexiunea a fost dezactivată de procesul de fundal prezentat mai jos, atunci rezultatul este că aplicația sau fluxul furnizează un mesaj de eroare că conexiunea MSN Weather este întreruptă și necesită rezolvare. Când producătorul încearcă să-și actualizeze conexiunea pentru a o remedia, primește o eroare în experiența de proiectare, conform căreia conectorul este blocat de politică.

Procesul de modificare a politicii

Pe măsură ce sunt create noi politici de date sau când politicile existente sunt actualizate, există un proces specific care este declanșat în cadrul Power Platform ecosistem de servicii care ajută la aplicarea acestor politici în întregul set de resurse pe care un client le are în chiriașul său. Acest proces implică următorii pași.

1. Configurarea politicii de date este salvată la nivelul de management al clienților.
2. Configurațiile sunt în cascadă în fiecare mediu din chiriașul clientului.
3. Resursele din fiecare mediu (cum ar fi aplicații, fluxuri și chatbot) verifică periodic configurațiile actualizate ale politicilor.
4. Când este detectată o modificare a configurației, fiecare aplicație, flux și chatbot sunt evaluate pentru a vedea dacă încalcă politica.
5. Dacă are loc o încălcare, aplicația, fluxul sau chatbot-ul este plasat într-o stare suspendată sau carantină așa ca nu poate functiona.
6. Conexiunile sunt scanate. Dacă politica blochează întregul conector, atunci conexiunea este setată la starea dezactivată , astfel încât să nu poată funcționa.
7. Orice resurse care rulează și încearcă să utilizeze o conexiune inactivă eșuează în timpul execuției.

Important

Aplicarea timpului de execuție se bazează pe starea conexiunii. Dacă nu este încă dezactivat sau nu a fost încă scanat, atunci conexiunea poate fi încă executată în timpul execuției fără eroare.

Considerații privind latența

Timpul necesar pentru implementarea eficientă a politicilor de date variază de la client la client, în funcție de volumul de medii și resurse din acele medii. Cu cât un client are mai multe aplicații, fluxuri și chatboți, cu atât este nevoie de mai mult timp pentru ca modificările politicii să intre în vigoare. Pentru cazurile cele mai extreme, latența pentru aplicarea completă este de 24 de ore. În cele mai multe cazuri, este într-o oră.

Consultați și

Gestionarea politicilor de prevenire a pierderilor de date (DLP)