GKE 的 PCI DSS 法規遵循

本指南可在您履行付款卡產業資料安全標準 (PCI DSS) 所要求的客戶責任時，幫助您解決 Google Kubernetes Engine (GKE) 應用程式專有的問題。

免責事項：本指南僅供參考。 Google 在本指南中提供的資訊或建議不構成法律或稽核建議。客戶有責任自行評估在使用服務時，本身已善盡相關法律與法規的遵循義務。

PCI DSS 法規遵循與 GKE 簡介

在處理付款卡資料時，無論資料是位於內部部署資料庫或是雲端中，都必須確保資料安全。PCI DSS 的制定是為了鼓勵及增強持卡人的資料安全性，並促進全球廣泛採用一致的資料安全性措施。PCI DSS 的用意在於提供保護信用卡資料的技術和操作要求基準。PCI DSS 適用於涉及付款卡處理的所有實體，包括商家、處理方、收單機構、發卡機構和服務供應商。PCI DSS 也適用於所有其他儲存、處理或傳輸持卡人資料 (CHD) 和/或機密驗證資料 (SAD) 的實體。

近來容器化應用程式十分普遍，許多舊版工作負載已從虛擬機器 (VM) 架構遷移到容器化架構。 Google Kubernetes Engine 是代管環境，專供部署容器化應用程式，隨時可用於實際工作。這項服務匯集了 Google 在開發人員生產力、資源效率、自動化作業和開放原始碼靈活性等方面的最新創新技術，可以加快應用程式的上市腳步。

雲端服務的買賣雙方都有責任遵循法規。 Google Cloud，包括 GKE (Autopilot 和 Standard 兩種作業模式)，皆遵循 PCI DSS 要求。我們在共同責任矩陣中概述了我們的責任。

目標對象

• 想要將符合 PCI 規定的工作負載移至包含 GKE 的 Google Cloud 客戶。
• 開發人員、資安管理人員、法規遵循人員、IT 管理員，以及其他負責落實控管機制及確保相關作業符合 PCI DSS 規範的人員。

事前準備

對於後續的建議，您可能會使用到下列項目：

• Google Cloud 機構、資料夾和專案資源
• 身分與存取權管理 (IAM)
• Google Kubernetes Engine
• Google Cloud VPC
• Google Cloud Armor
• Cloud Data Loss Prevention API (屬於機密資料保護服務)
• Identity-Aware Proxy (IAP)
• Security Command Center

本指南適合熟悉如何使用容器與 GKE 的人員。

適用範圍

本指南指出下列 GKE 需要特別考量的 PCI DSS 的要求，並提供達到這些要求的指引。此為針對該標準的 4.0 版所撰寫。本指南並未涵蓋 PCI DSS 中的所有要求。本指南提供的資訊或許有助於機構遵守 PCI DSS 規範，但並非全面性的建議。組織可以聘請 PCI 合格安全評估人員 (QSA)進行正式驗證。

PCI DSS 目標	PCI DSS 規範
區隔持卡人資料環境	有時也稱為要求 0。儘管這並非 PCI 法規遵循的必要條件，但我們仍建議您遵守此規範以限制 PCI 適用範圍。
建構並維護安全的網路和系統	1. 安裝及維護網路安全性控管機制 要求 1.1 要求 1.1.2 要求 1.2 要求 1.2.2 要求 1.2.5 要求 1.3 要求 1.3.1 要求 1.4 要求 1.4.3 要求 1.4.5 2. 為所有系統元件套用安全設定 要求 2.2 要求 2.2.4 要求 2.2.5 要求 2.2.6
保護帳戶資料	3. 保護所儲存的帳戶資料 要求 3.5 要求 3.6 4. 在開放的公開網路上進行傳輸時，使用高強度密碼編譯保護持卡人資料 要求 4.1
維護安全漏洞管理計畫	5. 保護所有系統和網路，防範惡意軟體 要求 5.2 要求 5.2.3 要求 5.3 6. 開發並維護安全的系統和軟體 要求 6.2 要求 6.2.1 要求 6.3 要求 6.3.1 要求 6.4
實施健全的存取權控管措施	7. 將系統元件和持卡人資料的存取權限制為僅有業務上需要的人員可存取 要求 7.2 要求 7.2.2 8. 識別並驗證系統元件的存取權 要求 8.2 要求 8.2.1 要求 8.2.5 要求 8.3 要求 8.3.1 9. 限制持卡人資料所在地點的實際進出權限
定期監控及測試網路	10. 記錄並監控所有系統元件和持卡人資料的存取行為 要求 10.2 要求 10.2.2 11. 定期測試系統和網路的安全性 要求 11.3 要求 11.3.1 要求 11.5 要求 11.5.1
維護資安政策	12. 透過機構政策和方案維護資訊安全

術語

本節定義本指南所使用的術語。詳情請參閱 PCI DSS 詞彙。

CHD

「Cardholder data」(持卡人資料)。至少會包含完整的主要帳號 (PAN)。持卡人資料的形式也可能是完整 PAN 加上下列任一資訊：

• 持卡人姓名
• 到期日或服務代碼
• 機密驗證資料 (SAD)

CDE

「Cardholder data environment」(持卡人資料環境)。儲存、處理或傳輸持卡人資料或機密驗證資料的人員、程序和技術。

PAN

