共用方式為


Linux 上的 SQL Server 安全性功能逐步解說

適用於:SQL Server - Linux

如果您是剛開始使用 SQL Server 的 Linux 使用者,下列工作將逐步解說其中一些安全性工作。 這不是 Linux 唯一或特定功能,但可協助您大致了解哪些區域需要進一步調查。 在每個範例中,會提供該區域的深入文件連結。

本文 Transact-SQL 程式碼範例使用 AdventureWorks2022AdventureWorksDW2022 範例資料庫,從 Microsoft SQL Server Samples 和 Community Projects (Microsoft SQL Server 範例和社群專案)首頁即可下載。

建立登入和資料庫使用者

使用 CREATE LOGIN 陳述式,在 master 資料庫中建立登入,以將 SQL Server 的存取權授與其他人。 例如:

CREATE LOGIN Larry
    WITH PASSWORD = '<password>';

警告

您的密碼應遵循 SQL Server 預設 密碼原則。 依預設,密碼長度必須至少有 8 個字元,並包含下列四種字元組合中其中三種組合的字元:大寫字母、小寫字母、以 10 為底數的數字以及符號。 密碼長度最多可達 128 個字元。 盡可能使用長且複雜的密碼。

登入可以連線到 SQL Server 且可以存取 (權限受限) master 資料庫。 若要連線到使用者資料庫,登入需要資料庫層級的對應識別,稱為資料庫使用者。 使用者特定於每個資料庫,且必須在每個資料庫中個別建立,才能授與其存取權。 下列範例會將您移至 AdventureWorks2022 資料庫,然後使用 CREATE USER 陳述式來建立名為 Larry 的使用者,其與名為 Larry 的登入建立關聯。 雖然登入和使用者相互關聯 (彼此對應),但它們是不同的物件。 登入是伺服器層級的主體。 使用者是資料庫層級的主體。

USE AdventureWorks2022;
GO

CREATE USER Larry;
GO
  • SQL Server 的系統管理員帳戶可以連線到任何資料庫,且可以在任何資料庫中建立更多登入和使用者。
  • 當有人建立資料庫時,他們就會成為資料庫擁有者,因而可以連線到該資料庫。 資料庫擁有者可以建立更多的使用者。

稍後,您可以授權其他登入,藉由授與其 ALTER ANY LOGIN 權限來建立更多登入。 在資料庫內,您可以授權其他使用者,藉由授與其 ALTER ANY USER 權限來建立更多使用者。 例如:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2022;
GO

GRANT ALTER ANY USER TO Jerry;
GO

現在登入 Larry 可以建立更多登入,而使用者 Jerry 可以建立更多使用者。

以最低權限授與存取權

第一個連線到使用者資料庫的人員,將會是系統管理員和資料庫擁有者帳戶。 不過,這些使用者擁有資料庫上所有可用權限。 這比大部分使用者擁有更多的權限。

當您剛開始使用時,可以使用內建的「固定資料庫角色」來指派一些一般的權限類別。 例如,db_datareader 固定資料庫角色可以讀取資料庫中的所有資料表,但不會進行任何變更。 請使用 ALTER ROLE 陳述式來授與固定資料庫角色中的成員資格。 下列範例會將使用者 Jerry 新增至 db_datareader 固定資料庫角色。

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

如需固定資料庫角色的清單,請參閱 資料庫層級角色

之後,當您準備好設定更精確的資料存取 (強烈建議) 時,請使用 CREATE ROLE 陳述式來建立您自己的使用者定義資料庫角色。 然後,將特定的細微權限指派給您的自訂角色。

例如,下列陳述式會建立名為 Sales 的資料庫角色,授與 Sales 群組從 Orders 資料表查看、更新及刪除資料列的能力,然後將使用者 Jerry 新增至該 Sales 角色。

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Sales TO Orders;
GRANT UPDATE ON OBJECT::Sales TO Orders;
GRANT DELETE ON OBJECT::Sales TO Orders;

ALTER ROLE Sales ADD MEMBER Jerry;

如需許可權系統的詳細資訊,請參閱開始使用 資料庫引擎許可權

設定資料列層級安全性

數據列層級安全性 可讓您根據執行查詢的使用者,限制對資料庫中數據列的存取。 此功能適用於確保客戶只能存取自己的資料,或背景工作角色只能存取其部門相關資料的情況。

下列步驟將逐步解說如何設定兩個對 Sales.SalesOrderHeader 資料表具有不同資料列層級存取權的使用者。

建立兩個使用者帳戶來測試資料列層級安全性:

