Can Microsoft employees see my data in Azure?

Solution 1:

Legally speaking, they can't read your data or send your data to law enforcement without a correct court order.

Requests for customer data

Government requests for customer data must comply with applicable laws. A subpoena or its local equivalent is required to request non-content data, and a warrant, court order, or its local equivalent, is required for content data.

Per transparency from Microsoft, to see the current state of how many laws subpoena they answered on there.

enter image description here

You have to choose wisely your Azure region for that reason. In example HIPAA enterprise in Canada would have to be hosted in Canada in example for their data.

A rogue Microsoft employee could maybe see your data. The process there is unknown, but that risk is the same from any hoster or rogue employee inside your corporation.

Solution 2:

You are putting your data on Somebody Else's Computer, and the data can be accessed in some way. In other words, the answer to your exact question is almost surely: Yes, some Microsoft employees can see your data but make an active choice not to perform the tasks that would let them do so.

A wider question is how large the risk actually is for leaks of such data. My opinion is that the risk is considerably lower that a Microsoft employee would attempt to access your data (and leak it) than that a configuration or software error made by you as a tenant would make such data available to third-parties. The latter is what we usually see when it comes to data leaks that make it to the news.


Solution 3:

I state this from experience because I used to work there.

Internally Microsoft is very strict about protecting the data of users and customers, and unlike some other big well-known WEB outfits, Microsoft explicitly does NOT scan the contents of user's private files (eg your Hotmail.com Email, your VM's data files) to be used for marketing or advertising.

Any employee who breaks internal rules to access user data would be shown the door PDQ, and would likely face legal consequences. And only a restricted cadre even have the technical ability/access to do that.

Note that "meta data" falls under different rules, which Microsoft is upfront about, but is strict about who might actually see even that. Usually it gets anonymized en-mass and sorted into some internal company database so the operations folks can keep the systems running. Those folks care only about the overall statistics, not the actual user data (which they can't normally see).

The SQL developers license data you mention is meta-data (eg "usage data") not the customer's SQL data.

In short, no human is going to read your files sitting on a Microsoft server unless there is a court order or some dire system repair problem requiring inspection of a specific file (extremely unlikely). And in either case it will be a limited number of eyeballs, and only after internal approvals are granted.

True story: in the very old days (1980s) two of the technicians would periodically take bunches of old hard drives out to the parking lot and drive a railroad spike through each with a sledge hammer. Very therapeutic. How's that for deleting files?


Solution 4:

Can they? Yes, the data is on their servers, which they control.

Will they? Probably not, except if they have a reason (usually legal and you have nice answer about that - also keep in mind that there are legal cases they cannot disclose). The probability depends on how your data is interesting or problematic.

Is what they get usable? That part depends on you: if you send them cleartext data then yes, if you encrypt it before sending then no


Solution 5:

I've not found exact details about Microsoft's internal access policies, but they do give general information in their brochure "Privacy Considerations in the Cloud" (PDF download, linked from their Privacy at Microsoft page:

Microsoft adheres to stringent policies and procedures when it comes to accessing your data. We have automated a majority of our service operations so that only a small set require human interaction. Microsoft operates on a “need-to-know-basis”, which means that access to your data by Microsoft personnel is restricted and can only be accessed when it is necessary for these operation. After that access rights are immediately revoked.

Further, data appears to be properly deleted and/or destroyed when you request deletion. ("Request" here appears to include things like releasing virtual hard drives and similar actions.)

What is your policy for deleting data? Can you assure me it will be completely removed? Microsoft follows strict standards for overwriting storage before reuse. If you delete your data or terminate your contract, we will ensure your data is deleted in accordance with your contract with us. In the event a hard drive fails, it will be physically destroyed in a way that makes data recovery impossible.

That said, some customer data appears not to fall under the above policies and you as the customer need to understand what this is and be careful with data you upload that falls under that. Most of this appears pretty obvious, however, One example from Microsoft data categories and definitions:

Object metadata

Is information provided by you, or on your behalf, that is used to identify or configure Online Service resources, such as software, systems, or containers, but does not include their content or user identities. Examples include the names and technical settings of Azure Storage accounts, Virtual Machines, Azure databases and data collections (and of their tables, column headings, labels, and document paths, as applicable). Customers should not include personal data or other sensitive information in object metadata because object metadata may be shared across global Microsoft systems to facilitate operations and troubleshooting.

The primary document about security and safety of data within Azure appears to be "Protecting Data in Microsoft Azure" (PDF download, linked as "Azure Data protection" in the middle of Data management at Microsoft). This touches on MS staff access only on page 17, where it discusses how staff are trained, they have strict protocols that are audited¹, etc., but it's vague on the details. It does reiterate what we've already seen above, in some cases being a bit more explicit:

Further protecting customer information, policy dictates that Microsoft personnel should not have persistent access to any customer data, including VMs, files, keys, databases, AD tenants, logs, or other types unless the customer explicitly grants access. If needed to resolve an urgent issue, Microsoft Azure administrators or support staff are provided with “just in time” access to customer data, which is revoked as soon as the issue is closed or requested.

The text couple of paragraphs also make clear that anything removed from the data centre is wiped first, and "delete means delete," and is "instantly consistent."

That said, the document is still well worth reading in its entirety if you're using Azure for any security-sensitive information, since security problems are far more likely to come from within your organization than from Microsoft.


¹ Don't read too much into the "comprehensive audits" part, by the way. Many security frameworks, such as ISO/IEC 27001 audit not that you're actually doing a good job at securing things, but that you have documented specific security controls and you have procedures for ensuring that you follow that documentation. Thus, if you document that passwords shall be no longer than 8 characters and consist only of lower-case letters, so long as you can show that you're following that, you pass the audit.