偵測適用於 PCI-DSS 3.2.1 的 AKS 受管制叢集弱點 (第 5 部分，共 9 部分)

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

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

與任何雲端解決方案一樣，PCI 工作負載也會面臨網路、身分識別和資料威脅。 常見的例子顯示，工作負載和系統的弱點常被病毒或產生不良結果的軟體更新所利用。 儘早發現威脅，並及時採取緩解措施。 為工作負載活動建立重大警示，並將這些警示延伸至核心系統流程。 務必隨時執行防毒軟體或檔案完整性監視 (FIM) 工具。 制定負責任的回應計畫，並成立負責調查警示、並採取回應行動的團隊。

維護弱點管理計畫

需求 5 - 保護所有系統免受惡意軟體侵害，並定期更新防毒軟體或程式

AKS 功能支援

AKS 的行為有別於傳統的應用程式主機。 AKS 叢集中的節點 VM 公開程度有限，並設計為無法直接存取。 由於節點 VM 有別於傳統 VM，因此無法使用常見的 VM 工具。 因此，本節中的建議需透過 Kubernetes 原生建構套用。 直接在 VM 層級套用這些要求，可能會導致您的叢集不受支援。

您必須在 DaemonSets 中部署想要的反惡意程式碼軟體，該軟體將於每個節點上的 Pod 中執行。

您的責任

確保該軟體專為 Kubernetes 和容器設計。 有幾款第三方軟體可供選擇。 常見的選擇包括 Prisma Cloud 和 Aquasec。 另外還有 Falco 等開放原始碼選項。 您有責任建立流程，確保第三方軟體維持在最新狀態。 此外，解決方案的監視和警示功能也是您的責任。

需求 6 — 開發和維護安全的系統和應用程式

AKS 功能支援

與其他 Azure 服務十分類似，AKS 遵循 Microsoft SDL (Security Development Lifecycle，安全性開發生命週期) 流程，以確保開發流程中各個階段的安全性。 此流程從開發初期階段就會開始掃描各種元件，以儘早解決安全性弱點。

AKS 映像遵循 FedRAMP SLA 方法，該方法要求在 30 天內修補映像中的弱點。 為了強制執行此要求，系統會透過 DevSecOps 管線清理所有映像。

AKS 每週都會為節點集區提供新的映像。 您必須負責套用這些映像，以確保修補和更新虛擬機器擴展集的背景工作角色節點。 如需詳細資訊，請參閱 Azure Kubernetes Service (AKS) 節點映像升級。

AKS 會為 AKS 控制平面安裝或升級安全性修補程式。 這些修補程式每 24 小時更新一次。

AKS 控制平面和背景工作角色節點會使用網際網路安全性中心 (CIS) 基準 (特別是 AKS CIS、Ubuntu CIS 和 Windows CIS) 加以強化。

AKS 會與 Azure Container Registry 整合。 搭配使用 Azure Container Registry 以及適用於雲端的 Microsoft Defender 中的連續掃描功能，以識別各種風險等級的易受攻擊映像和應用程式。 如需有關映像掃描和風險控制的資訊，請參閱適用於容器的 Microsoft Defender。

您的責任

需求 5.1

在所有經常受到惡意軟體影響的系統 (特別是個人電腦和伺服器) 上部署防毒軟體。

您的責任

您有責任選用合適的反惡意程式碼軟體，以保護工作負載、基礎結構和部署管線。

由於對 AKS 節點 VM 的存取受到限制，因此請在可於節點 VM 植入惡意軟體的所有層級實施系統保護。 在叢集節點、容器映像以及與 Kubernetes API 伺服器的執行階段互動中加入偵測和預防措施。 除了叢集之外，還要保護下列與叢集互動、並能以傳統方式安裝防毒軟體的元件：

• 跳躍箱
• 組建代理程式

配合安全性開發生命週期 (SDL) 執行掃描活動。 遵循 SDL 可確保從開發初期階段就開始掃描架構的各種元件，以儘早解決安全性弱點。

需求 5.1.1

確保防毒程式能夠偵測、移除及保護所有已知類型的惡意軟體。

