Bezpečné používání Microsoft SQL Serveru s Power Apps

Existují různé způsoby připojení a ověřování k SQL Serveru pomocí Power Apps. Tento článek popisuje koncepty, které můžou být užitečné při rozhodování o tom, jak se připojit k SQL Serveru pomocí přístupu zabezpečení, který odpovídá požadavkům vaší aplikace.

Důležité

Funkce zabezpečeného implicitního připojení byla vydána v lednu 2024. Microsoft důrazně vyzývá všechny aplikace, které v současné době používají implicitní připojení, aby se převedli na zabezpečená implicitní připojení a odvolali připojení sdílená s koncovými uživateli.

Rozdíl mezi explicitními, implicitními a zabezpečenými implicitními připojeními

Připojení k SQL Serveru se vytvoří pokaždé, když vytvoříte aplikaci pomocí Power Apps, která se připojuje k SQL Serveru. Když jsou takové aplikace publikované a sdílené s ostatními, nasadí se těmto uživatelům jak aplikace, tak připojení. Jinými slovy, aplikace a připojení – obě jsou viditelné pro uživatele, se kterými se aplikace sdílí.

Metoda ověřování používaná pro taková připojení může být explicitní nebo implicitní. Můžeme také říci, že takové připojení je sdíleno explicitně nebo implicitně.

• Explicitně sdílené připojení znamená, že koncový uživatel aplikace se musí ověřit na SQL Serveru pomocí vlastních explicitních přihlašovacích údajů. K tomuto ověřování obvykle dochází na pozadí jako součást ověřování Microsoft Entra nebo Windows handshake. Uživatel si ani nevšimne, kdy se ověřování provede.
• Implicitně sdílené připojení znamená, že uživatel implicitně používá přihlašovací údaje účtu, který tvůrce aplikace použil k připojení a ověření ke zdroji dat během vytváření aplikace. Přihlašovací údaje koncového uživatele se nepoužívají k ověření. Pokaždé, když koncový uživatel spustí aplikaci, použije přihlašovací údaje, se kterými autor aplikaci vytvořil.
• Zabezpečené implicitně sdílené připojení odkazuje na scénář, ve kterém koncový uživatel aplikace implicitně používá přihlašovací údaje účtu, který tvůrce aplikace použil k připojení a ověření ke zdroji dat při vytváření aplikace. To znamená, že k ověření se nepoužívají vlastní přihlašovací údaje koncového uživatele. Místo toho, když uživatel spustí aplikaci, používá přihlašovací údaje, se kterými ji vytvořil autor aplikace. Je důležité si uvědomit, že koncový uživatel není k dispozici s přímým přístupem k připojení a aplikace umožňuje přístup pouze k omezené sadě akcí a tabulek.

S SQL Serverem pro Power Apps je možné použít následující čtyři typy ověřování připojení:

Typ ověřování	Metoda připojení Power Apps
Integrované Microsoft Entra	Explicitní
Ověřování SQL Serveru	Implicitní /zabezpečený implicitní
Ověřování systému Windows	Implicitní /zabezpečený implicitní
Ověřování systému Windows (nesdílené)	Explicitní

Rizika implicitního sdílení připojení

Všechny nové aplikace automaticky používají nová zabezpečená implicitní připojení. U aplikací, které používají starší implicitní připojení, se ale aplikace i její připojení nasazují koncovým uživatelům, znamená to, že koncoví uživatelé můžou vytvářet nové aplikace založené na těchto připojeních.

Když autor používá zabezpečená implicitní připojení, znamená to, že se nesdílí žádné připojení a žádný koncový uživatel objekt připojení neobdrží. Tím se eliminuje riziko, že autor koncového uživatele znovu používá připojení k vytvoření nové aplikace. Místo toho aplikace funguje s připojením proxy, které o aplikaci vědí a komunikují pouze s danou konkrétní aplikací. Připojení proxy serveru umožňuje omezené akce (vytvoření, čtení, aktualizace, odstranění) a přístup ke konkrétním tabulkám v aplikaci, které jsou definované při publikování aplikace. Proto jsou koncovému uživateli uděleny pouze autorizované akce a přístup.

Starší styl jednoduché implicitní připojení ve skutečnosti distribuuje objekt připojení koncovému uživateli. Pokud například vytvoříte aplikaci, která vyfiltruje data, která nechcete, aby uživatelé viděli. Vyfiltrovaná data se ale nacházejí v databázi. Spoléháte ale na filtr, který jste nakonfigurovali, aby koncoví uživatelé neviděli určitá data.