「primary account number」(主要帳號)。根據 PCI DSS 要求，您有義務保護的關鍵持卡人資料。PAN 通常為付款卡 (信用卡和簽帳金融卡) 專屬的 16 位數字，可用來識別發卡機構和持卡人帳戶。

印度郵遞區號 (PIN)

「Personal identification number」(個人識別號碼)。僅有使用者和系統知道的數字密碼；用於在系統上進行使用者驗證。

QSA

「Qualified security assessor」(合格的安全性評鑑人員)。經過 PCI 安全標準委員會 (SSC) 認證，可執行稽核與法規遵循分析的人員。

SAD

「Sensitive authentication data」(機密驗證資料)。在 PCI 法規遵循中，發卡機構用來授權交易的資料。PCI DSS 與持卡人資料類似，因此必須保護 SAD。此外，商家及其付款處理方不得保留 SAD。SAD 包含下列項目：

• 磁條的「追蹤」資料
• 晶片和感應式卡片產生的「等同追蹤的資料」
• 用於線上和無卡交易的安全驗證碼 (例如，印在卡片上的 3 至 4 位數字)。
• PIN 碼與 PIN 碼區塊

區隔

在 PCI DSS 中將 CDE 與實體網路其餘部分區隔的做法。區隔並非 PCI DSS 的要求，但我們仍強烈建議您使用，因為這個做法可協助降低下列項目：

• PCI DSS 評鑑的適用範圍和成本
• 實施和維護 PCI DSS 管控的成本和難度
• 組織的風險 (將持卡人資料整合至更少且更受控管的位置以降低風險)

區隔持卡人資料環境

持卡人資料環境 (CDE) 包含儲存、處理或傳輸持卡人資料或機密驗證資料的人員、程序和技術。在 GKE 中，CDE 亦包括以下內容：

• 提供安全防護服務的系統 (例如，IAM)。
• 利於區隔的系統 (例如專案、資料夾、防火牆、虛擬私人雲端 (VPC) 和子網路)。
• 儲存、處理或傳輸持卡人資料的應用程式 pod 和叢集。如果沒有適當的區隔，您的整個雲端空間可能都會屬於 PCI DSS 的適用範圍。

若要讓系統元件不在 PCI DSS 的適用範圍內，必須將系統元件與 CDE 作適當的區隔，使適用範圍外的系統元件即使遭駭，也不會影響 CDE 的安全性。

要縮減 CDE 的適用範圍前，重要的前提是要先明確瞭解持卡人資料在儲存、處理和傳輸方面的相關業務要求和程序。若要透過消除不必要的資料並整合必要的資料，將持卡人的資料限制在最少的位置，可能會需要重新設計長期實施的業務做法。

您可以透過Google Cloud上的多種方式，為 CDE 劃分適當區隔。本節將說明下列方式：

• 使用資源階層結構進行邏輯區隔
• 使用虛擬私人雲端和子網路進行網路區隔
• 使用虛擬私人雲端進行服務層級區隔
• 適用範圍內任何叢集的其他注意事項

使用資源階層結構進行邏輯區隔

您可以透過以下幾種方式使用 Google Cloud的資源階層在機構架構中區隔 CDE。Google Cloud 資源會以階層方式組織。機構資源是 Google Cloud 資源階層中的根節點。資料夾和專案都屬於機構資源之下。資料夾中可包含專案或資料夾。 透過資料夾層級的身分與存取權管理權限，資料夾可用於控管資料夾階層結構的資源存取權，亦可用來將類似的專案集合在一起。專案是所有資源以及身分與存取權管理之強制執行點的信任界線。

您可以將 PCI 適用範圍內的所有專案集合在一個資料夾中，以在資料夾層級進行區隔。您也可以為所有適用範圍內的 PCI 叢集和應用程式使用單一專案，或是為適用範圍內的每個 PCI 應用程式各建立一個專案和叢集，並使用這些項目來整理Google Cloud 資源。無論如何，我們都建議您將適用範圍內和範圍外的工作負載分別放在不同的專案中。

使用虛擬私人雲端網路與子網路進行網路區隔

您可以使用虛擬私有雲 (VPC) 和子網路來佈建網路，將 CDE 相關資源集合在一起，或加以區隔。虛擬私人雲端是透過邏輯隔離的公用雲端區段。虛擬私有雲網路為 Compute Engine 虛擬機器 (VM) 執行個體以及使用 VM 執行個體的服務 (包括 GKE) 提供可擴充且靈活的網路。如需瞭解詳情，請查看虛擬私人雲端總覽，並參閱最佳做法與參考架構的相關說明。

使用 VPC Service Controls 和 Google Cloud Armor 進行服務層級區隔

虛擬私有雲和子網路可提供區隔與範圍建立功能，用於隔離 CDE，而 VPC Service Controls 則能增強第 7 層的安全範圍。您可以使用 VPC Service Controls 為適用範圍的 CDE 專案建立範圍。 VPC Service Controls 提供以下控管功能：

• 輸入控管。只有經授權的身分和用戶端能進入安全範圍。
• 輸出控管。安全範圍內的身分和用戶端僅允許使用經過授權的目的地。

您可以使用 Google Cloud Armor 建立 IP 位址清單，以在 Google Cloud 網路邊緣允許或拒絕 IP 位址對 HTTP(S) 負載平衡器進行存取。在盡量靠近使用者和惡意流量的位置檢查 IP 位址，有助於防止惡意流量消耗資源或進入您的虛擬私人雲端網路。

