透過 Power Apps 安全地使用 Microsoft SQL Server
有多種不同的方法可使用 Power Apps 連線 和對 SQL Server 進行驗證。 本文概述的概念可幫助您選擇符合應用程式要求的安全方法，來連線到 SQL Server。
重要
安全隱式連線功能於 2024 年 1 月發行。 Microsoft 強烈建議目前使用隱式連線的所有應用程式轉換為安全隱式連線，並撤銷與終端使用者共用的連線。
顯式、隱式和安全隱式連線之間的區別
每當您使用連線到 SQL Server 的 Power Apps 建立應用程式時，都會建立到 SQL Server 的連線。 當這類應用程式發行並與其他人共用時，應用程式和連線都會部署到這些使用者。 換句話說，應用程式和連線—都會顯示給共用應用程式的使用者。
這類連線所使用的驗證方法可以是顯式或隱式。 我們也可以說這類連線是顯式或隱式共用的。
- 顯式共用連線表示應用程式的使用者必須使用自己的顯式認證向 SQL Server 進行驗證。 通常，這種驗證會做為 Microsoft Entra 或 Windows 驗證交握的一部分，在後台進行。 使用者甚至不會注意到驗證何時發生。
- 隱式共用連線表示使用者在建立應用程式期間，會隱式地使用應用程式製作者用於連線和驗證資料來源的帳戶憑證。 使用者的認證不會用於驗證。 使用者每次執行應用程式時，都會使用作者建立應用程式時使用的認證。
- 安全隱式共用連線會參考一個情境，其中應用程式的終端使用者在建立應用程式期間，會隱式地使用應用程式製作者用於連接和驗證資料來源的帳戶認證。 這代表不會使用終端使用者自己的認證來進行身份驗證。 使用者反而在執行應用程式時，會使用作者建立應用程式時所使用的認證。 請務必注意，終端使用者無法直接存取連線，且應用程式僅允許存取一組有限的動作和表格。
以下四種連線驗證類型可用於從 Power Apps 連線到 SQL Server：
| 驗證類型 | Power Apps 連線資料 |
|---|---|
| 整合型 Microsoft Entra | 顯式 |
| SQL 伺服器驗證 | 隱式/安全隱式 |
| Windows 驗證 | 隱式/安全隱式 |
| Windows 驗證 (非共用) | 顯式 |
隱式連線共用風險
所有新應用程式都會自動使用新的安全隱式連線。 不過，新應用程式和使用較舊「隱式連線」的應用程式，兩種應用程式及其連線都會部署到使用者，這代表使用者可以根據這些連線製作新的應用程式。
當作者使用安全隱式連線時，這代表不共用任何連線，且沒有終端使用者會收到連線物件。 這會消除終端使用者作者重複使用連線來建立新應用程式的風險。 相反地，應用程式使用 proxy 連線，該連線可識別應用程式且僅和該特定應用程式通訊。 Proxy 連線允許執行有限的動作 (建立、讀取、更新、刪除) 和存取發佈應用程式時所定義之應用程式中的特定表格。 因此，僅授予終端使用者授權的動作和存取權。
舊式簡單隱式連線實際上是把連線物件分配給終端使用者。 例如，如果您建立了一個應用程式，該應用程式會篩選您不希望使用者看到的資料。 但是篩選掉的資料會出現在資料庫中。 但您得依賴您設定的篩選來確保使用者不會看到某些資料。
同樣地，透過舊式簡單隱式連線，在您部署應用程式後，終端使用者可以在他們建立的任何新應用程式中，使用透過您的應用程式部署的連線。 在新的應用程式中，使用者可以看到您在應用程式中篩選掉的資料。 使用新的安全隱式連線非常重要。
重要
一旦將較舊隱式共用連線部署至使用者後，您在共用應用程式中設定的限制 (例如篩選或唯讀存取) 都不再適用於使用者建立的新應用程式。 作為隱式共用連線的一部分，使用者將擁有驗證允許的任何權限。 因此，將應用程式轉換為使用安全隱式連線時，也必須撤銷與應用程式共用的連線。 管理員可以獲取與 COE 工具套件隱式共用連線的應用程式的報告。
用戶端和伺服器安全性
您不可以透過篩選或其他用戶端作業來保證資料的安全性。 需要安全篩選資料的應用程式必須確保使用者識別和篩選都發生在伺服器上。
在使用者身分識別和安全性方面，使用 Microsoft Entra 識別碼等服務，而不是依賴應用程式中設計的篩選條件。 這種設定可確保伺服器端篩選器可以如期運作。
下圖說明用戶端和伺服器端安全性模型之間，應用程式中的安全性模式有何不同。
在用戶端安全性應用程式模式中，[1] 使用者僅對用戶端的應用程式進行驗證。 然後 [2] 應用程式要求服務的資訊，而且 [3] 服務僅根據資料要求傳回資訊。
在伺服器端安全性模式中，[1] 使用者會先對服務進行驗證，以便服務知道使用者。 然後，[2] 當從應用程式發出呼叫時，服務會 [3] 使用目前使用者的已知身分識別來適當地篩選資料，然後傳回 [4] 資料。
以上描述的隱式部門共用案例是這兩種模式的組合。 使用者必須使用 Microsoft Entra 認證登入 Power Apps 服務。 此行為是伺服器安全性應用程式模式。 已知使用者在服務上使用 Microsoft Entra 身分識別。 因此，應用程式受限於與 Power Apps 正式共用應用程式的使用者集。
但是，與 SQL Server 的隱式共用連線是用戶端安全性應用程式模式。 SQL Server 只知道使用特定的使用者名稱和密碼。 例如，使用相同使用者名稱和密碼的新應用程式可以繞過任何用戶端篩選。
若要在伺服器端安全地篩選資料，請使用 SQL Server 中的內建安全性功能，例如資料列的資料列層級安全性，以及特定使用者對特定物件 (例如資料行) 的拒絕權限。 這種方法會使用 Microsoft Entra 使用者身分識別來篩選伺服器上的資料。
部分現有公司服務所用的在商務資料層中擷取使用者身分識別的方式，與 Microsoft Dataverse 的方式非常相似。 在這種情況下，商務層可能會也可能不會直接使用 SQL Server 的資料列等級安全性和拒絕功能。 如果不是，則通常會使用預存程序或檢視啟用安全性。
業務層 (位於伺服器端) 使用已知的使用者 Microsoft Entra 身分識別，叫用預存程序做為 SQL Server 主體並篩選資料。 但是，Power Apps 目前並未連線至預存程序。 業務層也可以調用使用該 Microsoft Entra標識做為 SQL Server 主體的視圖。 在這種情況下，請使用 Power Apps 來連接至檢視，以便在伺服器端篩選資料。 只有向使用者公開檢視時，可能需要 Power Automate 流程進行更新。