Utilizarea în siguranță a Microsoft SQL Server cu Power Apps

Există diferite modalități de a vă conecta și autentifica la SQL Server cu Power Apps. Acest articol prezintă concepte care pot fi utile pentru a alege cum să vă conectați la SQL Server cu o abordare de securitate care corespunde cerințelor pentru aplicația dvs.

Important

Caracteristica de conexiuni implicite securizate a fost lansată în ianuarie 2024. Microsoft încurajează cu tărie toate aplicațiile care utilizează în prezent conexiuni implicite pentru a efectua conversia la conexiuni implicite securizate și pentru a revoca conexiunile partajate cu utilizatorii finali.

Diferența dintre conexiunile implicite, implicite și explicite

Se creează o conexiune la SQL Server ori de câte ori creați o aplicație utilizând Power Apps care se conectează la SQL Server. Atunci când aceste aplicații sunt publicate și partajate cu alte persoane, atât aplicația, cât și conexiunea sunt implementate pentru acei utilizatori. Cu alte cuvinte, aplicația și conexiunea, ambele sunt vizibile pentru utilizatorii cu care sunt partajate aplicațiile.

Metoda de autentificare utilizată pentru astfel de conexiuni poate fi explicită sau implicită. De asemenea, putem spune că o astfel de conexiune este partajată în mod explicit sau implicit.

• O conexiune partajată explicit înseamnă că utilizatorul final al aplicației trebuie să se autentifice la SQL Server cu propriile acreditări explicite. De obicei, această autentificare are loc în culise, ca parte a bătăii de mână de autentificare Microsoft Entra sau Windows. Utilizatorul nici măcar nu observă când are loc autentificarea.
• O conexiune partajată implicit înseamnă că utilizatorul utilizează în mod implicit acreditările contului pe care creatorul de aplicații l-a utilizat pentru a se conecta și a se autentifica la sursa de date în timpul creării aplicației. Acreditările utilizatorului final nu sunt utilizate pentru autentificare. De fiecare dată când utilizatorul final rulează aplicația, utilizează acreditările cu care autorul a creat aplicația.
• O conexiune partajată implicită securizată se referă la un scenariu în care utilizatorul final al aplicației utilizează în mod implicit acreditările contului pe care creatorul de aplicații l-a utilizat pentru conectarea și autentificarea la sursa de date în timp ce creați aplicația. Aceasta înseamnă că acreditările proprii ale utilizatorului final nu sunt utilizate pentru autentificare. În schimb, atunci când utilizatorul rulează aplicația, utilizează acreditările cu care l-a creat autorul aplicației. Este important să rețineți că utilizatorul final nu este furnizat cu acces direct la conexiune, iar aplicația permite doar accesul la un set limitat de acțiuni și tabele.

Următoarele patru tipuri de autentificare de conexiune pot fi utilizate cu SQL Server pentru Power Apps:

Tip de autentificare	Metoda de conexiune Power Apps
Microsoft Entra Integrated	Explicit
Autentificare SQL Server	Implicit /Secure Implicit
Autentificare Windows	Implicit /Secure Implicit
Autentificare Windows (nepartajată)	Explicit

Riscuri implicite de partajare a conexiunii

Toate aplicațiile noi utilizează automat noile conexiuni implicite securizate. Cu toate acestea, cu aplicațiile care utilizează "conexiunile implicite" mai vechi, atât aplicația, cât și conexiunile sale sunt implementate pentru utilizatorii finali, înseamnă că utilizatorii finali pot crea aplicații noi pe baza acelor conexiuni.

Atunci când un autor utilizează conexiuni implicite securizate, înseamnă că nu este partajată nicio conexiune și niciun utilizator final nu primește obiectul de conexiune. Acest lucru elimină riscul ca un autor final să reutilizeze o conexiune pentru a crea o aplicație nouă. În schimb, aplicația funcționează cu o conexiune proxy care cunoaște aplicația și comunică doar cu acea aplicație. Conexiunea proxy permite acțiuni limitate (creare, citire, actualizare, ștergere) și acces la anumite tabele din aplicație care sunt definite atunci când aplicația este publicată. Prin urmare, doar acțiunile și accesul autorizate sunt acordate utilizatorului final.

Stilul mai vechi, o conexiune implicită simplă distribuie de fapt un obiect de conexiune utilizatorului final. De exemplu, dacă creați o aplicație care elimină datele pe care nu doriți să le vadă utilizatorii. Dar, datele filtrate sunt prezente în baza de date. Dar vă bazați pe filtrul pe care l-ați configurat pentru a vă asigura că utilizatorii finali nu vor vedea anumite date.