使用 VPC Service Controls 定義適用範圍內專案的服務範圍。此範圍控管 VM 對服務和服務對服務的路徑，以及虛擬私人雲端的輸入和輸出流量。

建構並維護安全的網路和系統

建構安全的網路並維護其安全涵蓋了 PCI DSS 的要求 1 和 2。

要求 1

安裝並維護防火牆設定以保護持卡人資料以及進出 CDE 的流量。

容器和 GKE 的網路概念與傳統 VM 的網路概念不同。Pod 無需 NAT 即可彼此直接連線，即使式跨節點亦可。如此便可建立一個簡單的網路拓撲，如果您習慣管理更複雜的系統，可能會對此感到驚訝。GKE 網路安全的第一步是瞭解這些網路概念。

在深入研究「要求 1」下的各個要求之前，您可能需要查看以下與 GKE 相關的網路概念：

• 防火牆規則。 防火牆規則用於限制節點的流量。GKE 節點是以 Compute Engine 執行個體形式進行佈建，並使用與其他執行個體相同的防火牆機制。您可以在您的網路中使用標記，將這些防火牆規則套用於每個執行個體。每個節點集區都會收到一組可在規則中使用的標記。根據預設，節點集區中的每個執行個體都會收到一個標記，該標記代表此節點集區所屬的特定 GKE 叢集。此標記用於 GKE 自動建立的防火牆規則。您可以使用 Google Cloud CLI 中的 --tags 標記，在建立叢集或節點集區時新增自訂標記。

• 網路政策。網路政策可讓您限制 pod 間的網路連線，以便在 pod 發生安全性問題時，限制叢集內的網路跳板攻擊和水平擴散。如要使用網路政策，必須在建立 GKE 叢集時明確啟用該功能。您可以在現有叢集上啟用，但是這會導致叢集節點重新啟動。根據預設，所有 pod 對 pod 通訊都一律是開放的。因此，如果要區隔網路，則需要執行 pod 層級網路政策。在 GKE 中，您可以使用 Kubernetes Network Policy API 或 kubectl 工具來定義網路政策。這類 Pod 層級流量政策的規則會決定同一叢集內的哪些 pod 和服務可以互相存取。

• 命名空間。命名空間提供在 Kubernetes 叢集內部進行資源區隔的功能。Kubernetes 具有立即可用的預設命名空間，但您也可以在叢集內建立多個命名空間。命名空間在邏輯上彼此隔離。命名空間為叢集中的 Pod、服務和部署限定範圍，因此與某個命名空間進行互動的使用者無法看到另一個命名空間中的內容。不過，若命名空間皆位在同一叢集，命名空間之間的通訊則不受限制；這時網路政策就可以派上用場。如要進一步瞭解如何設定命名空間，請參閱網誌文章「命名空間最佳做法」的相關說明。

下圖說明前述概念彼此之間，以及與其他 GKE 元件 (如叢集、節點與 pod) 之間的關係。

要求 1.1

定義並瞭解安裝及維護網路安全控管機制的程序和機制。

要求 1.1.2

說明用於管理網路元件的群組、角色和責任。

首先，就像在 Google Cloud上的大多數服務一樣，您需要設定 IAM 角色，才能在 GKE 上設定授權。設定 IAM 角色後，還需要新增 Kubernetes 角色型存取權控管 (RBAC) 設定做為 Kubernetes 授權策略的一部分。

基本上，所有身分與存取權管理設定都適用於專案中的任何 Google Cloud 資源和所有叢集。Kubernetes RBAC 設定適用於每個 Kubernetes 叢集中的資源，並在命名空間層級提供精細的授權機制。使用 GKE，這些授權方式可以平行運作，且使用者的權限可有效表示指派給他們的身分與存取權管理和 RBAC 角色的聯集：

• 使用 IAM 控管群組、角色和責任，以對 GKE 中的網路元件進行邏輯管理。
• 使用 Kubernetes RBAC 對 Kubernetes 叢集中的網路政策授予更精細的權限，以控制 pod 對 pod 的流量，並防止非 CDE 使用者進行未經授權或意外的變更。
• 能夠為所有身分與存取權管理和 RBAC 使用者與權限提供正當理由。 通常在 QSA 測試控管情形時，他們會選擇部分身分與存取權管理和 RBAC 的使用者和權限做為樣本，然後查看這些樣本是否有正當的業務理由。

要求 1.2

設定及維護網路安全控管機制 (NSC)。

首先，在執行 GKE 節點的 Compute Engine 執行個體上設定防火牆規則。防火牆規則能保護這些叢集節點。

接下來，您需要設定網路政策，以限制流量並保護叢集中的 pod。網路政策規範 pod 群在那些情形下，允許與彼此及其他網路端點進行通訊。您可以使用 GKE 的強制執行網路政策來控制叢集的 pod 和服務之間的通訊。如要進一步區隔叢集，請在其中建立多個命名空間。 命名空間在邏輯上彼此隔離。命名空間為叢集中的 Pod、服務和部署項目限定範圍，因此與某個命名空間進行互動的使用者無法看到另一個命名空間中的內容。不過，若命名空間皆位在同一叢集，命名空間之間的通訊則不受限制；這時網路政策就可以派上用場。命名空間允許在 Kubernetes 叢集內部進行資源區隔。如要進一步瞭解如何設定命名空間，請參閱網誌文章「命名空間最佳做法」的相關說明。

