適用於 PCI-DSS 3.2.1 的 AKS 基準叢集存取管理 (第 6 部分，共 9 部分)

本文說明根據支付卡產業資料安全標準 (PCI-DSS 3.2.1) 所設定的 Azure Kubernetes Service (AKS) 叢集的考量事項。

本文是系列文章的一部分。 閱讀簡介。

Kubernetes 提供原生角色型存取控制 (RBAC)，可用於管理 Kubernetes API 權限。 有多個內建角色擁有 Kubernetes 資源的特定權限，或可對其執行操作。 Azure Kubernetes Service (AKS) 支援這些內建角色，以及可進行精細控制的自訂角色。 您可以透過 Kubernetes RBAC 授權 (或拒絕) 使用者執行這些操作。

此架構和實作並非設計用來提供對內部部署資源或資料中心的實體存取控制項。 將 CDE 裝載於 Azure 中、而非邊緣平台或資料中心內部的好處之一是，實體存取限制大多已透過 Azure 資料中心的安全性機制完成處理。 組織無需承擔任何實體硬體管理責任。

實作強大的存取控制措施

需求 7 — 依業務知情需求，限制對持卡人資料的存取

AKS 功能支援

AKS 會與 Microsoft Entra ID 完全整合為身分識別提供者。

您不必管理個別的 Kubernetes 使用者身分識別和認證。 您可以為 Kubernetes RBAC 新增 Microsoft Entra 使用者。 這種整合可讓您為 Microsoft Entra 使用者指派角色。 您可以透過 Microsoft Entra 身分使用各種內建角色，例如檢視人員、編寫人員、服務管理員和叢集管理員。 您還可以建立自訂角色，以進行更精細的控制。

根據預設，Azure RBAC 會設定為拒絕所有存取，因此在未授予權限的情況下無法存取資源。 AKS 會限制對 AKS 背景工作角色節點的 SSH 存取，並使用 AKS 網路原則來控制對 Pod 內部工作負載的存取。

如需詳細資訊，請參閱使用適用於 Kubernetes 授權的 Azure RBAC 和使用 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 原則的使用指示。
• 成立事件監視和回應團隊。 使用 Microsoft Sentinel 或適用於雲端的 Microsoft Defender 等安全性資訊和事件管理 (SIEM) 系統，調查和修復安全性事件。

接著，請正式定義每個角色需要的工作負載和基礎結構存取權層級。 這是一個用於說明的簡單定義。

角色	責任	存取層級
應用程式擁有者	定義與業務成果相對應的功能，並排定優先順序。 了解這些功能如何影響工作負載的合規範圍，並在保護客戶資料與負責達成業務目標之間取得平衡。	對應用程式發出的記錄和計量擁有讀取權限。 不需要擁有存取工作負載或叢集的權限。
應用程式開發人員	開發應用程式。 所有應用程式碼皆需通過訓練和品質關卡，以遵守合規性、證明和發行管理流程。 可能負責管理組建管線，但通常不負責管理部署管線。	擁有工作負載範圍內 Kubernetes 命名空間和 Azure 資源的讀取權限。 不具備部署或修改任何系統狀態的寫入權限。
應用程式操作員 (SRE)	對程式碼庫、可檢視性和作業有深入的了解。 執行即時站點分級和疑難排解。 與應用程式開發人員合作，改善應用程式的可用性、可擴縮性和效能。 管理「最後一哩」部署管線，並協助管理組建管線。	在應用程式範圍 (包括相關的 Kubernetes 命名空間和 Azure 資源) 內擁有高度權限。 可能擁有 Kubernetes 叢集特定部分的常設存取權。
基礎結構擁有者	設計符合成本效益的架構，包括連線能力以及各項元件的功能。 範圍可能包括雲端和內部部署服務。 決定資料保留、商務持續性等功能。	擁有平台記錄和成本中心資料的存取權。 不需要擁有叢集內部的存取權。
基礎結構操作員 (SRE)	處理與叢集和相依服務相關的作業。 為用於部署工作負載之叢集組建、部署和啟動管線。 設定目標節點集區，以及預期的調整大小和級別需求。 監視容器裝載基礎結構和相依服務的健康情況。	擁有工作負載命名空間的讀取權限。 擁有叢集的高度存取權限。
原則/安全性擁有者	擁有安全性或法規合規性專業知識。 定義原則，用於保護公司及其客戶之員工和資產的安全性和法規合規性。 與所有其他角色合作，確保在每個階段中套用和稽核原則。	擁有工作負載和叢集的讀取權限。 此外還需擁有記錄和稽核資料的存取權。
網路操作員	配置整個企業的虛擬網路和子網路。 設定和維護 Azure 防火牆、WAF、NSG 和 DNS 組態。	擁有網路層的高度權限。 在叢集內沒有寫入權限。

