This guide helps you learn how to implement the Payment Card Industry Data Security Standard (PCI DSS) for your business on Google Cloud. The guide goes beyond the PCI SSC Cloud Computing Guidelines (PDF) to provide background about the standard, explain your role in cloud-based compliance, and then give you the guidelines to design, deploy, and configure a payment-processing app using PCI DSS. The tutorial also discusses methods for monitoring, logging, and validating your app.
This document refers to the PCI DSS 4.0 requirements where applicable.
The PCI Data Security Standard, created by the PCI Security Standards Council, is an information security standard for businesses that handle payment card (both credit and debit) information. The PCI Security Standards Council includes every major payment card company. Businesses that take Visa, MasterCard, Discover, American Express, JCB, or UnionPay are expected to comply with PCI DSS, and they can be fined or penalized if they don't.
PCI DSS includes classifications for several merchant types, from merchants that collect payment information in person to merchants that outsource payment processing entirely. This guide covers the SAQ A, SAQ A-EP, and SAQ D merchant types.
Objectives
- Review the payment-processing app architecture.
- Set up your payment-processing environment.
- Deploy and configure your app servers.
- Set up logging and monitoring.
- Validate your payment-processing environment.
Definitions
This guide uses many unique phrases. Here are several of the most common. For more information, refer to the PCI DSS glossary.
CDE: Acronym for cardholder data environment. This acronym refers to any part of your app that holds or transfers any cardholder data, including the payment account number or any personally identifiable information related to the card.
Compensating controls: Alternative solutions that can be considered if an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints. Entities must sufficiently mitigate the risk associated with the requirement when they implement these other controls. See "Compensating Controls" Appendixes B and C in PCI DSS Requirements and Security Assessment Procedures for guidance on the use of compensating controls.
PAN: Acronym for primary account number and also referred to as an account number. It is the unique payment card number that identifies the issuer and the cardholder account.
QSA: Acronym for Qualified Security Assessor. QSAs are qualified by the PCI Security Standards Council (SSC) to perform PCI DSS on-site assessments. The Qualification Requirements for Qualified Security Assessors (QSA) provides details about requirements for QSA companies and employees.
SAQ: Acronym for Self-Assessment Questionnaire, the reporting tool that is used to document self-assessment results from an entity's PCI DSS assessment. This only applies for entities that are eligible for self-assessment.
Scope: The systems, procedures, and people to be included in a PCI DSS assessment.
Tokenization: A process that replaces the primary account number (PAN) with a surrogate value called a token. The PAN is then stored in a secure lookup. De-tokenization is the reverse process of looking up a PAN by its token. A token can either be a hash or an assigned value.
Background
PCI DSS provides a list of requirements designed to enhance cardholder security. These requirements are divided into twelve major numbered parts and many subparts. This document references these part numbers to add context, but the section references are not an exhaustive list of applicable requirements.
Your PCI DSS compliance requirements vary depending on how your company handles payment card transactions (type) and how many transactions it performs each year (level).
As your number of transactions increases, your PCI DSS merchant level increases, and the PCI DSS compliance guidelines become stricter. At the highest merchant level, Level 1, PCI DSS requires an audit. Levels vary by the card brand. Level 1 is defined by American Express as 2.5 million annual transactions, and by Visa, Mastercard, and Discover as 6 million annual transactions. Each card brand has additional level requirements that are beyond the scope of this document. Ensure that your payment-processing environment is audited to support your merchant level.
Because Google Cloud is a Level 1 PCI DSS 4.0–compliant service provider, it can support your PCI DSS compliance needs no matter what your company's merchant level is. The Committed to compliance section lays out which areas are covered for you by Google.
The other fundamental variable is your SAQ type. The SAQ outlines criteria that you must address to comply with PCI DSS if you are eligible for self-assessment. Your SAQ type is determined by your app architecture and the precise way you handle payment card data. Most merchants in the cloud are one of the following:
| SAQ type | Description |
|---|---|
| A | Merchants that have fully outsourced payment card processing to a
third-party site. Customers leave your domain (including through an
<iframe> web form), complete payment, and then return to your
app.In other words, your company can't touch customer card data in any way. |
| A-EP | Merchants that outsource payment processing to a third-party provider, but
who can access customer card data at any point in the process. Merchants
that can access card data include merchant-controlled page elements such as
JavaScript or CSS that are embedded in the third-party payment page. In other words, your payment processing app forwards card data to a processor on the client side, or the processor renders any content hosted by you. |
| D | Merchants that accept payments online and don't qualify for SAQ A or
SAQ A-EP. This type includes all merchants that call a payment processor
API from their own servers, regardless of tokenization. In other words, if you are not SAQ A or SAQ A-EP, you are SAQ D. SAQ D differentiates between merchants and service providers. Service providers are not discussed in this document, and all SAQ D references address merchants as defined in PCI DSS. |
Committed to compliance
Google uses a variety of technologies and processes to secure information that is stored on Google servers. Google independently validated PCI DSS requirements that apply to Google Cloud technologies and infrastructure that are managed by Google. You can download Google's PCI DSS compliance reports from Compliance Reports Manager. While Google offers merchants a great deal of control over their compute instances that run on Google infrastructure, Google doesn't control security for the operating system, packages, or apps that merchants deploy on Google Cloud. It is your responsibility to comply with PCI DSS requirements for operating system packages and apps that you deploy, in addition to other customizations required by your architecture.
Google Cloud follows the PCI DSS requirements set forth for a Level 1 Service Provider and all applicable service provider requirements. The Google Cloud Shared Responsibility Matrix outlines the compliance obligations of PCI DSS. The responsibility matrix can be a helpful reference as you pursue PCI DSS compliance and conduct your own PCI DSS audits.
Product guidance
This section contains guidance for commonly-used Google Cloud services in architectures used for PCI DSS environments.
App Engine
Use App Engine ingress firewall rules and egress traffic controls.
Cloud Run
Use Cloud Run ingress settings, VPC Service Controls, and egress controls on VPC connectors. If needed, configure a static outbound IP address.
Cloud Run functions
Use Cloud Run functions ingress and egress network settings.
Cloud Logging
Log interactions with Cloud Logging.
Cloud Monitoring
Monitor interactions with Cloud Monitoring.
Google Kubernetes Engine
For information about using Google Kubernetes Engine for PCI DSS environments, see PCI DSS compliance on GKE.
Cloud Storage
Requirement 3.5 stipulates that a primary account number (PAN) is secured wherever 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.
Example architectures
This section illustrates the approaches to implementing an environment that complies with SAQ A, SAQ A-EP, and SAQ D.
Architecture overview
SAQ A
SAQ A is the most basic payment-processing architecture. Payments are processed by a third party, and no card data is accessed by merchant apps or pages.
At a high level, the payment-processing flow is as follows:
The customer makes their selections and proceeds to check out.
The checkout app redirects the customer to a third-party payment processor.
The customer enters their payment card information into a payment form that the third-party processor owns and maintains.
The third-party payment processor checks the payment card information and then charges or declines the card.
After processing the transaction, the third-party payment processor sends the customer back to the merchant app along with transaction details.
The merchant app sends a verification request to the payment processor to confirm the transaction.
The payment processor responds to verify the transaction details.
SAQ A-EP
The SAQ A-EP payment-processing architecture is centered around a payment-processing app that runs on Compute Engine virtual machine instances. These instances are in a secure private network, and they use secure channels to communicate with services that are outside the network.
At a high level, the payment-processing flow is as follows:
The customer enters their payment card information into a payment form that your company owns and maintains.
When the customer submits their information, the form information is securely passed on to a third-party payment processor.
The third-party payment processor checks the payment card information and then charges or declines the card.
The payment processor sends a response back to your payment app, which then passes a message to your core app.
All of these interactions are logged and monitored with Cloud Logging and Cloud Monitoring.
SAQ D
The SAQ D payment–processing architecture centers around a payment-processing app that runs on Compute Engine virtual machine instances. These instances are in a secure private network and use secure channels to communicate with services that are outside the network.
At a high level, the payment-processing flow is as follows:
The customer enters their payment card information into a payment form that your company owns and maintains.
When the customer submits their information, your payment app receives the form information.
Your payment app validates the payment information and securely passes it on to a third-party payment processor through a backend API.
The third-party payment processor checks the payment card information and then charges or declines the card.
The payment processor sends a response back to your payment app, which then passes a message to your core app.
All of these interactions are logged and monitored with Logging and Monitoring.
Payment processing customer-facing flow
SAQ A
This section describes the third-party payment processing flow from the perspective of the customers using your app.
When your customer accesses your payment form, the app presents an
<iframe> hosted by the payment processor. Your
app cannot access or monitor the contents of the
<iframe> because of
cross-origin resource sharing limitations.
When the customer submits their payment card information, the payment
processor accepts or declines the card, then sends the customer back to your
app. Your app then checks the transaction response from the
payment processor and acts accordingly. Your app didn't access or
handle any payment card information.
SAQ A-EP
This section describes the same internal payment processing flow as previously described, but from the perspective of the customers using your app.
When your customer accesses the URL for your payment form, the site presents a form hosted by your payment app. When the customer submits their payment card information, the form goes directly to the payment processor. The processor accepts or declines the card, then sends the customer back to your app. Your app then checks the transaction response from the payment processor and acts accordingly. The customer might not see the third-party payment processor, but your app didn't access any payment card information on the server side.
SAQ D
This section describes the internal payment processing flow from the perspective of the customers using your app.
When your customer accesses the URL for your payment form, they are securely routed to the form through an HTTPS load balancer. When the customer submits their payment card information, your payment-processing app securely sends the information to a third-party payment processor. The third-party payment processor accepts or declines the card, then returns a response to your payment-processing app.
Payment-processing internal flow
SAQ A & A-EP
This section describes the payment-processing flow from the perspective of the servers running your app.
Your payment-processing app receives and parses the response returned by the third-party payment processor, and then sends some or all of the response data to the core app. At this point, your payment-processing app is finished with the transaction. The core app handles the task of notifying your customers.
SAQ D
This section describes the internal payment processing flow from the perspective of the servers running your app.
Your payment-processing app validates the payment card information submitted by the customer, and then sends it to the payment processor through a backend API. The processor attempts the charge and responds with transaction details. Your app receives and processes the response and then sends some or all of the response data to the core app. At this point, your payment-processing app is finished with the transaction. The core app handles the task of notifying your customer and delivering product.
Monitoring and logging data flow
The monitoring and logging flow is designed as follows:
Setting up your payment-processing environment
This section describes how to set up your payment-processing environment. Setup includes the following:
- Creating a new Google Cloud account to isolate your payment-processing environment from your production environment.
- Restricting access to your environment.
- Setting up your virtual resources.
- Designing the base Linux image that you will use to set up your app servers.
- Implementing a secure package management solution.
Setting up a new account
To simplify access restriction and compliance auditing, create a production-quality, payment-processing environment that is fully isolated from your standard production environment and any dev and QA environments (requirement 6.5.3). To ensure isolation, create and use a Google Cloud account that is separate from your core production environment account. Users experienced with Identity and Access Management (IAM) configuration can accomplish equivalent isolation by using separate projects for in-scope work.
Restricting access to your environment
Allow payment-processing environment access only to individuals who deploy your payment system code or manage your payment system machines (section 7.2 and requirement 8.2.1). This is known as the principle of least privilege. Use IAM roles to restrict access. Best practices include using roles wherever possible, granting only the permissions required to perform expected work, and only granting the Owner role to principals who legitimately need full root access to your services. Refer to the IAM security guide for more information.
Automated access to any managed service should rely on service accounts. Service accounts simplify the app management lifecycle by giving you a way to manage app authentication and authorization. These accounts give you a flexible, yet secure way to group virtual machine instances with similar apps and functions that have a common identity. You can enforce security and access control at the service-account level through IAM roles and VPC firewall rules.
IAM rules that you apply to folders are inherited by all items contained in that folder. Default permissions are deny-all (requirement 7.2.3), and every rule that you apply only adds permissions.
Requirement 8.3.6 provides some basic rules for user passwords. The National Institute of Standards and Technology (NIST) defines a more secure set of rules for secure passwords in section 5.1.1 of NIST SP800-63B. Google recommends following the NIST Digital Identity guidelines whenever possible.
PCI DSS SAQ D section 12.7 requires individuals with access to your in-scope environment to pass a background check, in compliance with local laws, before they are granted access to the environment. To reduce the risk of compliance violations, consider performing these criminal background checks and reference checks on each individual regardless of your compliance type.
Securing your network
To secure inbound and outbound traffic to and from your payment-processing app network, you need to create the following:
- Cloud Next Generation Firewall policies or Compute Engine firewall rules
- A Cloud VPN tunnel
- An External Application Load Balancer
For creating your VPC, we also recommend Cloud NAT for an additional layer of network security. There are many powerful options available to secure networks of both Compute Engine and GKE instances.
Creating firewall rules
Use Cloud Next Generation Firewall policies or VPC firewall rules to restrict inbound traffic to each of your Compute Engine instances (requirements 1.3 and 1.4). Allow inbound traffic only from the following three sources:
- Public HTTPS, so that customers can reach your payment page.
- Your app network, so that your payment-processing app can receive responses from your third-party payment processor.
- Your internal office network, so that you can access the instances for auditing and management purposes.
Use firewall rules on individual instances to restrict outbound traffic. You can implement these rules locally with iptables or, more broadly, by using VPC firewall rules and network tags. Allow outbound traffic only from your payments form to the third-party payment processor. This connection must be HTTPS-only. To test your work, see the section on Firewall Rules Logging later in this document.
Cloud DNS offers private DNS zones so you can securely name hosts within your CDE without the potential of leaking sensitive network topology data to the public.
Restrict traffic as follows:
| Source | Destination | Port | Direction and reason |
|---|---|---|---|
| Public load balancer | Third-party payments form | tcp:443 | Inbound Public access to the payment-processing app |
| Third-party payment form | Third-party payment processor | tcp:443 | Outbound Forwarding AUTH requests to payment service provider |
| Third-party payment processor | Your payment-processing app | tcp:5480 | Inbound Accepting AUTH requests from payment systems (does not contain any cardholder data) |
| Your company's office network | vpn-gateway | tcp:8000 | Inbound Access to payment-processing environment for access to logs and development machines |
In addition, the following traffic occurs securely in your payment-processing app internal network:
| Source | Destination | Port | Reason |
|---|---|---|---|
| Card form | PCI proxy | tcp:5480 | Exchange of encrypted card data for payment instrument token |
| All hosts | Google NTP servers | udp:123 | Time synchronization |
| VPN gateway | All hosts | tcp:22 | Secure Shell (SSH) connections |
Establishing a secure VPN tunnel
You can use Cloud VPN to establish a secure VPN tunnel between your on-premises environment and your payment-processing environment (sections 2.2.7 and 4.2).
Creating an External Application Load Balancer
You can help ensure that incoming customer traffic is secure by creating an external Application Load Balancer (sections 2.2.7 and 4.2). To create an external Application Load Balancer, you need the following:
- A subdomain of your website that is used for your payment processing
form, for example,
payments.your-domain-name.com. - A valid, signed SSL certificate that has been registered for your subdomain.
Ensure that your domain is valid by looking at its DNS settings in your web registrar domain configuration interface.
Creating a base Linux image
The PCI DSS contains requirements that describe how to set up machines that are part of a compliant payment-processing architecture. You can implement these requirements in several ways, but the easiest approach is as follows:
Create a list of the software and libraries that must be installed on each server that is in scope for your payment-processing app. To avoid introducing unnecessary vulnerabilities to your system (requirement 2.2.4), include only the minimum of software and libraries that you need to run your app. Candidates might include the Google Cloud CLI, language-specific runtimes and libraries, or a web server.
Create a Compute Engine instance that uses one of the Compute Engine preconfigured operating system images.
Install the libraries and software you listed earlier.
Install and configure
ntpto keep system clocks in sync. Managing server clocks with the Network Time Protocol ensures the integrity of timestamps in logs (section 10.6).Ensure that the image follows the best practices for creating a secure Compute Engine image (all of section 2.2).
After you've configured your base image, create a custom Compute Engine disk image from your image. This image lets you use your base Linux image when you create virtual machine instances.
Using secure package management
Package management is a key component of a security-hardened hosting environment. Per section 2.2, you must implement industry-accepted hardening standards. Unless you use Container-Optimized OS from Google, you likely have a package manager installed such as RPM, Yum, or Apt. Your app might use its own programming language-specific package manager such as NPM, PyPi, or Composer, and download dependencies upon first run.
If your app can fetch updates from the internet, you must treat update sources as a potential security risk. Supply-side, or upstream attacks, that are maliciously included in publicly hosted packages are becoming more common. Imagine the effects of installing an update to SSH that contains malicious code.
You can mitigate the risk of supply-side attacks by creating a safe recipients list for your packages and verifying that they match the list. Keep a list of tested and approved version numbers for each package that you use. Record the version number along with its hash or signature. Ensure that the package manager validates the hash or signature before installing or updating an app.
Most package management systems allow for private hosting. If possible, launch your own private package management server and only host tested and approved software. Lock down the package manager so that it cannot reach out to other servers for updates.
Ideally, your app build process fetches and validates all packages, and then creates a revision of the custom disk image that includes everything that the container needs. This way, your servers launch and scale up with no installer delay, and there is a reduced chance of random errors at launch time. You can also revisit any previous version of your app exactly as it was in production by launching its image, which can be helpful for diagnostics and forensics.
Deployment and configuration
Next, set up the deployment and configuration of your instances from your base image.
Deploying your environment
To meet the PCI DSS requirements, ensure that you're deploying the correct app every time, that you're deploying the app securely, and that you aren't installing any other software packages during the deployment. To simplify the deployment process, consider creating an automated deployment for your app by using Terraform. Terraform lets you describe your entire payment-processing environment, including its firewall rules, gateways, load balancers, and instances in code.
In an automated deployment, you must verify the integrity of the software being deployed, whether it's from a third party or it's your own. You can verify your software by running an automated hash against each package as the package is installed. After a hash is verified, you can then use an automated testing framework to run security and other tests, and to verify that the tests have passed.
Finally, when deploying Compute Engine instances, design a recovery plan in the event that your instances fail. If your window for acceptable downtime is large enough, a manual recovery plan might be sufficient; if not, you must design an automated recovery plan. See the Disaster recovery planning guide, Designing robust systems, and Building scalable and resilient web apps for guidance.
Configuring your environment
After your instances have been deployed, ensure that they're configured correctly. Install additional software and libraries on top of each instance base image as needed. To avoid the complexity, overhead, and overall risk of manual configuration, use an automated configuration management tool such as Skaffold, Chef, Puppet, Ansible, or Salt.
Implementing immutable audit logging
Logging produces audit logs automatically for a wide variety of activities across many products. Long-term, you can securely store immutable logs by using Cloud Storage bucket locks (section 10.3). Bucket locks let you set a policy to make all objects immutable and non-deletable for an amount of time that you specify, from seconds to years.
Implementing Virtual Private Cloud Flow Logs
The VPC Flow Logs service is designed to record network flows sent from or received by virtual machine instances. You can use these logs for network monitoring, forensics, and real-time security analysis (section 10.2).
Installing the Logging agent
After you set up iptables on your servers, each server logs every activity to the server's block storage. Check out the Logging pricing page for details on the free allotment and data transfer pricing. To retain these logs and to generate alerts based on suspicious activity, stream them to Logging and Monitoring by installing the Logging agent on each server (section 10.3).
Integrating an intrusion detection system
To help ensure the security of your payment-processing environment, described in section 11.5, use an intrusion detection system (IDS), so you know when bad actors try to attack the system. There are two ways to place an IDS in a payment-processing environment: place an IDS at every entry point, or install an IDS on every server.
To reduce the complexity of your environment architecture and to simplify compliance with 11.5, install an IDS on each server. After you research and choose the IDS software to use, make IDS installation part of the startup installation script for each server.
Cloud Intrusion Detection System (Cloud IDS), an intrusion detection service, provides threat detection for intrusions, malware, spyware, and command-and-control attacks on your network. Cloud IDS provides full visibility into network traffic, including both north-south and east-west traffic, letting you monitor VM-to-VM communication to detect lateral movement. You can also use Cloud IDS to simplify compliance with requirement 11.5.
IDS logs fall in the scope of PCI DSS compliance, and must be sent to Logging and Monitoring for reporting, alerting, and auditing.
Implementing Security Command Center
Security Command Center helps security teams gather data, identify threats, and respond to threats before they result in business damage or loss. It offers deep insight into app and data risk so that you can quickly mitigate threats to your cloud resources and evaluate overall health. With Security Command Center, you can view and monitor an inventory of your cloud assets, scan storage systems for sensitive data, detect common web vulnerabilities, and review access rights to your critical resources, all from a single, centralized dashboard. It can help you comply with several requirements, including sections 5 and 6.4.
Automating your app deployment
Build your configuration management tool to securely retrieve and launch the latest version of your app. Your app can be retrieved from any location, such as Cloud Storage, as long as that location is secure.
Many of the configuration management tools mentioned earlier support continuous integration and deployment (CI/CD) workflows, which can also be used to perform automated scanning (section 11.3) and to ensure that code is reviewed (requirement 6.2.3).
Capturing configuration manager logs
When setting up your configuration manager, ensure that it logs all installation details. After completing the configuration process, ensure that it delivers the logs to Logging and Monitoring.
Logging and monitoring
To ensure PCI DSS compliance under section 10, ensure that every step taken in your payment-processing environment is monitored and recorded. Every server activity on every instance must be logged, and every user action must be able to be examined at a later time.
Enabling Access Transparency
Through Access Transparency, Logging now offers near real-time logs when Google Cloud admins access your content. Cloud Audit Logs logs already provide visibility into the actions of your own admins. However, this audit trail typically excludes actions taken by your cloud provider's support or engineering team. For example, before Access Approval logging, if you opened a ticket with Google Support that required data access, it wouldn't have been tracked in Cloud Audit Logs. Access Approval closes that gap, capturing near real-time logs of manual, targeted access by either support or engineering.
Access Approval lets you explicitly approve access to your data or configurations on Google Cloud before that access occurs. Access Approval also provides insight into accesses by Google Support and Engineering.
Enabling Firewall Rules Logging
Firewall Rules Logging lets you enable logging at the individual rule level. It can record TCP and UDP connections inside a VPC for any rules you create yourself. These can be useful for auditing network access or providing early warning that the network is being used in an unapproved manner.
Using VPC Service Controls
VPC Service Controls lets you define a security perimeter around Google Cloud resources such as Cloud Storage buckets, Bigtable instances, and BigQuery datasets to constrain data in a VPC network and help mitigate data exfiltration risks (requirements 1.3.1 and 1.3.2). With VPC Service Controls, you can keep your sensitive data private as you take advantage of the fully managed storage and data processing capabilities of Google Cloud.
Setting up VPC Flow Logs
VPC Flow Logs record network traffic flows sent or received by VM instances. The logs are useful under PCI DSS for monitoring, auditing, forensics, and real-time security analysis. Each VPC network subnet can have Flow Logs enabled or disabled independently. You can minimize the amount of log data by only enabling Flow Logs on your in-scope CDE. Flow Logs, combined with egress firewall rules, enable you to limit outbound traffic to authorized endpoints in a way that is auditable and difficult to circumvent (requirements 1.2.1 and 1.3.4).
The following diagram shows how VPC Flow Logs record network traffic flows sent or received by VM instances."
If you require more detailed data than Flow Logs can provide, such as individual HTTP request logging, you can implement controls in your app or proxy outbound requests. You do this through your own reverse proxy server configured to forward access logs to Logging. For instructions on setting up a Squid proxy server on Compute Engine, see Setting up a network proxy. To avoid bottlenecks, set up at least two redundant proxy servers.
Logging internal access data
In addition to logging external threats, also monitor and log the activity of individuals who have administrator access to your payment-processing environment (section 10.2). To do this, you can log shell commands. Several open source tools can audit shell commands and send them to logging. Popular choices for this task include OSSEC or Tripwire.
Setting up monitoring alerts
Configure Monitoring to send alerts if something goes wrong in your payment-processing environment (section 10.6). Ensure that your alerts cover environmental, audit, and internal app events. Base your alerting strategy on the potential risk or attack vectors for each component of your payment-processing app. For example, trigger Monitoring alerts if your IDS detects any intrusion attempts, whether they are successful or unsuccessful. You can also use Firewall Rules Logging to trigger alerts in response to attempts to violate specific network policies.
Streaming logs to BigQuery
Optionally, you can route Logging logs to BigQuery to analyze later; see Routing and storage overview: Sinks for details. Because BigQuery is optimized to query large datasets, it is an ideal tool for large-scale logs analysis. Logging can even log directly to BigQuery for logs that require near real-time analysis (requirement 10.4.1).
Using Sensitive Data Protection to sanitize data
There are many reasons to use parts of the data contained in your in-scope app that are not themselves in scope, such as for analytics or development. Grant apps access to PCI data only after it has been sanitized with Sensitive Data Protection (requirement 6.5.1).
App security
To help secure your app, you first need to evaluate the administrator interface. You might also want to use Cloud Key Management Service.
Evaluating the administrator interface
Most ecommerce apps have their own non-console administrator interface, such as a customer service billing portal. Such a tool must have robust access controls; it must have individualized access that uses multi-factor authentication (section 8.4); and it must be instrumented with audit logging (section 10.2).
Any logs you create should answer these questions: Who did what? Where did they do it? When did they do it? According to section 2.2.7, all access to such a tool must use strong transport encryption. Use Sensitive Data Protection to filter sensitive information before displaying it in any administration tool.
Using Cloud Key Management Service (Cloud KMS)
Cloud KMS is a service that lets you manage encryption keys. It can generate, use, rotate, and destroy AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 encryption keys. Cloud KMS lets you remove plain-text passwords stored in code or config files, which simplifies compliance with sections 2.2.2, 3.6, 3.7, and 8.2.
Validating your environment
After your environment is implemented, but before any production traffic flows through it, you must have the environment validated:
- If you're a Level 1 merchant, your environment must be validated by a Qualified Security Assessor (QSA). A QSA is a firm or an individual that is approved by the PCI Security Standards Council to validate PCI environments and give the seal of approval.
- If you're a Level 2 merchant or lower, you can validate your environment by filling out the Self-Assessment Questionnaire.
What's next
- PCI DSS document library
- Explore reference architectures, diagrams, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.