透過 Power Apps 安全地使用 Microsoft SQL Server

有多種不同的方法可使用 Power Apps 連線 和對 SQL Server 進行驗證。 本文概述的概念可幫助您選擇符合應用程式要求的安全方法，來連線到 SQL Server。

重要

本文適用於所有關聯式資料庫以及隱式連線。

顯式和隱式連線之間的區別

每當您使用連線到 SQL Server 的 Power Apps 建立應用程式時，都會建立到 SQL Server 的連線。 當這類應用程式發行並與其他人共用時，應用程式和連線都會部署到這些使用者。 換句話說，應用程式和連線—都會顯示給共用應用程式的使用者。

這類連線所使用的驗證方法可以是顯式或隱式。 我們也可以說這類連線是顯式或隱式共用的。

• 顯式共用連線表示應用程式的使用者必須使用自己的顯式認證向 SQL Server 進行驗證。 通常，這種驗證會做為 Microsoft Entra 或 Windows 驗證交握的一部分，在後台進行。 使用者甚至不會注意到驗證何時發生。
• 隱式共用連線表示使用者在建立應用程式期間，會隱式地使用應用程式製作者用於連線和驗證資料來源的帳戶憑證。 使用者的認證不會用於驗證。 使用者每次執行應用程式時，都會使用作者建立應用程式時使用的認證。

以下四種連線驗證類型可用於從 Power Apps 連線到 SQL Server：

驗證類型	Power Apps 連線資料
整合型 Microsoft Entra	顯式
SQL 伺服器驗證	隱式
Windows 驗證	隱式
Windows 驗證 (非共用)	顯式

隱式連線共用風險

由於應用程式及其連線都會部署到使用者，這代表使用者可以根據這些連線製作新的應用程式。

例如，假設您建立了一個應用程式，該應用程式會篩選您不希望使用者看到的資料。 篩選掉的資料會出現在資料庫中。 但您得依賴您設定的篩選來確保使用者不會看到某些資料。

部署此應用程式之後，使用者可以在他們建立的任何新應用程式中，使用透過您的應用程式部署的連線。 在新的應用程式中，使用者可以看到您在應用程式中篩選掉的資料。

重要

將隱式共用連線部署至使用者後，您在共用應用程式中設定的限制 (例如篩選或唯讀存取) 不再適用於使用者建立的新應用程式。 作為隱式共用連線的一部分，使用者將擁有驗證允許的任何權限。

隱式連線的實際使用

以下式隱式和顯式驗證方法的有效使用案例。 在選擇方法時，請將全性模型和輕鬆開發納入考慮。 一般而言，如果您的業務需求必須在資料列或資料行上限制資料，則請使用顯式驗證方法。

對於顯式連線使用案例的範例，假設有一個銷售經理，他應該只有權查看同一資料表中的價格折扣或基本成本資料，而另一個銷售專業人員需要查看產品和價格。

但是，並不是所有的資料都必須以相同的方式加以保護。 應用程式會共用，並部署至特定使用者或使用者群組。 該群組以外的人員無權存取應用程式或連線。 因此，如果群組中的每個人都有權查看資料庫中的所有資料，則隱式共用方法就能順利運作。

對於隱式連線使用案例的範例，假設有一個部門，該部門擁有他們正在追蹤之專案的小型資料庫。 該資料庫可能包含整個公司的資訊 (例如部門工作票證或公司行事曆)。 在這種情況下，只要具備存取權的所有使用者都可以存取所有的資料，就會建議您在隱式共用連線之上建立更多應用程式。

使用 Power Apps 建立的應用程式旨在讓使用者易於使用。 這種情況很常見，因為與隱式連線相關的開發成本較低。

以部門為基礎的應用程式可以發展為企業級的任務關鍵性應用程式。 在這些案例中，重要的是要了解隨著部門應用程式向整個企業移動時，它需要內建傳統的企業安全性。 這種方法對於應用程式組建工作來說成本更高，但在公司級的案例中很重要。

用戶端和伺服器安全性

您不可以透過篩選或其他用戶端作業來保證資料的安全性。 需要安全篩選資料的應用程式必須確保使用者識別和篩選都發生在伺服器上。

在使用者身分識別和安全性方面，使用 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 流程進行更新。

請參閱

畫布應用程式的連接器概觀