需求 7.1.2

限制特殊權限使用者 ID 的存取權，使其僅具備履行工作職責所需的最低權限。

您的責任

根據工作職責，在不造成干擾的情況下盡可能減少存取。 這裡有一些最佳做法：

• 減少每種身分識別所需的存取權。 建議授予每種身分識別恰好足以完成其任務的存取權。
• 盡可能減少常設權限，特別是有權存取範圍內元件、具有重大影響力的身分。
• 盡量增設額外的限制。 其中一種方法是根據存取權準則，提供條件式存取權。
• 定期檢閱和稽核在訂用帳戶中擁有存取權 (即使只是讀取權限) 的使用者和群組。 避免邀請外部身分識別。

需求 7.1.3

根據個別人員的工作分類和職責指派存取權。

您的責任

根據明確指派的個人工作職責來決定權限。 避免使用系統或員工年資等參數來決定權限。 僅向單一使用者或群組授予存取權。

以下列出一些範例。

工作分類	角色
產品負責人需定義工作負載的範圍，並排定各項功能的優先順序。 在保護客戶資料與負責達成業務目標之間取得平衡。 需要存取報表、成本中心或 Azure 儀表板。 不需要叢集內部或叢集層級權限的存取權。	應用程式擁有者
軟體工程師負責應用程式碼的設計、開發和容器化。 在 Azure 中的已定義範圍 (例如 Application Insights) 和工作負載命名空間內擁有常設讀取權限的群組。 這些範圍和權限在生產前環境和生產環境之間可能有所不同。	應用程式開發人員
網站可靠性工程師負責執行即時站點分級、管理管線，以及設定應用程式基礎結構。 群組 A 在已配置給他們的命名空間內擁有完整控制權。 不需要常設權限。 群組 B 負責工作負載的日常作業。 此群組可於配置給他們的命名空間內擁有常設權限，但不得為高度權限。	應用程式操作員
叢集操作員負責設計可靠且安全的 AKS 叢集，並將其部署至平台。 負責維護叢集的正常運作時間。 群組 A 在已配置給他們的命名空間內擁有完整控制權。 不需要常設權限。 群組 B 負責工作負載的日常作業。 此群組可於配置給他們的命名空間內擁有常設權限，但不得為高度權限。	基礎結構操作員
網路工程師負責整個企業的虛擬網路和子網路配置、內部部署至雲端的連線能力，以及網路安全性。	基礎結構操作員

需求 7.1.4

需由授權方指定所需的權限，並以書面方式核准。

您的責任

設置一道把關流程，用來核准角色和權限的變更 (包括初始的權限分配)。 確認這些核准流程留有文件記錄，並可供檢查。

需求 7.2

為系統元件建立存取控制系統，以根據使用者的知情需求設定存取限制，且除非特別允許，否則應設定為「全部拒絕」。

您的責任

遵循需求 7.1 之後，您就應該完成了適用於組織和工作負載的角色和責任評估。 該架構中所有範圍內元件的存取權皆需受到限制。 包括用來執行工作負載、資料儲存體、網路存取，以及涉及持卡人資料 (CHD) 處理之所有其他服務的 AKS 節點。

