資料庫引擎權限使用者入門

適用於：SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics 分析平台系統（PDW）Microsoft Fabric 中的 SQL 資料庫

本文會檢閱一些基本的安全性概念，然後描述許可權的一般實作。 Database Engine 中的許可權是透過登入和伺服器角色在 伺服器層級 管理，以及透過資料庫用戶和資料庫角色在 資料庫層級 管理。

Microsoft Fabric 中的 SQL 資料庫和 SQL 資料庫在每個資料庫內提供相同的選項，但伺服器層級的權限不適用。

在 SQL Database 中，請參閱教學課程：保護 Azure SQL Database 中的資料庫。建議使用Microsoft Entra ID 驗證。如需詳細資訊，請參閱教學課程：使用 Microsoft Entra 應用程式建立 Microsoft Entra 使用者。
在 Microsoft Fabric 的 SQL 資料庫中，唯一支援資料庫使用者的認證方法是 Microsoft Entra ID。伺服器層級角色和許可權不提供。如需詳細資訊，請參閱 Microsoft Fabric 中的 SQL 資料庫中的授權。

Note

Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。

安全原則

安全性主體是 SQL Server 所使用的身分識別，可獲指派許可權以採取動作。安全性主體通常是人員或人員群組，但可以是假裝為人員的其他實體。您可以使用本文所示的 Transact-SQL 範例，或使用 SQL Server Management Studio 來建立和管理安全性主體。

Logins

登入是用於登入 SQL Server Database Engine 的個別用戶帳戶。 SQL Server 和 SQL Database 支援以 Windows 驗證為基礎的登入，以及以 SQL Server 驗證為基礎的登入。如需這兩種登入類型的相關信息，請參閱選擇驗證模式。

固定伺服器角色

在 SQL Server 中， 固定伺服器角色 是一組預先設定的角色，可提供方便的伺服器層級許可權群組。您可使用 ALTER SERVER ROLE ... ADD MEMBER 陳述式將登入新增至角色。如需詳細資訊，請參閱 ALTER SERVER ROLE。 SQL Database 不支援固定伺服器角色，但在資料庫（master 和 loginmanager）中具有兩個角色，其作用就像伺服器角色一樣。

使用者定義伺服器角色

在 SQL Server 中，您可以建立自己的 伺服器角色 ，併為其指派伺服器層級許可權。您可使用 ALTER SERVER ROLE ... ADD MEMBER 陳述式將登入新增至伺服器角色。如需詳細資訊，請參閱 ALTER SERVER ROLE。 SQL Database 不支援使用者定義伺服器角色。

資料庫使用者

若要將登入的存取權授與資料庫，您可以在該資料庫中建立 資料庫使用者 ，並將資料庫用戶對應至登入。資料庫用戶名稱通常與慣例的登入名稱相同，但不需要相同。每個資料庫使用者皆會對應至單一登入。登入只能對應至資料庫中的一位使用者，但可以對應為數位不同資料庫中的資料庫使用者。

您亦可建立未具備對應登入的資料庫使用者。這些使用者稱為「自主資料庫使用者」。 Microsoft鼓勵使用自主資料庫用戶，因為它可讓您更輕鬆地將資料庫移至不同的伺服器。自主資料庫與登入相似，可使用 Windows 驗證或 SQL Server 驗證。如需詳細資訊，請參閱使用自主資料庫讓資料庫具有可攜性。

共有 12 個類型的使用者，其僅在驗證方式與顯示對象方面略有差異。若要查看使用者清單，請參閱 CREATE USER。

固定資料庫角色

固定資料庫角色 是一組預先設定的角色，可提供方便的資料庫層級許可權群組。您可使用 ALTER ROLE ... ADD MEMBER 陳述式，將資料庫使用者與使用者定義資料庫角色新增至固定資料庫角色。如需詳細資訊，請參閱 ALTER ROLE。

使用者定義資料庫角色