USE AdventureWorks2022;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

Sales.SalesOrderHeader 資料表的讀取權限授與這兩個使用者:

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

建立新的結構描述,以及內嵌資料表值函式。 SalesPersonID 資料行中的資料列符合 SalesPerson 登入的識別碼,或執行查詢的使用者是管理員使用者時,此函數會傳回 1。

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
          OR (USER_NAME() = 'Manager')

建立安全性原則,同時將函式新增為資料表上的篩選述詞和區塊述詞:

CREATE SECURITY POLICY SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
    ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
    WITH (STATE = ON);

執行下列動作,以每個使用者的身分查詢 SalesOrderHeader 資料表。 確認 SalesPerson280 只會看到其本身銷售額的 95 個資料列,且 Manager 可以查看資料表中的所有資料列。

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

變更安全性原則,以停用原則。 現在這兩個使用者都可以存取所有資料列。

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

啟用動態資料遮罩

動態數據遮罩 可讓您完全或部分遮罩特定數據行,以限制敏感數據暴露給應用程式的使用者。

使用 ALTER TABLE 陳述式,將遮罩函式新增至 Person.EmailAddress 資料表中的 EmailAddress 資料行:

USE AdventureWorks2022;
GO

ALTER TABLE Person.EmailAddress
    ALTER COLUMN EmailAddress
        ADD MASKED WITH (FUNCTION = 'email()');

建立具有資料表 SELECT 權限的新使用者 TestUser,然後以 TestUser 的形式執行查詢,以檢視已遮罩的資料:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

確認遮罩函式會從下列位置變更第一筆記錄中的電子郵件地址:

EmailAddressID EmailAddress
1 ken0@adventure-works.com

into

EmailAddressID EmailAddress
1 kXXX@XXXX.com

啟用透明資料加密

對資料庫的威脅之一,就是有人會從您的硬碟竊取資料庫檔案的風險。 當入侵透過問題員工的動作,或是透過竊取包含檔案的電腦 (例如膝上型電腦) 而取得系統更高權限的存取權,就可能發生這種情況。

透明資料加密 (TDE) 會加密儲存在硬碟上的資料檔案。 SQL Server 資料庫引擎的 master 資料庫具有加密金鑰,因此資料庫引擎可以操作資料。 需要存取金鑰才可讀取資料庫檔案。 高層級的管理員可以管理、備份及重新建立金鑰,因此可以移動資料庫,但只能由所選人員移動。 設定 TDE 時,也會自動加密 tempdb 資料庫。

由於資料庫引擎可以讀取資料,TDE 無法保護可直接讀取記憶體或透過管理員帳戶存取 SQL Server 之電腦管理員進行未經授權的存取。

設定 TDE

  • 建立主要金鑰
  • 建立或取得受到主要金鑰保護的憑證
  • 建立資料庫加密金鑰,並使用憑證保護它
  • 設定資料庫使用加密

設定 TDE 需要 master 資料庫的 CONTROL 權限,以及使用者資料庫的 CONTROL 權限。 通常管理員會設定 TDE。

下列範例說明如何使用 AdventureWorks2022 伺服器上安裝的憑證來加密和解密 MyServerCert資料庫。

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2022;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;

若要移除 TDE,執行下列命令:

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION OFF;

SQL Server 會將加密和解密作業排定在背景執行緒上。 您可以使用本文章稍後出現之清單內的目錄檢視和動態管理檢視,以檢視這些作業的狀態。

警告

啟用了 TDE 的資料庫備份檔案也會使用資料庫加密金鑰來加密。 因此,當您要還原這些備份時,保護資料庫加密金鑰的憑證必須可以使用。 這表示,除了備份資料庫以外,必須確定可維護伺服器憑證的備份,以免資料遺失。 如果此憑證無法再使用,就會造成資料遺失。 如需詳細資訊,請參閱 SQL Server Certificates and Asymmetric Keys

如需 TDE 的詳細資訊,請參閱 透明資料加密 (TDE)

設定備份加密

SQL Server 可在建立備份時加密資料。 在建立備份時透過指定加密演算法及加密程式 (憑證或非對稱金鑰),即可建立加密的備份檔案。

警告

永遠備份憑證或非對稱金鑰,而且最好與其用以加密的備份檔案存放於不同位置。 若沒有憑證或非對稱金鑰,您將無法還原備份,而此備份檔案將無法使用。

下列範例會建立憑證,然後建立受該憑證保護的備份。

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2022]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2022.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

如需詳細資訊,請參閱 備份加密