您的責任

了解每種軟體產品的功能組合，以及可執行的掃描深度。 軟體應封鎖常見的威脅，並監視新的威脅。 務必定期更新及測試軟體，如發現不適用則應予以替換。 請考慮使用信譽良好的廠商所開發的軟體。

• 用於偵測叢集弱點的監視工具。

  在 AKS 中，您無法直接在節點 VM 上執行傳統的代理程式型 VM 解決方案。 您必須在 DaemonSets 中部署反惡意程式碼軟體，該軟體將於每個節點上的 Pod 中執行。

  選擇為 Kubernetes 和容器化工作負載特製化的軟體。 有幾款第三方軟體可供選擇。 常見的選擇包括 Prisma Cloud 和 Aquasec。 另外還有 Falco 等開放原始碼選項。

  部署後，它們會以代理程式的形式在叢集中執行，以掃描所有使用者和系統節點集區。 儘管 AKS 會使用系統節點集區來處理其執行階段系統的二進位碼，但底層計算仍是您的責任。

  執行代理程式的目的是偵測異常的叢集活動。 例如，是否有應用程式嘗試呼叫 API 伺服器？ 有些解決方案會產生 Pod 之間的 API 呼叫記錄、報表以及警示。 請務必檢閱這些記錄，並採取必要的行動。

  啟動叢集之後，請立即安裝安全性代理程式，以盡可能縮短叢集與 AKS 資源部署之間未受監視的間隙時間。

  安全性代理程式會以高級權限運作，並會掃描叢集上執行的所有內容，而不僅僅是工作負載。 安全性代理程式不得成為資料外洩的來源。 此外，供應鏈攻擊對於容器來說也很常見。 使用深度防禦策略，並確保軟體和所有相依項皆受到信任。

  此外，也請在參與叢集作業的外部資產上執行防毒軟體。 其中一些例子包括跳躍箱、組建代理程式，以及與叢集互動的容器映像。

  代理程式在執行掃描時，不應因鎖定檔案等原因，而封鎖或干擾叢集的重要作業。 組態錯誤可能會引發穩定性問題，並導致您的叢集不受支援。

  重要

  參考實作提供了一個預留位置 DaemonSet 部署，用於執行反惡意程式碼軟體代理程式。 代理程式將在叢集中的每個節點 VM 上執行。 將您選擇的反惡意程式碼軟體置於此部署中。

• 維護容器的安全性。 在管線中執行容器掃描工具，例如適用於容器的 Microsoft Defender 中的 CI/CD 弱點掃描，以偵測可能透過容器映像傳入的威脅。 第三方選擇包括 Trivy 和 Clair。 建立映像時，請盡可能實作無發行版本 (Distroless) 映像。 這種映像僅包含基本 Linux 映像中的基本二進位碼，並減少了攻擊的介面區。 使用持續掃描解決方案，例如適用於容器的 Microsoft Defender 中的弱點評估，對存放庫中已設為待用的映像進行持續掃描。

需求 5.1.2

即使是不常成為惡意軟體攻擊目標或受惡意軟體影響的系統，仍請定期執行評估，以識別和評估不斷演變的惡意軟體威脅，進而確認這些系統是否仍然不需要防毒軟體。

您的責任

叢集外部的元件可能會受到常見弱點影響。 從 Azure 平台監看 CVE 和其他安全性警示，以追蹤安全性弱點。 檢查 Azure 更新是否有可偵測弱點的新功能，並在 Azure 託管服務上執行防毒解決方案。

例如，Blob 儲存體應包含惡意軟體信譽檢測，以偵測可疑的上傳活動。 適用於儲存體的 Microsoft Defender 包含惡意軟體信譽檢測。 此外，也請考慮這類服務是否需要防毒解決方案。

需求 5.2

確保所有防毒機制均受到維護，如下所示：

• 保持最新狀態；
• 執行定期掃描
• 產生稽核記錄，並根據 PCI DSS 需求 10.7 保留這些記錄。

您的責任

