為適用於 PCI-DSS 3.2.1 的 AKS 受管制叢集設定網路 (第 3 部分，共 9 部分)

本文說明根據支付卡產業資料安全標準 (PCI-DSS 3.2.1) 所設定的 Azure Kubernetes Service (AKS) 叢集的網路功能考量。

本文是系列文章的一部分。 閱讀簡介。

安全性是 PCI-DSS 3.2.1 標準的核心主題。 想要建立受管制的網路環境，中樞輪輻拓樸是最理所當然的選擇。 建立允許安全通訊的基礎結構，是比較容易的做法。 此做法會將網路控制項置於兩個中樞輪輻網路內部，並遵循 Microsoft 零信任模型。 這些控制項可以使用最低權限來調整，以確保流量安全，並根據知情需求來授予存取權。 此外，您可以在每個網路躍點和網路層新增控制項，以套用數種深度防禦方法。

將工作負載裝載於 Kubernetes 中時，僅依賴傳統的網路建構 (例如防火牆規則) 是不夠的。 您還需要使用 Kubernetes 原生建構來控管叢集內部的流量，例如 NetworkPolicy 資源。 強烈建議您參考 Kubernetes 文件，了解有關隔離 Pod 以及輸入和輸出原則的核心概念。

建置及維護安全的網路和系統

需求 1—安裝及維護防火牆組態，以保護持卡人資料

AKS 功能支援

AKS 支援在私人虛擬網路中部署叢集，做為私人叢集使用。 叢集與 AKS 管理的 Kubernetes API 伺服器之間的通訊，會透過受信任的網路進行。 透過私人叢集，您可以使用 Azure 虛擬網路、網路安全性群組 (NSG) 和其他內建網路控制項，保護整個持卡人資料環境 (CDE)。 此組態會禁止網際網路與該環境之間任何未經授權的公用存取。 有關如何佈建此類叢集的詳細資訊，請參閱 建立私人 Azure Kubernetes Service 叢集。

Azure 防火牆可以與 AKS 整合，並限制從叢集輸出的流量，而這是 CDE 的一項關鍵機制。 此組態可使用 AKS FQDN 標籤輕鬆完成設定。 使用 Azure 防火牆來保護 Azure Kubernetes Service (AKS) 部署中提供了建議的流程。

AKS 叢集需要對公用網際網路進行一定程度的存取。 請使用叢集子網路上的 Azure 防火牆和 NSG，限制輸出至網際網路的流量。 如需相關資訊，請參閱控制 Azure Kubernetes Service (AKS) 中叢集節點的輸出流量。

AKS 支援定義 HTTP Proxy 的功能 (選用)，可進一步控制輸出流量，並加強叢集監控功能。 叢集節點會根據指定的 HTTP Proxy 組態，設定輸出流量的路由。 此外，系統會登錄 MutatingWebhook ，以便將 Proxy 資訊插入新建立的 Pod，因此建議工作負載應繼承相同的 Proxy 資訊。 Pod 可能會覆寫 Proxy 資訊，因此建議在使用 Azure 防火牆的同時，額外使用 HTTP Proxy。

AKS 叢集應使用 NetworkPolicy 外掛程式建立。 AKS 內部提供幾種網路原則外掛程式選項，包括 Calico、Azure 網路原則管理和 Cilium。 Calico 網路原則可搭配 Kubenet 或 Azure CNI 使用。 Azure 網路原則管理只能搭配 Azure CNI 使用 (不能使用 Kubenet)。 Azure 和 Calico 網路原則外掛程式皆為開放原始碼。 如需 Project Calico 的進一步資訊，請參閱完整的 PCI 解決方案白皮書。此白皮書解決了下列許多防火牆需求。

您的責任

需求	責任
需求 1.1	建立及實作防火牆和路由器組態標準。
需求 1.2	建立防火牆及路由器組態，以限制未受信任的網路與持卡人資料環境中任何系統元件之間的連線。
需求 1.3	禁止網際網路與持卡人資料環境中任何系統元件之間的直接公用存取。
需求 1.4	任何可攜式計算裝置 (包括公司及/或員工擁有的裝置) 只要會在位於網路外時連線到網際網路 (例如員工使用的筆記型電腦)，而且也可用來存取 CDE，即應安裝個人防火牆軟體或對等功能。
需求 1.5	確保用於管理防火牆的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方知悉。

需求 1.1

建立並實施防火牆和路由器組態標準，包括：

需求 1.1.1

用於核准及測試所有網路連線、以及防火牆和路由器組態變更的正式流程。

您的責任

請勿手動實作組態，例如直接使用 Azure 入口網站或 Azure CLI。 建議使用基礎結構即程式碼 (IaC)。 有了 IaC，就能透過使用版本控制系統的描述性模型來管理基礎結構。 IaC 模型會於每次套用時產生相同的環境。 IaC 的常見範例包括 Bicep、Azure Resource Manager 範本 (ARM 範本) 或 Terraform。 如果 IaC 不可行，請制定一套記錄完整的流程，用於追蹤、實作及安全部署防火牆規則變更。 如需更多詳細資料，請參閱需求 11.2 中的部分說明。

