適用於 PCI-DSS 3.2.1 的 AKS 受管制叢集架構 (第 2 部分，共 9 部分)

本文說明 Azure Kubernetes Service (AKS) 叢集的參考架構，該叢集執行符合支付卡產業資料安全標準 (PCI-DSS 3.2.1) 的工作負載。 此架構著重於基礎結構，而非 PCI-DSS 3.2.1 工作負載。

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

建議和範例擷取自隨附的參考實作：

GitHub：適用於受管制工作負載的 Azure Kubernetes 服務 (AKS) 基準叢集提供了受管制基礎結構的示範。 此實作內含一個微服務應用程式。 其用意在於協助您體驗基礎結構，並針對網路和安全性控制項進行說明。 應用程式不代表且並未實作實際的 PCI DSS 工作負載。

下載此架構的 Visio 檔案。

該網路架構是以中樞輪輻拓撲為基礎。 中樞虛擬網路包含用於控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及可供 SRE (站點可靠性工程師) 存取叢集的第三個網路。 共有兩個輪輻虛擬網路。 其中一個輪輻包含 AKS 叢集，該叢集是持卡人環境 (CDE) 的一個元件，並裝載了 PCI DSS 工作負載。 另一個輪輻會建立虛擬機器映像，讓受控 SRE 用於存取環境。

元件

這些是此架構中使用的主要元件。 如果您不熟悉這些服務，請參閱相關 Azure 服務，以取得產品文件的連結。

Azure 防火牆

防火牆執行個體會保護輸出網路流量。 如果沒有這一層安全性，流量可能會與惡意的第三方服務進行通訊，從而洩露敏感的公司資料。

Azure Bastion

基準架構為 Azure Bastion 提供了子網路，但並未佈建資源。 此架構會在子網路中新增 Azure Bastion，並提供對跳躍箱的安全存取權。

Azure Image Builder

分別佈建於不同的虛擬網路中，用來建立具有基底安全性和組態的 VM 映像。 它在此架構中經過自訂，可使用預先安裝的 Azure CLI、kubectl 和 Flux CLI 等管理工具，建立安全的節點映像。

適用於跳躍箱執行個體的 Azure 虛擬機器擴展集

輪輻網路為跳躍箱提供額外的計算資源。 此擴展集旨在做為受控存取點使用，以根據需要針對 AKS 叢集執行 kubectl 等工具。

已整合 Web 應用程式防火牆 (WAF) 的 Azure 應用程式閘道

Azure 應用程式閘道會在第 7 層進行負載平衡。 WAF 可保護傳入流量免於遭受常見的 Web 流量攻擊。 執行個體具有公用前端 IP 設定，其會接收使用者要求。

Azure Kubernetes Service (AKS)

裝載基礎結構，此為持卡人資料環境 (CDE) 的重要部分。 AKS 叢集會部署為私人叢集。 因此，Kubernetes API 伺服器不會在公用網際網路上公開，且傳至 API 伺服器的流量僅限於您的私人網路。

ACR 工作

提供自動化的容器映像建置和維護方法。

Azure Key Vault

用於儲存和管理叢集作業所需的秘密，例如憑證和加密金鑰。

叢集組態

與基準架構相比的一些重大變更包括：

節點集區分割

在此架構中，叢集有 2 個使用者節點集區，以及 1 個系統節點集區。 節點集區的計算選項仍與基準架構相同。 與基準架構不同的是，每個節點集區皆位於專用子網路中，以在計算層之間提供額外的網路隔離邊界。

在作業和連線能力方面，PCI-DSS 3.2.1 要求將 PCI 工作負載與其他工作負載隔離。

• 範圍內：PCI 工作負載及其所在環境，以及相關作業。

• 範圍外：可能共用服務，但需與範圍內元件隔離的其他工作負載。

關鍵策略是提供所需的分隔層級。 首選方法是將範圍內和範圍外元件分別部署於不同的叢集中。 使用多個叢集的缺點是會增加基礎結構和維護負擔，因而導致成本變高。 為了簡單起見，此實作將所有元件共置於同一個共用叢集中。 如果選擇遵循單一叢集模型，請使用嚴格的叢集內分割策略。 無論您選擇如何維持區隔，請注意，隨著解決方案不斷發展，有些範圍外元件可能會變成範圍內元件。