根據角色和責任，為基礎結構的角色型存取控制 (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 角色型存取控制和 Azure Kubernetes Service 中的 Microsoft Entra 身分識別來控制雲端資源的存取。

您可以在叢集或命名空間層級選擇權限範圍。 擁有範圍內責任的角色 (例如應用程式操作員)，其權限會在工作負載的命名空間層級指派。

此外，這些角色還需要 Azure RBAC 權限才能執行工作。 例如，叢集操作員需要透過入口網站存取 Azure 監視器。 因此，請務必為基礎結構操作員角色指派適當的 RBAC 權限。

除了人員及其角色之外，叢集中的 Azure 資源 (甚至包括 Pod) 也有受控身分識別。 這些身分識別需要透過 Azure RBAC 取得一組權限，並且必須根據預期的工作嚴格限定範圍。 例如，Azure 應用程式閘道必須擁有從 Azure Key Vault 取得秘密 (TLS 憑證) 的權限。 但它不應擁有修改秘密的權限。

這裡有一些最佳做法：

• 詳細記錄每個角色及其獲指派的權限，以及指派的理由。 清楚區分哪些權限是 JIT，哪些是常設權限。

• 監視角色的變更情況，例如指派或角色定義的變更。 建立變更警示 (即使是預期變更)，以洞察變更背後的意圖。

需求 7.2.1

涵蓋所有系統元件

您的責任

以下是維護存取控制措施的一些最佳做法：

• 不要提供常設存取權。 請考慮使用 即時 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 Key Vault 和 Azure Container Registry) 皆會拒絕所有權限。

• 任何管理存取點 (例如跳躍箱) 皆應拒絕初始組態中的所有存取權。 所有提高的權限在覆寫「全部拒絕」規則之前，皆需加以明確定義。

需求 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 ID 做為身分識別存放區。 叢集和所有 Azure 資源皆會使用 Microsoft Entra ID，因此若停用或撤銷主體的存取權，將會自動套用至所有資源。 如果有任何元件並非直接由 Microsoft Entra ID 提供支援，請務必訂定移除存取權的流程。 舉例來說，如果使用者不再有效，則可能需要明確移除用於存取跳躍箱的 SSH 認證。

適用於：8.1.5

善用 Microsoft Entra 外部 ID，其設計目的旨在將第三方企業對企業 (B2B) 帳戶 (例如供應商和合作夥伴) 裝載為來賓使用者。 使用條件式原則授予適當的存取權層級，以保護公司資料。 這些帳戶必須設有最低限度的常設權限和強制到期日。 如需詳細資訊，請參閱讓您的員工與外部來賓進行 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 密碼/片語需符合以下條件：
  • 至少 7 個字元的長度。
  • 包含數字和字母字元。
• 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 ID，例如使用 SSH 存取跳躍箱。 針對此類情況，請使用金鑰大小至少為 RSA 2048 的公開金鑰加密。 請一律指定複雜密碼。 建立一個驗證流程，用於追蹤已知核准的公開金鑰。 使用公開金鑰存取的系統不得在網際網路上公開。 相反地，所有 SSH 存取皆應僅允許透過 Azure Bastion 等媒介進行，以降低私密金鑰外洩的影響。 停用直接密碼存取，並使用替代的無密碼解決方案。

需求 8.3

使用多重要素驗證，保護對 CDE 進行的所有個別非主控台管理存取及所有遠端存取。 注意：多重要素驗證需至少使用三種驗證方法中的兩種 (如需驗證方法的說明，請參閱需求 8.2)。 使用同一項要素兩次 (例如，使用兩個不同的密碼) 不被視為多重要素驗證。

您的責任

使用條件式存取原則來強制執行多重要素驗證，特別是針對管理帳戶。 建議針對多個內建角色使用這些原則。 將這些原則套用至具有高級權限的 Kubernetes 角色所對應的 Microsoft Entra 群組。

您可以搭配使用其他原則，以強化此原則。 以下列出一些範例：

• 您可以限制只對 Microsoft Entra 租用戶管理的裝置進行驗證。
• 如果存取來自叢集網路以外的網路，您可以強制執行多重要素驗證。

如需詳細資訊，請參閱

• 條件式存取：要求管理員通過 MFA
• 條件式存取：需要符合規範的裝置
• 條件式存取：登入風險型多重要素驗證

需求 8.4

記錄並向所有使用者傳達身分驗證程序和原則，包括：

• 選取強式驗證認證的指導
• 使用者應如何保護其驗證認證的指導
• 不重複使用先前使用過密碼的指示
• 懷疑密碼遭洩漏時變更密碼的指示。

您的責任

維護有關強制執行原則的文件。 在入職培訓提供有關身分驗證的指導，特別是針對密碼重設程序，以及有助於保護資產的組織最佳做法。

需求 8.5

請勿使用群組、共用或泛型識別碼、密碼或其他驗證方法，如下所示：

