本文說明 Azure Kubernetes Service (AKS) 叢集的考量事項，該叢集執行符合支付卡產業資料安全標準 (PCI-DSS 3.2.1) 的工作負載。
本文是系列文章的一部分。 閱讀簡介。
本架構和實作著重於探討基礎結構，而非工作負載。 本文提供可協助您做出設計決策的一般考量因素和最佳做法。 請遵循官方 PCI-DSS 3.2.1 標準中的需求，並視情況使用本文做為輔助資訊。
重要
指引和隨附的實作建置於 AKS 基準架構上。 該架構是以中樞和輪輻拓撲為基礎。 中樞虛擬網路包含用來控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及用於維護的第三個網路。 輪輻虛擬網路包含用來提供持卡人資料環境 (CDE)，並裝載 PCI DSS 工作負載的 AKS 叢集。
GitHub：適用於受管制工作負載的 Azure Kubernetes 服務 (AKS) 基準叢集提供了受管制基礎結構的示範。 此實作內含一個微服務應用程式。 其用意在於協助您體驗基礎結構，並針對網路和安全性控制項進行說明。 應用程式不代表且並未實作實際的 PCI DSS 工作負載。
保護持卡人資料
需求 3 — 保護已儲存的持卡人資料
您的責任
| 需求 | 責任 |
|---|---|
| 需求 3.1 | 實作資料保留和處置原則、程序和流程，將持卡人資料儲存體保持在最低限度，其中所有持卡人資料 (CHD) 儲存體應至少採取以下措施： |
| 需求 3.2 | 即使已加密，也不要在授權之後儲存敏感性驗證資料。 如果收到敏感性驗證資料，請在授權流程完成時，將所有資料轉譯為無法復原的格式。 |
| 需求 3.3 | 顯示時遮罩 PAN (前六個數字和最後四個數字為顯示的最大位數)，讓只有具備合法商務需求的人員才能看到完整的 PAN。 |
| 需求 3.4 | 使用下列任何方法，將儲存在任何位置 (包括可攜式數位媒體、備份媒體和記錄) 的 PAN 轉譯為無法讀取的格式： |
| 需求 3.5 | 記錄並實作相關程序，以保護用來保護已儲存之持卡人資料的金鑰，以避免洩漏或誤用： |
| 需求 3.6 | 針對用於加密持卡人資料的密碼編譯金鑰，完整記錄並實作所有金鑰管理流程與程序，包括： |
| 需求 3.7 | 確保用於保護已儲存持卡人資料的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方所知悉。 |
需求 3.1
實作資料保留和處置原則、程序和流程，將持卡人資料儲存體保持在最低限度，其中所有持卡人資料 (CHD) 儲存體應至少採取以下措施：
- 限制資料儲存體數量和保留時間，以符合法律、法規和業務要求
- 當不再需要資料時，安全刪除資料的流程
- 針對持卡人資料的特定保留需求
- 識別及安全刪除超過定義保留期的已儲存持卡人資料的每季流程。
您的責任
請勿在 AKS 叢集中儲存狀態。 如果選擇儲存 CHD，請探索安全儲存體選項。 選項包括適用於檔案儲存體的 Azure 儲存體，或是 Azure SQL Database、Azure Cosmos DB 等資料庫。
嚴格遵守有關可以儲存何種 CHD 的標準指引。 根據您的業務需求和所使用的儲存體類型，定義資料保留原則。 一些重要的考量因素包括：
- 資料的儲存方式和位置為何？
- 儲存的資料是否經過加密？
- 保留期間是多久？
- 保留期間允許執行哪些操作？
- 如何在保留期間到期後刪除儲存的資料？
針對其中一些選項制定治理原則。 內建 Azure 原則會強制執行這些選項。 例如，您可以在叢集 Pod 上限制磁碟區類型，或拒絕對根檔案系統的寫入作業。
查看此原則定義清單，並將其套用到叢集 (如適用)。
您可能需要暫時快取資料。 建議您在將快取資料移至儲存體解決方案時，對其進行保護。 請考慮在 AKS 上啟用主機型加密功能。 這將會對儲存在節點 VM 上的資料進行加密。 如需詳細資訊，請參閱 Azure Kubernetes Service (AKS) 上主機型加密。 此外，請啟用要求對暫存磁碟和節點集區快取進行加密的內建 Azure 原則。
請在選擇儲存體技術時，探索相關的保留功能。 例如，Azure Blob 儲存體提供以時間為基礎的保留原則。 另一種選擇是實作自訂解決方案，以根據保留原則刪除資料。 一個例子是資料生命週期管理 (DLM)，可用來管理資料生命週期活動。 此解決方案使用 Azure Data Factory、Microsoft Entra ID 和 Azure Key Vault 等服務設計而成。
如需詳細資訊，請參閱使用 Azure Data Factory 管理資料生命週期。
需求 3.2
即使已加密，也不要在授權之後儲存敏感性驗證資料。 如果收到敏感性驗證資料，請在授權流程完成時，將所有資料轉譯為無法復原的格式。
您的責任
(適用於：需求 3.2.1、需求 3.2.2、需求 3.2.3)
處理和保護資料是工作負載問題，因此超出本架構的範圍。 以下是一些一般考量因素。
根據標準，敏感性驗證資料包括完整的追蹤資料、卡片驗證碼或值，以及 PIN 資料。 請確保驗證資料不會在 CHD 處理期間透過以下來源公開：
- Pod 發出的記錄。
- 例外狀況處理常式。
- 檔案名稱。
- 快取。
一般指引是，商家不應儲存此資訊。 如果需要儲存，請記錄業務理由。
需求 3.3
顯示時遮罩 PAN (前六個數字和最後四個數字為顯示的最大位數)，讓只有具備合法商務需求的人員才能看到完整的 PAN。
您的責任
主要帳戶號碼 (PAN) 視同於敏感性資料，必須防止暴露。 一種方法是透過遮罩來減少顯示的位數。
請勿在工作負載中實作資料遮罩。 請改用資料庫層級的建構。 Azure SQL 系列服務 (包括 Azure Synapse Analytics) 支援動態資料遮罩，有助於減少應用程式層上的暴露風險。 這是一種以原則為基礎的安全性功能，定義了哪些人可以查看未遮罩的資料，以及透過遮罩公開的資料量。 內建的信用卡遮罩方法會公開指定欄位的末四碼，並新增常數字串做為信用卡格式的前置詞。
如需相關資訊，請參閱動態資料遮罩。
如果您確實需要將未遮罩的資料導入叢集，請盡快遮罩。
需求 3.4
使用下列任何方法，將儲存在任何位置 (包括可攜式數位媒體、備份媒體和記錄) 的 PAN 轉譯為無法讀取的格式：
- 根據強式加密的單向雜湊，(雜湊必須是完整 PAN)
- 截斷 (不能使用雜湊取代 PAN 的截斷區段)
- 索引權杖和填補 (填補必須以安全方式儲存)
- 設有相關金鑰管理流程和程序的強式密碼編譯。
您的責任
為滿足此需求，您可能需要在工作負載中使用直接密碼編譯。 PCI DSS 指引建議使用經過業界測試的演算法，以抵禦實際的攻擊行為。 避免使用自訂加密演算法。
合適的資料遮罩技術也可以滿足此需求。 您必須負責遮罩所有主要帳戶號碼 (PAN) 資料。 Azure SQL 系列服務 (包括 Azure Synapse Analytics) 支援動態資料遮罩。 請參閱需求 3.3。
確保 PAN 不會在工作流程中公開。 以下是一些考量：
將 PAN 排除在記錄之外，包括工作流程記錄和 (預期或非預期的) 例外狀況處理記錄。 此外，診斷資料流量 (例如 HTTP 標頭) 亦不得公開此資料。
請勿使用 PAN 做為快取查閱金鑰，或讓 PAN 出現在此流程產生的任何檔案名稱中。
您的客戶可能會在缺少提示的情況下，在自由格式文字欄位中提供 PAN。 請務必為任何自由格式文字欄位實作內容驗證和偵測流程，以清除 PAN 資料與所有類似的內容。
需求 3.4.1
如果使用磁碟加密 (而非檔案或資料行層級資料庫加密)，則必須獨立於原生作業系統驗證和存取控制機制之外 (例如，不得使用本機使用者帳戶資料庫或一般網路登入認證)，單獨管理邏輯存取。 解密金鑰不得連結至使用者帳戶。
您的責任
根據一般規則，請勿在 AKS 叢集中儲存狀態。 使用支援儲存引擎層級加密的外部資料儲存體。
儲存在 Azure 儲存體中的所有資料皆會使用強式密碼編譯技術進行加密和解密。 Microsoft 負責管理相關聯的金鑰。 建議使用自控加密金鑰。 一律在儲存層外加密，且僅將加密資料寫入儲存媒體，確保金鑰永遠不會與儲存層相鄰。
Azure 儲存體也允許您使用自控金鑰。 如需詳細資料，請參閱為 Azure 儲存體加密的客戶自控金鑰。
資料庫也有提供類似的功能。 如需 Azure SQL 選項，請參閱搭配使用 Azure SQL 透明資料加密與客戶自控金鑰。
請務必將金鑰存放在受控金鑰存放區中，例如 Azure Key Vault、Azure 受控 HSM 或第三方金鑰管理解決方案。
如需暫時儲存資料，請啟用 AKS 的主機加密功能，以確保儲存在 VM 節點上的資料已加密。
需求 3.5
記錄並實作相關程序，以保護用來保護已儲存之持卡人資料的金鑰，以避免洩漏或誤用。
您的責任
如需這些要點的說明，請參閱以下小節：
- 針對密碼編譯金鑰採取最低權限存取做法。
- Azure Key Vault 和 Microsoft Entra ID 是為了支援授權和稽核記錄需求而設計。 如需詳細資訊，請參閱要求 Azure Key Vault 驗證。
- 使用儲存在密碼編譯裝置中的金鑰加密金鑰，保護所有資料加密金鑰。
- 如果您使用自控金鑰 (而非 Microsoft 管理的金鑰)，請制定用於維護金鑰管理相關作業的流程和文件。
需求 3.5.1
僅適用於服務提供者的附加需求：維護密碼編譯架構的書面說明，內容包括：
- 用於保護持卡人資料的所有演算法、通訊協定及金鑰的詳細資料，包括金鑰強度與到期日
- 每個金鑰的使用方式描述
- 用於金鑰管理的任何 HSM 及其他 SCD 之清查
您的責任
儲存敏感性資訊 (金鑰、連接字串等) 的其中一種方法是使用原生 Kubernetes Secret 資源。 您必須明確啟用待用加密。 或者也可以將它們儲存在受控存放區中，例如 Azure Key Vault。 在這兩種方法中，建議使用受控存放區服務。 其中一個優點是可以減少金鑰管理相關工作的負擔，例如金鑰輪替。
預設情況下，Azure 會為每個客戶的所有加密資料使用 Microsoft 管理的金鑰。 然而，某些服務也支援使用自控金鑰進行加密。 如果您使用自控金鑰進行待用加密，請務必考慮制定用於處理金鑰管理工作的流程和策略。
在文件中加入與金鑰管理相關的資訊，例如到期、位置和維護方案詳細資料。
需求 3.5.2
將密碼編譯金鑰的存取限制為所需最少的保管人數。
您的責任
盡可能減少擁有金鑰存取權的人數。 如果您使用任何群組型角色指派，請設定定期稽核流程，以審查擁有存取權的角色。 專案團隊成員發生變更時，必須將不再相關的帳戶從權限中移除。 只有合適的人員才能擁有存取權。 使用 Microsoft Entra ID 存取權檢閱，定期審查群組成員資格。
請考慮移除常設權限，以支援即時 (JIT) 角色指派、基於時間的角色啟用，以及基於核准的角色啟用。 例如，請考慮使用 Privileged Identity Management。
需求 3.5.3
一律使用下列其中一種 (或多種) 形式，儲存用於加密/解密持卡人資料的秘密和私密金鑰：
- 使用強度至少相當於資料加密金鑰的金鑰加密金鑰進行加密，並與資料加密金鑰分開儲存
- 儲存在安全的密碼編譯裝置中 (例如硬體 (主機) 安全性模組 (HSM) 或經 PTS 核准的互動點裝置)
- 使用業界認可的方法，儲存為至少兩個完整長度的金鑰元件或金鑰共用
您的責任
PCI-DSS 3.2.1 工作負載需要使用多個加密金鑰，以符合待用資料保護策略。 資料加密金鑰 (DEK) 用於加密和解密 CHD，但您必須負責使用額外的金鑰加密金鑰 (KEK) 來保護該 DEK。 您還必須負責確保 KEK 儲存在密碼編譯裝置中。
您可以使用 Azure Key Vault 來儲存 DEK，並使用 Azure 專用 HSM 來儲存 KEK。 如需有關 HSM 金鑰管理的資訊，請參閱什麼是 Azure 專用 HSM？。
需求 3.6
針對用於加密持卡人資料的密碼編譯金鑰，完整記錄並實作所有金鑰管理流程與程序，包括：
您的責任
(適用於：需求 3.6.1、需求 3.6.2、需求 3.6.3、需求 3.2.4)
如果您使用 Azure Key Vault 來儲存金鑰、憑證和連接字串等秘密，請保護其免於未經授權的存取。 適用於 Key Vault 的 Microsoft Defender 會偵測可疑的存取嘗試，並產生警示。 您可以在適用於雲端的 Microsoft Defender 中檢視這些警示。 如需詳細資訊，請參閱適用於 Key Vault 的 Microsoft Defender。
請遵循有關金鑰管理的 NIST 指引。 如需詳細資料，請參閱：
另請參閱適用於 Key Vault 的 Microsoft Defender。
需求 3.6.7
防止未經授權的密碼編譯金鑰替換。
您的責任
- 在所有金鑰存放區上啟用診斷。 使用適用於 Key Vault 的 Azure 監視器。 它會收集記錄和計量，並傳送至 Azure 監視器。 如需更多資訊，請參閱使用適用於 Key Vault 的 Azure 監視器監視金鑰保存庫服務。
- 授予唯讀權限給所有取用者。
- 請勿提供常設權限給管理使用者或主體。 請改用即時 (JIT) 角色指派、基於時間的角色啟用和基於核准的角色啟用。
- 將記錄和警示整合至安全資訊和事件管理 (SIEM) 解決方案中，例如 Microsoft Sentinel，以建立集中式檢視。
- 對警示和通知採取行動，特別是針對非預期的變更。
需求 3.6.8
要求密碼編譯金鑰保管人正式確認，他們了解並接受其身為金鑰保管人的責任。
您的責任
維護相關文件，用來說明負責金鑰管理作業之各方的責任。
需求 3.7
確保用於保護已儲存持卡人資料的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方所知悉。
您的責任
為所有角色建立文件，包括一般聲明以及一系列最新的角色指南。 執行新進員工培訓和持續培訓活動。
請務必保留有關流程與原則的完整文件。 多個團隊共同參與，確保資料在待用和傳輸期間皆受到保護。 在您的文件中，為所有角色提供角色指引。 這些角色應包括 SRE、客戶支援、銷售、網路作業、安全性作業、軟體工程師、資料庫管理員等。 相關人員應接受 NIST 指引和待用資料策略的培訓，以保持最新技能。 訓練需求載明於需求 6.5 和需求 12.6 中。
需求 4 — 為跨開放式公用網路的持卡人資料傳輸加密
您的責任
| 需求 | 責任 |
|---|---|
| 需求 4.1 | 使用強式密碼編譯和安全性通訊協定 (例如 TLS、IPSEC、SSH 等)，在透過開放式公用網路傳輸期間保護敏感的持卡人資料，包括下列各項： |
| 需求 4.2 | 一律不得透過終端使用者傳訊技術 (例如電子郵件、立即訊息、簡訊、聊天等) 傳送未受保護的 PAN。 |
| 需求 4.3 | 確認持卡人資料加密傳輸的安全性原則及作業程序留有記錄、正在使用，並為所有受影響方所知悉。 |
需求 4.1
使用強式密碼編譯和安全性通訊協定 (例如 TLS、IPSEC 以及 SSH 等)，在透過開放式公用網路傳輸期間保護敏感的持卡人資料，包括下列各項：
您的責任
透過公用網際網路傳輸的持卡人資料 (CHD) 必須加密。 所有資料傳輸皆須使用 TLS 1.2 (或更新版本) 加密，並減少支援的加密類型類型。 請勿為任何資料傳輸服務提供非 TLS 到 TLS 重新導向支援。
您的設計應包含 TLS 終止點策略鏈。 資料透過網路躍點傳輸時，請為需要執行封包檢查的躍點維護 TLS。 至少應在叢集的輸入資源上設置最終的 TLS 終止點。 請考慮將它進一步納入叢集資源。
使用 Azure 原則管理資源建立流程：
- 拒絕建立任何非 HTTPS 輸入資源。
- 拒絕在叢集中建立任何公用 IP 或公用負載平衡器，以確保 Web 流量透過閘道進行傳輸。
如需詳細資訊，請參閱 Azure 加密概觀。
需求 4.1.1
確保傳輸持卡人資料或連接至持卡人資料環境的無線網路使用業界最佳做法 (例如 IEEE 802.11i)，針對身分驗證和資料傳輸實作強式加密。
您的責任
此架構和實作並非設計用來透過無線連線，進行內部部署或公司網路至雲端的交易。 相關考量事項請參閱官方 PCI-DSS 3.2.1 標準中的指引。
需求 4.2
一律不得透過終端使用者傳訊技術 (例如電子郵件、立即訊息、簡訊、聊天等) 傳送未受保護的 PAN。
您的責任
如果您的工作負載需要傳送電子郵件，請考慮建立電子郵件隔離閘門。 此驗證可讓您掃描所有輸出訊息以確保合規性，並檢查是否包含敏感性資料。 理想情況下，您還應該考慮使用此方法發送客戶支援訊息。
驗證應於工作負載層級上或透過變更控制流程進行。 核准閘門應了解需求。
相關考量事項請參閱官方 PCI-DSS 3.2.1 標準中的指引。
需求 4.3
確認持卡人資料加密傳輸的安全性原則及作業程序留有記錄、正在使用，並為所有受影響方所知悉。
您的責任
請務必保留有關流程與原則的完整文件。 管理有關傳輸層安全性 (TLS) 的原則時更是如此。 其中一些區域包括：
- 公用網際網路輸入點。 例如 Azure 應用程式閘道提供的 TLS 加密支援。
- 周邊網路和工作負載 Pod 之間的網路躍點。
- Pod 到 Pod 加密 (如果已實作)。 可包含有關服務網格組態的詳細資料。
- Pod 到儲存體 (如果是架構的一部分)。
- Pod 到外部服務、使用 TLS 的 Azure PaaS 服務、付款閘道或詐騙偵測系統。
受管制環境的作業人員需接受培訓、充分知情並受到獎勵，以確保安全性保證。 從原則觀點而言，這點對於參與核准流程的人員來說特別重要。
下一步
保護所有系統不受惡意程式碼攻擊，並定期更新防毒軟體或程式。 開發及維護安全的系統和應用程式。