我們會在參考實作中將微服務應用程式部署至單一叢集，以示範共用叢集方法。 範圍內和範圍外工作負載會分別置於兩個獨立的使用者節點集區中。 應用程式有兩組服務：一組含有範圍內的 Pod，另一組則含有範圍外的 Pod。 這兩組服務會分散於兩個使用者節點集區中。 藉由使用 Kubernetes 污點，範圍內和範圍外的 Pod 會部署至不同的節點，且永遠不會共用節點 VM 或網路 IP 空間。

輸入控制器

基準架構原本是使用 Traefik 進行輸入控制。 在此參考架構中，我們改用 Nginx。 這項調整代表您可以根據工作負載需求變更此元件。

私人 Kubernetes API 伺服器

基準架構已將 AKS 叢集部署為公用模式。 這代表與 AKS 管理的 Kubernetes API 伺服器之間的所有通訊皆會透過公用網際網路進行。 這在此架構中是不可接受的情況，因為 PCI-DSS 3.2.1 禁止公開暴露任何系統元件。 在此受管制架構中，叢集會部署為私人叢集。 傳入 Kubernetes API 伺服器的網路流量僅限於私人網路。 API 伺服器會透過叢集網路中的私人端點公開。 使用網路安全性群組和其他內建功能，可進一步加強安全性。 如需相關說明，請參閱網路組態。

Pod 安全性

請使用容器的相關 securityContext 設定來描述工作負載的安全性需求。 這包括 fsGroup、runAsUser / runAsGroup 等基本設定，以及將 allowPrivilegeEscalation 設為 false (除非確實有必要)。 在 seLinuxOptions 中明確定義和移除 Linux 功能，並定義 SELinux 選項。

避免在部署資訊清單中根據標籤參照映像。 請改用實際的映像識別碼。 這樣就能可靠地將容器掃描結果對應至叢集中執行的實際內容。 您可以透過適用於映像名稱的 Azure 原則強制執行此做法，藉此將映像識別碼模式納入允許的規則運算式中。 使用 Dockerfile FROM 指示時，也請遵循此指引。

網路設定

所有中樞輪輻皆分別部署於不同的虛擬網路中，每個網路都有自己的私人位址空間。 根據預設，任何兩個虛擬網路之間不允許有任何流量。 在網路內建立子網路，以套用分割。

搭配使用各種 Azure 服務和功能加上 Kubernetes 原生建構，即可提供所需的控制層級。 以下是此架構中使用的一些選項。

透過網路安全性群組 (NSG) 實作的子網路安全性

有多個 NSG 用於控制進出叢集的流量。 以下列出一些範例：

• 叢集節點集區會放置在專用子網路中。 每個子網路都有一些 NSG，用於封鎖對節點 VM 的任何 SSH 存取，並允許來自虛擬網路的流量。 來自節點集區的流量僅限於虛擬網路。

• 來自網際網路的所有輸入流量，都會遭到 Azure 應用程式閘道攔截。 例如，NSG 規則確保了：

  • 僅允許 HTTPS 流量進入。
  • 使用服務標籤允許來自 Azure 控制平面的流量。 如需詳細資訊，請參閱允許存取一些來源 IP。

• 在含有 Azure Container Registry 代理程式的子網路上，NSG 僅允許必要的輸出流量。 例如，允許流量流向 Azure Key Vault、Microsoft Entra ID、Azure 監視器，以及需要與容器登錄通訊的其他服務。

• 含有跳躍箱的子網路用於執行管理作業。 跳躍箱子網路上的 NSG 規則僅允許從中樞內部的 Azure Bastion 進行 SSH 存取，並會限制輸出連線。 跳躍箱沒有通用網際網路存取權，並同時受到子網路 NSG 和 Azure 防火牆控制。

請在部署工作負載、系統安全性代理程式以及其他元件時新增更多 NSG 規則，以協助定義應允許的流量類型。 流量不應跨越這些子網路邊界。 每個節點集區都位於自己的子網路中，因此請觀察流量模式，然後套用更明確的規則。

透過網路原則實現 Pod 到 Pod 安全性

此架構會嘗試盡可能實作 Microsoft 的「零信任」原則。