• 停用或移除泛型使用者識別碼。
• 系統管理和其他重要功能禁止使用共用使用者識別碼。
• 禁止使用共用和泛型使用者識別碼管理任何系統元件。

您的責任

請勿針對叢集或 Pod 不同部分的功能，共用或重複使用身分識別。 例如，請勿使用團隊帳戶存取資料或叢集資源。 確保身分識別文件明確指出不得使用共用帳戶。

在 CDE 中停用 root 使用者。 停用 Kubernetes 本機帳戶，讓使用者無法對 CDE 中的叢集使用內建的 --admin 存取權。

需求 8.6

使用其他驗證機制 (例如實體或邏輯安全性權杖、智慧卡、憑證等) 之前，必須指派使用下列機制：

• 驗證機制必須指派給單一帳戶，而非由多個帳戶共用。
• 務必建置實體和/或邏輯控制項，以確保只有預期的帳戶才能透過該機制獲得存取權。

您的責任

確保所有 CDE 存取權皆依個別使用者身分識別授予，並會延伸至任何實體或虛擬權杖。 這包括對 CDE 網路的任何 VPN 存取，以確保企業點對站存取 (如果有的話) 使用個別使用者憑證做為身分驗證流程的一部分。

需求 8.7

對含有持卡人資料的任何資料庫進行的任何存取 (包括由應用程式、系統管理員和所有其他使用者進行的存取) 皆需受到下列限制：

• 使用者對資料庫的任何存取、查詢和操作，皆需透過程式設計方式進行。
• 只有資料庫管理員才能直接存取或查詢資料庫。
• 資料庫應用程式的應用程式識別碼只能由應用程式使用 (而不能由個人使用者或其他非應用程式程序使用)。

您的責任

根據角色和責任提供存取權。 人員可以使用自己的身分識別，但存取權必須依知情需求受到限制，且只能擁有最低限度的常設權限。 人員絕對不得使用應用程式身分識別，而且資料庫存取身分識別絕對不能共用。

盡可能透過受控身分識別，從應用程式存取資料庫。 否則請設定限制，以避免公開連接字串和認證。 使用 Kubernetes 祕密來儲存敏感性資訊，而非將它們保存在容易發現的地方，例如 Pod 定義。 另一種方法是將秘密儲存在專為安全資料設計的受控儲存體 (例如 Azure Key Vault) 中，並透過這些儲存體載入。 在 AKS 叢集上啟用受控身分識別後，AKS 叢集必須針對 Key Vault 完成自我身分驗證，才能取得存取權。

需求 8.8

確保用於識別和驗證的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方知悉。

您的責任

請務必保留有關流程與原則的完整文件。 維護有關強制執行原則的文件。 在入職培訓提供有關身分驗證的指導，特別是針對密碼重設程序，以及有助於保護資產的組織最佳做法。 受管制環境的作業人員必須接受培訓、充分知情並受到獎勵，以確保安全性保證。 從原則觀點而言，這點對於參與核准流程的人員來說特別重要。

需求 9 — 限制對持卡人資料的實體存取

AKS 功能支援

此需求沒有任何適用的 AKS 功能。

您的責任

此架構和實作並非設計用來提供對內部部署資源或資料中心的實體存取控制項。 相關考量事項請參閱官方 PCI-DSS 3.2.1 標準中的指引。

以下是關於套用技術控制項的一些建議：

• 調整任何管理主控台存取 (例如 CDE 中的跳躍箱) 的工作階段逾時，以盡可能減少存取。

• 調整條件式存取原則，以盡量縮短來自存取點 (例如 Azure 入口網站) 的 Azure 存取權杖 TTL。 若要了解詳細資訊，請參閱這些文章：

  • 設定調適型工作階段存留期原則
  • 可在 Microsoft 身分識別平台中設定的權杖存留期

• 針對雲端裝載的 CDE，無需負責管理實體存取和硬體。 仰賴公司的網路實體和邏輯控制項。

• 盡量避免將 CHD 備份匯出至內部部署目的地。 使用裝載於 Azure 中的解決方案，限制對備份進行實體存取。

• 盡量避免將備份至內部部署。 如果需要這樣做，請留意應將內部部署目的地納入稽核範圍。

下一步

追蹤及監視對網路資源和持卡人資料進行的所有存取。 定期測試安全性系統與流程。