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é

Funkce Zabezpečená implicitní připojení byla vydána v lednu 2024. Společnost Microsoft důrazně doporučuje u všech aplikací, které aktuálně používají implicitní připojení, přechod na zabezpečená implicitní připojení a zrušení připojení sdílených s koncovými uživateli.

Rozdíl mezi explicitním, implicitním a zabezpečeným 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 Microsoft Entra 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.
• Zabezpečené implicitní sdílené připojení označuje situace, kdy koncový uživatel aplikace implicitně používá přihlašovací údaje účtu, který tvůrce aplikace použil při připojování a ověřování ke zdroji dat během 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žije přihlašovací údaje, s nimiž autor vytvořil aplikaci. Je důležité si uvědomit, že koncový uživatel nemá přímý přístup k připojení a aplikace umožňuje přístup pouze k omezené sadě akcí a tabulek.

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é Microsoft Entra	Explicitní
Ověřování serveru SQL Server	Implicitní / zabezpečené implicitní
Ověřování systému Windows	Implicitní / zabezpečené implicitní
Ověřování systému Windows (nesdílené)	Explicitní

Implicitní rizika sdílení připojení

Všechny nové aplikace automaticky používají nová zabezpečená implicitní připojení. Nicméně v případě aplikací, které používají starší „implicitní připojení“, jsou aplikace i její připojení nasazeny koncovým uživatelům, což znamená, že koncoví uživatelé mohou na základě těchto připojení vytvářet nové aplikace.

Když autor používá zabezpečená implicitní připojení, znamená to, že není sdíleno žádné připojení a žádný koncový uživatel neobdrží objekt připojení. To se eliminuje riziko, že autor koncového uživatele znovu použije připojení k vytvoření nové aplikace. Místo toho aplikace pracuje s připojením proxy, které si je vědomo aplikace a komunikuje pouze s touto konkrétní aplikací. Připojení proxy umožňuje omezené akce (vytvoření, čtení, aktualizace, odstranění) a přístup ke konkrétním tabulkám v aplikaci, které jsou definovány při publikování aplikace. Proto jsou koncovému uživateli uděleny pouze autorizované akce a přístup.

Starší styl jednoduchého implicitního připojení ve skutečnosti distribuuje objekt připojení ke koncovému uživateli. Například když vytvoříte aplikaci, která odfiltruje data, která nechcete zobrazovat uživatelům. Vyfiltrovaná data jsou však 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.

V případě starších jednoduchých implicitních připojení mohou po nasazení aplikace koncoví uživatelé opět 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. Je důležité používat nová zabezpečená implicitní připojení.

Důležité

Jakmile je starší 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í. Když tedy převedete aplikaci, aby používala zabezpečená implicitní připojení, musíte také zrušit připojení, která jste s aplikací sdíleli. Správci mohou získat přehled aplikací s implicitně sdílenými připojeními pomocí sady nástrojů COE.

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 Microsoft Entra ID 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 Apps pomocí přihlašovacích údajů Microsoft Entra. Toto chování je vzorem aplikace zabezpečení serveru. Uživatel je znám pomocí totožnosti Microsoft Entra 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 používá identitu uživatele Microsoft Entra 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 Microsoft Entra 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 Microsoft Entra 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