具有許可權的使用者 CREATE ROLE 可以建立新的 使用者定義資料庫角色 ，以代表具有一般許可權的使用者群組。通常會針對整個角色授與或拒絕權限，以精簡權限管理與監視作業。您可使用 ALTER ROLE ... ADD MEMBER 陳述式，將資料庫使用者新增至資料庫角色。如需詳細資訊，請參閱 ALTER ROLE。

其他主要人物

此處未討論的其他安全性主體包括 應用程式角色，以及以憑證或非對稱密鑰為基礎的登入和使用者。

如需顯示 Windows 使用者、Windows 群組、登入和資料庫使用者之間關聯性的圖形，請參閱建立資料庫使用者。

典型案例

下列範例表示通用和建議的權限設定方法。

在 Windows Active Directory 或 Microsoft Entra ID 中

為每個人員建立使用者。
建立代表工作單位與工作職務的 Windows 群組。
將 Windows 使用者新增至 Windows 群組。

如果使用者將連線到許多資料庫

針對 Windows 群組建立登入。（如果您使用 SQL Server 驗證，請略過 Active Directory 步驟，並在這裏建立 SQL Server 驗證登入。
在使用者資料庫中，建立代表 Windows 群組的登入資料庫使用者。
在使用者資料庫中，建立一或多個使用者定義資料庫角色，每個角色皆代表類似的職務。例如，您可能具有財務分析師角色和銷售分析師角色。
將資料庫使用者新增至一或多個使用者定義資料庫角色。
授與權限至使用者定義資料庫角色。

如果使用者只會連線到一個資料庫

在使用者資料庫中，針對 Windows 群組建立自主資料庫。（如果您使用 SQL Server 驗證，請略過 Active Directory 步驟，並在這裏建立自主資料庫使用者 SQL Server 驗證。
在使用者資料庫中，建立一或多個使用者定義資料庫角色，每個角色皆代表類似的職務。例如，您可能具有財務分析師角色和銷售分析師角色。
將資料庫使用者新增至一或多個使用者定義資料庫角色。
授與權限至使用者定義資料庫角色。

此時顯示的結果，通常會是屬於 Windows 群組成員的 Windows 使用者。 Windows 群組在 SQL Server 或 SQL Database 中具有登入。登入會對應至使用者資料庫中的使用者身分識別。使用者是資料庫角色的成員。現在您必須新增權限至角色。

指派權限

大部分的許可權語句都有下列格式：

<authorization> <permission> ON <securable>::<name> TO <principal>;

<authorization> 必須是 GRANT、 REVOKE或 DENY。
<permission> 決定您允許或禁止的動作。 SQL Server 與 Azure SQL Database 之間的確切許可權數目不同。如需許可權的相關信息，請參閱許可權（Database Engine），並參閱本文稍後的圖表。
ON <securable>::<name> 是安全性實體類型 (伺服器、伺服器物件、資料庫或資料庫物件) 及其名稱。某些許可權不需要 <securable>::<name> ，因為它在內容中明確或不適當。例如，CREATE TABLE 權限不需要 <securable>::<name> 子句 (GRANT CREATE TABLE TO Mary; 允許 Mary 建立資料表)。
<principal> 是接收或失去權限的安全性主體 (登入、使用者或角色)。盡可能授與權限給角色。

下列範例語句會將在UPDATE架構中包含的Parts資料表或檢視表的Production許可權授與名為 PartsTeam的角色：

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;

下列範例語句將 UPDATE 許可權授予 Production 架構，及此架構中包含的任何資料表或檢視，給予名為 ProductionTeam 的角色，這是比在個別物件層級指派許可權更有效且可擴展的方法。

GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;

使用 GRANT 陳述式，將權限授與至安全性主體 (登入、使用者和角色)。使用 DENY 命令明確拒絕權限。使用 REVOKE 陳述式移除先前授與或拒絕的權限。權限會累計，使用者會接收授與至使用者登入以及任何群組成員資格的所有權限；不過，任何權限拒絕皆會覆寫所有授與。