Din nou, cu conexiuni implicite simple în stil mai vechi, după ce implementați aplicația, utilizatorii finali pot utiliza conexiunea implementată cu aplicația în orice aplicații noi pe care le creează. În noile aplicații, utilizatorii pot vedea datele pe care le-ați filtrat în aplicația dvs. Este important să utilizați noile conexiuni implicite securizate.

Important

După ce o conexiune partajată implicită mai veche este implementată pentru utilizatorii finali, restricțiile pe care le-ați introdus în aplicația pe care ați partajat-o (cum ar fi filtrele sau accesul doar în citire) nu mai sunt valide pentru aplicațiile noi create de utilizatorii finali. Utilizatorii finali vor avea orice drepturi permite autentificarea ca parte a conexiunii partajate implicit. Prin urmare, atunci când efectuați conversia unei aplicații pentru a utiliza conexiuni implicite sigure , trebuie să revocați și conexiunile pe care le-ați partajat cu aplicația. Administratorii pot obține un raport cu aplicațiile cu conexiuni partajate implicit cu kitul de instrumente COE.

Securitate client și server

Nu vă puteți baza pe securitatea datelor prin filtrare sau alte operațiuni pe partea client pentru a fi securizate. Aplicațiile care necesită filtrare securizată a datelor trebuie să se asigure că atât identificarea utilizatorului, cât și filtrarea au loc pe server.

Utilizați servicii cum ar fi Microsoft Entra ID în loc să vă bazați pe filtrele proiectate în aplicații atunci când vine vorba de identitatea și securitatea utilizatorilor. Această configurație asigură că filtrele pe partea server funcționează așa cum vă așteptați.

Următoarele ilustrații explică modul în care modelele de securitate din cadrul aplicațiilor diferă între modelele de securitate pe partea client și pe server.

Într-un model de aplicație de securitate client, [1] utilizatorul se autentifică doar în aplicația din partea clientului. Apoi[2] aplicația solicită informații ale serviciului și [3] serviciul returnează informațiile numai pe baza solicitării de date.

Într-un model de securitate pe partea server, [1] utilizatorul se autentifică mai întâi la serviciu, astfel încât utilizatorul să fie cunoscut pentru serviciu. Apoi, [2] atunci când se efectuează un apel din aplicație, serviciul [3] utilizează identitatea cunoscută a utilizatorului curent pentru a filtra datele corespunzător și [4] returnează datele.

Scenariile implicite de partajare a departamentelor descrise mai sus sunt combinații între aceste două modele. Utilizatorul trebuie să se conecteze la serviciul Power Apps utilizând acreditările Microsoft Entra. Acest comportament este modelul aplicației de securitate server. Utilizatorul este cunoscut utilizând identitatea Microsoft Entra în serviciu. Prin urmare, aplicația este restricționată la setul de utilizatori la care Power Apps a partajat oficial aplicația.

Cu toate acestea, conexiunea partajată implicită la SQL Server este modelul aplicației de securitate client. SQL Server știe doar că se utilizează un anumit nume de utilizator și o parolă. De exemplu, orice filtrare pe partea client poate fi ocolită cu o aplicație nouă, utilizând același nume de utilizator și aceeași parolă.

Pentru a filtra în siguranță datele de pe partea server, utilizați caracteristicile de securitate predefinite din SQL Server, cum ar fi securitatea la nivel de rând pentru rânduri și permisiunile refuzate pentru anumite obiecte (cum ar fi coloanele) pentru anumiți utilizatori. Această abordare utilizează identitatea de utilizator Microsoft Entra pentru a filtra datele de pe server.

Unele servicii corporative existente au utilizat o abordare în care identitatea utilizatorului este capturată într-un nivel de date de firmă, la fel cum face Microsoft Dataverse. În acest caz, stratul de firmă poate utiliza sau nu securitatea la nivel de rând a SQL Server și poate refuza direct caracteristicile. Dacă nu se întâmplă acest lucru, adesea este cazul în care securitatea este activată utilizând proceduri sau vizualizări stocate.

Stratul de afaceri (pe partea server) utilizează o identitate Microsoft Entra a utilizatorului cunoscut pentru a invoca o procedură stocată ca principal SQL Server și a filtra datele. Totuși, Power Apps nu se conectează în prezent la procedurile stocate. De asemenea, un nivel de afaceri poate invoca o vizualizare care utilizează identitatea Microsoft Entra ca principal SQL Server. În acest caz, utilizați Power Apps pentru a vă conecta la vizualizări, astfel încât datele să fie filtrate pe partea server. Expunerea doar a vizualizărilor utilizatorilor poate avea nevoie de fluxuri Power Automate pentru actualizări.

Consultați și

Prezentare generală a conectorilor pentru aplicațiile pe pânză