設定 PCI-DSS 3.2.1 的 AKS 管制叢集網路功能（第 3 部分為 9）

Azure Kubernetes Service (AKS)

Azure 防火牆

Azure 應用程式閘道

Microsoft Entra ID

適用於雲端的 Microsoft Defender

本文說明根據支付卡產業數據安全性標準（PCI-DSS 3.2.1）所設定的 Azure Kubernetes Service （AKS）叢集的網路考慮。

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

PCI-DSS 3.2.1 標準的主要主題是安全性。中樞輪輻拓撲是設定受管制環境的自然選擇。建立允許安全通訊的基礎結構會比較容易。網路控制會放在中樞輪輻網路中，並遵循 Microsoft 零信任模型。控件可以使用最低許可權來調整，以保護流量，並視需要知道的方式提供存取權。此外，您可以在每個網路躍點新增控件，以套用數種深度防禦方法。

當您在 Kubernetes 中裝載工作負載時，依賴傳統網路建構是不夠的，例如防火牆規則。還有 Kubernetes 原生建構可控制叢集內流量，例如 NetworkPolicy 資源。強烈建議您參考 Kubernetes 檔，以了解隔離 Pod 和輸入和輸出原則的核心概念。

重要

指導方針和隨附的實作建置在 AKS 基準架構上。該架構是以中樞輪輻拓撲為基礎。中樞虛擬網路包含用來控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及維護的第三個網路。輪輻虛擬網路包含 AKS 叢集，可提供卡片持有者環境（CDE），並裝載 PCI DSS 工作負載。

GitHub logo GitHub：適用於受管制工作負載的 Azure Kubernetes Service （AKS）基準叢集示範受管制的基礎結構。實作說明在 CDE 中使用各種網路和安全性控制。這包括原生至 Azure 的網路控件，以及 Kubernetes 原生的控件。它也包含應用程式，只是為了示範環境與範例工作負載之間的互動。本文的重點在於基礎結構。此範例不會指出實際的PCI-DSS 3.2.1 工作負載。

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

需求 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 中，您可以在 Azure 或 Calico 之間選擇作為網路原則外掛程式。使用 Calico 網路原則，您可以使用 Kubenet 或 Azure CNI。針對 Azure 網路原則，您只能使用 Azure CNI（而非 Kubenet）。僅限 Calico 支援 Windows 節點的網路原則。 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 的常見範例是 Azure Resource Manager 或 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 的界限。例如，持卡人數據環境（CDE）位於受防火牆、網路原則和其他控制措施保護的 DMZ 內。如需詳細資訊，請參閱 Cloud DMZ。

針對PCI DSS基礎結構，您必須負責使用網路控制來保護 CDE，以封鎖未經授權的存取 CDE。網路控制必須針對強式安全性狀態正確設定，且必須套用至：

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

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

Azure 應用程式閘道整合式 Web 應用程式防火牆（WAF）作為流量路由器，並用來保護叢集的輸入（輸入）流量。
Azure 防火牆可用來保護來自任何網路及其子網的所有輸出（輸出）流量。

在處理交易或管理作業時，叢集必須與外部實體通訊。例如，叢集可能需要與 AKS 控制平面通訊、取得 Windows 和套件更新，以及工作負載與外部 API 的互動。其中一些互動可能透過 HTTP 進行，應該視為攻擊媒介。這些向量是中間人攻擊的目標，可能會導致數據外洩。將防火牆新增至輸出流量可降低該威脅。

我們建議即使是 Pod 對 Pod 通訊也經過 TLS 加密。使用 mTLS 網格的參考實作中會顯示這個做法。
新增 NSG 以保護叢集與基礎結構內其他元件之間的流量。例如，在參考實作中，子網上有 NSG 與節點集區會封鎖任何 SSH 存取嘗試。只允許來自虛擬網路的流量。

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