• 務必使用最新版本的防毒軟體，以保護叢集免於遭受新的攻擊。 有兩種類型的更新需要列入考慮：
  • 防毒軟體必須跟上最新的功能更新。 其中一種方法是將更新加入平台更新排程。
  • 一旦有可用的安全性情報更新，就必須立即套用，以偵測和識別最新的威脅。 選擇自動更新。
• 確認弱點掃描是否依照排程執行。
• 保留掃描之後產生的任何記錄，這些記錄會指出狀況良好和狀況不良的元件。 建議的保留期限為一年，如需求 10.7 所示。
• 制定一個流程，用來分類和修復偵測到的問題。

如需有關如何套用適用於端點的 Microsoft Defender 防毒更新的資訊，請參閱 Microsoft Defender 防毒軟體安全性情報和產品更新。

需求 5.3

防毒功能應主動執行，且不得由使用者停用或變更。 除非是在限定時段內，由管理階層以個案方式授權

您的責任

您必須負責為安全性代理程式設定監視和警示功能。 除了工作負載，還必須為核心系統流程建立重大警示。 代理程式必須持續執行。 回應反惡意程式碼軟體發出的警示。

• 保留掃描活動的記錄。 確保掃描流程不會記錄從磁碟或記憶體中抓取的任何持卡人資料。
• 為可能導致合規性意外失效的活動設定警示。 避免在無意中關閉警示。
• 限制代理程式部署和所有其他重大安全性工具的修改權限。 將這些權限與工作負載部署權限分開。
• 如果安全性代理程式未如預期執行，請勿部署工作負載。

需求 5.4

確認用於保護系統免受惡意軟體侵害的安全性原則和作業程序留有記錄、正在使用，並已傳達給所有受影響方。

您的責任

請務必保留有關流程與原則的完整文件，特別是要為用於保護系統的防毒解決方案留下詳細記錄。 需要加入的資訊包括：安全情報更新是在產品週期中的哪個階段維護、掃描的頻率，以及即時掃描功能的相關資訊等。

制定有關記錄儲存的保留原則。 基於合規性目的，您可能會希望設置長期儲存體。

維護標準作業程序文件，用於評估和修復問題。 受管制環境的作業人員必須接受培訓、充分知情並受到獎勵，以確保安全性保證。 從原則觀點而言，這點對於參與核准流程的人員來說至關重要。

需求 6.1

建立流程以識別安全性弱點、使用信譽良好的外部來源取得安全性弱點資訊，並為新發現的安全性弱點指派風險排序 (例如高、中或低)。

您的責任

建立用來查核偵測到的弱點，並進行適當排序的流程。 適用於雲端的 Microsoft Defender 會根據資源類型、嚴重性和環境，顯示建議和警示。 大部分的警示都包含 MITRE ATT&CK® 策略，可幫助您了解狙殺鏈的意圖。 請務必訂定用於調查和減輕問題的補救計畫。

在 AKS 中，您可以搭配使用 Azure Container Registry 與持續掃描功能，以識別各種風險等級的易受攻擊映像和應用程式。 您可以在適用於雲端的 Microsoft Defender 中檢視結果。

如需詳細資訊，請參閱適用於雲端的 Defender 中的容器保護。

需求 6.2

安裝廠商提供的適用安全性修補程式，確保所有系統元件和軟體不會受到已知弱點的影響。 重大安全性修補程式必須在發布後一個月內完成安裝。

您的責任

• 為了防止來自第三方廠商的供應鏈攻擊，請確保所有相依項皆受到信任。 請務必選擇信譽良好且受到信任的廠商。

• AKS 每週都會為節點集區提供新的映像。 這些映像不會自動套用。 一旦可供使用，請立即套用。 您可以手動更新，也可以透過「節點映像更新」自動更新。 如需詳細資訊，請參閱 Azure Kubernetes Service (AKS) 節點映像升級

  AKS 會為 AKS 控制平面安裝或升級安全性修補程式。

