Preventing path information from being stored in analytics
Hi,
We are using APIgee cloud and have user sensitive information passing through the URL. This is personally identifiable information and we don't want it to be logged anywhere.
I guess we can override the internal analytics field in the proxy, so that the masked information is logged. But this will add maintenance overhead.
Is there a better way to do this.
Example - Resource - user
Request - GET /user/1234/details
We want to prevent the user id i.e 1234 from being logged in analytics.
Thanks,
Jaskaran
Jaskaran, your own suggestion is the best way to do this. Create a policy that will perform the appropriate masking of the path before it is forwarded to Analytics.
Thanks @spadmanabhan. However as I think more, there can still be a problem with it.
If we did this masking in a JS or any other policy in preflow, but the proxy errors out at this stage, the substitution might not happen and analytics will go ahead and log the information.
Not sure how this can be prevented.
Thanks,
Jaskaran
Not sure if in the last 4 years something has changed.
We tried the masking, but it only works for tracing/debugging.
The URI is still in the analytics store and you can generate reports that show the complete URI with the sensitive information.
Is there a way for commercial customers to work with Apigee support and get certain fields not being captured into analytics store? E.g.
URI, IP address, ...
masking only works in trace.
URI by default goes to analytics. So, this is still not changed.
@jaskarangump
Why would you be passing sensitive information via the URL? Can you do either of the following
- http://docs.apigee.com/api-services/content/data-masking#configuringamaskconfigurationresource.
- Use the Variable to mask the request.path if the information is sensitive?
- tokenize the url parameter?
Hi @rajeev@apigee.com -
My understanding is that masking only works for trace sessions. I will see if it masks information stored in analytics.
Tokenizing would require a big change at our end.
Thanks
Jaskaran
As per documentation also, masking is only for trace session and is enabled when tracing is on.
Jaskaran, I think you are analyzing this correctly. Best is if you can prevent this input in the first place. Otherwise, the policy mechanism will capture and address all the well formed scenarios. I don't think we have a solution to address the router erroring scenario.
@spadmanabhan Does it mean that the requests get logged in analytics even if there is afailure in router?
Can you please let us know where is the information logged in analytics. I guess I want to know if a something is logged even if the request doesnt reach messageprocessor.
We are not storing router failure messages in analytics right now. But we could do this in the foreseeable future.
