本文說明根據支付卡產業數據安全性標準 （PCI-DSS 3.2.1） 所設定的 Azure Kubernetes Service （AKS） 叢集的考慮。
本文是一系列文章的一部分。 閱讀簡介。
Kubernetes 具有原生角色型訪問控制 （RBAC），可管理 Kubernetes API 的許可權。 Kubernetes 資源上有數個具有特定許可權或動作的內建角色。 Azure Kubernetes Service （AKS） 支援這些內建角色和自定義角色，以進行細微控制。 這些動作可以透過 Kubernetes RBAC 授權或拒絕使用者。
此架構和實作並非設計來提供內部部署資源或數據中心實體存取的控制。 在 Azure 中裝載 CDE 的其中一個優點，與邊緣或數據中心的平臺相反，限制實體存取大多已透過 Azure 資料中心安全性來處理。 組織在管理實體硬體方面沒有任何責任。
重要
本指南和隨附的 實作建置在 AKS 基準架構上。 該架構是以中樞和輪輻拓撲為基礎。 中樞虛擬網路包含用來控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及維護的第三個網路。 輪輻虛擬網路包含 AKS 叢集，可提供持卡人數據環境 （CDE） 並裝載 PCI DSS 工作負載。
GitHub：適用於受管制工作負載的 Azure Kubernetes Service （AKS） 基準叢集示範具有身分識別和訪問控制的受管制基礎結構。 此實作提供Microsoft Entra ID 支援的私用叢集，可支援 Just-In-Time 存取和條件式存取模型以說明用途。
實作強式訪問控制措施
需求 7 - 限制商務需要知道的持卡人數據的存取
AKS 功能支援
AKS 與 Microsoft Entra 識別碼完全整合為識別提供者。
您不需要管理 Kubernetes 的個別使用者身分識別和認證。 您可以為 Kubernetes RBAC 新增Microsoft Entra 使用者。 這項整合可讓您對 Microsoft Entra 使用者執行角色指派。 Microsoft Entra RBAC 支援角色定義，例如查看器、寫入器、服務管理員、叢集管理員作為內建角色。 您也可以建立自定義角色以取得更細微的控制。
根據預設，Azure RBAC 會設定為拒絕所有專案，因此在未授與許可權的情況下無法存取資源。 AKS 會限制對 AKS 背景工作角色節點的 SSH 存取，並使用 AKS 網路原則來控制 Pod 中工作負載的存取。
如需詳細資訊，請參閱使用 Azure RBAC for Kubernetes Authorization and Secure your cluster with Azure 原則。
您的責任
| 需求 | 責任 |
|---|---|
| 需求 7.1 | 將系統元件和持卡人數據的存取限制為只有工作需要這類存取權的個人。 |
| 需求7.2 | 為系統元件建立訪問控制系統，以根據使用者需要知道來限制存取，且除非特別允許，否則會設定為「全部拒絕」。 |
| 需求7.3 | 請確定限制持卡人數據存取的安全策略和操作程式已記載、使用中，以及所有受影響的合作物件都知道。 |
需求 7.1
將系統元件和持卡人數據的存取限制為只有工作需要這類存取權的個人。
您的責任
以下是一些考量：
- 請確定您的實作符合組織的需求，以及身分識別管理的合規性需求。
- 將站立許可權降到最低，特別是對於重大影響帳戶。
- 遵循最低許可權存取原則。 提供足夠的存取權來完成工作。
需求 7.1.1
定義每個角色的存取需求，包括：
- 每個角色需要存取其作業功能的系統元件和數據資源
- 存取資源所需的許可權層級（例如使用者、系統管理員等）。
您的責任
根據範圍內元件及其與 Azure 資源互動所需的工作和責任來定義角色。 您可以從廣泛的類別開始，例如：
- 依 Azure 管理群組、訂用帳戶或資源群組的範圍
- 工作負載或訂用帳戶的 Azure 原則
- 容器作業
- 秘密管理
- 建置和部署管線
雖然這些區域的角色和責任定義可能與小組結構相關聯，但請專注於工作負載的需求。 例如，誰負責維護安全性、隔離、部署和可觀察性。 以下列出一些範例：
- 關於應用程式安全性、Kubernetes RBAC、網路原則、Azure 原則，以及其他服務的通訊決策。
- Azure 防火牆、Web 應用程式防火牆 （WAF）、網路安全組 （NSG） 和 DNS 設定的設定和維護。
- 監視和補救伺服器安全性、修補、設定和端點安全性。
- 設定使用 RBAC、適用於雲端的 Microsoft Defender、系統管理員保護策略和 Azure 原則 來管理 Azure 資源的方向。
- 事件監視和回應小組。 調查並補救安全性資訊和事件管理 （SIEM） 或 適用於雲端的 Microsoft Defender 中的安全性事件。
然後，藉由判斷角色在工作負載和基礎結構方面所需的存取層級，將定義正規化。 以下是說明用途的簡單定義。
| 角色 | 責任 | 存取層級 |
|---|---|---|
| 應用程式擁有者 | 定義並排定與業務成果一致的功能優先順序。 他們瞭解功能如何影響工作負載的合規性範圍，以及平衡客戶數據保護和擁有權與商務目標。 | 讀取應用程式發出的記錄和計量存取權。 他們不需要存取工作負載或叢集的許可權。 |
| 應用程式開發人員 | 開發應用程式。 所有應用程式程式代碼都受限於維護合規性、證明和發行管理程序的訓練和品質網關。 可能會管理組建管線，但通常不是部署管線。 | 讀取工作負載範圍內 Kubernetes 命名空間和 Azure 資源的存取權。 無法部署或修改系統的任何狀態的寫入許可權。 |
| 應用程式操作員（或 SRE） | 深入瞭解程式代碼基底、可觀察性和作業。 進行即時網站分級和疑難解答。 與應用程式開發人員一起，改善應用程式的可用性、延展性和效能。 管理「最後一英里」部署管線，並協助管理組建管線。 | 在應用程式範圍內具有高度特殊許可權，其中包含相關的 Kubernetes 命名空間和 Azure 資源。 可能具有 Kubernetes 叢集部分的常設存取權。 |
| 基礎結構擁有者 | 設計符合成本效益的架構，包括其連線能力和元件的功能。 範圍可以包含雲端和內部部署服務。 決定功能數據保留、商務持續性功能及其他功能。 | 存取平台記錄和成本中心數據。 叢集中不需要存取權。 |
| 基礎結構操作員 （或 SRE） | 與叢集和相依服務相關的作業。 建置、部署和啟動部署工作負載之叢集的管線。 設定目標節點集區，以及預期的重設大小和調整需求。 監視容器裝載基礎結構和相依服務的健全狀況。 | 讀取工作負載命名空間的存取權。 叢集具有高度特殊許可權的存取權。 |
| 原則、安全性擁有者 | 具備安全性或法規合規性專業知識。 定義原則，以保護公司員工、其資產和公司客戶的安全性和法規合規性。 與所有其他角色合作，以確保原則會透過每個階段套用和稽核。 | 工作負載和叢集的讀取許可權。 也存取記錄和稽核數據。 |
| 網路操作員 | 全企業虛擬網路和子網的配置。 Azure 防火牆、WAF、NSG 和 DNS 設定的設定和維護。 | 網路層中具有高度特殊許可權。 叢集中沒有寫入許可權。 |
需求 7.1.2
將特殊許可權使用者識別碼的存取限制為執行作業責任所需的最低許可權。
您的責任
根據作業功能，努力將存取降到最低，而不會造成中斷。 這裡有一些最佳做法：
- 身分識別應該有足夠的存取權來完成工作。
- 將站立許可權降到最低，特別是對於具有範圍內元件存取權的重大影響身分識別。
- 盡可能新增額外的限制。 其中一種方式是根據存取準則提供條件式存取。
- 定期檢閱和稽核訂用帳戶中具有存取權的使用者和群組，甚至是讀取許可權。 避免邀請外部身分識別。
需求 7.1.3
根據個別人員的工作分類和功能指派存取權。
您的責任
根據個別明確指派的工作職責來判斷許可權。 避免參數，例如系統或員工的任期。 將訪問許可權授與單一使用者或群組。
以下列出一些範例。
| 工作分類 | 角色 |
|---|---|
| 產品擁有者會定義工作負載的範圍，並設定功能的優先順序。 平衡客戶數據保護和擁有權與商務目標。 需要存取報表、成本中心或 Azure 儀錶板。 叢集內或叢集層級許可權不需要存取權。 | 應用程式擁有者 |
| 軟體工程師會設計、開發和容器化應用程式程式碼。 在 Azure 內已定義範圍內具有常設讀取許可權的群組（例如 Application Insights）和工作負載命名空間。 在生產前與生產環境之間，這些範圍和許可權可能會不同。 | 應用程式開發人員 |
| 網站可靠性工程師會執行即時網站分級、管理管線，以及設定應用程式基礎結構。 在其配置命名空間內具有完整控制權的群組 A。 不需要常設許可權。 針對工作負載上的日常作業，群組 B。 它可以在其配置的命名空間中具有常設許可權，但許可權並不高。 |
應用程式運算元 |
| 叢集操作員設計和將可靠且安全的 AKS 叢集部署到平臺。 負責維護叢集的上行時間。 在其配置命名空間內具有完整控制權的群組 A。 不需要常設許可權。 針對工作負載上的日常作業，群組 B。 它可以在其配置的命名空間中具有常設許可權，但許可權並不高。 |
基礎結構操作員 |
| 網路 工程師 會配置全企業虛擬網路和子網、內部部署到雲端連線能力，以及網路安全性。 | 基礎結構操作員 |
需求 7.1.4
需要已獲授權者指定必要許可權的已記載核准。
您的責任
擁有核准角色和許可權變更的閘道程式，包括初始許可權指派。 請確定這些核准已記載並可供檢查。
需求7.2
為系統元件建立訪問控制系統，以根據使用者需要知道來限制存取，且除非特別允許，否則會設定為「全部拒絕」。
您的責任
遵循 需求 7.1 之後，您應該已評估組織與工作負載適用的角色和責任。 範圍內架構中的所有元件都必須具有限制的存取權。 這包括執行工作負載的 AKS 節點、資料儲存區、網路存取，以及參與處理卡片持有者數據的其他所有服務（CHD）。
根據角色和責任，將角色指派給基礎結構的角色型訪問控制 （RBAC）。 該機制可以是：
- Kubernetes RBAC 是原生 Kubernetes 授權模型，可控制透過 Kubernetes API 伺服器公開的 Kubernetes 控制平面存取權。 這組許可權會定義您可以使用 API 伺服器執行的動作。 例如，您可以拒絕使用者建立或甚至列出 Pod 的許可權。
- Azure RBAC 是一種Microsoft以 Entra ID 為基礎的授權模型，可控制對 Azure 控制平面的存取。 這是您的 Microsoft Entra 租使用者與 Azure 訂用帳戶的關聯。 透過 Azure RBAC，您可以授與建立 Azure 資源的許可權，例如網路、AKS 叢集和受控識別。
假設您需要授與叢集操作員的許可權（對應至基礎結構操作員角色）。 獲指派基礎結構操作員責任的所有人員都屬於Microsoft Entra 群組。 如同在 7.1.1 中建立，此角色需要叢集中的最高許可權。 Kubernetes 具有內建的 RBAC 角色，例如 cluster-admin，符合這些需求。 您必須建立角色系結，將基礎結構操作員的 Microsoft Entra 群組系結至 cluster-admin 。 有兩種方法。 您可以選擇內建角色。 或者，如果內建角色不符合您的需求（例如，這些角色可能過於寬鬆），請為您的系結建立自定義角色。
參考實作會示範上述範例，方法是使用原生 Kubernetes RBAC。 您可以使用 Azure RBAC 來完成相同的關聯。 如需詳細資訊，請參閱 使用 Kubernetes 角色型訪問控制來控制叢集資源的存取，以及在 Azure Kubernetes Service 中Microsoft Entra 身分識別。
您可以選擇叢集層級或命名空間層級的許可權範圍。 對於具有範圍責任的角色，例如應用程式操作員，許可權會指派在工作負載的命名空間層級。
此外，角色也需要 Azure RBAC 許可權，讓他們能夠執行其工作。 例如，叢集操作員必須透過入口網站存取 Azure 監視器。 因此，基礎結構操作員角色必須具有適當的 RBAC 指派。
除了人員及其角色之外，叢集中的 Azure 資源和甚至是 Pod 都有受控識別。 這些身分識別需要透過 Azure RBAC 的一組許可權，而且必須根據預期的工作嚴格範圍。 例如，Azure 應用程式閘道 必須具有從 Azure 金鑰保存庫 取得秘密 （TLS 憑證） 的許可權。 它不得具有修改秘密的許可權。
這裡有一些最佳做法：
維護每個角色和指派許可權的細緻檔。 請清楚區分哪些許可權是 JIT，以及哪些許可權是站立的。
監視角色是否有變更，例如在指派變更或角色定義中。 建立變更的警示，即使這些變更預期會瞭解變更背後的意圖。
需求 7.2.1
涵蓋所有系統元件
您的責任
以下是維護訪問控制措施的一些最佳做法：
沒有常設存取權。 請考慮使用 Just-In-Time AD 群組成員資格。 此功能需要Microsoft Entra Privileged Identity Management。
在叢集Microsoft Entra ID 中設定條件式存取原則。 這會進一步限制 Kubernetes 控制平面的存取。 使用條件式存取原則，您可以要求多重要素驗證、限制由您Microsoft Entra 租使用者管理的裝置驗證，或封鎖非典型的登入嘗試。 將這些原則套用至具有高許可權的 Microsoft對應至 Kubernetes 角色的 Entra 群組。
注意
JIT 和條件式存取技術選項都需要Microsoft Entra ID P1 或 P2。
在理想情況下，停用叢集節點的 SSH 存取。 此參考實作不會針對該用途產生 SSH 連線詳細數據。
任何額外的計算，例如跳躍方塊，都必須由授權的使用者存取。 請勿建立整個小組可用的泛型登入。
需求 7.2.2
根據作業分類和函式，將許可權指派給個人。
您的責任
根據 7.1.3，叢集作業將涉及許多角色。 除了標準 Azure 資源角色之外，您必須定義存取的範圍和程式。
例如，請考慮叢集操作員角色。 它們應該有明確定義的叢集分級活動的劇本。 工作負載小組的存取權有多不同？ 視您的組織而定，它們可能相同。 以下是一些需要考慮的要點：
- 他們應該如何存取叢集？
- 允許存取哪些來源？
- 叢集上應該具有哪些許可權？
- 何時指派這些許可權？
請確定定義記載在控管文件、原則和訓練材料中，以圍繞工作負載操作員和叢集操作員。
需求 7.2.3
預設的「全部拒絕」設定。
您的責任
當您啟動設定時，請從零信任原則開始。 視需要進行例外狀況，並詳細記錄這些例外狀況。
Kubernetes RBAC 預設會實作 全部拒絕 。 請勿藉由新增可反轉拒絕所有設定的高寬鬆叢集角色系結來覆寫。
Azure RBAC 預設也會實作 全部拒絕 。 請勿藉由新增反轉拒絕所有設定的 RBAC 指派來覆寫。
所有 Azure 服務、Azure 金鑰保存庫 和 Azure Container Registry 預設都會拒絕所有許可權集。
任何系統管理存取點，例如跳躍方塊，都應該拒絕初始設定中的所有存取。 所有提高許可權都必須明確定義至拒絕所有規則。
注意
請記住，針對網路存取，NSG 默認允許所有通訊。 變更以將所有拒絕設定為具有高優先順序的起始規則。 然後，視需要新增將在拒絕所有規則之前套用的例外狀況。 在命名上保持一致，以便更容易進行稽核。
Azure 防火牆 預設會實作全部拒絕。
需求7.3
請確定限制持卡人數據存取的安全策略和操作程式已記載、使用中，以及所有受影響的合作物件都知道。
您的責任
請務必維護有關程序與原則的徹底檔。 這包括 Azure 和 Kubernetes RBAC 原則和組織治理原則。 管理環境的人員必須接受教育、通知和激勵，以支援安全性保證。 對於從原則觀點而言，屬於核准程式一部分的人員來說，這特別重要。
需求 8 - 識別和驗證系統元件的存取權
AKS 功能支援
由於 AKS 和 Microsoft Entra 整合，因此您可以利用標識碼管理和授權功能，包括存取管理、標識符物件管理及其他功能。 如需詳細資訊，請參閱 AKS 管理的 Microsoft Entra 整合。
您的責任
| 需求 | 責任 |
|---|---|
| 需求8.1 | 定義並實作原則和程式，以確保所有系統元件上非取用者使用者和系統管理員的適當用戶識別管理，如下所示： |
| 需求8.2 | 除了指派唯一標識碼之外，請至少採用下列其中一種方法來驗證所有使用者，以確保所有系統元件上非取用者使用者和系統管理員的適當用戶驗證管理： |
| 需求8.3 | 使用多重要素驗證保護所有個別的非控制台系統管理存取，以及 CDE 的所有遠端存取。 |
| 需求8.4 | 記錄並傳達驗證程式和原則和程式給所有使用者，包括： |
| 需求8.5 | 請勿使用群組、共用或一般標識碼、密碼或其他驗證方法，如下所示： |
| 需求8.6 | 如果使用其他驗證機制（例如實體或邏輯安全性令牌、智慧卡、憑證等），則必須指派這些機制，如下所示： |
| 需求8.7 | 所有包含持卡人數據的數據庫存取權（包括應用程式、系統管理員和所有其他使用者的存取權）都會受到限制，如下所示： |
| 需求8.8 | 請確定識別和驗證的安全策略和操作程序記載、使用中，以及所有受影響的合作物件都知道。 |
需求8.1
定義並實作原則和程式，以確保所有系統元件上非取用者使用者和系統管理員的適當用戶識別管理，如下所示：
- 8.1.1 在允許所有使用者存取系統元件或持卡人數據之前，請先指派唯一標識符。
- 8.1.2 控制使用者標識碼、認證和其他標識符物件的新增、刪除和修改。
- 8.1.3 立即撤銷任何已終止使用者的存取權。
- 8.1.4 在90天內移除/停用非使用中的用戶帳戶。
- 8.1.5 管理第三方用來透過遠端訪問存取、支援或維護系統元件的標識碼，如下所示：
- 只有在非使用期間才啟用，且未使用時停用。
- 在使用時受到監視。
- 8.1.6 在未超過六次嘗試之後，鎖定使用者標識碼來限制重複存取嘗試。
- 8.1.7 將鎖定持續時間設定為至少 30 分鐘，或直到系統管理員啟用使用者標識符為止。
- 8.1.8 如果會話已閑置超過15分鐘，則要求使用者重新驗證以重新啟用終端機或會話。
您的責任
以下是此需求的整體考慮：
適用於：8.1.1、8.1.2、8.1.3
請勿共用或重複使用 CDE 功能不同部分的身分識別。 例如，請勿使用小組帳戶來存取數據或叢集資源。 請確定身分識別檔清楚說明不使用共享帳戶。
將此身分識別主體延伸至 Azure 中的受控識別指派。 請勿跨 Azure 資源分享使用者受控識別。 指派每個 Azure 資源自己的受控識別。 同樣地，當您在 AKS 叢集中使用 Microsoft Entra 工作負載 ID 時，請確定工作負載中的每個元件都會收到自己的身分識別，而不是使用範圍很廣的身分識別。 請勿在生產階段前和生產環境中使用相同的受控識別。
Azure Kubernetes Service (AKS) 的存取與身分識別選項
適用於：8.1.2、8.1.3、8.1.4
使用 Microsoft Entra 識別碼作為身分識別存放區。 因為叢集和所有 Azure 資源都使用 Microsoft Entra ID，因此會自動將 entra ID 存取權停用或撤銷Microsoft。 如果有任何元件未直接由 Microsoft Entra ID 支援，請確定您有移除存取權的程式。 例如，如果使用者不再有效，則存取跳躍方塊的 SSH 認證可能需要明確移除。
適用於：8.1.5
利用Microsoft Entra 企業對企業（B2B），其設計目的是裝載第三方帳戶，例如廠商、合作夥伴，作為來賓使用者。 使用條件式原則來保護公司數據，授與適當的存取層級。 這些帳戶必須具有最少的常設許可權和強制到期日。 如需詳細資訊，請參閱 什麼是 Microsoft Entra B2B 中的來賓使用者存取權。
您的組織應該具有清楚且記載的廠商模式和類似的存取權。
適用於：8.1.6、8.1.7、8.1.8
您的責任
Microsoft Entra ID 提供 智慧鎖定功能 ，可在登入嘗試失敗后鎖定使用者。 實作鎖定的建議方法是使用 Microsoft Entra 條件式存取原則。
針對支持類似功能的元件實作鎖定，但不支援Microsoft Entra ID（例如已啟用 SSH 的計算機，例如跳躍方塊）。 這可確保啟用鎖定以防止或緩慢存取嘗試濫用。
AKS節點並非設計為例行存取。 封鎖對叢集節點的直接 SSH 或遠端桌面。 SSH 存取應該只被視為進階疑難解答工作的一部分。 存取權應該受到密切監視，並在完成特定事件之後立即還原。 如果您這樣做，請注意，任何節點層級變更都可能導致您的叢集無法支援。
需求8.2
除了指派唯一標識碼之外，請至少採用下列其中一種方法來驗證所有使用者，確保非取用者使用者和系統管理員的適當用戶驗證管理：您知道的內容，例如密碼或複雜密碼、您擁有的專案，例如令牌裝置或智慧卡、您身為的 例如生物特徵辨識。
- 8.2.1 使用強式密碼編譯，在所有系統元件上的傳輸和儲存期間，轉譯所有驗證認證（例如密碼/詞組）都無法讀取。
- 8.2.2 修改任何驗證認證之前先驗證使用者身分識別，例如執行密碼重設、布建新令牌或產生新密鑰。
- 8.2.3 密碼/片語必須符合下列條件：
- 至少需要七個字元的長度下限。
- 同時包含數值和字母字元。
- 8.2.4 每隔 90 天變更用戶密碼/複雜密碼至少一次。
- 8.2.5 不允許個人提交與過去四個密碼/片語中任何一個相同的新密碼/片語。
- 8.2.6 設定第一次使用的密碼/片語，並在重設為每個使用者的唯一值時，並在第一次使用后立即變更。
您的責任
在叢集Microsoft Entra ID 中設定條件式存取原則。 這會進一步限制 Kubernetes 控制平面的存取。
上述陣列需求會自動由 entra ID Microsoft處理。 以下列出一些範例：
密碼安全性
Microsoft Entra ID 提供強制使用強密碼的功能。 例如，已封鎖屬於全域禁用密碼清單的弱式密碼。 這並不足以保護。 請考慮新增 Microsoft Entra Password Protection 功能，以建立組織特定的禁止清單。 預設會套用密碼原則。 某些原則無法修改，並涵蓋上述一組需求。 其中包括密碼到期和允許的字元。 如需完整清單，請參閱 Microsoft Entra 密碼原則。 請考慮使用可搭配條件式存取原則強制執行的進階功能，例如根據使用者風險強制執行的進階功能，以偵測洩露的使用者名稱和密碼組。 如需詳細資訊，請參閱 條件式存取：用戶風險型條件式存取。
注意
強烈建議您考慮無密碼選項。 如需詳細資訊，請參閱在 Microsoft Entra ID 中規劃無密碼驗證部署。
使用者身分識別驗證
您可以套用登入風險條件式存取原則，以偵測驗證要求是否已由要求身分識別發出。 要求會根據威脅情報來源進行驗證。 其中包括密碼噴洒和IP位址異常。 如需詳細資訊，請參閱 條件式存取：以風險為基礎的條件式存取。
您可能有不使用 Microsoft Entra 識別碼的元件，例如使用 SSH 存取跳躍方塊。 在這種情況下，請使用至少 RSA 2048 金鑰大小的公鑰加密。 一律指定複雜密碼。 具有追蹤已知已核准公鑰的驗證程式。 使用公鑰存取的系統不得公開至因特網。 相反地，所有 SSH 存取都應該透過媒介允許，例如 Azure Bastion，以減少私鑰洩漏的影響。 停用直接密碼存取，並使用替代的無密碼解決方案。
需求8.3
使用多重要素驗證保護所有個別的非控制台系統管理存取，以及 CDE 的所有遠端存取。 注意：多重要素驗證需要至少三個驗證方法中的兩個（如需驗證方法的描述，請參閱需求 8.2）用於驗證。 使用一個因素兩次（例如，使用兩個不同的密碼）不被視為多重要素驗證。
您的責任
使用條件式存取原則來強制執行多重要素驗證，特別是在系統管理帳戶上。 建議在數個內建角色上使用這些原則。 將這些原則套用至具有高許可權的 Microsoft對應至 Kubernetes 角色的 Entra 群組。
此原則可透過其他原則進一步強化。 以下列出一些範例：
- 您可以將驗證限制為由Microsoft Entra 租使用者管理的裝置。
- 如果存取來自叢集網路外部的網路，您可以強制執行多重要素驗證。
如需詳細資訊，請參閱
需求8.4
記錄並傳達驗證程式和原則和程式給所有使用者，包括：
- 選取強身份驗證認證的指引
- 使用者應如何保護其驗證認證的指引
- 不重複使用先前使用密碼的指示
- 如有任何懷疑密碼可能遭到入侵的指示，請變更密碼。
您的責任
維護有關強制執行原則的檔。 身分識別上線訓練的一部分，提供密碼重設程式和組織保護資產最佳做法的指引。
需求8.5
請勿使用群組、共用或一般標識碼、密碼或其他驗證方法，如下所示：
- 一般使用者標識碼已停用或移除。
- 系統管理和其他重要功能不存在共用使用者標識碼。
- 共用和一般使用者標識碼不會用來管理任何系統元件。
您的責任
請勿針對叢集或 Pod 的功能不同部分共用或重複使用身分識別。 例如，請勿使用小組帳戶來存取數據或叢集資源。 請確定身分識別檔清楚說明不使用共享帳戶。
停用 CDE 中的根使用者。 停用 Kubernetes 本機帳戶的使用方式，讓用戶無法使用 CDE 內的叢集內 --admin 建存取權。
需求8.6
如果使用其他驗證機制（例如實體或邏輯安全性令牌、智慧卡、憑證等），則必須指派這些機制，如下所示：
- 驗證機制必須指派給個別帳戶，而不是在多個帳戶之間共用。
- 實體和/或邏輯控件必須就緒，以確保只有預期的帳戶可以使用該機制來取得存取權。
您的責任
請確定每個使用者身分識別上都提供 CDE 的所有存取權，而且這會延伸至任何實體或虛擬令牌。 這包括 CDE 網路的任何 VPN 存取，確保企業點對站存取（如果有的話）使用該驗證流程中的個別用戶憑證。
需求8.7
所有包含持卡人數據的數據庫存取權（包括應用程式、系統管理員和所有其他使用者的存取權）都會受到限制，如下所示：
- 所有使用者對、使用者查詢和資料庫的用戶動作都是透過程序設計方法。
- 只有資料庫管理員能夠直接存取或查詢資料庫。
- 資料庫應用程式的應用程式識別碼只能由應用程式使用（而不是由個別使用者或其他非應用程式進程使用）。
您的責任
根據角色和責任提供存取權。 人員可以使用其身分識別，但必須視需要知道的方式限制存取權，且具有最少的常設許可權。 人員不應該使用應用程式身分識別，而且數據庫存取身分識別絕不能共用。
可能的話，請透過受控識別從應用程式存取資料庫。 否則，請限制暴露在 連接字串 和認證。 使用 Kubernetes 秘密來儲存敏感性資訊，而不是將它們保留在容易探索的位置，例如 Pod 定義。 另一種方式是儲存和載入受控存放區中的秘密，例如 Azure 金鑰保存庫。 在 AKS 叢集上啟用受控識別時，它必須針對 金鑰保存庫 進行自我驗證，才能取得存取權。
需求8.8
請確定識別和驗證的安全策略和操作程序記載、使用中，以及所有受影響的合作物件都知道。
您的責任
請務必維護有關程序與原則的徹底檔。 維護有關強制執行原則的檔。 身分識別上線訓練的一部分，提供密碼重設程式和組織保護資產最佳做法的指引。 管理環境的人員必須接受教育、通知和激勵，以支援安全性保證。 對於從原則觀點而言，屬於核准程式一部分的人員來說，這特別重要。
需求 9 - 限制持卡人數據的實體存取
AKS 功能支援
此需求沒有任何適用的 AKS 功能。
您的責任
此架構和實作並非設計來提供內部部署資源或數據中心實體存取的控制。 如需考慮，請參閱官方PCI-DSS 3.2.1標準中的指引。
以下是套用技術控件的一些建議：
調整任何管理主控台存取中的會話逾時，例如 CDE 中的跳躍方塊，以將存取降至最低。
微調條件式存取原則，以將來自存取點的 Azure 存取令牌上的 TTL 降到最低，例如 Azure 入口網站。 如需詳細資訊，請參閱下列文章：
針對雲端裝載的 CDE，對於管理實體存取和硬體沒有任何責任。 依賴公司網路實體和邏輯控制。
將 CHD 備份匯出到內部部署目的地的最小化。 使用 Azure 中裝載的解決方案來限制對備份的實體存取。
將備份最小化至內部部署。 如果需要，請注意內部部署目的地將會在稽核範圍內。
下一步
追蹤和監視網路資源和持卡人數據的所有存取權。 定期測試安全性系統和程式。