• AKS 節點每 24 小時會自動下載並安裝個別的作業系統和安全性修補程式。 如果想要接收這些更新，請確保您的防火牆並未封鎖這些流量。

  請考慮啟用安全性代理程式的報告功能，以取得有關已套用更新的資訊。 有些安全性更新需要重新開機。 請務必檢閱警示，並採取對應行動，以確保在重新開機時盡可能縮短應用程式的停機時間，甚至完全避免停機。 Kured (Kubernetes 重新開機精靈) 是一個以受控方式執行重新開機的開放原始碼選項。

• 將修補流程延伸至已佈建的叢集以外的資源，例如跳躍箱和組建代理程式。

• 隨時將 AKS 更新為支援的最新版本。 如果您的設計所使用的版本生命週期已終止，請升級至最新的版本。 如需詳細資訊，請參閱支援的 AKS 版本。

需求 6.3

以安全的方式開發內部和外部軟體應用程式 (包括應用程式的 Web 型管理存取權)，如下所示：

• 依照 PCI DSS (例如，安全驗證及記錄)
• 以產業標準和/或最佳做法為基礎。
• 在整個軟體開發生命週期中納入資訊安全性，這適用於所有內部開發的軟體，包括第三方開發的定制或自訂軟體。

您的責任

將安全性選項納入工作負載生命週期和作業中，並排定優先順序。

有數個產業架構對應至此生命週期，例如 NIST 架構。 NIST 功能 (識別、保護、偵測、回應和復原) 提供了每個階段的預防控制策略。

Microsoft SDL (安全性開發生命週期) 則提供了整個開發流程中各個階段的安全性最佳做法、工具和流程。 所有 Azure 服務 (包括 AKS) 皆遵循 Microsoft SDL 做法。 此外，我們也遵循適用於雲端服務作業的營運安全性保證 (OSA) 架構。 請確保您有類似的流程。 我們已發布這些做法，以協助您保護應用程式。

• Microsoft SDL
• Microsoft OSA

需求 6.3.1

在啟動應用程式或將其發佈給客戶之前，請先移除開發、測試和/或自訂應用程式帳戶、使用者識別碼及密碼。

您的責任

建立叢集時，預設會建立多個本機 Kubernetes 使用者。 這些使用者無法稽核，因為他們並非唯一的身分識別。 其中有些使用者擁有很高的權限。 使用 AKS 的停用本機帳戶功能停用這些使用者。

有關其他考量事項，請參閱官方 PCI-DSS 3.2.1 標準中的指引。

需求 6.3.2

將自訂程式碼發行至生產環境或客戶之前，請先進行下列檢查 (使用手動或自動流程)，以識別任何潛在的編碼弱點：

• 由原始程式碼作者以外的人員，以及熟悉程式碼檢閱技術和安全編碼實務的人員檢閱程式碼變更。
• 程式碼審查可確保程式碼是根據安全程式碼撰寫方針開發而成
• 在發行前進行適當的修正。
• 程式碼檢閱結果應由管理階層在發布前審查並核准。

您的責任

安裝於叢集內的所有軟體皆源自您的容器登錄。 與應用程式碼類似，請設立負責仔細檢查 Azure 和第三方映像 (Dockerfile 和 OCI) 的流程和團隊。 此外：

• 從建立叢集的初期階段，就開始掃描容器映像。 讓掃描流程成為持續整合/持續部署管線的一部分。

  確保您的部署管線設有閘門，讓叢集啟動載入映像和您的工作負載都必須通過審查和/或隔離閘門。 記錄流程在被提取進叢集之前的使用歷程，以及曾使用哪些流程。

• 減少映像大小。 映像包含的二進位碼通常多於實際需求。 減少映像大小不僅有效能上的好處，還可以限制受攻擊面。 例如，使用無發行版本 (Distroless) 映像可以將基底 Linux 映像的受攻擊面減至最小。

• 使用靜態分析工具，驗證 Dockerfile 和資訊清單的完整性。 第三方選項包括 Dockle 和 Trivy。

• 僅使用已簽署的映像。

• 了解 (並接受) Azure 提供的基底映像，以及它如何符合 CIS 基準。 如需詳細資訊，請參閱網際網路安全中心 (CIS) 基準。