如需零信任網路概念的範例，請參閱 a0005-i和 a0005-o 使用者提供的命名空間中的實作示範。 每個工作負載命名空間皆應套用嚴格的 NetworkPolicy。 原則定義取決於在這些命名空間中執行的 Pod。 請確認您負責整備度、活躍度和開機探查，並允許 Log Analytics 代理程式收集的計量。 請考慮將所有工作負載的連接埠標準化，以便為允許的容器連接埠提供一致的 NetworkPolicy 和 Azure 原則。

在某些情況下，這種做法不適用於叢集內部的通訊。 並非所有使用者提供的命名空間都能使用零信任網路 (例如 cluster-baseline-settings 就無法使用)。

TLS 加密

基準架構提供 TLS 加密流量，直到至叢集內的輸入控制器為止，但 Pod 到 Pod 的通訊則不會加密。 在此架構中，TLS 會透過憑證授權 (CA) 驗證延伸至 Pod 到 Pod 的流量。 該 TLS 由服務網格提供，該服務網格會在允許通訊之前強制執行 mTLS 連線和驗證。

此實作使用 mTLS。 mTLS 支援可透過服務網格實作，但也可以不透過服務網格。 如果使用網格，請確保它與您選擇的憑證簽發者相容。 此實作使用 Open Service Mesh。

當輸入資源不包含特定憑證時，此實作中的輸入控制器會使用萬用字元憑證來處理預設流量。 這或許屬於可接受的情況，但如果您的組織原則不允許使用萬用字元憑證，您可能需要將輸入控制器調整為不使用萬用字元憑證。

Azure Key Vault 網路限制

所有秘密、金鑰和憑證都會儲存在 Azure Key Vault 中。 Key Vault 會處理憑證管理工作 (例如輪替)。 與 Key Vault 的通訊會透過 Azure Private Link 進行。 與 Key Vault 關聯的 DNS 記錄會存放在私人 DNS 區域中，因此無法透過網際網路解析。 這種做法可以增強安全性，但也會產生一些限制。

Azure 應用程式閘道不支援從經由 Private Link 公開的 Key Vault 執行個體，為 HTTP 接聽程式取得 TLS 憑證。 因此，該實作使用混合式模型部署 Key Vault。 雖然仍使用 Private Link 進行支援的連線，但也允許公用存取以整合應用程式閘道。 如果此混合式方法不適合您的部署，請將憑證管理流程移至應用程式閘道上進行。 這會增加管理負擔，但將能完全隔離 Key Vault 執行個體。 如需詳細資訊，請參閱：

• Azure 應用程式閘道與 Key Vault 整合
• 使用 Azure CLI 建立包含 TLS 終止的應用程式閘道。

DDoS 保護

如果您有任何具有公用 IP 位址的虛擬網路，請啟用 Azure DDoS 網路保護。 在此參考架構中，包含應用程式閘道的子網路已連結至公用 IP 位址，因此位於 DDoS 的保護範圍內。

Azure DDoS 網路保護可保護基礎結構和工作負載免於受到大量詐騙要求的影響。 此類要求可能導致服務中斷，或掩蓋其他並行攻擊。 Azure DDoS 網路保護的成本很高，通常會由跨越多個 IP 位址的多個工作負載分攤。 與您的網路團隊合作，協調您的工作負載涵蓋範圍。

身分識別與存取權管理

定義角色，並根據角色需求設定存取控制項。 將角色對應至 Kubernetes 作業，並盡可能縮小範圍。 避免建立兼具多項職能的角色。 如果多個角色皆由同一人擔任，請為該人員指派對應至這些職能的所有相關角色。 因此，即使叢集和工作負載皆由同一人直接負責，仍可比照有兩名個別人員的情況建立 Kubernetes ClusterRole。 接著，再為該名人員指派所有相關角色。

盡可能減少常設存取權，特別是具有高影響力的帳戶，例如與叢集互動的 SRE/Ops。 AKS 控制平面同時支援 Microsoft Entra ID Privileged Access Management (PAM) 即時 (JIT) 和條件式存取原則，可根據您建立的規則，為特殊權限存取提供額外的必要驗證查驗層。

