You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs/api-platform/reference/pci-configuration-guide). info

For a customer to be PCI compliant on Apigee Edge Public Cloud, there are some actions and
processes the customer owns under the "Shared Responsibility Model." The following items should
be reviewed by customers who have purchased the PCI compliance pack and are required to be PCI
compliant. These items are self-service within Edge and need to be addressed for the customer
organization (org) to be PCI compliant. The overarching concept is "Google secures the platform,
the customer secures their data."

## Customer Responsibility Matrix


Customers should reference the
[Google Cloud Plaform: PCI DSS v4.0.1 Shared Responsibility Matrix](https://services.google.com/fh/files/misc/gcp_pci_dss_v4_responsibility_matrix.pdf)
and share it with their PCI Qualified Security Assessor when conducting their own PCI audit.

## PCI Requirements Mapping

| **[PCI Requirement](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)** | **Section** |
|---|---|
| Requirement 7: Restrict access to system components and cardholder data by business Need to Know | [Use/Authorizations](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#authorizations) |
| Requirement 3: Protect stored account data | [Data masking](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#masking) |
| Requirement 10: Log and monitor all access to system components and cardholder data | [Audit trail](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#audit) |
| Requirement 8: Identify users and authenticate access to system components | [Complex password requirements or SAML](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#passwords) |
| Requirement 11: Test security of systems and networks regularly | [Endpoint scanning](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#scanning) |
| Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks | [TLS configuration](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#tls) |
| Requirement 3: Protect stored account data | [Data storage](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#storage) |
| Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks | [Data encryption](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#encryption) |

To obtain a PCI Data Security Standard Attestation of Compliance (AOC), open a ticket with Apigee
Support or contact your Apigee sales team.

## Trace / Debug

Trace/Debug is a troubleshooting tool that allows the user to view the status and contents of
an API call as it is processed through the Apigee Message Processor. Trace and Debug are two
names for the same service but accessed through different mechanisms. Trace is the name of this
service inside of the Edge UI. Debug is the name of the same service when used through API calls.
Use of the term Trace in this document is valid for both Trace and Debug.

During a Trace session, "Data Masking" is enforced. This tool can block data from being
displayed during a Trace. See the [Data Masking](https://docs.apigee.com/api-platform/faq/pci-configuration-guide-edge-public-cloud#masking) section below.

Encrypted Key Value Maps (KVMs) may be used for PCI customers. If an encrypted KVM is in use,
Trace may still be used, but some variables will not be visible in the Trace display screen. It
is possible to take additional steps to also display these variables during a Trace.

Detailed instructions on the use of Trace are available at [Using the Trace tool](https://docs.apigee.com/api-platform/debug/using-trace-tool-0).

Details on KVMs, including encrypted KVMs, are available at [Working with key value maps](https://docs.apigee.com/api-platform/cache/key-value-maps).

## Use/Authorizations

Access to Trace is managed through the RBAC (Role-Based Access Control) system for user
accounts within Edge. Detailed instructions on using the RBAC system to give and revoke Trace
privileges are available at [Assigning roles](https://docs.apigee.com/api-platform/system-administration/understanding-roles) and [Creating custom roles in the
UI](https://docs.apigee.com/api-platform/system-administration/creating-custom-roles). Trace permissions allow the user to launch a Trace, stop a Trace, access the output from
a Trace session.

Since Trace has access to the payload of API calls (formally called the "Message Body"), it's
important to consider who has access to run a Trace. Because user management is a customer
responsibility, the granting of Trace permissions is also a customer responsibility. Apigee, as
the platform owner, does have the ability to add a user to a customer org and to assign the
privileges. This ability is only used upon customer request for support in a situation where it
appears that the customer service is failing and reviewing a Trace session is believed to provide
the best information on the root cause.

## Data masking

Data masking prevents the display of sensitive data during a Trace/Debug session only, both in
the Trace (Edge UI) and in the backend by Debug (Edge API). Details of how to set up masking are
available at [Data masking and hiding](https://docs.apigee.com/api-platform/security/data-masking).
Masking sensitive data is part of [PCI
Requirement 3 - Protect stored cardholder data](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)

Data masking does NOT prevent the data from being visible in log files, the cache, analytics,
etc. For help with data masking in logs, consider adding a regex pattern to logback.xml file.
Sensitive data should typically not be written to cache or analytics without a strong business
justification and review by customer security and legal teams.

## L1 \& L2 cache

Caching is available to PCI customers for use with non-regulated data only. Cache should not
be used for PCI Card Holder Data (CHD); it is not approved by the Apigee PCI Compliance audit as
a storage location for CHD. Per PCI guidance ([Requirement
3: Protect stored cardholder data](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)) , PCI data should be stored only in a PCI compliant
location. Use of the L1 cache will automatically use the L2 cache also. The L1 cache is "memory
only" while the L2 cache writes data to disk to synchronize across multiple L1 caches. L2 cache
is what keeps multiple Message Processors in sync within a region and globally. It is not
currently possible to have L1 cache enabled without an L2 cache behind it. The L2 cache writes
data to disk so that it can be synced to other message processors for the customer org. Because
L2 Cache writes the data to disk, use of cache for CHD or other restricted data is not
supported.

Use of cache by customers is permitted for non-CHD and other unrestricted data. **We do
not disable the cache by default for PCI customers, because some customers run both PCI and
non-PCI related API calls through a single org.** Because the capability is still enabled
for PCI customers, it is the customer's responsibility to use the service appropriately and train
their users to not use cache when PCI data is likely to be in the API call. The Apigee PCI
Compliance audit does not support CHD stored in the cache.

Detailed instructions on using the Cache are available at [Adding caching and persistence](https://docs.apigee.com/api-platform/cache/caching-edge).

## Audit trail

Customers have the ability to review the audit trail of all administrative activities
performed within the customer's org, including the use of Trace. Detailed instructions are
available [here](https://discuss.google.dev/t/apigee-edge-auditing/18020) and at [Using the Trace tool](https://docs.apigee.com/api-platform/debug/using-trace-tool-0). ([PCI
Requirement 10: Track and monitor all access to network resources and cardholder data](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf))

## Complex password requirements or SAML

Customers with specific password requirements should use SAML to meet their individual requirements.
See [Enabling SAML
Authentication for Edge](https://docs.apigee.com/api-platform/system-administration/enabling-saml-authentication-edge). Edge
also offers multi-factor authentication ([PCI
Requirement 8: Assign a unique ID to each person with computer access](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)). See [Enable
two-factor auth for your Apigee account](https://docs.apigee.com/api-platform/system-administration/enable-two-factor-auth-your-apigee-account).

## Endpoint security

### Endpoint scanning

Scanning and testing of hosts is required for PCI compliance ([Requirement
11: Regularly test security systems and processes](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)). For Edge Cloud, customers are responsible
for the scanning and testing of their API endpoints (sometimes called the "runtime components")
in Edge. Customer testing should cover the actual API proxy services hosted on Edge where API
traffic is sent into Edge prior to being processed and then delivered to the customer datacenter.
Testing of shared resources, such as the management portal UI, is not approved for individual
customers (a third party report covering testing of the shared services is available to customers
under a non-disclosure agreement and upon request).

Customers should, and are encouraged to, test their API endpoints. Your agreement with Apigee
does not prohibit testing of your API endpoints, but we don't permit you to test the shared
management UI. Although if additional clarification is required, please open a support request
referencing your planned testing. Notification to Apigee in advance is appreciated so that we can
be aware of the testing traffic.

Customers testing their endpoints should look for any API-specific issues, any issues related
to Apigee services, and also check on the TLS and other configurable items. Any items that are
found related to Apigee services should be communicated to Apigee through a support request.

Most items related to the endpoint are customer self-service items and can be fixed by
reviewing the Edge documentation. If there are items where it is unclear how to fix them, please
open a support request.

### TLS configuration

As per [PCI
standards](https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls), SSL and early TLS need to be migrated to secured versions. Customers are
responsible for defining and configuring their own TLS endpoints for API proxies. This is a
self-service feature in Edge. Customer requirements around encryption, protocol, and algorithm
selections are widely variable and specific to individual use cases. Because Apigee does not know
the details of every customer's API design and data payloads, customers have the responsibility
to determine appropriate encryption for data in transit. Detailed instructions on TLS
configuration are available at [TLS/SSL](https://docs.apigee.com/api-platform/system-administration/ssl).

## Data storage

Storage of data within Edge is not required for Edge to function properly. However, there are
services available for data storage in Edge. Customers may choose to use cache, key value
maps, or analytics for data storage. None of these services are authorized for
storage of CHD per the Apigee PCI audit. Per [PCI
Requirement 3 (Protect stored cardholder data)](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf), PCI data should be stored only in PCI
compliant locations. Use of these services is available to customers for storing non-PCI data or
other unrestricted data subject to the customer's security and legal requirements. These services
are customer self-service items, so it is customer's responsibility to configure them not to
capture or store CHD. Reviews of configuration, policies, and deployments by customer
administrators is recommended to avoid an accidental or malicious use of data storage services in
Edge in a non-compliant manner .

## Data encryption

Data encryption tools are not offered to customers for their use inside of Edge. However,
customers are free to encrypt their PCI data prior to sending to Edge. [PCI
Requirement 4: (Encrypt transmission of cardholder data across open, public networks)](https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf)
recommend to encrypt cardholder data across open, public networks. Encrypted data in the payload
(or Message Body) does not prevent Edge from functioning. Some Edge policies may be unable to
interact with the data if it is received encrypted by the customer. For example, a transformation
is not possible if the data itself is not available to Edge to change. But other policies and
customer-built policies and bundles will work even if the data payload is encrypted.