搭配使用 Azure Container Registry 以及適用於雲端的 Microsoft Defender 中的持續掃描功能，將有助於識別易受攻擊的映像，以及這些映像可能對工作負載造成的各種風險。 如需更多有關映像掃描和風險控制的資訊，請參閱容器安全性。

需求 6.4

遵循變更控制流程與程序，進行系統元件的所有變更。

您的責任

務必記錄變更控制流程，並根據這些流程設計部署管線。 加入其他流程，用來偵測流程與實際管線不一致的情況。

需求 6.4.1、6.4.2

• 將開發/測試環境與生產環境分開，並使用存取控制項強制分隔。
• 在開發/測試與生產環境之間區分職責。

您的責任

分別維護生產環境和生產前環境，以及在這些環境中運作的角色。

• 請勿將生產叢集用於開發/測試目的。 例如，請勿在生產叢集中安裝 Bridge to Kubernetes。 非生產工作負載必須使用專用的叢集。

• 確保您的生產環境不允許對生產前環境進行網路存取，反之亦然。

• 請勿跨生產前環境和生產環境使用相同的系統身分識別。

  叢集系統管理員、管線主體等群組應使用 Microsoft Entra 群組。 請勿使用通用或一般群組做為存取控制項。 請勿跨生產前叢集和生產叢集重複使用這些群組。 其中一種做法是，在群組名稱中使用叢集名稱 (或其他不透明的識別碼)，以明確顯示成員資格。

  在不同的環境中，使用合適的 Azure 角色型存取控制 (RBAC) 角色。 通常，在生產前環境中會指派更多角色和權限。

  僅在生產前環境中運作的身分識別 (授予管線或軟體工程團隊)，不應授予生產環境的存取權。 相反地，僅在生產環境中運作的身分識別 (例如管線)，亦不應授予生產前叢集的存取權。

  請勿為生產前環境和生產環境中的任何資源，使用相同的使用者指派受控識別。 此建議適用於支援使用者指派受控識別的所有資源，而不只是部署於叢集中的資源。 一般來說，需要身分識別的 Azure 資源應擁有自己獨立的身分識別，而非與其他資源共用。

• 使用即時 (JIT) 存取進行高級權限存取，包括在生產前叢集上 (如果可行的話)。 在生產前和生產叢集上，皆請使用條件式存取原則。

需求 6.4.3

請勿將生產資料 (即時 PAN) 用於測試或開發。

您的責任

確保 CHD 資料不會流入開發/測試環境。 製作清楚的文件，用來說明將資料從生產環境移轉至開發/測試環境的程序。 此程序必須通過責任方的核准，且當中必須包含移除真實資料的步驟。

需求 6.4.4

在系統正式啟用/進入生產環境之前，請先從系統元件移除測試資料及帳戶。

您的責任

將系統部署至生產環境之前，請先移除系統中的預設組態資料、範例資料和已知的測試資料。 請勿將持卡人資料用於測試目的。

需求 6.4.5

用來實作安全性修補程式和軟體修改的變更控制程序需包括以下步驟：

• 6.4.5.1 記錄影響。
• 6.4.5.2 經獲授權方核准的變更記錄。
• 6.4.5.3 功能測試，用於確認變更不會對系統安全性產生負面影響。
• 6.4.5.4 退出程序。

您的責任

下列指導要點對應至上述需求：

• 記錄安全性修補程式和軟體修改預期引發的基礎結構變更。 使用基礎結構即程式碼 (IaC) 方法，將有助於簡化此流程。 例如，您可以透過 Bicep 檔案或 Azure Resource Manager 範本 (ARM 範本)，使用假設狀況作業來預覽部署的變更。 如 有關基礎結構變更的更多資訊，請參閱 Bicep 部署假設狀況作業。

• 在部署管線中實作閘門，以驗證一般部署的變更核准。 記錄可能繞過閘門之緊急部署的理由。

  定義變更的層級和深度。 確保團隊就重大變更 (而非次要變更) 的定義達成共識。 如果可行，請將其中一些變更的探索程序設為自動執行。 工作負載、基礎結構和管線的檢閱者必須清楚了解這些層級，並根據對應準則進行驗證。

