GCP adheres to the PCI DSS requirements set forth for a level 1 Service Provider. GCP is required to be compliant with PCI DSS and all applicable requirements that directly apply to a service provider.
As of Nov 11, 2020 here is the list of 93 GCP services that ARE in scope for PCI DSS:
PCI examples on GCP:
PCI Requirement 1: Install and maintain a firewall configuration to protect cardholder data
PCI Requirement 2: Do not use vendor-supplied defaults
The PCI DSS contains a set of rules that describe how to set up machines that are part of a payment-processing architecture. These rules can be implemented in several ways, but Packer from Hashicorp offers an easy process to automate baking images.
Baking images helps meet requirements (and others)
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.
2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
- Base image – OS or hardened image from CIS with unnecessary packages removed
- Core – packages and libraries needed for all instances (security, monitoring, language specific packages)
- Application – application code
PCI Requirement 3: Protect stored cardholder data
PCI Requirement 3 talks about encryption at rest, there are multiple options on GCP to accomplish is
Google encrypts data at-rest by default with no configuration required by customers. In some cases, customers may want additional control over encryption for many reasons. For that reason, Google has two additional key management options. In the middle option, customers may choose to utilize customer-managed encryption keys (CMEK) using Google Cloud Key Management Service (KMS). You can define access controls to encryption keys, establish rotation policies, and gather additional logging into encryption/decryption activities. In both the default and customer-managed case, Google remains the root-of-trust for encryption/decryption activities. On the right-hand side, customers may choose to use customer-supplied encryption keys (CSEK) in some Google services, such as Google Cloud Storage, in which Google is no longer in the root of trust. Using CSEK comes with the added risk of data loss, as Google can not help you decrypt data if you lose encryption keys. Furthermore, customers do not have to choose one key management option only. You can make use of the default encryption for most of your workload, meets regulatory requirements, and add some additional control for select applications
Data Loss Prevention API can be used to sanitize PCI data
Requirement 3.4 stipulates that a PAN must be unreadable anywhere it is stored. While Google automatically offers encryption at rest, it doesn’t automatically perform the one-way hashes, truncation, or tokenization that the rules also require. Use GCS with DLP for truncation or tokenization or use KMS for strong cryptography with managed keys.
PCI Requirement 4: Encrypt transmission of cardholder data across open, public networks
PCI requirement 4 talks about encryption transmission of cardholder data across open, public networks.
By default, any data sent to a data cloud service is encrypted by default using TLS from the user to the frontend (using BoringSSL)
Once inside Google, what happens to your data?
- Google encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries not controlled by Google or on behalf of Google.
- Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.
You can also take advantage of HTTPS load balancing to encrypt incoming customer traffic. Istio can be used to secure traffic between VMs. Cloud VPC can be used to establish a secure VPN tunnel between on-premises environment and payment-processing environment.
Contact our GCP Security experts for a FREE GCP Security consultation, today!