根據預設設定，如果命名空間中沒有定義政策，系統就會允許所有輸入和輸出流量進出該命名空間中的 pod。例如，您可以建立選取所有 pod 但不允許輸入流量進入這些 pod 的網路政策，為命名空間建立預設的隔離政策。

要求 1.2.2

所有網路連線和 NSC 設定的變更，都會根據「需求 6.5.1」中定義的變更控管程序進行核准和管理。

如要將網路設定和基礎架構視為程式碼，您需要建立一個持續整合和持續推送軟體更新 (CI/CD) 的管道，做為管理變更和控制變更程序的一部分。

您可以使用 Cloud Deployment Manager 或 Terraform 範本做為持續整合/持續推送軟體更新管道的一部分，在叢集上建立網路政策。使用 Deployment Manager 或 Terraform，即可將設定和基礎架構視為程式碼，複製出與目前實際工作環境或其他環境一致的副本。之後，您便可以撰寫單元測試和其他測試，確保您的網路變更能夠依照預期執行。控制變更的程序若包含核准，可以透過版本存放區中儲存的設定檔來管理。

您可以使用 Terraform Config Validator 來定義強制執行安全性和管理政策的限制。透過新增 Config Validator 到持續整合/持續推送軟體更新管道，您可以在任何工作程序中新增步驟。此步驟會驗證 Terraform 方案，並在發現違反情形時加以拒絕。

要求 1.2.5

所有允許的服務、通訊協定和通訊埠都會經過識別、核准，並有明確的業務需求。

為了對 GKE 叢集執行強力的輸入控管，您可以使用授權網路來限制能夠連線到叢集控制層的某些 IP 範圍。GKE 使用傳輸層安全標準 (TLS) 和驗證機制，以確保從公開網際網路存取叢集控制層端點的安全，此存取方式可讓您自由選擇要從哪個位置來管理叢集。您可以透過授權網路進一步限制特定 IP 位址組合的存取權。

您可以使用 Google Cloud Armor 為 GKE 託管應用程式建立 IP 拒絕清單、允許清單及安全性政策。在 GKE 叢集中，HTTP(S) 負載平衡會處理傳入流量。HTTP(S) 負載平衡是 Cloud Load Balancing 的元件。HTTP(S) 負載平衡器通常是由 GKE Ingress 控制器設定，該控制器會從 Kubernetes Ingress 物件取得設定資訊。詳情請參閱如何使用 GKE 設定 Google Cloud Armor 政策。

要求 1.3

限制持卡人資料環境的網路存取權。

為了使機密資料保持為私密狀態，您可以使用 VPC Service Controls 和私人 Google 存取權，在虛擬私人雲端網路中的 GKE 叢集與內部部署混合型部署項目之間設定私人通訊。

要求 1.3.1

請考慮使用 GKE 實作 Cloud NAT 設定，將內送網際網路流量限制在該叢集。您可以為 CDE 中的非公開叢集設定私人叢集。在私人叢集中，節點僅擁有內部 RFC 1918 IP 位址，這是為了確保其工作負載能與公開網際網路環境隔離。

要求 1.4

信任和不信任網路之間的網路連線會受到控管。

您可以使用在「規定 1.3」中列出的相同方法來處理這項規定。

要求 1.4.3

實施反假冒措施，以偵測並阻止來源 IP 位址經過假冒的流量進入信任的網路。

您可以在 GKE pod 和叢集上使用別名 IP 位址來實施反假冒措施，以偵測並阻止來源 IP 位址經過假冒的流量進入網路。使用別名 IP 範圍的叢集稱為虛擬私有雲原生叢集。

要求 1.4.5

只有經過授權的對象才能揭露內部 IP 位址和轉送資訊。

您可以使用 GKE IP 偽裝代理程式進行網路位址轉譯 (NAT)，在叢集上進行多對一 IP 位址轉譯。偽裝功能可將多個來源 IP 位址隱藏在一個位址後面。

要求 2

為所有系統元件套用安全設定。

要求 2 指示如何透過移除預設值和服務供應商提供的憑證來強化安全性參數。 強化叢集是客戶的責任。

要求 2.2

要求 2.2.4

只啟用必要的服務、通訊協定、Daemon 和函式，並移除或停用所有不必要的功能。

要求 2.2.5

要求 2.2.6

設定系統安全性參數，以防濫用。

預先部署作業

在將容器移到 GKE 上之前，我們建議您採取下列做法：

• 以容器代管基本映像檔開始，該映像檔須經由可信任來源建構、維護及進行安全漏洞檢查。考慮建立一組「已知良好」或「最佳」基本映像檔供開發人員使用。如要選擇更嚴格的方式則是使用 distroless 映像檔或暫存基本映像檔。
• 使用 Artifact Analysis 掃描容器映像檔，檢查是否有安全漏洞。
• 建立內部開發運作/安全性運作政策，僅將已核准的可信任程式庫和二進位檔包含在容器中。

設定作業

在設定過程中，我們建議您採取下列做法：