• 測試安全性能供性。 確保綜合交易測試涵蓋安全性 (允許和拒絕) 考量事項。 此外，請確保這些綜合測試是在生產前環境中執行。

• 制定退出流程，以因應安全性修正的非預期結果 常見策略是使用藍綠部署來進行部署，同時保留先前的狀態。 為工作負載 (包括資料庫) 制定適用於特定拓撲的策略，並將範圍限定在部署單位內。

需求 6.5

解決軟體開發流程中常見的編碼弱點，如下所示：

• 每年至少為開發人員舉辦一次最新安全編碼技術培訓活動，內容涵蓋如何避免常見的編碼弱點。
• 根據安全編碼指導方針開發應用程式。

您的責任

確保應用程式團隊和營運團隊接受培訓、充分知情並受到獎勵，以支援工作負載和基礎結構掃描活動。 以下是一些資源：

• 安全程式碼撰寫指導方針
• 安全 DevOps
• 安全開發生命週期資源

需求 6.6

針對公開的 Web 應用程式，請持續解決新的威脅和弱點。 務必使用下列任一方法，保護這些應用程式免於遭受已知的攻擊：

• 使用手動或自動化的應用程式弱點安全性評估工具或方法，審查對外公開的 Web 應用程式。 執行弱點評估 (每年至少一次，以及在每次變更之後)。

  注意

  此評估有別於需求 11.2 中的弱點掃描。

• 安裝用於偵測並防止網頁式攻擊的自動化解決方案。 例如：Web 應用程式防火牆。 將防火牆部署於公開 Web 應用程式前方，並主動評估所有流量。

您的責任

使用 Web 應用程式防火牆 (WAF)，設置檢查機制來偵測來自公用網際網路的流量。 在此架構中，Azure 應用程式閘道會使用其整合式 WAF 檢查所有連入流量。 WAF 是以 Open Web Application Security Project (OWASP) 的核心規則集 (CRS) 為基礎。 如果沒有可用的技術控制措施，請採用補償控制措施。 其中一種方法是手動檢查程式碼。

務必使用最新版本的規則集，並套用與您的工作負載相關的規則。 這些規則應以預防模式運行。 您可以新增一個 Azure 原則執行個體來強制執行該需求；此執行個體會檢查 WAF 是否已啟用，並以該模式執行。

保留應用程式閘道 WAF 產生的記錄，以取得已偵測到的威脅詳情。 根據需要微調規則。

針對應用程式碼進行滲透測試。 如此一來，應用程式團隊以外的實作人員就能透過收集資訊、分析弱點和製作報表，找出安全性缺口 (例如 SQL 插入式攻擊和目錄周遊)。 在此練習中，實作人員可能需要存取敏感資料。 為了避免存取意圖遭到濫用，請遵循滲透測試參與規則中的指引。

需求 6.7

確保用於開發和維護安全性系統和應用程式的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方所知悉。

您的責任

請務必保留有關流程與原則的完整文件。 您的團隊應接受相關訓練，以將安全性選項納入工作負載生命週期和作業中，並排定優先順序。

Microsoft SDL 提供涵蓋整個開發流程中各個階段的安全性最佳做法、工具和流程。 Microsoft 在建置軟體時，會嚴格遵循 Microsoft SDL 實務。 此外，我們也遵循適用於雲端服務作業的營運安全性保證 (OSA) 架構。 我們已發布這些做法，以協助您保護應用程式。

• Microsoft SDL
• Microsoft OSA

保留完整的滲透測試文件，用來描述測試範圍、分類流程，以及偵測到問題時的補救策略。 發生安全性事件時，請將需求 6 的評估事項納入根本原因分析中。 如果發現漏洞 (例如偵測到 OWASP 違規事項)，請修正這些漏洞。

文件中應有明確的指導方針，用來說明預期的 WAF 保護狀態。

受管制環境的作業人員需接受培訓、充分知情並受到獎勵，以確保安全性保證。 從原則觀點而言，這點對於參與核准流程的人員來說至關重要。

下一步

依業務知情需求，限制對持卡人資料的存取。 識別並驗證對系統元件的存取。 限制對持卡人資料的實體存取。