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