• 使用預設的 Container-Optimized OS 做為 GKE 的節點映像檔。Container-Optimized OS 是以 Chromium OS 為基礎，且已經過節點安全性的最佳化處理。
• 為執行應用程式的叢集啟用自動升級節點功能。此功能會自動將節點升級為在代管控制層中執行的 Kubernetes 版本，進而提供更良好的穩定性和安全性。
• 啟用自動修復節點功能。 啟用此功能後，GKE 會定期檢查節點的健康狀態，並根據節點的健康狀態來決定是否需要修復節點。 如果節點需要進行修復，該節點就會進行清空，且系統會建立新節點並將其加入到叢集中。
• 開啟 Cloud Monitoring 與 Cloud Logging 以查看所有事件，包括安全性事件和節點健康狀態。建立 Cloud Monitoring 快訊政策，以便在發生安全性事件時收到通知。
• 為 GKE 節點使用最低權限服務帳戶
• 檢閱 Google Cloud CIS 基準指南中的 GKE 章節，並在適合時應用。Kubernetes 稽核記錄已預設為啟用，且對於 kubectl 和 GKE API 要求的記錄皆已寫入 Cloud 稽核記錄。
• 設定稽核記錄。

保護帳戶資料

保護持卡人資料涵蓋了 PCI DSS 的要求 3 和 4。

要求 3

保護儲存的帳戶資料

PCI DSS 的要求 3 規定，保護技術 (例如加密、截斷、遮蓋和雜湊) 是保護持卡人資料的關鍵元件。如果入侵者繞過其他安全性控管機制並取得加密資料的存取權，在沒有適當加密編譯金鑰的情況下，將無法讀取和使用該資料。

建議您考慮採用其他方法保護儲存的資料，以緩解潛在的風險。舉例來說，將風險降到最低的方法包括：除非絕對必要，否則不儲存持卡人的資料；如果不需要完整的 PAN，則截斷持卡人資料；不使用使用者通訊技術 (例如電子郵件和即時通訊) 傳送未受保護的 PAN。

在 Google Cloud 上執行時，CHD 可能會因為是付款處理流程的一部分，而持續存在於系統中。範例如下：

• Cloud Storage 值區
• BigQuery 執行個體
• Datastore
• Cloud SQL

請注意，CHD 可能會在無意間儲存於電子郵件或客戶服務通訊記錄中。建議您使用機密資料保護功能篩選這些資料串流，將適用範圍內的環境限制為付款處理系統。

請注意，在 Google Cloud上，資料預設會在靜態時進行資料加密，且預設會在通過實體界限時進行傳輸加密。不需要額外的設定即會啟用這些保護措施。

要求 3.5

無論主帳號 (PAN) 儲存在何處，都會受到保護。

要將 PAN 資料轉譯為無法讀取的其中一種機制是代碼化。詳情請參閱根據 PCI DSS 的規定將機密性質的持卡人資料代碼化解決方案指南。

您可以使用 DLP API 來掃描、搜尋及回報持卡人資料。Sensitive Data Protection 內建掃描和分類功能，可處理 Cloud Storage、BigQuery 和 Datastore 中的 12 至 19 位數 PAN 資料，並提供串流內容 API 來支援其他資料來源、自訂工作負載和應用程式。您也可以使用 DLP API 來截斷 (遮蓋) 或雜湊資料。

要求 3.6

用於保護儲存帳戶資料的密碼編譯金鑰已加以保護。

Cloud Key Management Service (KMS) 是加密編譯金鑰的代管儲存系統。此系統可以產生、使用、輪替及摧毀加密編譯金鑰。雖然 Cloud KMS 不會直接儲存 Secret (例如持卡人資料)，但可以將其用於加密此類資料。

Kubernetes 中的 Secret 是可讓您儲存及管理機密資訊 (如密碼、憑證和金鑰) 的 Kubernetes 密鑰物件。

根據預設， Google Cloud 會加密靜態儲存的客戶內容。GKE 會處理及管理這項預設的加密作業，您不需要另行操作。應用程式層 Secret 加密針對機密資料 (例如 Secret) 提供額外一層安全防護。有了這項功能，您就可以提供您在 Cloud KMS 中管理的金鑰，在應用程式層將資料加密，藉此防範成功存取叢集的 Kubernetes 設定儲存執行個體副本的攻擊者。

要求 4

在開放的公開網路上進行傳輸時，使用高強度密碼編譯保護持卡人資料。

適用範圍內的資料在通過容易遭惡意人士存取的網路 (例如公開網路) 進行傳輸時必須加密。

Istio 是開放原始碼的服務網格，可以透明地堆疊到現有的分散式應用程式上。Istio 採可調度資源的做法來管理微服務之間的驗證作業、授權作業以及流量加密作業。此為包含 API 的平台，可讓您整合到任何記錄平台、遙測或政策系統中。Istio 的功能組合讓您可以高效率地執行分散式微服務架構，並提供統一的方式來保護、連線和監控微服務。

要求 4.1

定義並記錄在開放的公開網路上傳輸時，使用高強度密碼編譯保護持卡人資料的程序和機制。

您可以使用 Istio 來建立已部署服務的網路，並讓該網路包括負載平衡、服務對服務驗證和監控功能。您還可以使用 Istio 在叢集中提供安全的服務對服務通訊，並在該通訊中使用以雙向傳輸層安全標準 (TLS) 為基礎的高強度身分驗證及授權機制。雙向傳輸層安全標準 (mTLS) 會執行傳輸層安全標準 (TLS) 握手兩次，以雙向建立相同的信任層級 (與用戶端對伺服器的單向信任不同)。

