Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

PCI Configuration Guide for Edge Public CLoud

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 fully PCI compliant. The overarching concept is 'Google secures the platform, the customer secures their data.'

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, but 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 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.

Details on KVMs, including encrypted KVMs, are available at Key Value Map Operations policy and Create KeyValueMap in an Organization.


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 Using permissions. 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 in a support 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.

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 your 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.  

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 PCI CHD or other restricted data is not supported.  

Use of cache by customers is permitted for non PCI CHD. Other types of data are fine to store in cache. We do not disable the cache 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 staff to not use cache when PCI data is likely to be in the API call. The Apigee PCI Compliance audit does not support PCI CHD stored in the cache.

Detailed instructions on using the Cache are available at Adding caching and persistence.

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 and at Using the Trace tool.

Complex Password requirements or SAML

For PCI customers, user passwords are configured to meet advanced requirements as mandated by PCI DSS. These password requirements are the minimum necessary settings for PCI compliance.

Edge also offers multi-factor authentication, described at Enable two-factor auth for your Apigee account, and SAML, described at Enabling SAML Authentication for Edge, as alternatives for authentication controls.

Endpoint Security

Endpoint scanning

Scanning and testing of hosts is required for PCI compliance. 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 3rd party report covering testing of the shared services is available to customers under NDA 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 does request you not test the shared management UI. Although if additional clarification is required, please open a support ticket 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 and related to Apigee services should be communicated to Apigee through a support ticket.

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

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.

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 the cache, BaaS (Backend-as-a-Service), or analytics for data storage. None of these services are authorized for storage of PCI CHD per the Apigee PCI audit. Use of these services is available to customers for storing non-PCI data under the customer's security and legal requirements. These services are customer self-service items, so it's possible to configure them to capture and store PCI 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.

Apigee does attempt to detect misuse of storage services and placement of restricted data (like credit card numbers, Social Security numbers, etc), but we cannot guarantee that every possible piece of restricted data is identified before being placed into a storage service.

Data encryption

Data encryption services are not offered to customers inside of Edge. However, customers are free to encrypt data prior to sending to Edge. Encrypted data in the payload (or Message Body) does not prevent Edge from functioning. A few 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 the vast majority of policies and customer-built policies and bundles will work fine even if the data payload is encrypted.

Help or comments?