安全性功能和工作

  • 10 分鐘

SQL Server 和 Azure SQL 服務皆已因其在安全性方面的重要性而聞名，在企業級領域尤其是如此。 在此單元中，您將了解各種與網路安全性和存取管理相關的安全性功能。 在後續單元中，您將實際體驗如何使用這其中的某些功能。

企業級安全性的圖表。

網路安全性

第一層安全性涉及網路。 Azure SQL Database 和 Azure SQL 受控執行個體兩者的網路功能和工作並不相同。 如需 Azure SQL 受控執行個體網路功能的相關資訊，請參閱 Azure SQL 受控執行個體的連線架構。

Azure SQL Database 網路安全性

當要保護 Azure SQL Database 的網路時，您有四大選擇：

  • 允許存取 Azure 服務
  • 使用防火牆規則
  • 使用虛擬網路規則
  • 使用 Azure Private Link

除了這些主要選擇之外，您還有封鎖所有公用存取 (僅限使用 Azure Private Link) 的機會，以及強制使用最低傳輸層安全性 (TLS) 版本的選項。 最不安全但也最容易設定的方法，是允許對 Azure 服務的存取。 最安全的方法是使用 Private Link。 下列各節將涵蓋每個選項的功能，以及如何設定及維護每個選項。

允許存取 Azure 服務

在 Azure SQL Database 部署期間，您可選擇將 [允許 Azure 服務和資源存取此伺服器] 設定為 [是]。 如果您選擇此選項，便會讓任何區域或訂用帳戶中的任何資源獲得存取您資源的可能性。 此選項可供輕鬆地啟動並執行，並讓 Azure SQL Database 連線至其他服務，例如 Azure 虛擬機器、Azure App Service 或甚至是 Azure Cloud Shell，因為您會讓透過 Azure 而來的任何項目具有潛在連線可能性。

允許存取 Azure 服務的圖表。

不過，允許存取 Azure 服務不會讓 Azure 外部的任何項目 (例如，內部部署環境) 獲得存取權。

最安全的設定是將 [允許 Azure 服務和資源存取此伺服器] 設定為 [否]，這會封鎖所有連線和網路，但不包括您已明確使用後續各節中遵循的各種選項新增的連線和網路。

防火牆規則

下一個選項是套用防火牆規則。 結果可能類似於 [允許 Azure 服務和資源存取此伺服器] 的結果，不同之處在於，對於每個服務 (在下圖中為虛擬機器 (VM))，您將需要新增唯一的防火牆規則以允許連線。 防火牆規則也會啟用您的內部部署環境以連線到 Azure SQL Database 資源，因為您可在內部部署環境中新增適用於機器和應用程式的規則。

防火牆規則的圖表。

若要在 Azure 中取得連線，您也可以允許存取 Azure 服務，然後新增只適用於內部部署連線的防火牆規則。 如先前所述，[允許 Azure 服務和資源存取此伺服器] 並不安全，因為其允許所有的 Azure 流量。 建議以獨佔方式使用防火牆規則。

讓我們看看先前已設定防火牆規則的範例。 透過支援 Transact-SQL (T-SQL) 的工具 (例如 SQL Server Management Studio (SSMS))，即可從虛擬網路 SQLDBVNET-EUS 中的 Azure VM 執行下列查詢：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果會是 203.0.113.1。 這是 Azure VM 的公用 IP 位址。 雖然我們使用防火牆規則，但所有的連線都是公開的。

虛擬網路規則

如果您想要只使用防火牆規則，設定可能會很複雜。 只使用防火牆規則表示您必須指定適用於您所有連線的 IP 位址範圍 (有時會有動態 IP 位址)。 有一種更為簡單的替代方法，就是使用虛擬網路規則來建立和管理來自特定網路的存取，這些網路包含需要存取資料的 VM 或其他服務。

如果使用虛擬網路規則來設定虛擬網路的存取權，則該虛擬網路中的任何資源都可存取 Azure SQL Database 邏輯伺服器。 針對存取資料所需的所有靜態和動態 IP 位址，這可簡化設定其存取權所面臨的挑戰。 藉由使用虛擬網路規則，您可指定一或多個虛擬網路，並於其中包含所有資源。 您也可以開始套用虛擬網路技術，讓 Azure 與內部部署環境中各個區域的網路連線。

虛擬網路規則的圖表。

在此範例中，如同上一節所示，您可從虛擬網路 SQLDBVNET-EUS 中的 Azure VM 來執行相同查詢：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果現在會是 10.0.0.2，這是 Azure VM 的私人 IP 位址。 此結果可供更接近於完成對 Azure SQL Database 邏輯伺服器建立私人連線，因為資源現在會透過虛擬網路來連線。

另一個常見的連線分析策略是檢查網域名稱服務 (DNS) 階層。 在同一個 Azure VM 中，您可於命令提示字元中執行下列命令：

nslookup aw-server.database.windows.net

藉由使用此命令，您可取得與 DNS 基礎結構相關的詳細資料。 結果會與下列內容類似：

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   cr2.eastus1-a.control.database.windows.net
Address:    203.0.113.1
Aliases:    aw-server.database.windows.net
            dataslice2.eastus.database.windows.net

