本文說明根據支付卡產業資料安全性標準 （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 ID 完全整合為識別提供者。
您不需要管理 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、管理員istrator 保護原則，以及管理 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 來完成相同的關聯。 如需詳細資訊，請參閱 在 Azure Kubernetes Service 中使用 Kubernetes 角色型存取控制和 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 租使用者所管理的裝置驗證，或封鎖非一般登入嘗試。 將這些原則套用至對應至具有高許可權的 Kubernetes 角色的 Microsoft 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，因此會自動將停用或撤銷 Microsoft Entra ID 存取套用至所有資源。 如果有任何未由 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 控制平面的存取。
Microsoft Entra ID 會自動處理上述陣列需求。 以下列出一些範例：
密碼安全性
Microsoft Entra ID 提供強制使用強式密碼的功能。 例如，已封鎖屬於全域禁用密碼清單的弱式密碼。 這並不足以保護。 請考慮新增 Microsoft Entra 密碼保護功能，以建立組織特定的禁止清單。 預設會套用密碼原則。 某些原則無法修改，並涵蓋上述一組需求。 其中包括密碼到期和允許的字元。 如需完整清單，請參閱 Microsoft Entra 密碼原則 。 請考慮使用可搭配條件式存取原則強制執行的進階功能，例如根據使用者風險強制執行的進階功能，以偵測洩露的使用者名稱和密碼組。 如需詳細資訊，請參閱 條件式存取：使用者風險型條件式存取 。
注意
強烈建議您考慮無密碼選項。 如需詳細資訊，請參閱 在 Microsoft Entra ID 中規劃無密碼驗證部署。
使用者身分識別驗證
您可以套用登入風險條件式存取原則，以偵測驗證要求是否已由要求身分識別發出。 要求會根據威脅情報來源進行驗證。 其中包括密碼噴灑和 IP 位址異常。 如需詳細資訊，請參閱 條件式存取：以風險為基礎的條件式存取 。
您可能有不使用 Microsoft Entra 識別碼的元件，例如使用 SSH 存取跳躍方塊。 在這種情況下，請使用至少 RSA 2048 金鑰大小的公開金鑰加密。 一律指定複雜密碼。 具有追蹤已知已核准公開金鑰的驗證程式。 使用公開金鑰存取的系統不得公開至網際網路。 相反地，所有 SSH 存取都應該透過媒介允許，例如 Azure Bastion，以減少私密金鑰洩漏的影響。 停用直接密碼存取，並使用替代的無密碼解決方案。
需求 8.3
使用多重要素驗證保護所有個別的非主控台系統管理存取，以及 CDE 的所有遠端存取。 注意：多重要素驗證需要至少三個驗證方法中的兩個（如需驗證方法的描述，請參閱需求 8.2）用於驗證。 使用一個因素兩次（例如，使用兩個不同的密碼）不被視為多重要素驗證。
您的責任
使用條件式存取原則來強制執行多重要素驗證，特別是在系統管理帳戶上。 建議在數個內建角色上使用這些原則。 將這些原則套用至對應至具有高許可權的 Kubernetes 角色的 Microsoft 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 中裝載的解決方案來限制對備份的實體存取。
將備份最小化至內部部署。 如果需要，請注意內部部署目的地將會在稽核範圍內。
下一步
追蹤和監視網路資源和持卡人資料的所有存取權。 定期測試安全性系統和程式。