根據預設，Pod 對 Pod 通訊沒有任何限制。您必須在叢集內通訊上套用 NetworkPolicy ，從零信任網路開始，並視需要開啟路徑。參考實作示範和 a0005-o 命名空間中的a0005-i零信任網路。所有命名空間（除了 kube-system、 gatekeeper-system和其他 AKS 提供的命名空間）都已套用限制 NetworkPolicy 。原則定義取決於在這些命名空間中執行的 Pod。請確定您已開啟整備、即時線和啟動探查的路徑。此外，開啟的路徑 oms-agent ，以便傳送節點層級計量。請考慮將工作負載之間的埠標準化，讓您可以為允許的容器埠提供一致NetworkPolicy且 Azure 原則。

需求 1.1.5

群組、角色和網路元件管理責任的描述。

您的責任

您必須在網路流程和所涉及的元件上提供控制件。產生的基礎結構會有數個網路區段，每個區段都有許多控件，以及每個具有用途的控件。請確定您的文件不僅涵蓋範圍從網路規劃到所有組態，而且具有擁有權的詳細數據。有明確的責任線和對其負責的角色。

例如，知道誰負責管理 Azure 與因特網之間的網路。在企業中，IT 小組負責設定和維護 Azure 防火牆規則、Web 應用程式防火牆（WAF）、NSG 和其他跨網路流量。它們也可能負責全企業虛擬網路和子網配置，以及IP位址規劃。

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

一律從全部拒絕策略開始。只有在有商務需求或角色理由時，才授與許可權。

需求 1.1.6

允許使用所有服務、通訊協定和埠的商業理由和核准檔，包括針對那些視為不安全的通訊協定所實作的安全性功能檔。

您的責任

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

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

需求 1.1.7

至少每六個月檢閱防火牆和路由器規則集的需求。

您的責任

請至少每六個月處理一次，以檢閱網路設定和範圍規則。這可確保安全性保證是最新且有效的。請確定您檢閱這些組態：

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

需求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 與這類網路的互動應根據需求受到保護。使用此私人叢集，您可以使用 Azure 虛擬網絡、NSG 和其他內建功能來保護整個環境。

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

需求 1.2.1

限制持卡人數據環境所需的輸入和輸出流量，並特別拒絕所有其他流量。

您的責任

根據設計，公用因特網無法直接連線 Azure 虛擬網絡。所有輸入（或輸入）流量都必須通過中繼流量路由器。不過，網路中的所有元件都可以連線到公用端點。必須明確保護輸出（或輸出）流量，只允許安全的加密和 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 Service 中的 HTTP Proxy 支援。

叢集可能需要透過公用因特網存取其他服務。如果您使用第三方反惡意代碼軟體，則必須透過公用因特網從伺服器取得病毒定義。

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

除了防火牆規則和專用網之外，NSG 流量也會透過規則受到保護。以下是此架構中的一些範例，其中 CDE 受到拒絕流量的保護：

具有節點集區的子網上的 NSG 會拒絕對其節點的任何 SSH 存取。備妥 Just-In-Time 緊急存取的程式，同時仍維持全部拒絕原則。
子網上的 NSG 具有執行管理工具的跳躍方塊，會拒絕中樞網路中 Azure Bastion 以外的所有流量。
在具有 Azure 金鑰保存庫和 Azure Container Registry 私人端點的子網上，NSG 會拒絕來自內部負載平衡器和 Azure Private Link 流量以外的所有流量。

需求 1.2.2

保護及同步處理路由器組態檔。

您的責任

有機制可偵測實際部署狀態與所需狀態之間的差異。基礎結構即程序代碼（IaC）是該用途的絕佳選擇。例如，Azure Resource Manager 範本具有所需狀態的記錄。

部署資產，例如 ARM 範本，必須受到原始檔控制，才能擁有所有變更的歷程記錄。從 Azure 活動記錄、部署管線記錄和 Azure 部署記錄收集資訊。這些來源可協助您保留已部署資產的線索。

在叢集中，Kubernetes 網路原則之類的網路控制也應該遵循原始檔控制的流程。在此實作中，Flux 會當做 GitOps 操作員使用。當您同步處理叢集設定，例如網路原則時，結合 Flux 和 API 記錄的 Git 歷程記錄可以是組態歷程記錄來源。