Caution

常見的錯誤是嘗試使用 GRANT 而非 DENY 來移除 REVOKE。當使用者從多個來源收到許可權時，這可能會造成問題，這可以是常見的案例。下列範例示範原則。

Sales 群組透過語句SELECT接收OrderStatus在數據表GRANT SELECT ON OBJECT::OrderStatus TO Sales;上的許可權。使用者 Jae 是 Sales 角色的成員。 Jae 也已透過語句SELECT，以自己的用戶名稱授予OrderStatus許可權給GRANT SELECT ON OBJECT::OrderStatus TO Jae;數據表。假設系統管理員希望將 GRANT 從 Sales 角色中移除。

如果系統管理員正確地執行REVOKE SELECT ON OBJECT::OrderStatus TO Sales;，Jae會透過其個別SELECT語句保留對OrderStatus表格的GRANT存取權。
如果系統管理員不正確地執行 DENY SELECT ON OBJECT::OrderStatus TO Sales;，則 Jae，作為 Sales 角色的成員，會被拒絕 SELECT 許可權，因為 DENY 覆寫至 Sales ，覆蓋了他的個別 GRANT 。

Note

您可使用 Management Studio 來設定權限。在 [物件總管] 中找到安全性實體，以滑鼠右鍵按一下安全性實體，然後選取 [屬性]。選取 [權限] 頁面。如需使用權限頁面的說明，請參閱 Permissions or Securables Page。

權限階層

權限具有父子式階層。也就是說，若您在資料庫上授與 SELECT 權限，則該權限在資料庫中會包含所有 (子系) 結構描述的 SELECT 權限。若您在結構描述上授與 SELECT 權限，則其在結構描述中會包含所有 (子系) 資料表的 SELECT 權限。許可權是 可轉移的：如果您授與 SELECT 資料庫的許可權，它包含 SELECT 所有（子）架構的許可權，以及所有（孫子）數據表和檢視表。

權限亦具有涵蓋的權限。 CONTROL對象的許可權通常會為您提供物件上所有其他許可權。

由於父子式階層與涵蓋階層皆可做為同個權限，因此讓權限系統變得複雜。例如，讓我們在架構中取得數據表（Region），在資料庫（Customers）中。SalesDB

CONTROL數據表Region的許可權包含數據表Region上所有其他許可權，包括 ALTER、、SELECTINSERT、UPDATE、DELETE、和其他一些許可權。
SELECT Customers在擁有Region數據表的架構上，包含SELECT數據表的許可權Region。

因此，您可以透過下列六個語句中的任何一個來達成 SELECT 資料表的的權限 Region :

GRANT SELECT ON OBJECT::Region TO Jae;

GRANT CONTROL ON OBJECT::Region TO Jae;

GRANT SELECT ON SCHEMA::Customers TO Jae;

GRANT CONTROL ON SCHEMA::Customers TO Jae;

GRANT SELECT ON DATABASE::SalesDB TO Jae;

GRANT CONTROL ON DATABASE::SalesDB TO Jae;

授與最小權限

先前GRANT SELECT ON OBJECT::Region TO Jae;所列的第一個許可權是最細微的許可權。該語句是授予 SELECT 的最低限度的許可權。其並無任何從屬物件權限。一律盡可能授與最低許可權是個不錯的原則，但您應該考慮在較高層級授與，以簡化授與系統。

因此，如果 Jae 需要整個架構的許可權，請在架構層級授予 SELECT 一次，而不是多次在數據表或檢視層級授予 SELECT。資料庫的設計可能會大幅影響此策略的成功程度。當您的資料庫設計好時，此策略最適用，因此需要相同許可權的物件會包含在單一架構中。

Tip