「未經授權的回應」底下有一些要注意的重點：

  • 名稱：以 cr2 開頭的端點是公用 DNS 階層的一部分。 在不深入了解該階層的情況下，我們假設 cr2 是「控制通道 2」，而在其底下有多個資料「配量」。
  • 位址：此處傳回的 IP 位址應符合 Azure VM 的公用 IP 位址。 儘管 SSMS 最終躍點之類的工具可能會通過您 VM 的私人 IP 位址，但系統仍會在某些容量中使用您 VM 的公用 IP 位址來連線。
  • 別名：這些別名為 DNS 階層內的各種點；在此案例中，為特定的資料「配量」和作為連線目標的端點。

注意

在上述輸出區塊中，位址：168.63.129.16 是用來協助建立 Azure 平台資源通訊通道的虛擬公用 IP 位址。 該位址適用於所有區域和所有國家雲端，且不會變更。

雖然透過 SSMS 的連線是通過 Azure VM 的私人 IP 位址建立，但您最終仍會透過公用端點來連線。

您已了解如何使用 Azure SQL Database 中的資料庫搭配公用端點來設定最安全的網路。 這種保護 SQL Database 資料庫的方法已行之多年。 但在 2019 年時，Azure 就已開始朝著私人連結的概念移動，這種方法更類似於 Azure SQL 受控執行個體的部署方法。 透過 Azure Private Link，您可以使用私人端點來連線到您在 SQL Database 與其他數個平台即服務 (PaaS) 供應項目中的資料庫。 這表示其具有特定虛擬網路內的私人 IP 位址。

私人端點連線的圖表。

在上述範例中，您將注意到一般的網路基礎結構並未變更，而您仍然可以套用來自虛擬網路規則的虛擬網路連線策略。 不過，您不必建立虛擬網路規則。 需要連線至資料庫伺服器的資源必須能夠存取端點所在虛擬網路。 在此範例中，端點是 SQLDBVNet-EUS。 只有通過私人端點的連線才能存取，其他所有連線 (例如，來自網際網路) 都會遭到拒絕。

當您繼續進行此範例時，在虛擬網路 SQLDBVNet-EUS 中的 Azure VM 上，您可以再次執行下列 T-SQL 命令：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果現在會是 10.0.0.2，在此範例中，這是 Azure VM 的私人 IP 位址。 藉由新增從虛擬網路的存取權，從 VM 到 Azure SQL Database 的連線看起來會像是來自 VM 的私人 IP 位址。 這與您在虛擬網路規則中看到的結果相同。

但如果想要使用命令提示字元來查看 DNS 階層，則請使用下列命令：

nslookup aw-server.database.windows.net

如果使用上述命令，其結果會與已設定的私人端點略有不同：

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   aw-server.privatelink.database.windows.net
Address:    10.0.0.5
Aliases:    aw-server.database.windows.net

「未經授權的回應」底下有一些要注意的重點：

  • 名稱：請注意，您不再指向公用 DNS 階層，而只會指向 Private Link DNS。 這表示所顯示的資料庫伺服器相關較資訊變得較少。
  • 位址：針對虛擬網路規則，所傳回位址是 VM 的公用 IP 位址，但現在應該是 Private Link 階層內的一或多個「私人」IP 位址 (一個是 Azure SQL Database 的私人端點)。
  • 別名：如同在 [名稱] 欄位中，沒有任何與 DNS 階層相關的內容，但您仍可連線至伺服器名稱 (例如，aw-server.database.windows.net)。

您或許會想，如果要連線至私人端點，為何仍使用相同的伺服器名稱？在後端中，當僅使用 Private Link 方法連線至 Azure SQL Database (亦即沒有防火牆或虛擬網路規則) 時，資訊的處理方式如下：

  • aw-server.database.windows.net
    • 由服務解析為 aw-server.privatelink.database.net
      • 由服務解析為 10.0.0.5 (私人端點的 IP 位址)

此外，服務也會阻止使用 aw-server.database.windows.net 以外的任何方法來直接連線。

存取管理

當您處理完網路存取之後，下一層要考慮的是存取管理。

角色型存取控制

Azure SQL Database 的所有 Azure 作業類型都會透過角色型存取控制 (RBAC) 來控制。 RBAC 目前已與 Azure SQL 安全性分離，但您可將其視為 SQL Database 中資料庫之外的安全性權限，範圍包括訂用帳戶、資源群組與資源。 權限適用於 Azure 入口網站、Azure CLI 及 Azure PowerShell 中的作業。 RBAC 可供清楚區分部署、管理及使用方面的職責。

內建角色可用來減少對於較高層級 RBAC 角色 (例如擁有者或參與者) 的需求。 實際上，您可使用這些角色來讓某些人部署 Azure SQL 資源 (或管理安全性原則)，但對其他使用者授與實際存取權，使其能夠使用或管理資料庫。 例如，SQL Server 參與者可部署伺服器，並將使用者指派為伺服器及資料庫的管理員。 Azure SQL Database 的內建角色包括：

  • SQL DB 參與者：可建立及管理資料庫，但無法存取資料庫 (例如，無法連線與讀取資料)
  • SQL 安全性管理員：可管理資料庫及執行個體的安全性原則 (例如，稽核)，但無法進行存取
  • SQL Server 參與者：可管理伺服器及資料庫，但無法進行存取。