Opět platí, že při použití starších jednoduchých implicitních připojení po nasazení aplikace můžou koncoví uživatelé použít připojení nasazené s vaší aplikací v nových aplikacích, které vytvoří. V nových aplikacích uvidí uživatelé data, která jste vyfiltrovali ve své aplikaci. Je důležité používat nová zabezpečená implicitní připojení.

Důležité

Jakmile se koncovým uživatelům nasadí starší implicitně sdílené připojení, omezení, která jste možná uložili do aplikace, kterou sdílíte (například filtry nebo přístup jen pro čtení), už neplatí pro nové aplikace, které koncoví uživatelé vytvářejí. Koncoví uživatelé budou mít jakákoli práva, která ověřování umožňuje jako součást implicitně sdíleného připojení. Proto když převedete aplikaci tak, aby používala zabezpečená implicitní připojení, musíte také odvolat připojení, která jste s aplikací sdíleli. Správci můžou získat sestavu aplikací s implicitně sdílenými připojeními pomocí sady nástrojů COE.

Zabezpečení klienta a serveru

Při filtrování nebo jiných operacích na straně klienta nemůžete spoléhat na zabezpečení dat. Aplikace, které vyžadují zabezpečené filtrování dat, musí zajistit, aby se na serveru stalo identifikace uživatele i filtrování.

Pokud jde o identitu uživatele a zabezpečení, použijte služby, jako je Microsoft Entra ID, místo abyste se museli spoléhat na filtry navržené v rámci aplikací. Tato konfigurace zajišťuje, že filtry na straně serveru fungují podle očekávání.

Následující ilustrace vysvětlují, jak se vzory zabezpečení v aplikacích liší mezi modely zabezpečení na straně klienta a na straně serveru.

V vzoru aplikace zabezpečení klienta [1] se uživatel ověřuje pouze v aplikaci na straně klienta. Potom aplikace požaduje informace o službě a [3] vrátí informace výhradně na základě žádosti o data.

V modelu zabezpečení na straně serveru [1] se uživatel nejprve ověří ve službě, aby byl uživatel známý službě. Potom [2] při volání z aplikace služba [3] použije známou identitu aktuálního uživatele k filtrování dat a [4] vrátí data.

Implicitní scénáře sdílení oddělení popsané výše jsou kombinací těchto dvou vzorů. Uživatel se musí přihlásit ke službě Power Apps pomocí přihlašovacích údajů Microsoft Entra. Toto chování je vzor aplikace zabezpečení serveru. Uživatel je známý pomocí identity Microsoft Entra ve službě. Aplikace je proto omezena na sadu uživatelů, na které služba Power Apps formálně sdílela aplikaci.

Implicitní sdílené připojení k SQL Serveru je však vzor aplikace zabezpečení klienta. SQL Server ví, že se používá pouze konkrétní uživatelské jméno a heslo. Jakékoli filtrování na straně klienta je například možné obejít s novou aplikací pomocí stejného uživatelského jména a hesla.

Pokud chcete bezpečně filtrovat data na straně serveru, použijte integrované funkce zabezpečení SQL Serveru, jako je zabezpečení na úrovni řádků pro řádky, a oprávnění odepření konkrétních objektů (například sloupců) konkrétním uživatelům. Tento přístup používá identitu uživatele Microsoft Entra k filtrování dat na serveru.

Některé stávající podnikové služby používaly přístup, při kterém se identita uživatele zachytává ve vrstvě obchodních dat podobným způsobem jako Microsoft Dataverse. V takovém případě může nebo nemusí obchodní vrstva používat přímo funkce zabezpečení na úrovni řádků a odepřít funkce SQL Serveru. Pokud ne, často se jedná o případ, že je zabezpečení povolené pomocí uložených procedur nebo zobrazení.

Obchodní vrstva (na straně serveru) používá známou identitu Microsoft Entra uživatele k vyvolání uložené procedury jako objektu zabezpečení SQL Serveru a filtrování dat. Power Apps se ale aktuálně nepřipojí k uloženým procedurům. Obchodní vrstva může také vyvolat zobrazení, které používá identitu Microsoft Entra jako objekt zabezpečení SQL Serveru. V tomto případě se pomocí Power Apps připojte k zobrazením, aby se data filtrovala na straně serveru. Zveřejnění jenom zobrazení uživatelům může pro aktualizace potřebovat toky Power Automate.

Viz také

Přehled konektorů pro aplikace plátna