Bezpečné použití Microsoft SQL Server s Power Apps

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

Důležité

Tento článek se vztahuje na všechny relační databáze a implicitní připojení.

Rozdíl mezi explicitním a implicitním připojením

Připojení k SQL serveru se vytvoří vždy, když vytvoříte aplikaci pomocí Power Apps připojené k SQL Serveru. Když jsou takové aplikace publikovány a sdíleny s ostatními, aplikace i připojení jsou nasazeny těmto uživatelům. Jinými slovy, aplikace i připojení—jsou viditelné pro uživatele, se kterými jsou aplikace sdíleny.

Metoda ověřování použitá 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 serveru SQL Server pomocí vlastních explicitních pověření. Toto ověřování se obvykle děje v zákulisí jako součást Azure Active Directory nebo handshake ověření Windows. Uživatel si ani nevšimne, kdy dojde k ověření.
• Implicitně sdílené připojení znamená, že uživatel implicitně používá přihlašovací údaje účtu, který tvůrce aplikace použil při připojování a ověřování k zdroji dat během vytváření aplikace. Pověření koncového uživatele neslouží k ověření. Pokaždé, když koncový uživatel spustí aplikaci, použije přihlašovací údaje, s nimiž autor vytvořil aplikaci.

U SQL Serveru lze použít následující čtyři typy ověřování připojení Power Apps:

Typ ověřování	Metoda propojení Power Apps
Integrované Azure AD	Explicitní
Ověřování serveru SQL Server	Implicitní
Ověřování systému Windows	Implicitní
Ověřování systému Windows (nesdílené)	Explicitní

Implicitní rizika sdílení připojení

Protože aplikace i její připojení jsou nasazeny koncovým uživatelům, znamená to, že koncoví uživatelé mohou na základě těchto připojení vytvářet nové aplikace.

Zvažte například, že jste vytvořili aplikaci, která odfiltrovala data, která nechcete, aby uživatelé viděli. Vyfiltrovaná data jsou přítomna v databázi. Spoléháte však na filtr, který jste nakonfigurovali, abyste zajistili, že koncoví uživatelé neuvidí určitá data.

Po nasazení této aplikace mohou koncoví uživatelé používat připojení nasazené s vaší aplikací ve všech nových aplikacích, které vytvoří. V nových aplikacích mohou uživatelé zobrazit data, která jste ve své aplikaci odfiltrovali.

Důležité

Jakmile je implicitně sdílené připojení nasazeno koncovým uživatelům, omezení, která jste mohli dát do sdílené aplikace (například filtry nebo přístup jen pro čtení), již nejsou platná 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í.

Skutečné použití implicitního připojení

Existují platné případy použití pro implicitní i explicitní metody ověřování. Při výběru přístupu zvažte model zabezpečení a snadnost vývoje. Jako obecné pravidlo použijte explicitní metodu ověřování pro každou situaci, kdy máte obchodní požadavek, kde musí být data omezena na základě řádku nebo sloupce.

Pro příklad použití explicitního připojení zvažte manažera prodeje, kterému by mělo být povoleno prohlížet pouze cenové slevy nebo údaje o základních nákladech, které jsou ve stejné tabulce, kde jiný prodejní profesionál potřebuje vidět produkt a cenu.

Některá data však nemusí být zabezpečena stejným způsobem. Aplikace je sdílena a nasazena konkrétním uživatelům nebo skupinám uživatelů. Osoby mimo tuto skupinu nemají přístup k aplikaci nebo připojení. Pokud tedy má každý ve skupině oprávnění zobrazit všechna data v databázi, implicitní metoda sdílení funguje dobře.

Pro příklad případu použití implicitního připojení zvažte oddělení, které má malou databázi projektů, které sledují. Databáze může obsahovat informace, jako jsou pracovní lístky na oddělení nebo firemní kalendář pro celou společnost. V tomto scénáři může být podporováno vytváření dalších aplikací nad implicitně sdíleným připojením, pokud by všechna data měla být přístupná všem uživatelům, kterým byl udělen přístup.

Aplikace vytvořené pomocí Power Apps jsou navrženy tak, aby byly přístupné koncovým uživatelům. Tento druh scénáře je běžný, protože náklady na vývoj spojené s implicitními připojeními jsou nízké.

Oddělení založené na odděleních může růst do celopodnikových a kriticky důležitých aplikací. V těchto scénářích je důležité si uvědomit, že jak se resortní aplikace přesouvá do celého podniku, bude nutné mít zabudované tradiční podnikové zabezpečení. Tento přístup je nákladnější pro vytváření aplikací, ale je důležitý v celofiremních scénářích.

Zabezpečení klienta a serveru

Nemůžete se spolehnout na zabezpečení dat prostřednictvím filtrování nebo jiných operací na straně klienta, abyste byli v bezpečí. Aplikace, které vyžadují zabezpečené filtrování dat, musí zajistit, aby k identifikaci uživatele a filtrování došlo na serveru.

Využívejte služby jako Azure Active Directory namísto spoléhání se na filtry navržené v aplikacích, pokud jde o identitu uživatele a zabezpečení. 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 serveru.

Ve vzorci aplikace zabezpečení klienta [1] se uživatel se ověřuje pouze do aplikace na straně klienta. Pak [2] - aplikace požaduje informace o službě a [3] služba vrací informace pouze na základě požadavku na data.

Ve vzorci zabezpečení na straně serveru [1] se uživatel nejprve ve službě ověří, takže mu je známa. Pak [2] při volání z aplikace, služba [3] používá známou identitu aktuálního uživatele k odpovídajícímu filtrování dat a [4] vrácení dat.

Scénáře implicitního sdílení oddělení popsané výše jsou kombinací těchto dvou vzorů. Uživatel se musí přihlásit ke službě Power App pomocí přihlašovacích údajů Azure AD. Toto chování je vzorem aplikace zabezpečení serveru. Uživatel je znám pomocí totožnosti Azure AD ve službě. Proto je aplikace omezena na skupinu uživatelů, s nimiž Power Apps formálně sdílí aplikaci.

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

Chcete-li bezpečně filtrovat data na straně serveru, použijte integrované funkce zabezpečení na serveru SQL, jako je zabezpečení na úrovni řádků pro řádky a odepřít oprávnění ke konkrétním objektům (například sloupcům) konkrétním uživatelům. Tento přístup bude používat identitu uživatele Azure AD k filtrování dat na serveru.

Některé existující podnikové služby používaly přístup, při kterém je identita uživatele zachycena ve vrstvě obchodních dat mnohem stejným způsobem, jako to dělá Microsoft Dataverse. V tomto případě může obchodní vrstva používat zabezpečení na úrovni řádků serveru SQL Server a nemusí jej přímo používat. Pokud tomu tak není, často se stává, že je zabezpečení povoleno pomocí uložených procedur nebo zobrazení.

Obchodní vrstva (na straně serveru) používá známou identitu uživatele Azure AD k vyvolání uložené procedury jako instančního objektu serveru SQL a filtrovat data. Power Apps se však aktuálně nepřipojuje k uloženým procedurám. Obchodní vrstva může také vyvolat zobrazení, které používá identitu Azure AD jako instanční objekt serveru SQL. V tomto případě použijte Power Apps pro připojení k zobrazením, aby byla data filtrována na straně serveru. Vystavení pouze zobrazení uživatelům může vyžadovat toky Power Automate pro aktualizace.

Viz také

Přehled konektorů pro aplikace plátna