[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-03 (世界標準時間)。"],[[["\u003cp\u003eThis document outlines the shared responsibilities between Apigee and its customers regarding Payment Card Industry (PCI) compliance, emphasizing that Google secures the platform while customers are responsible for securing their data.\u003c/p\u003e\n"],["\u003cp\u003eCustomers using Apigee must address self-service items to meet PCI requirements, including data masking, TLS configuration, user authorizations, and audit trails, which are mapped to specific PCI requirements within this documentation.\u003c/p\u003e\n"],["\u003cp\u003eData masking is enforced during Debug sessions to prevent sensitive data display, but it does not prevent visibility in other areas like log files, cache, or analytics, which customers should manage carefully.\u003c/p\u003e\n"],["\u003cp\u003eCustomers are responsible for testing and scanning their API endpoints hosted on Apigee to ensure PCI compliance, while testing the shared management UI is not permitted.\u003c/p\u003e\n"],["\u003cp\u003eApigee does not store PCI data by default, however, customers can use services like caching and key-value maps, but they must ensure that PCI data is not stored in these services, as per PCI Requirement 3.\u003c/p\u003e\n"]]],[],null,["# PCI Configuration Guide for Apigee\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n\nFor a customer to be Payment Card Industry (PCI) compliant on Apigee, there are some actions and processes the customer\nowns under the \"Shared Responsibility Model.\" The following items should be reviewed by customers who are\nseeking to be PCI compliant. These items are self-service within Apigee\nand need to be addressed for the customer organization (org) to meet PCI requirements. The\noverarching concept is \"Google secures the platform, the customer secures their data.\"\n\nPCI Requirements Mapping\n------------------------\n\n\nThe following table maps PCI requirements to related Apigee documentation. For more information\nabout the requirements, see\n[PCI DSS v3.2.1 Quick Reference Guide](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf).\n\n\nTo obtain a PCI Data Security Standard Attestation of Compliance (AOC), please visit\n[Google\nCompliance Report Manager](https://cloud.google.com/security/compliance/compliance-reports-manager#/ProductArea=Apigee) or contact your Apigee sales team.\n\nDebug Sessions\n--------------\n\n\nDebug Sessions is a troubleshooting tool that allows the user to view the status and contents\nof an API call as it is processed through the Apigee platform.\n\n\nDuring a Debug session, [Data masking](#data-masking) is enforced. Data Masking\ncan block data from being displayed during a Debug session. See the [Data Masking](#data-masking) section below.\n\n\nDetailed instructions on the use of Debug are available at [Using Debug](/apigee/docs/api-platform/debug/trace).\n\nUse/Authorizations\n------------------\n\n\nAccess to Debug Session is managed through the Cloud IAM (Identity Access Management) RBAC\n(Role-Based Access Control) system. Detailed instructions on using the RBAC system to give\nand revoke Debug Session privileges are available at [Apigee roles](/apigee/docs/api-platform/system-administration/apigee-roles)\nand [Manage users in the Apigee UI](/apigee/docs/api-platform/system-administration/manage-users).\nDebug Session permissions allow the user to launch a Debug Session, access the output from a debug session.\n\n\nSince Debug Session has access to the payload of API calls (formally called the \"Message Body\"),\nit's important to consider who has access to run a Debug Session. Because user management is\na customer responsibility, the granting of Debug Session permissions is also a customer responsibility.\n\nData masking\n------------\n\n\nData masking prevents the display of sensitive data during a Debug session only, both in\nthe Debug tool (Apigee UI) and in the backend by Debug (Apigee API). Details of how to set up\nmasking are available at [Data\nmasking and hiding](/apigee/docs/api-platform/security/data-masking). Masking sensitive data is part of [PCI Requirement 3 - Protect stored cardholder data](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf).\n\n\nData masking does NOT prevent the data from being visible in places such as log files, the cache, and analytics.\nSensitive data should typically not be written to cache or analytics without a strong\nbusiness justification and review by customer security and legal teams.\n\nCaching\n-------\n\n\nCaching is available to all customers. For more information, see [Cache internals](/apigee/docs/api-platform/cache/cache-internals).\n\n\nAudit trail\n-----------\n\n\nCustomers have the ability to review the audit trail of all administrative activities performed\nwithin the customer's org, including the use of Debug. For detailed instructions, see\n[Audit logging](/apigee/docs/api-platform/debug/audit-logs) and\n[Using Debug](/apigee/docs/api-platform/debug/trace).\n[PCI Requirement 10: Track and monitor all access to network resources and cardholder data](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf)).\n\nComplex password requirements or SAML\n-------------------------------------\n\n\nFor PCI customers, user passwords are configured to meet most requirements as mandated by PCI DSS.\nCloud Identity also offers multi-factor authentication ([PCI\nRequirement 8: Assign a unique ID to each person with computer access](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf)). SAML as\ndescribed at [SAML Overview](/apigee/docs/api-platform/system-administration/saml-overview), can be used as an alternative for authentication controls.\n\n\n**Note:** Customers with specific password requirements are recommended to use SAML\nto meet their individual requirements.\n\nEndpoint security\n-----------------\n\n### Endpoint scanning\n\n\nScanning and testing of hosts is required for PCI compliance ([Requirement 11: Regularly test security systems and processes](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf)). For Apigee, customers are responsible for the scanning and testing of their API endpoints (sometimes called the \"runtime components\") in Apigee. Customer testing should cover the actual API proxy services hosted on Apigee where API traffic is sent into Apigee 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).\n\n\nCustomers should, and are encouraged to, test their API endpoints. Your agreement with Apigee does\nnot prohibit testing of your API endpoints, but we don't permit you to test the shared\nmanagement UI. Notification to Apigee in advance is appreciated so that we can be aware of the\ntesting traffic.\n\n\nCustomers testing their endpoints should look for any API-specific issues, any issues related\nto Apigee services, and also check on the TLS and other configurable items. Any items that\nare found related to Apigee services should be communicated to Apigee through a support request.\n\n\nMost items related to the endpoint are customer self-service items and can be fixed by\nreviewing the Apigeee documentation. If there are items where it is unclear how to fix\nthem, please open a support request.\n\n### TLS configuration\n\n\nAs per [PCI\nstandards](https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls), SSL and early TLS need to be migrated to secured versions. Customers are\nresponsible for defining and configuring their own TLS endpoints for API proxies. This is a\nself-service feature in Apigee. Customer requirements around encryption, protocol, and algorithm\nselections are widely variable and specific to individual use cases. Because Apigee does not\nknow the details of every customer's API design and data payloads, customers have the\nresponsibility to determine appropriate encryption for data in transit. Detailed instructions\non TLS configuration are available at [TLS/SSL](/apigee/docs/api-platform/system-administration/options-configuring-tls).\n\nData storage\n------------\n\n\nStorage of data within Apigee is not required for Apigee to function properly. However, there\nare services available for data storage in Apigee. Customers may choose to use cache, key\nvalue maps, or analytics for data storage. Analytics is not authorized for storage of Card Holder Data (CHD)\nper the Apigee PCI audit. Per [PCI Requirement 3 (Protect stored cardholder data)](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.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 the 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 accidental or malicious use of data storage services in Apigee in a non-compliant manner .\n\nData encryption\n---------------\n\n\nData encryption tools are not offered to customers for their use inside of Apigee. However,\ncustomers are free to encrypt their PCI data prior to sending to Apigee. [PCI Requirement 4: (Encrypt transmission of cardholder data across open, public networks)](https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf) recommends to encrypt cardholder data across open, public networks. Encrypted data in the payload (or Message Body) does not prevent Apigee from functioning. Some Apigee 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 Apigee to change. But other policies and customer-built policies and bundles will work even if the data payload is encrypted.\n\nData Capture\n------------\n\n\nCustomers can use the [Data\nCapture policy](/apigee/docs/api-platform/reference/policies/data-capture-policy) to send custom attributes to the Apigee analytics\nplatform. Apigee recommends not using Data Capture for storing card holder information.\n\nInformation exposure through query\nstrings in URL\n-------------------------------------------------\n\n\nApigee recommends API designs that avoid sensitive data (including, but not restricted to\ncardholder information) through query strings in URLs."]]