如需有關使用 PowerShell 設定條件式存取的更多詳細資料，請參閱 New-MgIdentityConditionalAccessPolicy、Get-MgIdentityConditionalAccessPolicy 和 Remove-MgIdentityConditionalAccessPolicy。

磁碟加密

為待用資料設計加密功能時，請考慮儲存體磁碟、AKS 代理程式節點 VM、其他 VM 以及任何臨時和作業系統磁碟。

儲存體磁碟

預設情況下，Azure 儲存體磁碟會使用 Microsoft 管理的金鑰進行待用加密。 如果您使用非暫時作業系統磁碟或新增了資料磁碟，建議使用客戶自控金鑰來控制加密金鑰。 在儲存層外進行加密，且僅將加密後的資料寫入儲存媒體。 此外，請確保金鑰永遠不會與儲存層相鄰。 如需詳細資訊，請參閱適用於 Azure 磁碟的自攜式金鑰 (BYOK)。

請考慮為可能與叢集互動的任何其他磁碟使用 BYOK，例如 Azure Bastion 前端的跳躍箱。 如果您選擇使用 BYOK，則 VM 的 SKU 選擇和區域可用性將會受到限制，因為並非所有 SKU 或區域都支援此功能。

VM 主機

建議啟用主機上的加密功能。 如此將會加密 VM 主機和任何臨時作業系統，或在 VM 主機上快取的資料磁碟。 進一步了解適用於主機型加密的 VM 支援。

該功能會透過主機型加密功能，延伸至儲存在 AKS 代理程式節點的 VM 主機上的資料。 與 BYOK 類似，此功能可能會限制您的 VM SKU 和區域選項。

您可以透過 Azure 原則強制執行這些功能。

叢集備份 (狀態和資源)

如果您的工作負載需要叢集內儲存體，請建立強大且安全的備份和復原流程。 請考慮使用 Azure 備份 (適用於 Azure 磁碟和 Azure 檔案) 等服務來備份和復原任何 PersistentVolumeClaim。 支援 Kubernetes 原生資源的備份系統會提供一些優勢。 您可以使用備份系統來補充將叢集調整至眾所周知狀態的主要方法，以實現重要的系統復原技術。 例如，它可以在 Kubernetes 資源層級上協助進行漂移偵測，並編目系統狀態隨時間的變化。

備份流程需要對備份中的資料進行分類，無論該資料來自叢集還是叢集外部。 如果資料位於 PCI DSS 3.2.1 範圍內，請擴展合規性邊界，以納入備份的生命週期和目的地 (備份將會位於叢集外部)。 備份可能會成為攻擊媒介。 設計備份時，請考慮地理限制、待用加密、存取控制、角色和責任、稽核、存留時間和防篡改功能。

叢集內備份系統應於作業期間以高級權限執行。 評估將備份代理程式導入叢集的風險和效益。 代理程式功能是否與叢集中的其他管理解決方案有所重疊？ 在不擴大受攻擊面的情況下，完成此任務所需的最小工具組為何？

Azure 原則考量因素

已套用的 Azure 原則通常沒有可根據工作負載微調的設定。 我們在實作中套用了適用於 Linux 型工作負載的 Kubernetes 叢集 Pod 安全性受限標準倡議，這是其中一項內建原則倡議。 此倡議不允許微調設定。 請考慮匯出此倡議，並根據特定工作負載自訂設定值。 您可以將所有 Gatekeeper deny Azure 原則納入同一個自訂倡議，並將所有 audit Azure 原則納入另一個倡議。 如此便能完成封鎖操作與純資訊原則的分類。

請考慮將 kube-system 和 gatekeeper-system 命名空間納入稽核原則，以提高可見度。 將這些命名空間納入拒絕原則，可能會因組態不受支援而導致叢集失敗。

您可以設定一些 Azure 原則警示，以強制執行資料加密。 例如，您可以設定一項用來強制執行 BYOK 的警示，以偵測叢集資源上沒有 diskEncryptionSetID 的叢集。 另一項原則可以偵測主機型加密是否已於 agentPoolProfiles 上啟用。 參考實作並未使用叢集中的任何磁碟，且作業系統磁碟是暫時性磁碟。 這兩個範例原則皆是為了做為安全性功能的提醒而設置。 原則會設定為 audit，而非 block。

管理映像

