You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
HIPAA Compliance with Apigee Edge
Ensuring that our customers' data is safe, secure, and always available to them is one of our top priorities. To demonstrate our compliance with security standards in the industry, Google has sought and received security certifications such as ISO 27001 certification and SOC 2 and SOC 3 Type II audits. For customers who are subject to the requirements of the Health Insurance Portability and Accountability Act (HIPAA), Apigee Edge can also support HIPAA compliance.
Under HIPAA, certain information about a person’s health or health care services is classified as Protected Health Information (PHI). Apigee Edge customers who are subject to HIPAA and wish to use Apigee Edge with PHI must sign a Business Associate Agreement (BAA) with Google.
Apigee Edge customers are responsible for determining whether they are subject to HIPAA requirements and whether they use or intend to use Google services in connection with PHI. Customers who have not signed a BAA with Google must not use Google services in connection with PHI.
Administrators must review and accept a BAA before using Google services with PHI.
We have published our Apigee HIPAA Configuration Guide in this topic to help customers understand how to organize data on Google services when handling PHI. This guide is intended for employees in organizations who are responsible for HIPAA implementation and compliance with Apigee Edge.
HIPAA Configuration Guide for Edge Public Cloud
This guide is for informational purposes only. Apigee does not intend the information or recommendations in this guide to constitute legal advice. Each customer is responsible for independently evaluating its own particular use of the services as appropriate to support its legal compliance obligations.
The following items should be reviewed by customers subject to Health Insurance Portability and Accountability Act (known as HIPAA, as amended, including by the Health Information Technology for Economic and Clinical Health — HITECH Act) who have purchased the HIPAA compliance pack. These items are self-service within Edge and can help support the customer organization (org) in meeting its HIPAA compliance obligations. The overarching concept is "Google secures the platform, the customer secures their data."
| HIPAA Requirements | Sections |
|---|---|
| HIPAA compliance: Security - Access Control | Use/Authorizations |
| HIPAA compliance: Security Management Process -Information System Activity Review | Audit trail |
| HIPAA compliance: Security Password Management | Complex Password requirements or SAML |
| HIPAA compliance: Security - Security Management Process | Endpoint scanning |
| HIPAA compliance: Security - Transmission | TLS configuration |
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 if enabled and configured by customer. This tool can block data from being displayed during a Trace. See the Data Masking section below.
Encrypted Key Value Maps (KVMs) are used for customers that require HIPAA compliance. With an encrypted KVM 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 (HIPAA compliance: Security - Access Control). 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.
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
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. 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 (HIPAA compliance: Security Management Process - Information System Activity Review). Detailed Instructions are available here and at Using the Trace tool.
Complex password requirements or SAML
For HIPAA customers, user passwords are configured to meet advanced requirements such as length, complexity, and life span. (HIPAA compliance: Security Password Management)
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
Edge Cloud customers are responsible for the scanning and testing of their API endpoints (sometimes called the "runtime components") in Edge ( HIPAA compliance: Security - Security Management Process). 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 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 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 ( HIPAA compliance: Security - Transmission).
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 or analytics for data storage. 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 of the payload
Data encryption tools are not offered to customers for their use 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 other policies and customer-built policies and bundles will work even if the data payload is encrypted.
PII in URIs
Apigee's unified analytics platform (UAP) captures analytics data, including any PHI or other sensitive data included in the uniform resource identifier (URI) of an API call into Apigee Edge, and retains it for 13 months. PHI in the URI is supported by Fast Healthcare Interoperability Resources (FHIR) standards and is therefore supported by Apigee. Analytics data in the UAP is encrypted at rest by default.
Apigee currently does not support:
- Data masking to UAP
- Changing the retention cycle
- Opting out of UAP
- Dropping the URI from UAP data collection