您需要搭配使用各種網路控制項，包括 Azure 防火牆、網路安全性群組 (NSG) 和 Kubernetes NetworkPolicy 資源。

盡量減少有權存取和修改網路控制項的人員數目。 為團隊定義角色以及明確的職責。 例如，由組織的網路團隊根據 IT 團隊設定的治理原則來驗證變更。 制定涉及人員和流程的閘道核准流程，以核准任何網路組態的變更。 此流程應包括測試所有網路控制項的步驟。 製作用於說明該流程的詳細文件。

需求 1.1.2

用於識別持卡人資料環境與其他網路 (包括任何無線網路) 之間所有連線的最新網路圖表

您的責任

在文件中維護一份網路流量圖表，用於顯示設有安全性控制項的傳入和傳出流量。 這包括從其他網路 (包括任何無線網路) 傳送到 CDE 的流量。 此圖表亦應顯示叢集內部的流量。 關於圖表有一些特定要求，包括應顯示入侵感應器和已套用的任何控制項。

此圖顯示參照實作的網路圖表。

下載此圖表的 Visio 檔案。

圖 1.1.2 - 網路流量

以下各節提供此流量圖表的說明。

如果您有 Azure 網路監看員，建議檢視 Azure 虛擬網路的拓撲。 您可以檢視虛擬網路中的所有資源、與虛擬網路中的資源相關聯的資源，以及資源之間的關係。

需求 1.1.3

顯示所有持卡人資料在系統和網路之間流動情況的最新圖表。

您的責任

在文件中加入一個資料流程圖表，顯示如何保護待用和傳輸中的資料。

此圖表應顯示資料如何流入和流出工作負載，以及哪些資訊會從一種資源傳送至另一種資源。 確保圖表處於最新狀態。 將更新資料流程圖表新增為變更管理流程中的一個步驟。

此架構著重於基礎結構，而非工作負載，因此我們在此省略了圖例。

需求 1.1.4

需要為每個網際網路連線設置防火牆，並在任何隔離區域 (DMZ) 與內部網路區域之間設置防火牆。

您的責任

必須明確定義 DMZ 的邊界。 例如，持卡人資料環境 (CDE) 可能位於受到防火牆、網路原則和其他控制項保護的 DMZ 內部。 如需詳細資訊，請參閱 雲端 DMZ。

針對 PCI DSS 基礎結構，您需負責使用網路控制項，禁止包含 CDE 的網路遭到未經授權的進出存取，以保護 CDE。 為了建立強大的安全性勢態，必須正確設定網路控制項，並將其套用至：

• 叢集內部共置元件之間的通訊。
• 工作負載與受信任網路中其他元件之間的通訊。
• 工作負載與公用網際網路之間的通訊。

此架構會使用不同的防火牆技術，檢查與裝載 CDE 的叢集之間的雙向流動流量：

• 使用 Azure 應用程式閘道做為流量路由器，並使用其整合式 Web 應用程式防火牆 (WAF) 保護叢集接收到的輸入 (傳入) 流量。

• 使用 Azure 防火牆，保護來自任何網路及其子網路的所有輸出 (傳出) 流量。

  處理交易或管理作業時，叢集必須與外部端點進行通訊。 例如，叢集可能需要與 AKS 控制平面進行通訊、與作業系統和套件更新系統進行通訊，還有許多工作負載需要與外部 API 互動。 其中有些互動可能會透過 HTTP 進行，因此應將其視為攻擊媒介。 這些媒介是中間人攻擊的目標，並可能導致資料外流。 為輸出流量新增防火牆，可降低這類威脅。

  我們建議，即使是 Pod 對 Pod 的通訊，也應使用 TLS 加密。 參考實作使用雙向 TLS (mTLS) 驗證，展示了這種做法。

• 新增 NSG 以保護叢集與基礎結構內其他元件之間的流量。 以參考實作中含有節點集區的子網路為例，當中的 NSG 會阻止任何 SSH 存取嘗試。 只允許來自虛擬網路內部的流量。

  在架構中新增元件時，請考慮新增更多 NSG，用於在子網路邊界上允許或拒絕特定的流量類型。 每個節點集區都位於專用子網路中，因此請根據工作負載的預期流量模式，套用更明確的規則。

• Kubernetes NetworkPolicy 物件會用來控制叢集內部的通訊。

  根據預設，Pod 對 Pod 通訊沒有任何限制。 您需要為叢集內部通訊套用 NetworkPolicy，從零信任網路開始，再根據需要開放路徑。 參考實作示範了 a0005-i 和 a0005-o 命名空間中的零信任網路。 所有命名空間 (除了 kube-system、gatekeeper-system 和其他 AKS 提供的命名空間以外) 皆已套用嚴格的網路原則。 原則定義取決於在這些命名空間中執行的 Pod。 確認您已開放用於整備度、活躍度及啟動探查的路徑。 另外，請開放通往 oms-agent 的路徑，以允許傳送節點層級計量。 請考慮將各個工作負載的連接埠標準化，以便為允許的容器連接埠提供一致的 NetworkPolicy 和 Azure 原則。

