search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.2k stars 21.35k forks source link

Instrumentation key #28048

Closed SeanFeldman closed 5 years ago

SeanFeldman commented 5 years ago

Reading "My iKey is visible in my web page source" section leaves me with multiple questions about considerations taken into compiling it rather than allowing instrumentation key.

This is common practice in monitoring solutions.

This is not a common practice for keys that could leak. Keys need to be replaceable.

It can't be used to steal your data.

Not relevant. It can be used to trash data. See next bullet point, which is a problem.

It could be used to skew your data or trigger alerts.

Precisely.

We have not heard that any customer has had such problems.

I guess you do now 🙂 Just because there was no incident doesn't mean the service shouldn't account for it. Azure supports Availability Zones not because customers asked for those, but because services might be disrupted. So is with Instrumentation Key. It needs to be rotateable.

The recommendations of how to handle the situations are also off:

Use two separate iKeys (separate Application Insights resources), for client and server data. Or

That's just off.

Write a proxy that runs in your server, and have the web client send data through that proxy.

The ability to replace the instrumentation key should be a fundamental concept baked into the service. Similar to what other Azure services are doing. Customers choose PaaS so that they don't have to build unnecessary infrastructure for the problems they solve.

Expected outcome

Introduce ability to replace instrumentation key, ideally with support for Primary and Secondary keys to align with a common practice for Azure Services.

Document details

âš  Do not edit this section. It is required for docs.microsoft.com âžź GitHub issue linking.

MarileeTurscak-MSFT commented 5 years ago

@SeanFeldman Thanks for your feedback! We will investigate and update as appropriate.

kobulloc-MSFT commented 5 years ago

@SeanFeldman We do get several questions about this and I'd like to do my best to address the points you've brought up here. First, I want to highlight a Microsoft blog that was written to address this question:

https://devblogs.microsoft.com/premier-developer/alternative-way-to-protect-your-application-insights-instrumentation-key-in-javascript/

Application Insights instrumentation key can be used in both Server and client side. Using the instrumentation key in the server side is secured and no one can see it. The opposite happens on the client side “JavaScript” where the instrumentation key is exposed, and anyone could see the key whenever they use fiddler to trace the calls. Knowing that, the instrumentation key doesn’t allow anyone to read anything from anywhere, it can only be used to write data to a resource.

Currently, there is no way to protect an instrumentation key in JavaScript. Every JavaScript based analytics tool has this issue so anything you do to protect it in the browser would be visible at debug time in the browser anyway.

At this point the risk is minimal since the most that could happen is unwanted data gets sent to your Application Insights resource, but to recognize whether the incoming data is real or not, you can enrich the data with properties that can be included in the queries and proves it is real.

Alternatively, the most secure way would be to send data from the browser to your custom API on your server then forward to Application Insights resource with the correct instrumentation key (see diagram below).

image

Now, to address your points:

Is this a common problem? The server side is secure, and no one can see the instrumentation key. The client side, however, uses JavaScript and as is the case with all JavaScript based analytic tools, there's no way to prevent someone from viewing the data with a network monitoring tool like Fiddler. This is a limitation of JavaScript and affects all of the JavaScript analytic tools (of which there are many).

Can my data be skewed? It's unlikely, but it is within the realm of possibility. A more secure approach would be to enrich the data with properties to prove that it's real, and send data from the browser to a custom API that would forward the data to Application Insights (see the blog above).

How can I make a suggestion for an improvement? If you still feel that a different approach is better, we're always taking suggestions!

https://feedback.azure.com/forums/357324-application-insights

Submit your suggestions at feedback.azure.com so they will be reviewed by the teams that are responsible for new Azure features.

Thank you again for your comments!

We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

SeanFeldman commented 5 years ago

@kobulloc-MSFT Thank you for linking that article. The concern I have over irreplaceable instrumentation key is not related to client-side or server-side. It's a security concern that doesn't care wherever your key is secure or not. A chance of leaking the key is real and needs to be addressed. I realize that documentation you put together is there to describe the existing state of affair and I should talk to the PG rather than documentation team. Thank you for trying to convince me that it's OK to have a non-replaceable key. I will disagree and work with PG to ensure they get this fixed.

kobulloc-MSFT commented 5 years ago

@SeanFeldman No worries! And it's ok to disagree--we get our best solutions when our ideas and views are challenged. We do our best to keep our documentation up to date and accurate, but if you do open a suggestion on feedback.azure.com, please link it here so that myself and others who read this can vote on it :)

SeanFeldman commented 5 years ago

I've raised this issue with MVP list. feedback.azure.com is a bit slow as a channel to get answers.