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