案例 1 解決方案 - 設計全球規模與安全存取

  • 10 分鐘

在上一個單元中，您已完成關於全球規模內容傳遞網路的案例。 在本單元則將檢閱一個可能的解決方案，以及一些要考慮的項目。

在檢閱時，建議將所提供解決方案與上一個單元中開發的解決方案進行比較。 任何問題通常都存在不止一個正確的解決方案，但一律會有取捨。 解決方案中有哪些項目與提議的不同？ 解決方案中是否有任何您可能會重新思考的項目？ 所提供解決方案中是否有任何您認為能夠在解決方案中更徹底地解決的項目？

部署選項和設定

第一個所要考慮決策是應該選取 Azure SQL 的哪個部署選項。 雖然 Azure 虛擬機器 (VM) 中的 SQL Server 可正常運行，但平台即服務 (PaaS) 供應項目可能會因管理的額外負荷較低而更為合適。

客戶正在使用通用語言執行平台 (CLR)，這是一種執行個體範圍功能。 Azure SQL 受控執行個體是唯一支援執行個體範圍功能 (例如 CLR、Service Broker、Database Mail 等) 的 PaaS 部署選項。 基於這個理由，Azure SQL 受控執行個體可供客戶移至 PaaS 供應項目，而不需要將其 CLR 應用程式重寫成與 Azure SQL Database 相容的解決方案 (例如彈性資料庫作業)。

下一個要進行的決策牽涉到服務層級。 由於客戶想要隔離其讀取工作負載和寫入工作負載，因此使用業務關鍵服務層級將是達成此目標的最簡單方式。 業務關鍵服務層級包含在幕後執行的 Always On 可用性群組。 其中一個次要複本可用來作為唯讀工作負載。

業務關鍵僅是此處讀取和寫入工作負載隔離設定的一半。 此案例說明客戶必須能夠在隔離讀取與寫入工作負載時，於發生多個查詢情況的同時，在多個區域中進行縮放？

有可能解決這項挑戰的兩個選項為異地複寫和自動容錯移轉群組。 不過，Azure SQL 受控執行個體目前不支援異地複寫。 因此，使用自動容錯移轉群組是唯一可協助此案例達到全域讀取規模的選項。

現在，由於客戶使用的是自動容錯移轉群組，因此其是否需要業務關鍵服務層級，都將取決於其分析工作負載所需的唯讀端點數。 透過業務關鍵服務層級中的自動容錯移轉群組，客戶可取得三個可讀取端點：

  • 一個來自主要區域可用性群組的次要複本
  • 容錯移轉群組的次要複本 (即位於次要地區中資料庫的主要複本)
  • 次要地區可用性群組的次要複本

如果分析工作負載不需要這些可讀取的複本，則使用一般用途可能是更符合成本效益的解決方案。

選取最適合的驗證方法

考慮到需要盡可能地建立及使用最安全的技術，此案例另一個部分涉及判斷每個應用程式或人員連線到解決方案的最佳方式。 如果細分此案例，則會有四個不同的用戶端需要存取 Azure SQL 受控執行個體：

  • 在 Azure VM 上執行的應用程式
  • 在非 Azure 機器 (已加入網域) 上執行的應用程式
  • 非 Azure 機器 (未加入網域) 上的 DBA 或其他 SQL 管理工具 (SQL Server Management Studio、Azure Data Studio、PowerShell) 的使用者
  • 在非 Azure 機器上執行且無法變更驅動程式或連接字串的較舊應用程式

讓我們逐一查看這些用戶端，了解如何選擇驗證方法，以及一些其他考量與限制。

在 Azure VM 上執行的應用程式

對在 Azure 虛擬機器上執行的應用程式而言，Azure 資源其受控識別一般是建議使用的無密碼驗證形式。

在非 Azure 機器 (已加入網域) 上執行的應用程式

如果是非 Azure 機器，則使用受控識別不是合適的選項。 針對在 Azure 外部已加入網域機器上執行的應用程式，建議透過 Microsoft Entra ID 進行整合式驗證作為驗證方法，前提是該網域已經是 Microsoft Entra ID 的同盟網域。

如果非 Azure 機器未加入網域，您可以：

  1. 在 Microsoft Entra ID 中，為應用程式建立應用程式身分識別。
  2. 將憑證與應用程式身分識別建立關聯。
  3. 透過提供用戶端識別碼和憑證來修改應用程式以取得 Azure SQL Database 的權杖。

雖然憑證必須包含私密金鑰，且必須部署在裝載應用程式的機器上，但您至少可避免在應用程式程式碼或設定中，以硬式編碼的方式加入應用程式密碼。 (您必須使用憑證指紋來設定應用程式。)

非 Azure 機器 (未加入網域) 上的 DBA 或其他 SQL 管理工具使用者

針對 Azure 外部的使用者，建議盡可能避免使用密碼。 您可使用 Microsoft Entra 整合式驗證，避免在 SQL 工具中使用密碼的情況。 不過，這些工具必須在已加入網域的機器上執行，且該網域必須已經與 Microsoft Entra ID 建立同盟關係，但本案例並非如此。

由於環境不符合上述整合式驗證的先決條件，建議搭配多重要素驗證來使用 Microsoft Entra 互動式驗證，這是大部分 SQL 工具所支援的驗證方式。

在非 Azure 機器上執行且無法變更驅動程式或連接字串的較舊應用程式

在無法變更驅動程式或連接字串的情況下，目前沒有任何選項可用於消除密碼。 這些較舊的應用程式必須繼續使用 SQL 驗證。 不過，您可考慮深入探討這些限制，以及如何解除這些限制，以便為所要驗證應用程式採取更安全且妥善防護的方法。