當您設計資料庫及其物件時，請從應用程式與使用者存取這些物件的方式開始規劃。使用這項資訊來控制使用架構對數據表、檢視、函式和預存程式的存取。架構可讓您更輕鬆地將存取類型分組。

權限圖表

下圖顯示這些權限及其彼此間的關聯性。一些較高等級的權限 (例如 CONTROL SERVER) 會多次列出。本文的海報字級太小，無法閱讀。您可以下載 PDF 格式的全尺寸資料庫引擎權限海報。

Database Engine 許可權 PDF 的螢幕快照。

如需顯示資料庫引擎主體與伺服器和資料庫物件間關係的說明圖，請參閱權限階層 (資料庫引擎)。

權限與固定伺服器與固定資料庫角色

固定伺服器角色和固定資料庫角色的許可權類似，但與細微許可權不同。例如， sysadmin 固定伺服器角色的成員具有 SQL Server 實例上的所有許可權，如同使用 CONTROL SERVER 許可權登入一樣。

但是，授予 CONTROL SERVER 權限並不會使使用者登入成為 sysadmin 固定伺服器角色的成員，而將使用者登入加入 sysadmin 固定伺服器角色並不會明確授予登入 CONTROL SERVER 權限。有時候，預存程序會透過檢查固定角色來檢查許可權，而不是檢查細微的許可權。

例如，卸離資料庫需要 db_owner 固定資料庫角色的成員資格。對等的 CONTROL DATABASE 權限不足。這兩個系統採平行方式運作，但彼此鮮少互動。 Microsoft建議盡可能使用較新的細微許可權系統，而不是固定角色。

監控權限

下列檢視會傳回安全性資訊。如需所有安全性相關檢視，請參閱安全性目錄檢視（Transact-SQL）。

View	Description
`sys.server_principals` ¹	伺服器上的登入和使用者定義伺服器角色
`sys.database_principals`	資料庫中的用戶和用戶定義角色
`sys.server_permissions` ¹	授與登入和使用者定義固定伺服器角色的許可權
`sys.database_permissions`	授予使用者和使用者定義的固定資料庫角色的權限
`sys.database_role_members`	資料庫角色成員資格
`sys.server_role_members` ¹	伺服器角色成員資格

¹ SQL Database 中無法使用此檢視。

Examples

下列陳述式會傳回關於權限的實用資訊。

A. 每個使用者的資料庫權限清單

若要傳回資料庫中授與或拒絕的明確許可權（SQL Server 和 SQL Database），請在資料庫中執行下列 Transact-SQL 語句。

SELECT perms.state_desc AS State,
       permission_name AS [Permission],
       obj.name AS [on Object],
       dp.name AS [to User Name]
FROM sys.database_permissions AS perms
     INNER JOIN sys.database_principals AS dp
         ON perms.grantee_principal_id = dp.principal_id
     INNER JOIN sys.objects AS obj
         ON perms.major_id = obj.object_id;

B. 列出伺服器角色成員

若要傳回伺服器角色的成員（僅限 SQL Server），請執行下列語句。

SELECT roles.principal_id AS RolePrincipalID,
       roles.name AS RolePrincipalName,
       server_role_members.member_principal_id AS MemberPrincipalID,
       members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
     INNER JOIN sys.server_principals AS roles
         ON server_role_members.role_principal_id = roles.principal_id
     LEFT OUTER JOIN sys.server_principals AS members
         ON server_role_members.member_principal_id = members.principal_id;

C. 列出屬於資料庫層級角色成員的所有資料庫主體

若要傳回資料庫角色的成員（SQL Server 和 SQL Database），請在資料庫中執行下列語句。

SELECT dRole.name AS [Database Role Name],
       dp.name AS [Members]
FROM sys.database_role_members AS dRo
     INNER JOIN sys.database_principals AS dp
         ON dRo.member_principal_id = dp.principal_id
     INNER JOIN sys.database_principals AS dRole
         ON dRo.role_principal_id = dRole.principal_id;

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-11-18