需求 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 叢集。如需詳細資訊，請參閱 Cloud 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 的輸出流量。
使用服務網格來處理其他原則。例如，如果您只允許 Pod 之間的 TLS 加密流量，服務網格 Proxy 可以處理 TLS 驗證。此實作會示範該範例。 Envoy 會部署為 Proxy。
除非由明確授權的子網，例如防火牆子網，否則防止將公用IP位址新增至CDE內的網路。
除了 Azure 防火牆之外，使用 HTTP Proxy 來限制從 AKS 叢集到因特網的輸出（輸出）流量。
使用 Azure 監視器 Private Link Service （AMPLS）從透過安全且私人連線傳送至 Azure 監視器的容器深入解析記錄。了解啟用 AMPLS 的影響。

注意

您可以使用 Kubernetes NetworkPolicies 來限制 Pod 的輸入和輸出流量。

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

需求 1.3.5

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

Azure 責任

Azure 會實作網路篩選，以防止詐騙流量，並將傳入和傳出流量限製為受信任的平台元件。 Azure 網路會隔離為將客戶流量與管理流量分開。

需求 1.3.6

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

您的責任

例如，僅透過專用網公開您的記憶體系統，例如使用 Private Link。此外，請限制從需要節點集區子網的存取。將狀態從叢集和自己的專用安全性區域中保留。

需求 1.3.7

請勿向未經授權的合作物件揭露私人IP位址和路由資訊。

您的責任

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

此外，使用私人 DNS 區域，在 Azure 應用程式閘道已與 WAF 整合的子網和具有內部負載平衡器的子網之間路由傳送。請確定標頭或本文中沒有任何 HTTP 回應包含任何私人 IP 資訊。確定可能包含IP和 DNS 記錄的記錄不會在作業需求之外公開。

透過 Private Link 連線的 Azure 服務沒有公開 IP 位址的公用 DNS 記錄。您的基礎結構應充分利用 Private Link。

需求1.4

在網路外部連線到因特網的任何可攜式運算裝置上安裝個人防火牆軟體或對等功能，以及用來存取 CDE 的裝置。

您的責任

私人叢集是由 AKS 控制平面所管理。您無法直接存取節點。若要執行系統管理工作，您必須使用來自個別計算資源的管理工具，例如 kubectl。選項是使用空中跳躍方塊，您可以在其中執行命令。此外，跳躍方塊的輸入和輸出流量也必須受到限制且安全。如果 VPN 用於存取，請確定用戶端電腦是由公司原則所管理，而且所有條件式存取原則都已就緒。

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

若要在跳躍方塊上執行特定命令，您必須連線到公用端點。例如，由 Azure 管理平面管理的端點。輸出流量必須安全。與輪輻網路中的其他元件類似，跳躍方塊中的輸出流量受限於使用強制 HTTP 流量通過 Azure 防火牆的 UDR。

需求 1.5

請確定管理防火牆的安全策略和操作程序記載、使用中，以及所有受影響的合作物件都知道。

您的責任

請務必維護有關程序與原則的徹底檔。當您管理區隔 AKS 叢集的 Azure 防火牆規則時，尤其如此。人員受監管的環境必須經過教育、通知和激勵，以支援安全性保證。對於獲授與廣泛系統管理許可權之帳戶的人員來說，這特別重要。

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

您的責任

需求	責任
需求 2.1	在網路上安裝系統之前，請一律變更廠商提供的預設值，並移除或停用不必要的預設帳戶。
需求 2.2	為所有系統元件開發元件開發元件標準。確保這些標準能解決所有已知的安全性弱點，並與業界公認的系統強化標準一致。
需求 2.3	使用強式密碼編譯來加密所有非控制台系統管理存取。
需求 2.4	維護PCI DSS範圍內的系統元件清查。
需求 2.5	請確定管理廠商預設值和其他安全性參數的安全策略和操作程序記載、使用中，以及所有受影響的合作物件都知道。
需求 2.6	共用主機提供者必須保護每個實體的託管環境和持卡人數據。

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

需求 2.1

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

您的責任

廠商所提供的預設設定必須變更。默認設定是常見的攻擊媒介，可讓系統容易遭受攻擊。以下是一些考量：

停用容器登錄上的系統管理員存取權。
請確定跳板和建置代理程式遵循使用者管理程式，移除所需的系統使用者。
請勿產生或提供節點的 SSH 金鑰存取權給系統管理員使用者。如果需要緊急存取，請使用 Azure 復原程式來取得 Just-In-Time 存取。

