You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. 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 Apigee PCI-DSS 3.2.1 Responsibility Matrix and share it with their PCI Qualified Security Assessor when conducting their own PCI audit.
PCI Requirements Mapping
| PCI Requirement | Section |
|---|---|
| Requirement 7: Restrict access to cardholder data by business need to know | |
| Requirement 3: Protect stored cardholder data | |
| Requirement 10: Track and monitor all access to network resources and cardholder data | |
| Requirement 8: Assign a unique ID to each person with computer access | |
| Requirement 11: Regularly test security systems and processes | |
| Requirement 4: Encrypt transmission of cardholder data across open, public networks | |
| Requirement 3: Protect stored cardholder data | |
| Requirement 4: Encrypt transmission of cardholder data across open, public networks |
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 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 Working with 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 and Creating custom roles in the UI. 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. Masking sensitive data is part of PCI Requirement 3 - Protect stored cardholder data
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) , 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.
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. (PCI Requirement 10: Track and monitor all access to network resources and cardholder data)
Complex password requirements or SAML
Customers with specific password requirements should use SAML to meet their individual requirements. See Enabling SAML Authentication for Edge. Edge also offers multi-factor authentication (PCI Requirement 8: Assign a unique ID to each person with computer access). See Enable two-factor auth for 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). 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, 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.
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), 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) 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.