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.