Istio 可讓您將傳輸層安全標準 (TLS) 憑證部署到應用程式內的每個 GKE pod。在 pod 上執行的服務可以使用 mTLS 明顯地辨識其對等身分。服務對服務的通訊是透過用戶端和伺服器端的 Envoy Proxy 建立通道。Envoy 使用 SPIFFE ID 在服務間建立 mTLS 連線。如要瞭解如何在 GKE 上部署 Istio，請參閱 GKE 說明文件。如要瞭解支援的傳輸層安全標準 (TLS) 版本，請參閱 Istio 流量管理參考資料。使用傳輸層安全標準 (TLS) 1.2 以上版本。

如果您的應用程式在網際網路上公開，請使用 GKE HTTP(S) 負載平衡，並將輸入轉送設為使用 HTTP(S)。Ingress 物件設定的 HTTP(S) 負載平衡包括以下功能：

• 彈性的服務設定。Ingress 物件定義流量如何到達您的服務，以及流量如何轉送到您的應用程式。此外，Ingress 可以為叢集中的多個服務提供單一 IP 位址。
• 與 Google Cloud 網路服務整合。Ingress 物件可以設定 Google Cloud 功能，例如 Google 代管的 SSL 憑證 (Beta 版)、Google Cloud Armor、Cloud CDN 和 Identity-Aware Proxy。
• 支援多個傳輸層安全標準 (TLS) 憑證。Ingress 物件可以指定使用多個傳輸層安全標準 (TLS) 憑證來進行要求終止。

建立 Ingress 物件時，GKE 輸入控制器會根據 Ingress 中的資訊及相關聯的 Service 建立 Cloud HTTP(S) 負載平衡器，並進行設定。

維護安全漏洞管理計畫

維護安全漏洞管理計畫涵蓋了 PCI DSS 的要求 5 和 6。

要求 5

保護所有系統和網路，防範惡意軟體。

PCI DSS 的要求 5 規定，必須在所有經常使用防毒軟體，以保護系統免受現有且不斷變化的惡意軟體威脅所影響，容器也不例外。

要求 5.2

系統會防範惡意軟體 (malware)，或偵測並處理惡意軟體。

您必須為容器映像檔實施漏洞管理計畫。

建議您採取以下行動：

• 定期檢查並在容器上套用最新的安全性修補程式。
• 定期對容器化應用程式和二進位檔/程式庫執行安全漏洞掃描。
• 在建構管道時掃描映像檔。
• 訂閱安全漏洞情報服務，以接收與容器中使用的環境和程式庫相關的最新安全漏洞資訊。

Google Cloud 與多個容器安全性解決方案供應商合作，以改善客戶 Google Cloud 部署項目內的安全防護。我們建議您利用經驗證的安全性解決方案和技術來提升 GKE 環境中的防禦深度。如需通過Google Cloud驗證的最新資安合作夥伴清單，請參閱「安全性合作夥伴」一文。

要求 5.2.2

要求 5.2.3

有許多解決方案可執行惡意軟體掃描，但 PCI DSS 瞭解並非所有系統都同樣容易受到攻擊。商家通常會宣稱自己的 Linux 伺服器、大型主機和類似機器並非「經常受到惡意軟體影響」，因此豁免於 5.2.2。這種情況則適用 5.2.3，而且您必須實作一個定期威脅評估的系統。

提醒您，這些規則 GKE 叢集中的節點和 pod 皆適用。

要求 5.3

啟用、維護及監控防惡意軟體機制和程序。

要求 5.2、5.3 和 11.5 要求適用範圍內的主機都需執行防毒掃描和檔案完整性監控 (FIM)。我們建議實施相關的解決方案，其中所有節點都可由叢集中受信任的代理程式掃描，或每個節點都有可回報至單一管理端點的掃描程序。

詳情請參閱 GKE 安全性總覽和 Container-Optimized OS 安全性總覽。

防毒和 FIM 要求常見的解決方案是鎖定容器，僅允許特定資料夾具有寫入權限。如要這麼做，您必須以非超級使用者身分的執行容器，並使用檔案系統權限來防止對容器檔案系統中工作目錄以外的所有項目進行寫入。禁止權限提升，以避免規避檔案系統規則。

要求 6

開發並維護安全的系統和軟體。

PCI DSS 的要求 6 規定須建立健全的軟體開發生命週期，並在軟體開發的每個步驟中建構安全性。

要求 6.2

開發客製化和自訂軟體時，會採用安全的開發方式。

要求 6.2.1

您可以使用二進位授權來確保僅有可信任的容器會部署到 GKE。如果您只想啟用由一或多個特定驗證者授權的映像檔，則可設定二進位授權以實施政策，制定根據安全漏洞掃描結果進行認證的規則。您也可以編寫政策，要求映像檔在由一或多個受信任對象 (稱為「驗證者」) 核准後才能進行部署。對於映像檔會經過開發、測試到實際工作環境叢集等階段的多階段部署管道，您可以使用驗證者來確保軟體在進入下一階段前已完成所有必要的程序。

在部署時，二進位授權會檢查容器映像檔是否通過所有必要的限制，藉此實施您的政策，這些限制包含所有必要的驗證者皆已驗證映像檔已可進行部署。如果映像檔通過檢查，則該服務會允許其部署作業。 否則，部署作業會遭到封鎖，且映像檔必須待其符合規定才能進行部署。

