本文說明執行工作負載以符合支付卡產業資料安全性標準（PCI-DSS 3.2.1）的 Azure Kubernetes Service （AKS） 叢集的考慮。
本文是一系列文章的一部分。 閱讀簡介 。
此架構和實作著重于基礎結構，而不是工作負載。 本文提供一般考慮和最佳做法，可協助您做出設計決策。 請遵循官方 PCI-DSS 3.2.1 標準中的需求，並視需要使用此文章做為其他資訊。
重要
指導方針和隨附的實作建置在 AKS 基準架構 上 。 以中樞和輪輻拓撲為基礎的架構。 中樞虛擬網路包含用來控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及維護的第三個網路。 輪輻虛擬網路包含 AKS 叢集，可提供持卡人資料環境 （CDE） 並裝載 PCI DSS 工作負載。
GitHub：適用于受管制工作負載 的 Azure Kubernetes Service （AKS） 基準叢集示範受管制的基礎結構。 此實作提供微服務應用程式。 其中包含可協助您體驗基礎結構，並說明網路和安全性控制措施。 應用程式不代表或實作實際的 PCI DSS 工作負載。
保護持卡人資料
需求 3 — 保護儲存的持卡人資料
您的責任
| 需求 | 責任 |
|---|---|
| 需求 3.1 | 藉由實作資料保留和處置原則、至少包含下列所有持卡人資料 （CHD） 儲存體的程式和程式，將持卡人資料儲存體保持在最低限度： |
| 需求 3.2 | 授權之後請勿儲存機密驗證資料（即使加密也一樣）。 如果收到機密驗證資料，請在完成授權程式時轉譯所有資料。 |
| 需求 3.3 | 顯示時遮罩 PAN（前六位數和最後四位數是要顯示的位數上限），因此只有具有合法商務需求的人員才能看到完整的 PAN。 |
| 需求 3.4 | 使用下列任何方法，將 PAN 轉譯為無法讀取的任何位置（包括可攜式數位媒體、備份媒體和記錄檔中）： |
| 需求 3.5 | 記錄並實作程式，以保護用來保護預存持卡人資料的金鑰，以防止洩漏和誤用： |
| 需求 3.6 | 完整記載並實作用於加密持卡人資料之密碼編譯金鑰的所有金鑰管理程式和程式，包括下列各項： |
| 需求 3.7 | 請確定保護預存持卡人資料的安全性原則和操作程式已記載、使用中，以及所有受影響的各方都知道。 |
需求 4 — 加密跨開放公用網路傳輸持卡人資料的傳輸。
您的責任
| 需求 | 責任 |
|---|---|
| 需求 4.1 | 使用強式密碼編譯和安全性通訊協定（例如 TLS、IPSEC、SSH 等）在透過開放式公用網路傳輸期間保護敏感性資料，包括下列各項： |
| 需求 4.2 | 絕不會透過使用者傳訊技術傳送未受保護的 PAN（例如電子郵件、立即訊息、簡訊、聊天等）。 |
| 需求 4.3 | 請確定加密持卡人資料傳輸的安全性原則和操作程式已記錄、使用中，以及所有受影響的各方都知道。 |
需求 3.1
藉由實作資料保留和處置原則、至少包含下列所有持卡人資料 （CHD） 儲存體的程式和程式，將持卡人資料儲存體保持在最低限度：
- 將資料儲存體數量和保留時間限制為法律、法規和商務需求所需的時間
- 不再需要時安全刪除資料的程式
- 持卡人資料的特定保留需求
- 識別並安全地刪除超過已定義保留期之已儲存持卡人資料的每季程式。
您的責任
請勿將狀態儲存在 AKS 叢集中。 如果您選擇儲存 CHD，請探索安全儲存選項。 選項包括檔案儲存體的Azure 儲存體，或 Azure SQL 資料庫 或 Azure Cosmos DB 等資料庫。
嚴格遵循可儲存何種 CHD 的標準指引。 根據您的業務需求和使用的儲存體類型，定義資料保留原則。 一些主要考慮包括：
- 資料的儲存方式和位置？
- 儲存的資料是否已加密？
- 保留期間為何？
- 保留期間允許哪些動作？
- 如何在保留期間過期之後刪除儲存的資料？
有一些選擇的治理原則。 內建的 Azure 原則會強制執行這些選擇。 例如，您可以限制叢集 Pod 上的磁片區類型，或拒絕根檔案系統上的寫入作業。
檢閱 此原則定義 清單，並在適用的情況下將其套用至叢集。
您可能需要暫時快取資料。 建議您在將資料移至儲存體解決方案時保護快取的資料。 請考慮在 AKS 上啟用主機型加密功能。 這會加密儲存在節點 VM 上的資料。 如需詳細資訊，請參閱 Azure Kubernetes Service （AKS） 上的主機型加密。 此外，啟用需要加密暫存磁片和節點集區快取的內建 Azure 原則。
當您選擇儲存體技術時，請探索保留功能。 例如，Azure Blob 儲存體提供 以時間為基礎的保留原則 。 另一個選擇是實作自訂解決方案，以根據保留原則刪除資料。 例如，資料生命週期管理 （DLM），可管理資料生命週期活動。 此解決方案是使用 Azure Data Factory、Microsoft Entra ID 和 Azure 金鑰保存庫 等服務所設計。
如需詳細資訊，請參閱 使用 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 資料的所有內容。
需求 3.4.1
如果使用磁片加密（而不是檔案或資料行層級資料庫加密），邏輯存取必須分開管理，且獨立于原生作業系統驗證和存取控制機制之外（例如，不使用本機使用者帳戶資料庫或一般網路登入認證）。 解密金鑰不得與使用者帳戶相關聯。
您的責任
一般規則不會將狀態儲存在 AKS 叢集中。 使用支援儲存體引擎層級加密的外部資料儲存體。
Azure 儲存體中的所有儲存資料都會使用強式密碼編譯來加密和解密。 Microsoft 會管理相關聯的金鑰。 偏好使用自我管理加密金鑰。 一律加密儲存層外部，並且只將加密的資料寫入儲存體媒體，確保金鑰永遠不會與儲存層相鄰。
透過Azure 儲存體，您也可以使用自我管理金鑰。 如需詳細資訊，請參閱 客戶管理的金鑰以進行Azure 儲存體加密 。
資料庫也提供類似的功能。 如需 Azure SQL 選項，請參閱 使用客戶管理的金鑰 透明資料加密 Azure SQL。
請務必將金鑰儲存在受控金鑰存放區中（Azure 金鑰保存庫、Azure 金鑰保存庫 受控硬體安全性模組 （HSM）和其他。
如果您需要暫時儲存資料，請啟用 AKS 的主機加密 功能，以確保儲存在 VM 節點上的資料已加密。
需求 3.5
記錄並實作程式，以保護用來保護預存持卡人資料的金鑰，以防止洩漏和誤用：
您的責任
這些點會在小節中說明：
- 維護密碼編譯金鑰最低許可權存取的做法。
- Azure 金鑰保存庫 和 Microsoft Entra ID 的設計目的是支援授權和稽核記錄需求。 如需詳細資訊，請參閱 要求 Azure 金鑰保存庫 的驗證。
- 使用儲存在密碼編譯裝置中的金鑰加密金鑰來保護所有資料加密金鑰。
- 如果您使用自我管理金鑰（而非 Microsoft 管理的金鑰），請具有程式與檔，以維護與金鑰管理相關的工作。
需求 3.5.1
僅限服務提供者的其他需求：維護密碼編譯架構的記載描述，包括：
- 用於保護持卡人資料的所有演算法、通訊協定和金鑰的詳細資料，包括金鑰強度和到期日
- 每個金鑰的金鑰使用方式描述
- 清查用於金鑰管理的任何 HSM 和其他 SCD
您的責任
儲存敏感性資訊（金鑰、連接字串和其他資訊）的其中一種方式是使用原生 Kubernetes Secret 資源。 您必須明確啟用待用加密。 或者，將它們儲存在受控存放區，例如 Azure 金鑰保存庫。 在兩種方法中，我們建議使用受控存放區服務。 其中一個優點是減少與金鑰管理相關的工作的額外負荷，例如金鑰輪替。
根據預設，Azure 會針對每位客戶的所有加密資料使用 Microsoft 管理的金鑰。 不過，某些服務也支援自我管理金鑰進行加密。 如果您使用自我管理金鑰進行待用加密，請確定您考慮處理金鑰管理工作的流程和策略。
在您的檔中，包含金鑰管理的相關資訊，例如到期、位置和維護計畫詳細資料。
需求 3.5.2
將密碼編譯金鑰的存取限制為所需的最少監管人數目。
您的責任
將可存取金鑰的人員數目降到最低。 如果您使用任何群組型角色指派，請設定週期性稽核程式來檢閱具有存取權的角色。 當專案小組成員變更時，不再相關的帳戶必須從許可權中移除。 只有正確的人員才應該有存取權。 請考慮移除常設許可權，以支援 Just-In-Time 角色指派、以時間為基礎的角色啟用，以及以核准為基礎的角色啟用。
需求 3.5.3
隨時以下列一或多個形式儲存用來加密/解密持卡人資料的秘密和私密金鑰：
- 使用至少與資料加密金鑰一樣強的金鑰加密，且與資料加密金鑰分開儲存
- 在安全的密碼編譯裝置內 （例如硬體 （主機） 安全性模組 （HSM） 或 PTS 核准的互動點裝置）
- 至少兩個全長金鑰元件或金鑰共用，根據業界接受的方法
您的責任
PCI-DSS 3.2.1 工作負載必須使用多個加密金鑰作為待用資料保護策略的一部分。 資料加密金鑰 （DEK） 用來加密和解密 CHD，但您必須負責額外的金鑰加密金鑰 （KEK） 來保護該 DEK。 您也必須負責確保 KEK 儲存在密碼編譯裝置中。
您可以使用 Azure 金鑰保存庫來儲存 DEK，並使用 Azure 專用 HSM 來儲存 KEK。 如需 HSM 金鑰管理的相關資訊，請參閱 什麼是 Azure 專用 HSM？ 。
需求 3.6
完整記載並實作用於加密持卡人資料之密碼編譯金鑰的所有金鑰管理程式和程式，包括下列各項：
您的責任
（適用于：需求 3.6.1、需求 3.6.2、需求 3.6.3、需求 3.2.4）
如果您使用 Azure 金鑰保存庫來儲存金鑰、憑證和連接字串等秘密，請防止未經授權的存取。 適用于 金鑰保存庫 的 Microsoft Defender 會偵測可疑的存取嘗試並產生警示。 您可以在 適用於雲端的 Microsoft Defender中檢視這些警示。 如需詳細資訊，請參閱 適用于 金鑰保存庫 的 Microsoft Defender。
請遵循 NIST 關於金鑰管理的指引。 如需詳細資料，請參閱：
另 請參閱適用于 金鑰保存庫 的 Microsoft Defender。
需求 3.6.7
防止未經授權的密碼編譯金鑰替代。
您的責任
- 在所有金鑰存放區上啟用診斷 。 使用 Azure 監視器進行金鑰保存庫。 它會收集記錄和計量，並將其傳送至 Azure 監視器。 如需詳細資訊，請參閱 使用適用于 金鑰保存庫 的 Azure 監視器監視金鑰保存庫服務。
- 授與所有取用者的唯讀許可權 。
- 沒有所有管理服務主體的常設許可權 。 請改用 Just-In-Time （JIT） 角色指派、以時間為基礎的角色啟用，以及以核准為基礎的角色啟用。
- 將記錄和警示整合到安全性資訊和事件管理 （SIEM） 解決方案中，例如 Microsoft Sentinel，以建立集中式檢視 。
- 對警示 和通知採取動作，特別是在非預期的變更上。
需求 3.6.8
要求密碼編譯金鑰監管人正式承認他們瞭解並接受其金鑰監管人的責任。
您的責任
維護檔，說明負責金鑰管理作業之各方的責任。
需求 3.7
請確定保護預存持卡人資料的安全性原則和操作程式已記載、使用中，以及所有受影響的各方都知道。
您的責任
將檔建立為一般語句，以及所有角色的一系列最新角色指南。 執行新進員工訓練和進行中的訓練。
請務必維護有關程式與原則的徹底檔。 數個小組參與確保待用和傳輸中的資料受到保護。 在您的檔中，提供所有角色的角色指引。 這些角色應包括 SRE、客戶支援、銷售、網路作業、安全性作業、軟體工程師、資料庫管理員和其他角色。 人員應接受 NIST 指引和待用資料策略的訓練，以便讓技能保持最新狀態。 需求 6.5 和 需求 12.6 中 會解決定型需求。
需求 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 服務、付款閘道或詐騙偵測系統。
人員誰是受監管的環境，必須接受教育、通知和激勵，以支援安全性保證。 對於從原則觀點而言，屬於核准程式一部分的人員來說，這特別重要。
下一步
保護所有系統免于惡意程式碼，並定期更新防毒軟體或程式。 開發和維護安全的系統和應用程式。