需求 1.1.5

網路元件管理團隊、角色和職責的描述。

您的責任

您需要針對網路流量及相關元件提供控制項。 由此產生的基礎結構將具有多個網路區段，每個網路區段都有許多控制項，而每個控制項各有一項用途。 確保您的文件涵蓋範圍廣泛，從網路規劃到已套用的所有組態一應俱全。 這些文件還應包含擁有權的詳細資訊，並明確列出責任分工以及負責的角色。

例如，說明 Azure 和網際網路之間的網路安全性是由誰負責治理。 在企業中，IT 團隊通常會負責 Azure 防火牆規則、Web 應用程式防火牆 (WAF) 規則、NSG 和其他跨網路流量的設定和維護。 此外，IT 團隊還可能負責整個企業的虛擬網路和子網路配置，以及 IP 位址規劃。

在工作負載層級，叢集操作員負責透過網路原則維護零信任。 他們的責任還可能包括與 Azure 控制平面、Kubernetes API 和監視技術的通訊。

一開始請一律採用全面拒絕策略。 只有當存在業務需求或角色正當性時，才授與相關權限。

需求 1.1.6

保留所有服務、通訊協定及連接埠 (包括針對不安全的通訊協定所實作的安全性功能) 的核准使用記錄及業務理由。

您的責任

詳細記錄並說明網路控制項中使用的服務、通訊協定和連接埠。 拒絕所有連接埠，但明確允許的連接埠除外。 如果無法避免使用不安全的通訊協定，請記錄業務理由和已實作的安全性功能。 以下是 Azure 防火牆參考實作中的一些範例。 防火牆規則的範圍必須僅限於其相關資源。 也就是說，只允許來自特定來源的流量前往特定的 FQDN 目標。

以下是可能允許流量的一些範例：

規則	通訊協定:連接埠	來源	Destination	靠齊
允許節點與控制平面之間的安全通訊。	HTTPS:443	指派給叢集節點集區的授權 IP 位址範圍	AKS 控制平面中的 FQDN 目標清單。 此清單是透過 AzureKubernetesService FQDN 標籤來指定的。	節點需要存取控制平面，才能取得管理工具、狀態和組態資訊，以及哪些節點可以擴充的相關資訊。
允許 Flux 與 GitHub 之間的安全通訊。	HTTPS:443	AKS 節點集區	%	Flux 是在節點上執行的第三方整合工具。 它能同步化叢集組態與私人 GitHub 存放庫。

需求 1.1.7

需要至少每六個月審查一次防火牆及路由器規則集。

您的責任

請至少每六個月審查一次網路組態，以及已設定領域的規則。 這樣才能確保安全性保證的時效性。 請務必審查下列組態：

• Azure 防火牆規則。
• NSG 規則。
• Azure 應用程式閘道和 WAF 規則。
• 原生 Kubernetes 網路原則。
• 適用 Azure 資源的防火牆控制項。 例如，此架構在 Azure Container Registry 上使用了一項規則，僅允許來自私人端點的流量。
• 您已於架構中新增的任何其他網路控制項。

如果您在上次審查後已淘汰任何工作負載或變更了叢集組態，請務必確認您先前對必要防火牆例外狀況或 NSG 規則所做的任何假設是否仍然有效。

需求 1.2

建立防火牆及路由器組態，以限制未受信任的網路與持卡人資料環境中任何系統元件之間的連線。

您的責任

在此架構中，AKS 叢集是持卡人資料環境 (CDE) 的重要元件。 強烈建議將叢集部署為私人叢集，以增強安全性。 在私人叢集中，AKS 管理的 Kubernetes API 伺服器與節點集區之間的網路流量是私人流量。 API 伺服器會透過叢集網路中的私人端點公開。

您也可以選擇公用叢集，但不建議將此設計用於包含受管制工作負載的叢集。 API 伺服器會對網際網路公開。 DNS 記錄一律可供探索。 因此，您需要設定控制項來保護叢集 API 不受公用存取。 如果需要使用公用叢集，建議的方法是透過 Kubernetes 角色型存取控制 (RBAC) 設定嚴格的控制項，並搭配使用 AKS 授權 IP 範圍功能，限制哪些人可以存取 AKS API 伺服器。 然而，不建議將此解決方案用於包含受管制工作負載的叢集。

處理持卡人資料 (CHD) 時，叢集需要與被視為受信任和不受信任的網路互動。 在此架構中，PCI-DSS 3.2.1 工作負載周邊以內的中樞輪輻網路均會被視為受信任的網路。

周邊以外的網路則為不受信任的網路。 不受信任的網路包括：