Azure 責任

Microsoft Entra ID 具有在使用者提供的新密碼上強制執行的密碼原則。如果您變更密碼，則需要驗證較舊的密碼。管理員 istrator 重設密碼必須在後續登入時變更。

需求 2.1.1

對於連線到持卡人數據環境或傳輸持卡人數據的無線環境，請在安裝時變更 ALL 無線廠商預設，包括但不限於預設無線加密密鑰、密碼和 SNMP 社群字串。

您的責任

此架構和實作並非設計為透過無線連線對雲端交易執行內部部署或公司網路。如需考慮，請參閱官方PCI-DSS 3.2.1標準中的指引。

需求 2.2

為所有系統元件開發元件開發元件標準。

您的責任

在 Azure 安全性效能評定中實作建議。其提供 Azure 安全性建議的單一合併檢視，涵蓋 CIS、NIST、PCI-DSS 3.2.1 等產業架構。使用適用於雲端的 Microsoft Defender 功能和 Azure 原則來協助追蹤標準。 Azure 安全性效能評定是適用於雲端的 Microsoft Defender 的預設方案。請考慮在 Azure 原則和 Azure 租使用者安全性解決方案中建置額外的自動化檢查（AzTS）。

記錄 CDE 中所有元件所需的設定狀態，特別是針對 AKS 節點、跳躍方塊、建置代理程式，以及其他與叢集互動的元件。

如需詳細資訊，請參閱 Azure 安全性效能評定。

Azure 責任

Azure 提供與業界公認的強化標準一致的安全性設定標準。標準至少每年審查一次。

需求 2.2.1

每個伺服器只實作一個主要函式，以防止需要不同安全性層級的函式在相同伺服器上共同存在。（例如，網頁伺服器、資料庫伺服器和 DNS 應該在不同的伺服器上實作。

您的責任

關鍵策略是提供所需的分割層級。其中一種方式是在個別叢集中部署範圍和範圍外元件。瞭解這會導致增加基礎結構和維護額外負荷的成本增加。另一種方法是在共用叢集中共置所有元件。使用分割策略來維護分隔。例如，在叢集中有個別的節點集區。

在參考實作中，第二種方法示範的是部署至單一叢集的微服務應用程式。應用程式有兩組服務：一組具有範圍中的 Pod，另一組則非範圍。這兩個集合會分散到兩個用戶節點集區。使用 Kubernetes 污點時，範圍內和範圍外 Pod 會部署到不同的節點集區，且永遠不會共享節點 VM。

針對容器技術，預設會提供該分割，因為只有一個容器實例負責系統中的一個函式。

工作負載應該使用Pod受控識別。它不得繼承任何叢集層級或節點層級身分識別。

盡可能使用外部記憶體，而不是節點上（叢集中）記憶體。保留叢集 Pod 專用於必須作為卡片持有人數據處理作業作業的一部分執行的工作。將超出範圍的作業移至叢集外部。本指南適用於建置代理程式、不相關的工作負載或活動，例如在叢集內有跳躍方塊。

需求 2.2.2

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

您的責任

在啟用功能之前，請先檢閱功能和含意。默認設定可能包含您不需要的功能，而且這些功能可能需要查看工作負載。其中一個範例是預設 SSL 原則中 Azure 應用程式閘道的加密。檢查原則是否過於寬鬆。建議只選取您需要的加密來建立自定義原則。

對於擁有完整控制權的元件，請從映像中移除所有不必要的系統服務（例如跳躍方塊和建置代理程式）。

針對只有可見度的元件，例如 AKS 節點，記載 Azure 在節點上安裝的內容。請考慮使用 DaemonSets 來提供這些雲端控制元件所需的任何其他稽核。

需求 2.2.3

針對任何被視為不安全的必要服務、通訊協定或精靈，實作其他安全性功能。

您的責任

應用程式閘道具有整合式 WAF，並交涉傳送至其公用端點之要求的 TLS 交握，只允許安全的加密。參考實作僅支援 TLS 1.2 和已核准的加密。

