Azure Well-Architected Framework (Azure 完善架構) 是一組指導原則，旨在根據卓越架構品質要素來評估解決方案：
本文為此系列文章的結尾。 閱讀簡介。
本系列提供的指引將 Well-Architected (完善架構) 原則納入了所有設計選項。 本文提供這些選項的摘要說明。 GitHub：適用於受管制工作負載的 Azure Kubernetes 服務 (AKS) 基準叢集提供了這些原則的示範 (如適用)。
PCI DSS 3.2.1 工作負載嚴格要求解決方案的架構設計必須完善周全。 確保基礎結構符合 PCI 需求至關重要，但合規性並不止於裝載基礎結構。 如果無法滿足品質要素 (特別是安全性)，可能會危及合規性。 架構完善的解決方案結合了基礎結構和工作負載的觀點，確保達成合規結果所需的嚴謹性。
安全性
遵循安全性設計原則中的基本指引。 這些章節旨在提供受管制環境的最佳做法摘要說明。
治理
治理實作是由 PCI-DSS 3.2.1 中的合規性需求所驅動。 這會影響用於維護分割、存取資源、偵測弱點，以及最重要的保護客戶資料的技術控制項。
企業分割策略
為了維持完全隔離，建議您在獨立的訂用帳戶中部署受管制的基礎結構。 如果您有多個合規性所需的訂用帳戶，請考慮根據管理群組階層將它們分組，以便為整個範圍內的訂用帳戶統一套用相關的 Azure 原則。 在訂用帳戶內，請在訂用帳戶層級套用相關的 Azure 原則，以擷取應為持卡人資料環境 (CDE) 中的所有叢集套用的廣泛原則。 在資源群組層級套用相關的 Azure 原則，以擷取適用於特定叢集執行個體的原則。 這些原則會建置登陸區域的核心護欄。
在作業和連線能力方面，請隔離 PCI 工作負載 (範圍內) 與其他 (範圍外) 工作負載。 您可以藉由部署各自獨立的叢集來建立隔離。 或者，也可以使用分割策略來保持分隔狀態。 例如讓叢集使用不同的節點集區，以確保工作負載永遠不會共用節點虛擬機器 (VM)。
原則強制執行
啟用 Azure 原則，以強制執行安全性控制項。 例如，您可以在此受管制架構中，防止持卡人資料環境發生組態錯誤。 您可以套用 Azure 原則，以禁止在 VM 節點上配置公用 IP。 系統將會偵測這類配置，並予以回報或封鎖。
如需可為 AKS 啟用的原則相關資訊，請參閱適用於 Azure Kubernetes Service 的 Azure 原則內建定義。
Azure 為大多數服務提供了數種內建原則。 請檢閱這些 Azure 原則內建原則定義，並視情況套用。
合規性監視
請務必以系統化方式，監視並維護合規性。 執行定期合規性證明。 了解您的雲端資源是否合規，將有助於為證明和稽核做好準備。
請善用適用於雲端的 Microsoft Defender 中的法規合規性儀表板。 持續監視此儀表板，以追蹤工作負載的合規性狀態。
網路安全性
在中樞輪輻拓樸中為每個實體設置獨立的虛擬網路，可以實現基本的網路使用量分割。 每個網路都會進一步分割為子網路。
AKS 叢集構成了 CDE 的核心。 它不得透過公開 IP 位址存取，而且必須確保連線安全無虞。 進出 CDE 的典型流量可分為以下幾類：
- 叢集的輸入流量。
- 叢集的輸出流量。
- Pod 之間的叢集內流量。
為了滿足受管制環境的需求，叢集會部署為私人叢集。 在此模式下，進出公用網際網路的流量會受到限制。 即使是與 AKS 管理的 Kubernetes API 伺服器進行的通訊，也是私人通訊。 嚴格的網路控制項和 IP 防火牆規則進一步強化了安全性。
- 網路安全性群組 (NSG) 可協助保護網路內部資源之間的通訊安全性。
- Azure 防火牆可用來篩選雲端資源、網際網路和內部部署之間的任何輸出流量。
- 使用已整合 Azure Web 應用程式架構的 Azure 應用程式閘道，篩選出經 Azure 應用程式閘道攔截的所有來自網際網路的輸入流量。
- Kubernetes NetworkPolicy 僅允許叢集中 Pod 之間的特定路徑。
- 使用 Azure Private Link 連線至其他 Azure 平台即服務 (PaaS) 服務，例如用於執行作業工作的 Azure Key Vault 和 Azure Container Registry。
監視流程是否準備就緒，以確保流量如預期般流動，並偵測和回報任何異常狀況。
如需有關網路安全性的詳細資料，請參閱網路分割。
資料安全性
PCI-DSS 3.2.1 規定，所有持卡人資料 (CHD) 無論是在傳輸或儲存過程中，都絕對不能以明文形式出現。
此架構和實作著重於探討基礎結構，而非工作負載，因此並未提供資料管理的示範。 以下是一些有關完善架構的建議。
待用資料
資料必須使用業界標準的加密演算法進行加密。
- 請勿將資料儲存在持卡人環境中。
- 在儲存層外部進行加密。
- 僅將加密後的資料寫入儲存媒體。
- 請勿在儲存層中儲存金鑰。
Azure 儲存體中的所有資料皆會使用強式密碼編譯技術進行加密和解密。 建議使用自控加密金鑰。
如需暫時儲存資料，請針對這些資料進行相同的考量。 強烈建議啟用 AKS 的主機加密功能。 您可以使用內建的 Azure 原則，強制加密暫存資料。
請在選擇儲存體技術時，探索相關的保留功能。 確保所有資料皆會在設定的時間到期時，以安全的方式移除。
此標準還要求不得儲存敏感性驗證資料 (SAD)。 請確保這些資料不會透過記錄、檔案名稱、快取以及其他資料公開。
傳輸中資料
與 CDE 互動的實體之間的所有通訊，皆需透過加密通道進行。
- 僅允許 HTTPS 流量流入 CDE。 在此架構中，Azure 應用程式閘道會拒絕所有透過連接埠 80 的流量。
- 最好不要在 CDE 外部加密和解密資料。 如果真的需要這樣做，請將該實體視為 CDE 的一部分。
- 在 CDE 中，使用 mTLS 提供 Pod 間的安全通訊。 您可以選擇實作服務網格，以實現此目的。
- 僅允許安全密碼和 TLS 1.2 或更新版本。
身分識別
設計存取原則時，請遵循以下安全性原則：
- 從零信任原則開始。 根據需要設定例外狀況。
- 僅授予足以完成工作的最低權限。
- 盡可能減少常設存取權。
使用 Kubernetes 角色型存取控制 (RBAC) 管理 Kubernetes API 權限。 AKS 支援這些 Kubernetes 角色。 AKS 已與 Microsoft Entra ID 完全整合。 您可以將 Microsoft Entra 身分識別指派給這些角色，並使用其他功能。
零信任存取
根據預設，Kubernetes RBAC、Azure RBAC 和 Azure 服務會實作全部拒絕。 覆寫該設定時需小心謹慎，僅將存取權授予有需要的實體。 停用對叢集節點的 SSH 存取，是實作零信任的另一個範疇。
最低權限
您可以針對 Azure 資源和 Pod 使用受控識別，並將其範圍限定為預期的工作。 例如，Azure 應用程式閘道必須擁有從 Azure Key Vault 取得秘密 (TLS 憑證) 的權限。 但它不應擁有修改秘密的權限。
盡量減少常設存取權
使用即時 Microsoft Entra 群組成員資格，盡量減少常設存取權。 使用 Microsoft Entra ID 中的條件式存取原則強化控制能力。 此選項支援許多使用案例，例如多重要素驗證、限制對 Microsoft Entra 租用戶管理的裝置進行驗證，或封鎖非典型登入嘗試。
祕密管理
將秘密、憑證、金鑰和密碼儲存於 CDE 外部。 您可以使用原生 Kubernetes 秘密物件或受控金鑰存放區，例如 Azure Key Vault。 使用受控存放區有助於執行秘密管理工作，例如金鑰輪替和憑證更新。
請確保金鑰存放區的存取權搭配使用網路和存取控制項。 啟用受控識別時，叢集必須針對 Key Vault 進行自我驗證，才能取得存取權。 此外，與金鑰存放區的連線不得透過公用網際網路進行。 請使用私人網路，例如 Private Link。
卓越營運
請遵循卓越營運原則中的基本指引。 這些章節旨在提供受管制環境的最佳做法摘要說明。
角色劃分
在受管制環境中強制執行明確的權責區分是關鍵所在。 根據工作負載需求以及與 CDE 的互動，定義角色和責任。 例如，您可能需要建立基礎結構操作員或網站可靠性工程師 (SRE) 角色，以執行與叢集和相依服務相關的作業。 此角色負責維護安全性、隔離、部署和可檢視性。 將這些定義正規化，並決定這些角色所需的權限。 例如，SRE 需要擁有極高的叢集存取權，但只需要擁有工作負載命名空間的讀取存取權。
工作負載隔離
PCI-DSS 3.2.1 要求在執行作業時，將 PCI 工作負載與其他工作負載隔離。 此實作將範圍內和範圍外的工作負載分割為兩個不同的使用者節點集區。 範圍內和範圍外工作負載的應用程式開發人員，可能會分別擁有不同的權限組合。 此外還會設定不同的品質閘門。 例如，範圍內的程式碼需要遵守合規性和證明要求，範圍外的程式碼則不需要。 此外，還需要分別設立不同的組建管線和發行管理流程。
作業中繼資料
根據 PCI DSS 3.2.1 標準的需求 12，您必須維護有關工作負載清查和人員存取權文件的資訊。 強烈建議使用 Azure 標籤，因為這樣可以將環境資訊與 Azure 資源、資源群組和訂用帳戶進行整合。
維護已納入基礎結構和工作負載之已核准解決方案的相關資訊。 當中包含一份您選擇導入 CDE 的 VM 映像、資料庫和第三方解決方案的清單。 您甚至可以建立服務類別目錄，以自動執行此流程。 服務類別目錄會根據進行中的平台作業，在特定組態中使用已核准的解決方案來提供自助式部署。
可檢視性
為了滿足需求 10，CDE 的可檢視性對於合規性至關重要。 活動記錄提供了與帳戶和秘密管理、診斷設定管理、伺服器管理以及其他資源存取作業相關的資訊。 所有記錄皆包含日期、時間、身分識別和其他詳細資訊。 在 Azure 監視器記錄中設定資料保留和封存原則，將記錄保留長達一年。
確保記錄僅供有需要的角色存取。 Log Analytics 和 Microsoft Sentinel 支援各種可用來管理稽核線索存取權的角色型存取控制項。
回應和補救
Azure 監視服務、Azure 監視器和適用於雲端的 Microsoft Defender 可以在偵測到異常活動時，產生通知或警示。 這些警示包含嚴重性、狀態和活動時間等脈絡資訊。 有警示產生時，請制定補救策略和審查程序。 建議您將資料集中在安全性資訊和事件管理 (SIEM) 解決方案中，因為整合這些資料有助於提供豐富的警示脈絡資訊。
您可以透過適用於雲端的 Microsoft Defender 中的安全性警示檢視，存取適用於雲端的 Microsoft Defender 在您的資源上偵測到的所有警示。 制定用來解決問題的分級流程。 與您的安全團隊合作，了解如何向工作負載擁有者提供相關警示。
效能效率
遵循效能效率原則中的基本指引。 這些章節旨在提供受管制環境的最佳做法摘要說明。
調整大小
觀察環境如何適應不斷變化的需求，有助於了解環境在高負載情況下的預期執行階段行為。 自動調整工作負載中的資源，有助於盡可能減少 CDE 中的人為互動。 附加的安全性優勢是能夠隨時減少受攻擊面。 您可以善用支援「調整為零」方法的資源，將這項優勢最大化。 例如，AKS 支援將使用者節點集區調整為零。 如需詳細資訊，請參閱將使用者節點集區調整為零。
資料分割
分割是受管制工作負載效能效率的關鍵因素。 擁有離散元件可幫助您明確定義責任，並有助於執行精確的控制項 (例如網路原則)。 與任何分割策略類似，資料分割可以隔離元件，並控制爆發範圍對非預期失敗或系統危害的影響。
零共用架構
零共用架構旨在消除共置工作負載之間的爭用。 此外，它也是消除單點故障的策略之一。 在受管制環境中，元件需透過邏輯或實體邊界進行隔離。 這與零共用架構一致，因而可帶來延展性優勢。 此外，它還能針對各個元件執行相關的安全性控制項，以及更嚴格的稽核功能。
輕量型工作負載
工作負載的複雜性十分難以記錄與稽核。 基於效能優勢考量，以及為了遵守便於稽核的法規需求，因此應力求簡單。 重新考慮涵蓋範圍超出實際需求的選項，因為它們會增加受攻擊面，以及誤用或設定錯誤的可能性。
可靠性
受管制環境的可靠性必須是可預測的，這樣才能基於稽核目的進行一致的解讀。 請遵循可靠性原則中的基本指引。 這些章節旨在提供受管制環境的最佳做法摘要說明。
復原目標和災害復原
受管制的工作負載所處理的資料具有敏感性，因此定義復原目標和復原點目標 (RPO) 至關重要。 可接受多少 CHD 遺失？ CDE 內的復原工作仍需遵守標準需求。 預期失敗將會發生，並根據各個角色、責任和合理的資料存取權，制定對應的明確失敗復原方案。 即時網站問題不構成違反任何法規的理由。 在全面災害復原的情況下，這點特別重要。 製作清楚且符合需求的災害復原文件，並盡可能減少非預期的 CDE 或 CHD 存取。 復原後，請務必檢查復原流程中的步驟，以確保不會發生非預期的存取。 記錄這些復原案例的業務理由。
復原
在您的架構中加入恢復和復原策略，可以消除對 CDE 的臨時存取需求。 系統應能按照定義的 RPO 自我復原，無需直接人為介入。 如此將能消除不必要的 CHD 暴露，就連經授權獲得緊急存取權的人員也是如此。 復原流程必須可供稽核。
解決安全性相關風險
檢查安全性風險，因為它們可能是工作負載停機和資料遺失的根源。 對安全性的投資也會連帶影響工作負載的可靠性。
操作流程
可靠性會延伸至 CDE 內部，以及相鄰的所有作業流程。 根據映像建置、跳躍箱管理等考量，制定定義完善且和經過測試的自動化流程，是打造架構完善解決方案的重要因素。
成本最佳化
遵循成本最佳化原則中的基本指引。
由於合規性需求和嚴格的安全性控制要求，成本將成為明顯的權衡要素。 建議使用定價計算機進行初步估算。
此示意圖大致說明了此架構使用的主要資源對成本的影響。
主要成本來源是構成節點集區和 Azure 防火牆的虛擬機器擴展集。 另一項成本來源是 Log Analytics。 適用於雲端的 Microsoft Defender 也會產生相關的累加費用，視您選擇的方案而定。
清楚了解服務價格的構成要素。 Azure 會追蹤計量付費使用量。 此圖表深入分析了 Azure 防火牆對此架構的成本影響。
與 Azure 防火牆等資源相關的成本，可以由多個業務單位或應用程式共同分攤。 最佳化成本的另一種可行方法，是在組織內裝載多租用戶叢集，以透過工作負載多樣性將密度最大化。 然而，我們不建議針對受管制的工作負載使用此方法。 請一律優先考慮合規性和分割，而非成本效益。
為了不超出預算限制，一些控制成本的方法包括：調整 Azure 應用程式閘道基礎結構、設定自動調整的執行個體計數，以及減少記錄輸出，前提是仍然符合 PCI-DSS 3.2.1 的稽核線索規定。 請一律根據其他設計層面的權衝因素來評估這些選擇，以符合您的 SLA 需求。 例如，您是否仍能適當擴充，以滿足流量尖峰的需求？
建立 Azure 資源群組時，請套用標籤，以便追蹤成本。 使用 Azure Advisor 和 Microsoft 成本管理等成本管理工具來追蹤和分析成本。
請考慮啟用 AKS 成本分析，以透過 Kubernetes 特有構造，精細分配叢集基礎結構成本。