• 可能位於同一個基礎結構上，但位於工作負載周邊以外的其他中樞和輪輻。
• 公用網際網路。
• 公司網路。
• Azure 或其他雲端平台上的其他虛擬網路。

在此架構中，裝載映像建立器的虛擬網路不受信任，因為它並未參與 CHD 處理。 CDE 與此類網路的互動應根據需求加以保護。 您可以透過此私人叢集，使用虛擬網路、NSG 和其他內建功能來保護整個環境。

如需私人叢集的相關資訊，請參閱建立私人 Azure Kubernetes Service 叢集。

需求 1.2.1

限制持卡人資料環境所需的傳入與傳出流量，並明確拒絕所有其他流量。

您的責任

根據設計，Azure 虛擬網路無法從公用網際網路直接觸達。 所有輸入 (或 傳入) 流量都必須經過中繼流量路由器。 不過，預設情況下，網路中的所有元件都可以觸達公用端點。 您可以設定私人子網路或使用 UDR 透過防火牆傳送所有輸出流量，以停用該行為。 請務必明確保護該輸出 (或傳出) 流量，以僅允許安全加密和 TLS 1.2 或更新版本。

• Azure 應用程式閘道的整合式 WAF 會攔截所有 HTTP(S) 輸入流量，並將檢查過的流量路由至叢集。

  此流量可能源自於受信任或不受信任的網路。 應用程式閘道會佈建在輪輻網路的子網路中，並由 NSG 保護。 當流量流入時，WAF 規則會加以允許或拒絕，並由應用程式閘道將流量路由至已設定的後端。 例如，應用程式閘道會透過拒絕此類流量來保護 CDE：

  • 所有未經 TLS 加密的流量。
  • 來自 Azure 基礎結構的控制平面通訊連接埠範圍以外的流量。
  • 由叢集內部負載平衡器以外的實體發送的健全狀態探查請求。

• Azure 防火牆用於保護來自受信任和不受信任網路的所有輸出 (傳出) 流量。

  Azure 防火牆佈建於中樞網路的子網路中。 為了強制使用 Azure 防火牆做為單一出口點，會在能夠產生輸出流量的子網路上使用使用者定義的路由 (UDR)。 這包括不受信任網路中的子網路，例如映像建立器虛擬網路。 流量觸達 Azure 防火牆後，將會套用數個範圍規則，以允許來自特定來源的流量觸達特定目標。

  如需詳細資訊，請參閱使用 Azure 防火牆來保護 Azure Kubernetes Service (AKS) 部署。

• 您可以選擇性地使用 HTTP Proxy 來監視和保護從叢集到外部資源的輸出 (傳出) 流量。

  除了防火牆之外，有些組織可能還希望使用 HTTP Proxy 對輸出流量進行額外控制。 建議您仍讓使用者定義的路由指向防火牆，並限制輸出流量僅能前往 HTTP Proxy。 透過此設定，當 Pod 嘗試覆寫 Proxy 時，防火牆仍然可以封鎖輸出流量。

  如需詳細資訊，請參閱Azure Kubernetes 服務中的 HTTP Proxy 支援。

叢集可能需要透過公用網際網路存取其他服務。 舉例來說，如果您使用第三方反惡意程式碼軟體，則需要透過公用網際網路從伺服器取得病毒定義。

與其他 Azure 服務端點的互動會透過 Azure 骨幹進行。 例如，在例行作業中，叢集需要從受控金鑰存放區中取得憑證、從容器登錄中提取映像等。 請使用 Azure Private Link，確保這些互動私密且安全。

除了防火牆規則和私人網路之外，還可以透過 NSG 規則來保護流量。 以下是一些在此架構中透過拒絕流量來保護 CDE 的範例：

• 含有節點集區的子網路上的 NSG 會拒絕對節點的任何 SSH 存取。 請確定您已訂定及時緊急存取流程，同時仍維持全面拒絕原則。
• 含有用來執行管理工具之跳躍箱的子網路上的 NSG 會拒絕所有流量，除了來自中樞網路內部 Azure Bastion 的流量。
• 含有 Azure Key Vault 和 Azure Container Registry 私人端點之子網路上的 NSG 會拒絕所有流量，除了來自內部負載平衡器的流量，以及透過 Azure Private Link 傳送的流量。

需求 1.2.2

保護並同步化路由器組態檔案。

您的責任

設定一種機制，用於偵測實際部署狀態與所需狀態之間的差異。 基礎結構即程式碼 (IaC) 是實現這點的絕佳選擇。 例如，Bicep 檔案或 Azure Resource Manager 範本 (ARM 範本) 會維護所需狀態的記錄。

部署資產 (例如 Bicep 檔案) 必須是來源受控資產，以確保您擁有所有變更的歷程記錄。 從 Azure 活動記錄、部署管線記錄和 Azure 部署記錄收集資訊。 這些來源可協助您追蹤已部署的資產。

在叢集中，Kubernetes 網路原則等網路控制項也應該遵循來源受控流程。 此實作使用 Flux 做為 GitOps 操作元。 當您同步化叢集組態 (例如網路原則) 時，可結合 Git 歷程記錄與 Flux 和 API 記錄，做為組態歷程記錄的來源。

