Security question about data masking and hiding

We applied data masking and hiding to customer password using the instruction written here:

https://docs.apigee.com/api-platform/security/data-masking#hidingsensitivedata

I see the password is hidden from trace (TRACE tab in the Apigee UI). Great!

Now my question is this. Are the customer passwords hidden also on the Apigee side of logs (accessible from us or not).

In other words, when the password is hidden or masked, is it not exposed in any possible way on the Apigee side?

Could you please help me find out the answer?

Solved Solved
0 2 235
1 ACCEPTED SOLUTION

Are the customer passwords hidden also on the Apigee side of logs

The Apigee service does not log payloads or headers of requests that it handles. Apigee does log "W3" style logs, which includes the timestamp, the verb, and the URL path of requests, and the status code of the response. If your requests accept password in a header or form parameter or as part of a JSON or XML payload, then no, Apigee does not log those things, ever. We would not say these things are "hidden". They are just never logged.

is it not exposed in any possible way on the Apigee side?

It is true that within the server in the cloud, there is a process that handles (processes?) the inbound requests. We call this the "message processor". Obviously the memory space inside that process does have access to the password, and every other part of the message body and headers and so on. So the data is visible THERE. And Apigee system operators have access to these systems, these processes. In theory, the Apigee sysadmins could attach a debugger to that message processor process and could view the memory contents of the process. That sysadmin could view the passwords.

But, that sort of activity is governed by the Google Cloud Data Processing and Security Terms.

I encourage you to read that entire document. But I'll call your attention to one particular section, section 7.1.2 , in which you can read:

7.1.2 Access and Compliance. Google will: (a) authorize its employees, contractors and Subprocessors to access Customer Personal Data only as strictly necessary to comply with Instructions; (b) take appropriate steps to ensure compliance with the Security Measures by its employees, contractors and Subprocessors to the extent applicable to their scope of performance; and (c) ensure that all persons authorized to process Customer Personal Data are under an obligation of confidentiality.

I am not a lawyer, but... the common interpretation of that statement is that Google will access your data only as necessary when instructed by you. The phrase "to comply with Instructions" in the above refers to instructions given to Google by you, in writing. For example, only when you open a support ticket and ask for help diagnosing a particular behavior or error you are observing.

So I would not be able to say "the data is not exposed in any possible way", which is your phrase. I would be able to say "the data is accessible only in the circumstance that you ask Apigee support people to help you diagnose a problem you're seeing."

Our customers, by definition, accept those terms. If you use Apigee, then legally speaking, you accept those terms.

If you want to discuss this issue further, I suggest that you contact your Apigee sales team directly.

View solution in original post

2 REPLIES 2

Are the customer passwords hidden also on the Apigee side of logs

The Apigee service does not log payloads or headers of requests that it handles. Apigee does log "W3" style logs, which includes the timestamp, the verb, and the URL path of requests, and the status code of the response. If your requests accept password in a header or form parameter or as part of a JSON or XML payload, then no, Apigee does not log those things, ever. We would not say these things are "hidden". They are just never logged.

is it not exposed in any possible way on the Apigee side?

It is true that within the server in the cloud, there is a process that handles (processes?) the inbound requests. We call this the "message processor". Obviously the memory space inside that process does have access to the password, and every other part of the message body and headers and so on. So the data is visible THERE. And Apigee system operators have access to these systems, these processes. In theory, the Apigee sysadmins could attach a debugger to that message processor process and could view the memory contents of the process. That sysadmin could view the passwords.

But, that sort of activity is governed by the Google Cloud Data Processing and Security Terms.

I encourage you to read that entire document. But I'll call your attention to one particular section, section 7.1.2 , in which you can read:

7.1.2 Access and Compliance. Google will: (a) authorize its employees, contractors and Subprocessors to access Customer Personal Data only as strictly necessary to comply with Instructions; (b) take appropriate steps to ensure compliance with the Security Measures by its employees, contractors and Subprocessors to the extent applicable to their scope of performance; and (c) ensure that all persons authorized to process Customer Personal Data are under an obligation of confidentiality.

I am not a lawyer, but... the common interpretation of that statement is that Google will access your data only as necessary when instructed by you. The phrase "to comply with Instructions" in the above refers to instructions given to Google by you, in writing. For example, only when you open a support ticket and ask for help diagnosing a particular behavior or error you are observing.

So I would not be able to say "the data is not exposed in any possible way", which is your phrase. I would be able to say "the data is accessible only in the circumstance that you ask Apigee support people to help you diagnose a problem you're seeing."

Our customers, by definition, accept those terms. If you use Apigee, then legally speaking, you accept those terms.

If you want to discuss this issue further, I suggest that you contact your Apigee sales team directly.

You gave me appropriately detailed, yet digestible, explanations.

Thank you very much!