驗證

在 Azure SQL Database 邏輯伺服器部署期間，您可以指定下列驗證方法：

  • 僅使用 Microsoft Entra 驗證
  • 同時使用 SQL 和 Microsoft Entra 驗證
  • 使用 SQL 驗證

您必須在部署期間設定伺服器管理員。 對於 Azure SQL Database 中的資料庫，伺服器管理員是 Azure SQL Database 邏輯伺服器的伺服器層級主體。

如果您要移轉需要 Windows 驗證的工作負載，或組織會使用 Microsoft Entra ID，則您可以使用 Microsoft Entra ID。 您可以使用入口網站或命令列工具來指派 Microsoft Entra 伺服器管理員。

設定新的伺服器時，僅限 Microsoft Entra 的驗證為預設選項。 引進伺服器登入目的在於允許 Microsoft Entra 伺服器主體，此為 SQL Database 虛擬 master 資料庫中的登入。 您可以從 Microsoft Entra 使用者、群組和服務主體建立 Microsoft Entra 登入。 使用僅限 Microsoft Entra 的驗證時，可以建立 SQL 驗證登入，並保留現有登入。 不過，只有 Microsoft Entra 驗證登入和使用者可以連線至邏輯伺服器。 若要深入了解僅限 Microsoft Entra 的驗證，請參閱使用 Azure SQL 進行僅限 Microsoft Entra 的驗證。

設定 Microsoft Entra 管理員的螢幕擷取畫面。

根據組織設定 Microsoft Entra 執行個體的方式而定，您可以從下列三種方法中挑選任一種進行連線 (例如，在 SSMS 中)：

  • Microsoft Entra ID - 整合式：非互動式方法，如果使用來自同盟網域的 Microsoft Entra 認證登入 Windows，則可使用此方法。

  • Microsoft Entra ID - 密碼：非互動式方法，可供使用 Microsoft Entra ID 受控網域以 Microsoft Entra 主體名稱進行連線。 從文件：

    這適用於原生或同盟 Microsoft Entra 使用者。 原生使用者是在 Microsoft Entra ID 中明確建立，並且會以使用者名稱和密碼進行驗證的使用者，同盟使用者則是其網域與 Microsoft Entra ID 同盟的 Windows 使用者。 如果使用者想要使用他們的 Windows 認證，但其本機電腦未加入網域 (例如使用遠端存取)，則可以使用後一種方法 (利用使用者名稱與密碼)。 在此情況下，Windows 使用者可指出其網域帳戶和密碼，並可使用同盟認證來向 SQL Database 或 Azure Synapse Analytics (先前稱為 SQL DW) 進行驗證。

  • Microsoft Entra ID - 具有多重要素驗證 (MFA) 的通用功能：互動式方法，既可保護資料的存取權，同時又可滿足組織使用 Microsoft Entra 多重要素驗證進行單一登入程序的需求。

針對 Azure SQL Database，則有數個細微差異。 您可以擁有存在於虛擬 master 資料庫的登入、資料庫使用者，甚至是 Microsoft Entra 帳戶的自主資料庫使用者 (建議使用)。 雖然 Azure SQL Database 的伺服器管理員基本上具有 sysadmin 權限，但您可使用伺服器或資料庫層級角色來建立限制更多的管理員。 有兩個資料庫層級角色可供 SQL Database 使用，其僅存在於虛擬 master 資料庫中：

  • loginmanager：資料庫層級的角色，可讓成員建立資料庫伺服器的登入
  • dbmanager：資料庫層級的角色，可以讓成員建立及刪除資料庫伺服器的資料庫

以下是 Azure SQL Database 中的伺服器層級角色清單：

  • ##MS_DatabaseConnector##
  • ##MS_DatabaseManager##
  • ##MS_DefinitionReader##
  • ##MS_LoginManager##
  • ##MS_SecurityDefinitionReader##
  • ##MS_ServerStateReader##
  • ##MS_ServerStateManager##

最終，當安裝並設定驗證及授權時，會有四個可供遵循的指導方針：

  • 使用伺服器管理員進行部署
  • 視需要建立其他管理員
  • 管理員可以建立使用者
  • 授與存取權，做法和在 SQL Server 中一樣

其他功能

在實際使用一些網路及驗證功能之後，您將在本課程模組稍後的地方檢查其他適用於資料保護、監視、記錄與稽核的功能 (及其相關工作)。

知識檢查

1.

建議用來保護 Azure SQL Database 網路的最安全方式為何？

2.

請考慮以下單元範例，Azure VM 公用 IP 位址是 203.0.113.1，Azure VM 私人 IP 位址是 10.0.0.2。 在使用虛擬網路規則來設定 Azure SQL Database 的網路存取時，SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID; 會傳回什麼？