需求 1.2.3

在所有無線網路和持卡人資料環境之間安裝周邊防火牆，並將這些防火牆設為拒絕；如果基於業務目的需要流量，則僅允許授權流量在無線環境和持卡人資料環境之間傳輸。

您的責任

禁止透過無線網路觸達 AKS 節點和節點集區。 此外，對 Kubernetes API 伺服器的要求也必須加以拒絕。 只有經過授權且受到保護的子網路，才能擁有這些元件的存取權。

一般而言，應限制來自內部部署的流量對輪輻網路的存取。

需求 1.3

禁止網際網路與持卡人資料環境中任何系統元件之間的直接公用存取。

您的責任

AKS 叢集節點集區會在虛擬網路內部運作，並與網際網路等公用網路隔離。 為了保持隔離，必須避免公用 IP 與叢集節點產生關聯，並對叢集子網路套用 NSG 規則，以確保網際網路流量遭到封鎖。 有關受控存取的資訊，請參閱 DMZ 區段。

AKS 叢集含有裝載關鍵系統 Pod 的系統節點集區。 即使在使用者節點集區上，也會有 Pod 執行其他參與叢集作業的服務。 例如，Pod 可能會執行 Flux，以便將叢集組態與 GitHub 存放庫同步化；或執行輸入控制器，以便將流量路由至工作負載 Pod。 無論節點集區的類型為何，所有節點皆需受到保護。

另一個重要的系統元件，是用於執行原生 Kubernetes 任務 (例如維護叢集和組態的狀態) 的 API 伺服器。 使用私人叢集的一個好處是，API 伺服器端點預設不會公開。 如需私人叢集的相關資訊，請參閱建立私人 Azure Kubernetes Service 叢集。

與其他端點的互動也需要受到保護。 其中一種方法是限制透過私人網路的通訊。 例如，讓叢集透過私人連結從 Azure Container Registry 提取映像。

需求 1.3.1

實作 DMZ，限制輸入流量只能前往用來提供經授權可公開存取之服務、通訊協定及連接埠的系統元件。

您的責任

這裡有一些最佳做法：

• 請勿在節點集區節點上設定公用 IP 位址。
• 使用 Azure 原則，確保 Kubernetes 不會公開公用負載平衡器。 叢集內部的流量必須透過內部負載平衡器路由傳送。
• 內部負載平衡器只能向已整合 WAF 的 Azure 應用程式閘道公開。
• 所有網路控制項應指定來源、目的地、連接埠和通訊協定限制 (如適用)。
• 請勿在網際網路上公開 API 伺服器。 以私人模式執行叢集時，端點不會公開，且節點集區與 API 伺服器之間的通訊會透過私人網路進行。

使用者可以實作周邊網路來保護 AKS 叢集。 如需詳細資訊，請參閱雲端 DMZ。

需求 1.3.2

限制輸入網際網路流量只能前往 DMZ 內部的 IP 位址。

您的責任

在叢集網路內部含有內部負載平衡器的子網路上建立一個 NSG。 設定規則，僅接受來自已整合 WAF 之 Azure 應用程式閘道所在子網路的流量。 在 AKS 叢集中，使用 Kubernetes NetworkPolicies 來限制前往 Pod 的輸入流量。

需求 1.3.3

實施反詐騙措施，以偵測並阻止偽造的來源 IP 位址進入網路。

Azure 的責任

Azure 會實施網路篩選措施，以防止詐騙流量，並限制受信任平台元件的輸入和輸出流量。

需求 1.3.4

禁止未經授權的輸出流量從持卡人資料環境傳送至網際網路。

您的責任

您可以使用以下方法，封鎖未經授權的輸出流量：

• 在所有叢集子網路上使用使用者定義的路由 (UDR)，強制來自 AKS 叢集的所有輸出 (傳出) 流量通過 Azure 防火牆。 這包括含有系統和使用者節點集區的子網路。
• 在含有節點集區的子網路上新增 NSG，以限制輸出流量。
• 使用 Kubernetes NetworkPolicies，限制來自 Pod 的輸出流量。
• 使用服務網格處理其他原則。 舉例來說，如果您只允許經過 TLS 加密的流量在 Pod 之間傳送，則可以使用服務網格 Proxy 處理 TLS 驗證。 此實作提供該範例的示範。 將 Envoy 部署為 Proxy。
• 除非是明確授權的子網路 (例如防火牆子網路)，否則禁止在 CDE 內部的網路中新增公用 IP 位址。
• 除了 Azure 防火牆，還可以使用 HTTP Proxy 來限制從 AKS 叢集到網際網路的輸出 (傳出) 流量。
• 使用 Azure 監視器私人連結服務 (AMPLS)，將容器深入解析記錄透過安全的私人連線傳送至 Azure 監視器。 了解啟用 AMPLS 的影響。