如要進一步瞭解二進位授權，請參閱「為 GKE 設定」一文。

在緊急情況下，您可以使用急用權限工作流程略過二進位授權政策。所有急用權限事件都會記錄在 Cloud 稽核記錄中。

GKE Sandbox 可降低容器與主機直接互動的需求，縮減主機遭駭時的攻擊範圍，並能限制惡意攻擊的移動路徑。

要求 6.3

找出安全漏洞並加以解決。

要求 6.3.1

雲端安全性是雲端服務供應商與客戶需共同承擔的責任。

在 GKE 中，Google 負責管理控制層，其中包括主要 VM、API 伺服器以及在這些 VM 上執行的其他元件，還有 etcd 資料庫。這包括升級和修補、資源調度和修復，這些都是由服務等級目標 (SLO) 所支援。對於節點的作業系統，例如 Container-Optimized OS 或 Ubuntu，GKE 會及時提供這些映像檔的任何修補程式。如果啟用自動升級功能，則會自動部署這些修補程式。(此為容器的基礎層，與容器中執行的作業系統不同。)

如要進一步瞭解 GKE 的共同責任模式，請參閱探索容器安全性：GKE 的共同責任模式的相關說明。

Google 提供多種安全性服務，可幫助您在持續整合/持續推送軟體更新管道中建構安全性措施。如要找出容器映像檔中的安全漏洞，可使用 Google Artifact Analysis Vulnerability Scanning。將容器映像檔推送到 Google Container Registry (GCR) 時，安全漏洞掃描功能會自動掃描映像檔，藉此找出來自已知 CVE 來源的已知安全漏洞與弱點。系統會根據 CVSS 分數為安全漏洞指派嚴重程度 (嚴重、高、中、低和最低)。

要求 6.4

對外公開的網頁應用程式可防範攻擊。

網路安全掃描工具可掃描公開的 App Engine、Compute Engine 和 GKE 網路應用程式，找出從跨網站指令碼、設定錯誤到易受攻擊的資源等常見安全性漏洞。掃描可以依需求執行，並在 Google Cloud 控制台進行排程。您可以使用 Security Scanner API，在應用程式建構管道中將掃描自動化，成為安全性測試套件的一部分。

實施健全的存取權控管措施

實施健全的存取權控管措施涵蓋了 PCI DSS 的要求 7、8 和 9。

要求 7

將系統元件和持卡人資料的存取權限制為僅有業務上需要的人員可存取。

要求 7 著重在「最低權限」或「有知情必要」的部分。PCI DSS 將此定義為授予最小資料量的存取權，以及提供執行作業所需的最小權限。

要求 7.2

適當定義及指派系統元件和資料的存取權。

IAM 與 Kubernetes 角色型存取控制 (RBAC) 互相搭配運作，為您的 GKE 環境提供精細的存取權控管。IAM 用於管理 CDE 專案中的Google Cloud 資源使用者存取權和權限。在 GKE 中，您也可以使用 IAM 來管理使用者和服務帳戶在您叢集中的存取權，以及可以執行的操作，例如建立和刪除叢集。

Kubernetes RBAC 則能夠設定精細的權限集，藉此定義特定的 Google Cloud 使用者、 Google Cloud服務帳戶或使用者群組 (Google 網路論壇) 能如何與叢集中或叢集特定命名空間中的 Kubernetes 物件進行互動。RBAC 權限的範例包括編輯部署項目或 configmap、刪除 pod 或查看 pod 的記錄。您會授予使用者或服務有限的身分與存取權管理權限，例如 Google Kubernetes Engine 叢集檢視者或自訂角色，然後依需要套用 Kubernetes RBAC RoleBindings。

Cloud Identity Aware Proxy (IAP) 可透過 GKE 的輸入整合，讓您控制員工或需要存取 PCI 應用程式之人員的應用程式層級存取權。

此外，您可以使用機構政策來限制專案中可用的 API 和服務。

要求 7.2.2

除了確保使用者和服務帳戶遵守最低權限原則外，容器也應比照辦理。執行容器的最佳做法是使用非超級使用者執行程序。您可以使用 PodSecurity 許可控制器來實現並強制執行此做法。

PodSecurity 是 Kubernetes 許可控制器，可讓您將 Pod 安全性標準套用至在 GKE 叢集中執行的 Pod。Pod 安全性標準是預先定義的安全性政策，涵蓋 Kubernetes 中 Pod 安全性的高層需求。這些政策的嚴格程度從寬鬆到嚴格都有。PodSecurity 取代了 Kubernetes 1.25 版中移除的舊版 PodSecurityPolicy 許可控制器。您可以參考操作說明，將 PodSecurityPolicy 改用 PodSecurity 許可控制器。

要求 8

識別使用者，並驗證對系統元件的存取權

要求 8 規定，必須為有權限存取適用範圍內 PCI 系統的每個人指派唯一的識別碼，以確保每個人對自己的行為都個別負責。

要求 8.2

在整個帳戶生命週期中，我們都會嚴格管理使用者和管理員的使用者身分和相關帳戶。

要求 8.2.1

為所有使用者指派專屬 ID 之後，才允許他們存取系統元件或持卡人資料。