為您的工作負載使用無散發的基底映像。 這些映像的安全性介面區已最小化，因為補充映像 (例如殼層和套件管理員) 已遭移除。 其中一項好處是能夠降低 CVE 命中率。

Azure Container Registry 支援符合 Open Container Initiative (OCI) 映像格式規格的映像。 搭配使用支援驗證簽章的許可控制器，即可確保只執行使用私密金鑰簽署的映像。 您可以使用 SSE Consisseur 或 IBM Portieris 等開放原始碼解決方案整合這些流程。

保護容器映像以及其他 OCI 成品，因為它們包含組織的智慧財產。 使用客戶自控金鑰，並加密登錄內容。 根據預設，資料會使用服務管理的金鑰進行待用加密，但有時需要有客戶自控金鑰才能符合法規合規性標準。 將金鑰存放在受控金鑰存放區中，例如 Azure Key Vault。 因為金鑰是由您建立並持有，因此您必須負責與金鑰生命週期相關的作業，包括輪替和管理。 如需更多資訊，請參閱使用客戶自控金鑰加密登錄。

Kubernetes API Server 作業存取權

除了建立基於跳躍箱的作業流程，您還可以透過其他方法限制針對叢集執行的命令。 如果您有設有 IAM 閘門的 IT 自動化平台，請使用預先定義的操作來控制並稽核各類操作。

組建代理程式

管線代理程式不應位於受管制叢集的範圍內，因為建置流程可能成為威脅媒介。 例如，建置流程常會使用未經測試且不受信任的元件。

雖然常會使用 Kubernetes 做為彈性組建代理程式基礎結構，但請勿在受管制工作負載執行階段的邊界內執行該流程。 組建代理程式不應直接存取叢集。 例如，請僅授予組建代理程式對 Azure Container Registry 的網路存取權，用於推送容器映像、Helm 圖表等。 接著，請透過 GitOps 進行部署。 常見的做法是，組建和發行工作流程不應直接存取 Kubernetes 叢集 API (或其節點)。

監視作業

叢集內活動

在 kube-system 中執行的叢集內 omsagent Pod 是 Log Analytics 收集代理程式。 這些代理程式會收集遙測資料、抓取容器 stdout 和 stderr 記錄，並收集 Prometheus 計量。 您可透過更新 container-azm-ms-agentconfig.yaml ConfigMap 檔案，調整其收集設定。 在此參考實作中，記錄會在 kube-system 和您的所有工作負載中啟用。 預設情況下，kube-system 會從記錄中排除。 請務必調整記錄收集流程，以實現成本目標、審查記錄時的 SRE 效率以及合規性需求之間的平衡。

安全性監視

使用 適用於雲端的 Microsoft Defender 中的適用於容器的 Defender 查看安全性建議並進行補救，同時查看有關容器資源的安全性警示。 啟用 Microsoft Defender 方案，因為它們適用於持卡人資料環境的各個元件。

整合記錄，以便有效率地查看、分析和查詢資料。 Azure 提供多種選項。 您可以開啟 AKS 診斷記錄，並將其傳送至 Azure 監視器中的 Log Analytics 工作區。 另一個選項是將資料整合至安全性資訊和事件管理 (SIEM) 解決方案中，例如 Microsoft Sentinel。

根據標準要求，所有 Log Analytics 工作區皆設有 90 天的保留期間。 請考慮為長期儲存體設定連續匯出。 請勿在記錄資料中儲存敏感性資訊，並確保對封存記錄資料的存取受到與最新記錄資料相同等級的存取控制。

如需完整觀點，請參閱適用於雲端的 Microsoft Defender Enterprise 上線指南。 此指南說明的主題包括註冊、將資料匯出至 SIEM 解決方案、回應警示，以及建立自動化的工作流程。

Azure 相關服務

以下是此架構中一些關鍵元件的功能說明文件連結。

• Azure Kubernetes Service (AKS)
• Azure 防火牆
• Azure Bastion
• Azure Image Builder
• Azure 虛擬機器擴展集
• 已整合 Web 應用程式防火牆 (WAF) 的 Azure 應用程式閘道
• Azure Container Registry 工作
• Azure Key Vault

下一步

安裝及維護防火牆設定，以保護持卡人資料。 請勿使用廠商提供的預設系統密碼和其他安全性參數。