如需詳細資訊，請參閱控制 Azure Kubernetes Service (AKS) 中叢集節點的輸出流量。

需求 1.3.5

只允許「已建立」的連線連進網路。

Azure 的責任

Azure 會實施網路篩選措施，以防止詐騙流量，並限制受信任平台元件的輸入和輸出流量。 Azure 網路會遭到隔離，以劃分客戶流量和管理流量。

需求 1.3.6

將儲存持卡人資料的系統元件 (例如資料庫) 放在內部網路區域中，與 DMZ 及其他不受信任的網路隔離。

您的責任

僅透過私人網路公開您的儲存系統，例如使用私人連結。 另外，請限制只有確實有需要的節點集區子網路，才能存取該系統。 將狀態資料保留在叢集外的專用安全性區域中。

需求 1.3.7

請勿將私人 IP 位址和路由資訊洩漏給未經授權的合作對象。

您的責任

為了符合此需求，請勿選擇使用公用 AKS 叢集。 私人叢集會使用私人 DNS 區域，將 DNS 記錄保留在公有網際網路之外。 不過，仍然可以建立具有公用 DNS 位址的私人 AKS 叢集。 因此，為了避免洩漏控制平面的私人 IP 位址，建議您將 enablePrivateClusterPublicFQDN 設定為 false 以明確停用此功能。 請考慮使用 Azure 原則，強制使用不含公用 DNS 記錄的私人叢集。

此外，請使用私人 DNS 區域，在已整合 WAF 的 Azure 應用程式閘道所屬子網路與內部負載平衡器所屬子網路之間進行路由傳送。 確認 HTTP 回應的標頭或本文並未包含任何私人 IP 資訊。 確保除非基於作業需求，否則不會公開可能包含 IP 和 DNS 記錄的記錄。

透過私人連結連接的 Azure 服務所包含的公用 DNS 記錄，不得導致您的私人 IP 位址公開。 基礎結構應該充分運用私人連結。

需求 1.4

任何可攜式計算裝置只要會在位於網路外時連線到網際網路，而且也可用來存取 CDE，即應安裝個人防火牆軟體或對等功能。

您的責任

私人叢集是由 AKS 控制平面管理。 您無權直接存取節點。 若要執行管理工作，您需要使用個別計算資源提供的管理工具，例如 kubectl。 其中一種選擇是使用實體隔離跳躍箱，您可以在當中執行命令。 此外，來自跳躍箱的輸入和輸出流量必須設有限制，而且安全無虞。 如果使用 VPN 進行存取，請確保用戶端電腦受到公司原則管理，並執行所有條件式存取原則。

在此架構中，該跳躍箱位於輪輻網路中的個別子網路中。 使用僅允許透過 Azure Bastion over SSH 存取的 NSG，限制對跳躍箱的輸入存取。

您需要觸達公用端點，才能在跳躍箱上執行特定命令。 例如，由 Azure 管理平面管理的端點。 輸出流量必須安全無虞。 與輪輻網路中的其他元件類似，來自跳躍箱的輸出流量需使用 UDR 加以限制，以強制 HTTPS 流量通過 Azure 防火牆。

需求 1.5

確保用於管理防火牆的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方知悉。

您的責任

請務必保留有關流程與原則的完整文件。 管理用於區隔 AKS 叢集的 Azure 防火牆規則時，這點特別重要。 受管制環境的作業人員必須接受培訓、充分知情並受到獎勵，以確保安全性保證。 對於擁有廣泛管理權限的帳戶使用者來說，這點特別重要。

需求 2 — 請勿使用廠商提供的預設系統密碼和其他安全性參數

您的責任

需求	責任
需求 2.1	在網路上安裝系統之前，請務必變更廠商提供的預設值，並移除或停用不必要的預設帳戶。
需求 2.2	為所有系統元件制定組態標準。 確保這些標準能夠解決所有已知的安全性弱點，並符合業界公認的系統強化標準。
需求 2.3	使用強式密碼，加密所有非主控台系統管理存取權。
需求 2.4	維護一份 PCI DSS 範圍內的系統元件清查目錄。
需求 2.5	確保用於管理廠商預設值以及其他安全性參數的安全性原則及作業程序留有記錄、正在使用，並為所有受影響方知悉。
需求 2.6	共用裝載提供者必須保護每個實體的裝載環境和持卡人資料。

請勿使用廠商提供的預設系統密碼和其他安全性參數

需求 2.1

在網路上安裝系統之前，請務必變更廠商提供的預設值，並移除或停用不必要的預設帳戶。

您的責任

請務必變更廠商提供的預設設定。 預設設定是常見的攻擊媒介，會讓系統更容易受到攻擊。 以下是一些考量：

• 請停用容器登錄的管理員存取權。
• 確保跳躍箱和組建代理程式遵循使用者管理程序，並移除不需要的系統使用者。
• 請勿產生或向管理員使用者提供節點的 SSH 金鑰存取權。 需要緊急存取時，請透過 Azure 復原程序取得即時存取權。