要求 8.2.5

系統會立即撤銷已終止使用者的存取權。

IAM 和 Kubernetes RBAC 均可用來控管 GKE 叢集的存取權，您也可以使用這兩種方式為使用者授予權限。我們建議將使用者綁定至您現有的身分識別系統，以在同個位置管理使用者帳戶和政策。

要求 8.3

建立並管理使用者和管理員的完善驗證機制。

要求 8.3.1

在使用者向 kubectl 驗證後，憑證會綁定至使用者的身分。所有 GKE 叢集都已設定為接受 Google Cloud 使用者和服務帳戶的識別資訊，方法是驗證憑證並擷取與使用者或服務帳戶身分相關的電子郵件地址。因此，這些帳戶的憑證必須包含 userinfo.email OAuth 範圍，才能順利通過驗證。

要求 9

限制持卡人資料所在地點的實際進出權限。

Google 負責構成Google Cloud基礎之所有 Google 資料中心的實體安全控管。

定期監控及測試網路

定期監控及測試網路涵蓋了 PCI DSS 的要求 10 和 11。

要求 10

記錄並監控所有系統元件和持卡人資料的存取。

要求 10.2

稽核記錄可協助偵測異常和可疑活動，並對事件進行鑑識分析。

Kubernetes 叢集預設會啟用 Kubernetes 稽核記錄功能，依時間順序記錄對 Kubernetes API 伺服器做出的呼叫。Kubernetes 稽核記錄項目適合用於調查可疑的 API 要求、收集統計資料，或是針對不想要的 API 呼叫建立監控快訊。

GKE 叢集的 GKE 稽核記錄預設設定是 Cloud 稽核記錄 及 Logging 的整合。您可以在 Google Cloud 專案中看到 Kubernetes 稽核記錄項目。

專案的稽核記錄不只有 Kubernetes 寫入的項目，也會有 GKE 寫入的項目。

為了區分 CDE 和 非 CDE 工作負載，我們建議您在 GKE pod 中加入標籤，過濾這些工作負載所產生的指標和記錄。

要求 10.2.2

Logging 中的每個稽核記錄項目都是 LogEntry 類型的物件，包含下列欄位：

• 屬於 protoPayload 類型的酬載。每個稽核記錄項目的酬載都是 AuditLog 類型的物件。使用者身分儲存在 AuditLog 物件的 AuthenticationInfo 欄位中。
• 特定事件，位於 AuditLog 的 methodName 欄位。
• 時間戳記。
• 事件狀態，位於 AuditLog 物件的 response 物件中。
• 作業要求，位於 AuditLog 物件的 request 與 requestMetadata 物件中。
• 即將執行的服務，位於 serviceData 的 AuditData 物件中。

要求 11

定期測試系統和網路的安全性。

要求 11.3

我們會定期找出內部和外部安全漏洞，並依優先順序處理。

要求 11.3.1

容器分析安全漏洞掃描會針對 Container Registry 中的映像檔執行下列類型的安全漏洞掃描：

• 初始掃描。首次啟動 Artifact Analysis API 時，Artifact Analysis API 會掃描 Container Registry 中的映像檔，然後擷取映像檔的套件管理員、映像檔基礎和安全漏洞例項。

• 增量掃描。將新的映像檔上傳至 Container Registry 時，Artifact Analysis 會掃描這些映像檔。

• 持續分析：Artifact Analysis 收到來自安全漏洞來源的全新和更新安全漏洞資訊時，就會重新執行容器分析，確保已掃描映像檔的安全漏洞例項清單維持在最新狀態。

要求 11.5

偵測到網路入侵和非預期的檔案變更後，會採取回應措施。

要求 11.5.1

Google Cloud 封包鏡像可搭配 Cloud IDS 使用，用於偵測網路入侵。 Google Cloud 封包鏡像會將 Compute Engine VM 或 Google Cloud 叢集的所有網路流量轉送至指定位址。Cloud IDS 可使用這類鏡像流量，偵測各種威脅，包括利用企圖、通訊埠掃描、緩衝區溢位、通訊協定片段化、指令與控制 (C2) 流量，以及惡意軟體。

Security Command Center 讓您能集中檢視整個機構中Google Cloud 服務 (包括 GKE) 和資產的安全性狀態，可更輕鬆地預防、偵測和回應威脅。透過 Security Command Center，您可以根據 Cloud Logging 記錄，查看系統何時偵測到高風險威脅，例如惡意軟體、挖礦獲取加密貨幣、未經授權存取資源、向外發動分散式阻斷服務攻擊、通訊埠掃描和 SSH 暴力攻擊。 Google Cloud

維護資安政策

健全的安全性政策制定安全性基調，並告知相關人員應盡的責任。在這裡「人員」是指可存取您 CDE 的全職和兼職員工、臨時員工、約聘人員和顧問。

要求 12

透過組織政策和方案維護資訊安全。

如要瞭解要求 12 的相關資訊，請參閱 Google Cloud PCI 共同責任表。

正在清除所用資源

如果您在按照本文操作時使用了任何資源 (例如，啟用新的 VM 或使用 Terraform 指令碼)，則可以刪除使用這些資源的專案來避免 Google Cloud 帳戶產生費用。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

後續步驟

• 進一步瞭解 PCI 資料安全標準法規遵循。
• 試用 Terraform 入門套件。
• 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。