本文說明如何設計雲端環境，以符合支付卡產業 (PCI) 安全標準委員會的規範。如果貴機構要遷移或設計雲端系統，且這些系統須符合 PCI 規範，本文的最佳做法將有助於您達成目標。本文會視情況參照 PCI DSS 4.0 規定。
瞭解 PCI DSS 評估範圍
如果貴機構透過網際網路進行商務活動，就必須支援並維持 PCI 法規遵循。您設計及管理雲端環境的方式，會影響系統在支付卡產業資料安全標準 (DSS) 評估中的範圍。範圍對 IT 資產的安全性，以及您支援和維持 PCI 法規遵循的能力，都有重要影響。為確保 PCI 環境範圍正確無誤，您必須瞭解業務流程和設計決策對範圍的影響。
什麼是範圍？
所有儲存、處理或傳輸持卡人資料 (CHD) 的系統，都屬於 PCI DSS 評估範圍。安全性對整個雲端環境至關重要，但如果範圍內的系統遭到入侵，可能會導致資料侵害，並暴露 CHD。
在圖 1 中，持卡人資料環境 (CDE)、連線系統和影響安全性的系統位於評估範圍界線內，而不受信任和超出範圍的系統則位於評估範圍界線外。
根據 PCI DSS，適用範圍內的系統是「受信任」的系統，包括 CDE，以及與 CDE 連線或可能影響 CDE 安全性的任何系統。
如果系統位於相同網路、共用資料庫或檔案儲存空間，或以其他方式存取/連線至 CDE 內的任何系統或程序，但無法直接存取 CHD，則該系統為「已連線至」。
如果系統遭到入侵，攻擊者就能存取 CDE，這類系統就是會影響安全的系統。所有連線系統和會影響安全性的系統，一律屬於範圍內。
根據 PCI DSS 的定義，適用範圍外的系統不受信任，對於想要存取 CHD 或機密驗證資料 (SAD) 的攻擊者來說，毫無價值。如果系統不會影響適用範圍內系統的安全性，即使遭到入侵，也屬於適用範圍外。雖然適用範圍外的系統不會直接受到評估，但 PCI 認證安全評估人員 (QSA) 會驗證您的範圍是否準確，並確保您根據 PCI DSS 保護 CHD。因此，請務必嚴密保護範圍界線，持續徹底監控，並清楚記錄。
PCI 環境中的連線
多項 PCI DSS 規定都提到「連線」，但 PCI DSS 並未明確定義連線。如要解讀這個情境中的連線意義，請參閱 PCI SSC 指南，瞭解 PCI DSS 範圍和網路區隔 (PDF) 中的範圍決策樹狀圖。
為評估 PCI 範圍，連線定義如下：
- 連接兩部電腦或系統的有效資訊傳輸
- 通話是由哪一方發起
記錄環境時，最好清楚指出授權啟動連線的當事人。如果防火牆設定為只允許單向流量，就能強制執行單向連線。舉例來說，如果符合下列所有條件，範圍內的付款處理應用程式就能查詢範圍外的資料庫伺服器，而範圍外的伺服器不會進入範圍：
- 連線和範圍外資料庫不會儲存、處理或傳輸 CHD 或 SAD。
- 資料庫位於不同網路，或與 CDE 分割。
- 資料庫無法直接或間接發起任何 CDE 呼叫。
- 資料庫不會為 CDE 提供安全防護服務。
- 資料庫不會影響 CDE 的設定或安全性。
- 資料庫支援 PCI DSS 規範。
下圖顯示決定系統範圍的因素：
在圖 2 中，系統範圍的決定方式如下：
屬於 PCI DSS 適用範圍的系統元件：
- CDE 中的系統，且符合下列其中一項條件：
- 系統元件儲存、處理或傳輸 CHD 或 SAD。
- 系統元件與儲存、處理或傳輸 CHD 的系統位於同一網路區段，例如同一子網路或 VLAN。
- 與下列系統連線或對其安全性造成影響的系統，且符合下列其中一項條件：
- 系統元件直接連線至 CDE。
- 系統元件會影響 CDE 的設定或安全性。
- 系統元件會將 CDE 系統與適用範圍外的系統和網路區隔開來。
- 系統元件間接連線至 CDE。
- 系統元件會為 CDE 提供安全防護服務。
- 系統元件支援 PCI DSS 規範。
- CDE 中的系統，且符合下列其中一項條件：
如果所有下列條件都成立，系統元件可視為不受信任，且不在 PCI DSS 適用範圍內：
- 系統元件不會儲存、處理或傳輸 CHD 或 SAD。
- 系統元件與儲存、處理或傳輸 CHD 或 SAD 的系統，並非位於相同的網路區隔 (例如相同的子網路或 VLAN)。
- 系統元件無法連線至 CDE 中的任何系統。
- 系統元件不符合任何與連線或安全影響系統相關的條件。
適用範圍外的系統可能包括連線至連線或安全影響系統元件的系統，其中設有控管措施，可防止適用範圍外的系統使用適用範圍內的系統元件存取 CDE。
就實務而言，如果適當實作並記錄區隔，PCI DSS 對系統範圍的定義可能表示網路應用程式的會話儲存空間和電子商務資料庫可能符合適用範圍外的資格。下圖顯示適用範圍內的系統和適用範圍外的系統之間的讀取和寫入連線運作方式：
圖 3 顯示下列連線：
- 唯讀：
- 範圍內的付款處理應用程式會從範圍外的購物車資料庫讀取購物車 ID，並從 DNS 和 NTP 讀取資料。
- 僅供寫入：
- 範圍內的付款處理應用程式會寫入範圍外的應用程式主資料庫和 Cloud Logging。
- 範圍外的主要網頁應用程式會將資料寫入記錄服務。這類資料不包括 CHD 或 SAD。
- 讀取及寫入：
- 公用網路上的使用者讀取及寫入要求中繼資料的方式如下：
- 使用者讀取及寫入適用範圍內的付款處理應用程式。這項要求中繼資料是購物車 ID 和購物車驗證金鑰，內含 CHD 和 SAD。
- 使用者讀取及寫入範圍外的網頁應用程式。這項要求中繼資料是不含 CHD 或 SAD 的工作階段 ID。
- 範圍外的主要網路應用程式會讀取資料，並將資料寫入範圍外的購物車資料庫、工作階段儲存區和應用程式主要資料庫。這類資料不包含 CHD 或 SAD。
- 符合規範的付款處理應用程式會讀取及寫入符合規範的卡片權杖化服務，以及公用網路上的信用卡處理器。這類資料包括 CHD 和 SAD。
- 公用網路上的使用者讀取及寫入要求中繼資料的方式如下：
圖 3 中的架構說明瞭兩個獨立的網頁應用程式：主要網頁應用程式 (主要應用程式)，不在 PCI 範圍內；以及付款處理應用程式 (結帳應用程式)，在 PCI 範圍內。在這個架構中，只有在上述清單所述的方向，才能在兩個實體之間啟動連線。從呼叫端的角度來看，實體之間的連結可以是唯讀、讀寫或僅供寫入。凡是未明確說明的路徑或要求方向，都會遭到區隔封鎖。舉例來說，付款處理應用程式可以從購物車資料庫讀取資料，並寫入記錄服務，這需要啟動與這些實體的連線。
範圍內的系統通常會呼叫範圍外的系統和服務。由於區隔機制會防止任何遠端呼叫端 (持卡人除外) 直接或間接啟動 CDE 連線，因此這些連線仍維持安全。圖 3 顯示，結帳應用程式的唯一進入路徑是使用者。
在圖 3 中，沒有任何超出範圍的服務或應用程式提供任何設定或安全資料給付款處理應用程式。資料在架構中流動的方式如下：
- 主要應用程式會將使用者轉送至結帳應用程式，並使用 HTTP
POST傳輸CartID和名為CartAuthKey的驗證器。CartAuthKey是CartID的雜湊值，以及只有主要和結帳應用程式知道的預先共用密鑰。 - 結帳應用程式會將
CartID與密鑰一起雜湊處理，然後將該值與CartAuthKey進行比較，藉此驗證使用者。 - 使用者資料通過驗證後，系統會使用
CartID從購物車資料庫讀取購物車內容。所有持卡人資料都會直接從使用者傳送至結帳應用程式。 - 如果使用付款資料，持卡人資料會儲存在權杖化服務中。
- 付款程序完成後，系統會使用僅供寫入的資料庫服務帳戶，將結果插入主要應用程式的資料庫。
範圍考量事項
在「PCI DSS 適用範圍和網路區隔指南」中，PCI 安全標準委員會 (SSC) 建議您假設所有項目都在適用範圍內，直到經過驗證為止。這項 SSC 建議並非指您應盡可能擴大適用範圍，而是指 QSA 會評估所有系統是否值得信任，除非您能證明系統與 CDE 沒有連線能力，或不會對 CDE 的安全性造成影響。為符合法規遵循規定並確保 IT 資產安全，您應根據最小權限原則劃定環境範圍，盡可能減少信任的系統。
在評估前，請先評估環境，瞭解並記錄範圍內和範圍外系統之間的界線。QSA 的首要工作是確認您記錄的範圍合理涵蓋 CDE 和連線系統。在整體評估過程中，QSA 接著會驗證範圍外系統是否會對任何範圍內系統造成負面影響。
請務必瞭解環境的任何特殊情況，例如：
- 如果您透過電話或 VoIP 系統收集持卡人資料，請考量「保護電話付款卡資料 (PDF)」中說明的其他範圍問題。
- 如果服務供應商需要存取 CDE (PDF)，才能操作銷售點系統，則服務供應商使用的系統可能會視為連線系統。這可能需要額外考量範圍和盡職調查。
Google 的安全最佳做法有助於您在範圍內和不受信任的系統之間，建立並展示明確且可防禦的界線，協助您進行評估。當您遵循最小權限原則管理存取權和安全性時，有助於盡可能減少持卡人資料的暴露點數量、縮小 CDE 的攻擊面，進而縮減範圍。當您縮減範圍內系統的足跡時，有助於降低系統複雜度，並簡化 PCI DSS 評估。
範圍不正確的風險
範圍過於廣泛可能會導致評估成本高昂，並增加法規遵循風險。為縮小範圍，請盡可能減少信任的系統，並只授予少數指定使用者存取權。透過認真評估和自我評估，您可以找出不應納入 PCI DSS 範圍的系統，確認這些系統符合適用範圍外系統的指南，並據此縮減範圍。這種排除程序是找出不受信任系統的最安全方法，有助於確保這些系統不會影響範圍內的系統。
如果您需要龐大的基礎架構足跡才能符合 PCI DSS 規定，可能會導致評估範圍納入多餘的系統。如果範圍內包含無關的系統，您可能無法達成法規遵循要求。此外，如果擴大受信任範圍內環境的攻擊面，也可能導致整體資安態勢惡化。
網路安全和 PCI DSS 的核心原則是假設部分或所有網路都已遭入侵。這項原則已納入 Google 的零信任安全模型，該模型捨棄僅限於周邊的安全防護，改為由每個系統負責保護自身安全。Google 的安全模式符合 PCI DSS 規定，建議您將 CDE 和連線系統部署在與更廣泛的 IT 環境區隔開來的小型可信空間，且不要與 IT 環境混用。
在 PCI 範圍內的環境中，請勿將 CDE 放在具有廣大周邊的大型信任空間。這麼做可能會產生錯誤的安全感，並破壞全方位的縱深防禦策略。如果攻擊者突破了邊界安全防護，就能在受信任的私人內部網路中輕鬆運作。請考慮如何縮緊信任空間，只保留運作和保護自身安全所需的項目，並避免完全依賴周邊安全措施。瞭解並遵循這些原則，有助於設計雲端環境，確保重要系統安全，並降低遭入侵系統污染的風險。
如果受評估環境中包含大量受信任的系統，就需要同樣龐大的管理機制，才能持續監控、維護、稽核及清查這些系統。系統架構、變更管理程序和存取控制政策的複雜性，可能會造成安全和法規遵循風險。如果難以維護這些監控程序，就可能難以符合 PCI DSS 要求 10 和 11。請務必瞭解這些風險，並實施策略來限制受評估環境的範圍。詳情請參閱本文稍後的「支援持續法規遵循」一節。
Google Cloud 屬於 PCI DSS 適用範圍的服務
開始縮減 PCI 環境範圍前，請先瞭解哪些 Google Cloud 服務屬於 PCI DSS 適用範圍。這些服務提供的基礎架構可供您打造自己的服務或應用程式，以儲存、處理或傳輸持卡人資料。
縮減範圍的策略
本節將討論下列縮減評估範圍的策略：資源階層控制項、VPC Service Controls 分段和權杖化。建議您採用所有這些策略，盡可能縮減範圍，而非只選擇其中一種做法。
PCI 範圍界定沒有通用解決方案。您可能已在內部部署網路中進行區隔，或使用卡片處理解決方案，因此基礎架構設計可能與本文所述略有不同。您可以將這些策略做為原則，套用至自己的環境。
建立資源階層控制項
Google Cloud 資源會以階層方式整理，如下所示：
- 機構資源是 Google Cloud 資源階層結構中的根節點。機構資源包含資料夾和專案資源。套用於機構資源的身分與存取權管理 (IAM)存取控管政策，也會套用於該機構中整個階層的所有資源。
- 資料夾可包含專案和其他資料夾，並使用資料夾層級的 IAM 權限控管資源存取權。資料夾通常用於將類似的專案分組。
- 專案是所有資源的信任邊界，也是 IAM 強制執行點。
如要縮小評估範圍，請按照 Google 的最佳做法定義資源階層。下圖為符合 PCI 標準的資源階層範例：
如圖 4 所示，PCI 適用範圍內的所有專案都集合在一個資料夾中，以在資料夾層級進行區隔。PCI 範圍內的資料夾包含 CDE，以及包含共用服務的另一個專案。實作類似的資源階層時，PCI 範圍內的資料夾會形成 PCI 法規遵循範圍的邏輯根目錄。確保只有指定使用者能存取這個資料夾和其中的專案，即可將階層中的其他資料夾、專案和資源排除在評估範圍之外。
視需要授予使用者存取權，確保只有指定使用者能存取範圍內的元件，有助於符合 PCI DSS 7.2 和 7.3 規定 (PDF) 等要求。如要確保父項機構和資料夾的權限設定正確無誤，請瞭解政策繼承的影響。如要符合 PCI DSS 8.4.1 規定，請務必為指定使用者實作兩步驟驗證，並參閱 PCI DSS 補充文件，瞭解多重驗證的相關指引 (PDF)。如要在資源階層中強制執行法規遵循，請務必瞭解如何設定機構政策限制。這些限制有助於持續確保法規遵循，並防範可信環境發生權限提升。
與所有 PCI 法規遵循一樣，您必須充分記錄及監控環境和範圍內元件，才能建立明確的範圍界線。資源階層與身分和存取權管理密不可分，因此必須有效記錄、稽核及監控使用者動作，才能強制執行並維持分離狀態。
實作網路區隔
網路區隔是重要的架構模式，有助於保護 CDE 和連線系統的安全，如 PCI SSC 網路區隔補充指南 (PDF) 所述。如果實作得當，網路區隔可移除不受信任的系統可能用來存取 CDE 或其連線元件的網路路徑，縮小評估範圍。只定義允許信任元件之間通訊所需的路徑。如果不可信的系統沒有路徑可供傳送或接收來自可信系統的封包，則不可信的系統不在適用範圍內，不會影響適用範圍內元件的安全性。
如要實作網路區隔，請將 CDE 放在專屬的虛擬私有雲 (VPC) 中，並啟用 VPC Service Controls。請在自訂模式中建立這個 VPC，確保不會建立多餘的子網路或路徑，以免預設存取權開放給信任的網路。實作機構政策限制，確保這個 VPC 無法與其他專案共用，且只能與其他信任的網路對等互連。
下圖顯示網路區隔策略與資源階層的密切關係。這張圖假設資源階層結構中，適用範圍內的 PCI 環境只有一個資料夾，且該資料夾中有兩個專案，分別用於 CDE 和共用服務。
在圖 5 中，共用服務專案不屬於 CDE，但它是「已連線至」的系統，因此屬於 PCI 範圍。負載平衡器和防火牆規則或防火牆政策會在網路層級限制 CDE 的存取權，以保護這些網路並符合 PCI DSS 1.2 和 1.3 規定。權杖化系統和付款系統位於不同的子網路，兩者之間的通訊受各子網路的防火牆規則控管，只允許必要的通訊。符合 PCI DSS 10.2、10.4 和 10.5 規定的必要記錄、監控和警報功能位於不同的專案。共用服務和 CDE 位於 VPC Service Controls 安全性 perimeter 內，可防範 IAM 存取控制項遭到意外誤設或入侵。
如果您的部署作業是在 Google Kubernetes Engine (GKE) 上進行，您還可以透過下列方式區隔 CDE，並保護持卡人資料免於不受信任的系統存取：
- 命名空間提供額外的存取控管隔離層，使用者只能存取 Kubernetes 叢集內的特定 Pod、服務和部署作業。這項功能有助於為指定使用者提供更精細的存取權。
- 網路政策可將 Pod 和服務彼此隔離，限制資料流動，並在叢集內提供額外的網路區隔層。
- PodSecurity 是 Kubernetes 許可控制器，可讓您將 Pod 安全性標準套用至 GKE 叢集上執行的 Pod。
這些層級都是縱深防禦安全態勢的重要環節，有助於進一步隔離及保護受信任的元件，避免受到周遭環境影響，進而縮小範圍。如果您使用 Kubernetes 部署 CDE 的全部或部分內容，請進一步瞭解如何在 GKE 上執行符合 PCI 規範的環境。
導入權杖化
代碼化是指不可逆地遮蓋主帳號 (PAN) 的程序。代碼化的 PAN (或稱「代碼」) 無法透過數學方式兌換成 PAN。PCI SSC 在代碼化指南補充文件 (PDF) 的第 3 章中，提供代碼化範圍影響的相關指引。PCI DSS 範圍會受到儲存及傳輸持卡人資料的元件組合影響。如果實作得當，代碼化可減少主帳號的出現和傳輸次數，有助於縮小評估範圍。
權杖化也是一種資料流分段形式，因為它會將儲存及傳輸持卡人資料的系統，與只能使用權杖執行作業的系統分開。舉例來說，分析消費者活動以偵測詐欺的系統可能不需要 PAN，而是使用權杖化資料執行這類分析。權杖化也會在儲存及傳輸 PAN 的系統與電子商務網頁應用程式之間，新增一層分隔。如果您的網頁應用程式只與使用權杖的系統互動，網頁應用程式可能會從已連線系統的集合中移除，進而縮小範圍。
下圖說明典型的代碼化系統如何處理信用卡號、PAN 和代碼化資料：
如圖 6 所示，系統會接收使用者提供的 PAN 和其他持卡人資料，然後立即傳送至權杖化服務。權杖化服務會加密 PAN、產生權杖，然後將兩者儲存在安全的權杖保管庫中。只有指定的服務 (例如結算服務) 才能存取網路上的保管庫，並獲授權使用產生的權杖兌換 PAN。結算服務只會使用 PAN 將其傳送至付款處理器。PAN 和任何其他持卡人資料都不會出現在這個嚴格控管的資料流程之外。為落實縱深防禦策略，架構也採用敏感資料保護，進一步防範 PAN 或其他持卡人資料意外洩漏。
如圖 6 所示，權杖化系統會使用嚴密保護的密碼儲存空間 Hashicorp Vault，管理 PAN 對應權杖的關係。只有獲得授權的使用者和服務，才能透過查詢程序從權杖兌換 PAN。獲得權杖儲存空間存取授權的元件，可以取得時間受限的存取權，因此元件只能在執行功能所需的特定時間範圍內兌換 PAN。視業務需求而定，其他資料儲存庫也可能適用。如要進一步瞭解如何在環境中安全地實作權杖化，請參閱「Tokenizing sensitive cardholder data for PCI DSS」(為 PCI DSS 權杖化持卡人機密資料)。
架構範例
下圖說明處理代碼化交易的範例架構，其中使用 Pub/Sub 和 Dataflow，並將代碼化交易記錄儲存在 Spanner 中。
在圖 7 中，交易處理專案是「已連線至」系統，因此屬於 PCI 範圍。由於交易處理專案中任何元件遭入侵，都不會讓攻擊者存取 CHD，因此不屬於「安全性影響」專案。網頁應用程式專案不在範圍內，因為該專案不會連線至 CDE，只會與經過清除的資料互動。
權杖化資料會從 CDE 傳送至 Pub/Sub。權杖化資料發布至其他訂閱者之前，Sensitive Data Protection 會先驗證資料是否含有 CHD。權杖化資料會由 Dataflow 處理，並儲存在 Spanner 交易資料庫中。交易可透過權杖與特定使用者建立關聯，不必存取 PAN。Spanner 交易資料庫也可用於使用商業智慧 (BI) 工具 (例如 Looker) 進行報表製作和分析。
支援持續法規遵循
資安和法規遵循不只是正確的架構和良好的工程設計。正確的架構可證明您的環境在理論上是安全設計。您也需要有效的稽核、記錄、監控和補救程序，才能確保環境實際保持安全。
為確保符合 PCI DSS 的 12 項要求類別，您必須持續監控這些要求的實作情況，並向自己和評估人員證明，在 PCI DSS 評估完成後，任何適用範圍內的元件都會維持安全。適當的監督搭配快速的補救措施，就是所謂的持續法規遵循。持續法規遵循是 PCI DSS 的要求，如果實作得當，有助於盡可能發揮其他範圍縮減策略的效果。
Google Cloud 可讓您使用防火牆規則記錄、虛擬私有雲流量記錄、VPC Service Controls 記錄和 Cloud Load Balancing 記錄，記錄網路中發生的所有事件。您可以使用 Cloud 稽核記錄 監控系統和使用者活動。定期監控這些記錄有助於遵守 PCI DSS 10.4 號規定，並快速回應及修正潛在的安全威脅。詳情請參閱這份 PDF 檔案，瞭解如何有效監控每日記錄 (PCI DSS 補充文件)。
Security Command Center 提供資產清點、探索、搜尋和管理功能，協助您瞭解安全性和資料受攻擊面。Security Command Center 可以分析 Sensitive Data Protection 掃描結果，協助找出外洩的持卡人資料，並驗證權杖化系統是否遭到濫用，惡意兌換 PAN。使用 Event Threat Detection，Security Command Center 可協助您主動偵測網路和 VM 中的威脅和異常活動，這可能表示攻擊者正在探查系統，以瞭解防禦能力。Security Command Center 也可讓您建立專屬環境的自訂安全來源。
Google Cloud Armor 可為公開的網頁應用程式提供額外保護，並協助您遵守 PCI DSS 6.4 規定。Cloud Armor 會評估各種常見網路攻擊的傳入要求，協助您避免 6.4 規定中耗時的手動程式碼審查。有了網頁應用程式防火牆，您就能持續維持合規狀態，同時降低持續合規成本和風險。 Google Cloud
後續步驟
- 查看管理法規遵循義務的最佳做法。
- 請參閱「PCI 資料安全標準法規遵循 Google Cloud」。
- PCI 委員會的 PCI DSS 範圍和網路區隔指南 (PDF)。
- 試用 PCI on GKE 藍圖。
- 保護 Kubernetes 工作負載，確保符合 PCI DSS 規定。
- 根據 PCI DSS 的規定，將機密性質的持卡人資料代碼化。
- 部署 PCI 入門 Terraform 專案。
- 查看 Google Cloud 的參考架構、圖表和最佳做法。 歡迎瀏覽我們的 Cloud Architecture Center。