Azure 的責任

Microsoft Entra ID 含有密碼原則，會針對使用者提供的新密碼強制執行。 變更密碼時，需要驗證先前的密碼。 系統管理員重設密碼後，使用者必須在下次登入時變更該密碼。

需求 2.1.1

安裝連線至持卡人資料環境或傳輸持卡人資料的無線環境時，請變更「所有」無線廠商預設值，包括但不限於預設無線加密金鑰、密碼和 SNMP 社群字串。

您的責任

此架構和實作並非設計用來透過無線連線，進行內部部署或公司網路至雲端的交易。 相關考量事項請參閱官方 PCI-DSS 3.2.1 標準中的指引。

需求 2.2

為所有系統元件制定組態標準。

您的責任

實作 Microsoft 雲端安全性基準中的建議。 該基準提供了 Azure 安全性建議的單一彙總檢視，涵蓋 CIS、NIST、PCI-DSS 3.2.1 等產業架構。 使用適用於雲端的 Microsoft Defender 功能和 Azure 原則，協助追蹤這些標準。 Azure 安全性基準是適用於雲端的 Microsoft Defender 的預設方案。 請考慮在 Azure 原則和 Azure 租用戶安全性解決方案 (AzTS) 中，建置額外的自動化檢查項目。

記錄 CDE 中所有元件的預期組態狀態，特別是 AKS 節點、跳躍箱、建置代理程式以及其他與叢集互動的元件。

如需詳細資訊，請參閱 Microsoft 雲端安全性基準。

Azure 的責任

Azure 提供的安全性組態標準符合業界公認的安全性強化標準。 這些標準每年至少會審查一次。

需求 2.2.1

每部伺服器僅實作一項主要功能，以防止需要不同安全性等級的功能共存於同一部伺服器上。 (例如，Web 伺服器、資料庫伺服器和 DNS 應在不同的伺服器上實作。)

您的責任

關鍵策略是提供所需的分割層級。 其中一種方法，是將範圍內和範圍外的元件分別部署在不同的叢集中。 需要了解的是，這會導致額外基礎結構的成本和維護負擔增加。 另一種方法是將所有元件共置於一個共用叢集中。 使用分割策略來保持分隔狀態。 例如，在一個叢集中設置數個獨立的節點集區。

參考實作藉由將微服務應用程式部署至單一叢集的例子，示範了如何使用第二種方法。 該應用程式有兩組服務：一組含有範圍內的 Pod，另一組則含有範圍外的 Pod。 這兩組服務會分散於兩個使用者節點集區中。 使用 Kubernetes 污點，將範圍內和範圍外的 Pod 分別部署至不同的節點集區，讓它們永遠不會共用節點 VM。

容器技術預設提供這樣的分割功能，因為一個容器執行個體只負責系統中的一項功能。

每個工作負載 Pod 皆應使用自己的身分識別。 不得繼承任何叢集層級或節點層級的身分識別。

盡可能使用外部儲存體，而不要使用節點上 (叢集內) 的儲存體。 保留叢集 Pod，專門用於執行持卡人資料處理作業中的必要工作。 將範圍外的作業移出叢集。 這項指引適用於建置代理程式、不相關的工作負載，或在叢集內部設置跳躍箱等活動。

需求 2.2.2

根據系統功能需求，僅啟用必要的服務、通訊協定、精靈等。

您的責任

啟用功能之前，請先了解其作用和影響。 預設設定可能包含您不需要的功能，且這些功能可能需要取得工作負載的檢視權限。 Azure 應用程式閘道預設 SSL 原則中的加密功能即為一例。 檢查原則是否過於寬鬆。 建議僅選取您需要的加密功能，以建立自訂原則。

針對您擁有完整控制權的元件，請從映像中移除所有不必要的系統服務。 例如，檢查跳躍箱和組建代理程式的映像，並移除任何不需要的元件。

對於您僅擁有檢視權限的元件 (例如 AKS 節點)，請記錄 Azure 在節點上安裝的內容。 請考慮使用 DaemonSets，對這些雲端控制元件進行額外的必要稽核。

需求 2.2.3

所有被視為不安全的必要服務、通訊協定或精靈，皆應實作額外的安全性功能。

您的責任

應用程式閘道已整合 WAF，並會針對發送至其公用端點的要求協商 TLS 交握 (僅允許安全加密)。 參考實作僅支援 TLS 1.2 和已核准的加密功能。

假設您有一部舊版裝置，需要透過 Azure 應用程式閘道與 CDE 互動。 為了滿足這項要求，應用程式閘道必須啟用不安全的通訊協定。 記錄此例外狀況，並監視該通訊協定是否被用於舊版裝置以外的其他用途。 舊版裝置的互動停止之後，立即停用該通訊協定。

應用程式閘道不得回應連接埠 80 上的要求。 請勿在應用程式層級執行重新導向。 此參考實作含有用來封鎖連接埠 80 流量的 NSG 規則。 此規則位於包含應用程式閘道的子網路上。