假設您有需要透過 Azure 應用程式閘道與 CDE 互動的舊版裝置。為此，應用程式閘道必須啟用不安全的通訊協定。記錄該例外狀況，並監視該通訊協定是否使用超過該舊版裝置。在該舊版互動停止之後，立即停用該通訊協定。

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

如果叢集中的工作負載無法遵循安全性合規性配置檔或其他控件的組織原則（例如限制和配額），請確定已記載例外狀況。您必須監視以確保只執行預期的功能。

需求 2.2.4

設定系統安全性參數以防止誤用。

您的責任

架構中使用的所有 Azure 服務都必須遵循 Azure 安全性效能評定所提供的建議。這些建議提供您選取特定安全性組態設定的起點。此外，請比較您的組態與該服務的基準實作。如需安全性基準的詳細資訊，請參閱 Azure 的安全性基準。

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

在基礎結構層級，您可以對 Azure 資源的類型和設定套用限制。使用 Azure 原則來防止這些情況。在此參考實作中，有一個原則會拒絕建立非私用的 AKS 叢集。

定期確保記錄並檢閱所有例外狀況。

Azure 責任

Azure 可確保只有授權的人員能夠使用多重要素訪問控制和記載的商務需求來設定 Azure 平臺安全性控制。

需求 2.2.5

拿掉所有不必要的功能，例如腳本、驅動程式、功能、子系統、檔案系統和不必要的網頁伺服器。

您的責任

請勿在跳板或建置代理程式上安裝軟體，這些代理程式不會參與交易的處理，或提供合規性需求的可觀察性，例如安全性代理程式。此建議也適用於叢集實體，例如 DaemonSet 和 Pod。請確定偵測到並記錄所有安裝。

需求 2.3

使用強式密碼編譯來加密所有非控制台系統管理存取。

您的責任

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

Azure 責任

Azure 可確保在存取 Hypervisor 基礎結構時強制執行強式密碼編譯。它可確保使用 Microsoft Azure 管理入口網站的客戶能夠使用強式密碼編譯來存取其服務/IaaS 控制台。

需求 2.4

維護PCI DSS範圍內的系統元件清查。

您的責任

架構中使用的所有 Azure 資源都必須正確標記。標籤有助於數據分類，並指出服務是否在範圍內或範圍外。細緻的標記可讓您查詢資源、保留庫存、協助追蹤成本，以及設定警示。同時定期維護該檔的快照集。

請避免在細微層級標記範圍內或範圍外資源。隨著解決方案的發展，範圍外的資源可能會變成範圍內，即使它們間接互動或與卡片持有者數據相鄰也一樣。這些資源會受到稽核，而且可能是稽核期間代表性範例的一部分。請考慮在較高層級的訂用帳戶和叢集層級標記。

如需標記考慮的相關信息，請參閱資源命名和標記決策指南。

藉由套用 Kubernetes 標籤叢集內物件。如此一來，您就可以組織對象、選取物件的集合和報表清查。

需求 2.5

請確定管理廠商預設值和其他安全性參數的安全策略和操作程序記載、使用中，以及所有受影響的合作物件都知道。

您的責任

請務必維護有關程序與原則的徹底檔。人員應針對每個 Azure 資源的安全性功能和組態設定進行訓練。人員受監管的環境必須經過教育、通知和激勵，以支援安全性保證。對於授與廣泛系統管理許可權的系統管理員帳戶來說，這特別重要。

需求 2.6

共用主機提供者必須保護每個實體的託管環境和持卡人數據。

您的責任

Azure 可為任何共用的託管環境元件提供安全性保證。強烈建議您將 AKS 節點視為此工作負載的專用主機。也就是說，所有計算都應該位於單一租使用者模型中，而不是與您操作的其他工作負載共用。

如果 Azure 基礎結構層級需要完整的計算隔離，您可以將 Azure 專用主機新增至 Azure Kubernetes Service （AKS）叢集。此供應專案提供 專用於工作負載的實體 伺服器，可讓您將 AKS 節點直接放入這些布建的主機。此架構選擇具有顯著的成本和容量規劃影響，而且在大部分案例中並不常見。

下一步

保護儲存的持卡人數據。加密跨開放公用網路傳輸持卡人數據的傳輸。

保護持卡人數據