如果叢集中的工作負載無法遵守有關安全合規性設定檔或其他控制項 (例如限制和配額) 的組織原則，請務必記錄該例外狀況。 您必須進行監視，以確保系統僅執行預期功能。

需求 2.2.4

設定系統安全性參數，以避免濫用。

您的責任

架構中使用的所有 Azure 服務皆需遵循 Microsoft 雲端安全性基準提供的建議。 這些建議可做為選取特定安全性組態設定的起點。 此外，請比較您的組態與該服務的基準實作。 如需有關安全性基準的詳細資訊，請參閱 Azure 的安全性基準。

開放原則代理程式許可控制器會與 Azure 原則搭配運作，以偵測並避免叢集上的錯誤配置。 假設有一個組織原則不允許在節點上配置公用 IP。 偵測到這類配置時，系統會根據原則定義中指定的動作，將其標記為需要稽核或已拒絕。

您可以在基礎結構層級，對 Azure 資源的類型和組態套用限制。 使用 Azure 原則來防止錯誤配置。 此參考實作中，有一項原則拒絕建立非私人的 AKS 叢集。

請務必記錄並定期檢閱所有例外狀況。

Azure 的責任

Azure 會使用多重要素存取控制項，同時根據已記錄的業務需求，確保只有授權人員才能設定 Azure 平台安全性控制項。

需求 2.2.5

移除所有不必要的功能，例如指令碼、驅動程式、功能、子系統、檔案系統及不必要的網頁伺服器。

您的責任

請勿在未參與交易處理、或未提供合規性需求可檢視性的跳躍箱或建置代理程式 (如安全性代理程式) 上安裝軟體。 此建議也適用於叢集實體，例如 DaemonSet 和 Pod。 請務必偵測並記錄所有安裝。

需求 2.3

使用強式密碼，加密所有非主控台系統管理存取權。

您的責任

對叢集的所有系統管理存取皆應使用主控台完成。 請勿公開叢集的控制平面。

Azure 的責任

Azure 可確保在存取 Hypervisor 基礎結構時，強制使用強式密碼編譯。 這確保了使用 Azure 入口網站的客戶能夠使用強式密碼編譯，存取其服務和主機主控台。

需求 2.4

維護一份 PCI DSS 範圍內的系統元件清查目錄。

您的責任

架構內部使用的所有 Azure 資源皆需正確標記。 標籤有助於資料分類，並指出服務位於範圍內還是範圍外。 精確的標記有助於查詢資源、保留清查目錄、追蹤成本，以及設定警示。 此外，請定期保留該文件的快照集。

避免以細微等級標記範圍內或範圍外資源。 隨著解決方案發展，範圍外的資源可能會變為範圍內的資源，即使是間接互動或與持卡人資料相鄰的資源也一樣。 這些資源會受到稽核，並可能成為稽核期間的部分代表性樣本。 請考慮在更高層級 (訂用帳戶和叢集層級) 進行標記。

如需標記注意事項的相關資訊，請參閱資源命名與標記決策指南。

套用 Kubernetes 標籤，以標記叢集內物件。 如此一來，您就可以組織物件、選取物件集合並回報清查目錄。

需求 2.5

確保用於管理廠商預設值以及其他安全性參數的安全性原則及作業程序留有記錄、正在使用，並為所有受影響方知悉。

您的責任

請務必保留有關流程與原則的完整文件。 相關人員需接受有關每項 Azure 資源之安全性功能和組態設定的訓練。 受管制環境的作業人員必須接受培訓、充分知情並受到獎勵，以確保安全性保證。 對於擁有廣泛管理權限的所有人員來說，這些步驟特別重要。

需求 2.6

共用裝載提供者必須保護每個實體的裝載環境和持卡人資料。

您的責任

Azure 可為任何共用的已裝載環境元件提供安全性保證。 強烈建議您將 AKS 節點視為此工作負載的專用主機。 也就是說，所有計算資源皆應採用單一租用戶模型，不得與您可能操作的其他工作負載共用。

如果需要在 Azure 基礎結構層級實現完全的計算隔離，您可以為 Azure Kubernetes 服務 (AKS) 叢集新增 Azure 專用主機。 這種做法可為您的工作負載提供專用的實體伺服器，讓您可以將 AKS 節點直接放入這些已佈建的主機。 選用此架構會對成本造成重大影響，而且需要審慎規劃容量。 這在大部分案例中並不常見。

下一步

保護儲存的持卡人資料。 加密在開放式公用網路上傳輸的持卡人資料。

相關資源

• Azure Kubernetes 服務 (AKS) 架構設計
• 適用於 PCI-DSS 3.2.1 的 AKS 受管制叢集簡介 (第 1 部分，共 9 部分)
• 適用於 PCI-DSS 3.2.1 的 AKS 受管制叢集架構 (第 2 部分，共 9 部分)
• Azure Kubernetes Service (AKS) 叢集的基準架構
• 多區域叢集的 AKS 基準