How we secure your data in Azure AD

Howdy folks,

With all the breaches of cloud identity services over the last few years, we get a lot of questions about how we secure customer data. So today’s blog is a dive into the details of how we protect customer data in Azure AD.

Datacenter and Service Security

Let’s start with our datacenters. First, all of Microsoft’s datacenter personnel must pass a background check. All access to our datacenters is strictly regulated and every entry and exit are monitored. Within these datacenters, the critical Azure AD services that store customer data are located in special locked racks—their physical access is highly restricted and camera-monitored 24 hours a day. Furthermore, if one of these servers is decommissioned, all disks are logically and physically destroyed to avoid data leakage.

Next, we limit the number of people who can access the Azure AD services, and even those who do have access permissions operate without these privileges day-to-day when they sign in. When they do need privileges to access the service, they need to pass a multi-factor authentication challenge using a smartcard to confirm their identity and submit a request. Once the request is approved, the users privileges are provisioned “just-in-time”. These privileges are also automatically removed after a fixed period of time and anyone needing more time must go through the request and approval process again.

Once these privileges are granted, all access is performed using a managed admin workstation (consistent with published Privileged Access Workstation guidance). This is required by policy, and compliance is closely monitored. These workstations use a fixed image and all software on the machine is fully managed. To minimize the surface area of risks, only selected activities are allowed, and users cannot accidentally circumvent the design of the admin workstation since they don’t have admin privileges on the box. To further protect the workstations, any access must be done with a smartcard and access to each one is limited to specific set of users.

Finally we maintain a small number (fewer than five) of “break glass” accounts. These accounts are reserved for emergencies only and secured by multi-step “break glass” procedures. Any use of those accounts is monitored, and triggers alerts.

Threat detection

There are several automatic checks we do regularly, every few minutes to ensure things are operating as we expect, even as we are adding new functionality required by our customers:

• Breach detection: We check for patterns that indicate breach. We keep adding to this set of detections regularly. We also use automated tests that trigger these patterns, so we are also checking if our breach detection logic is working correctly!
  
• Penetration tests: These tests run all the time. These tests try to do all sorts of things to compromise our service, and we expect these tests to fail all the time. If they succeed, we know there is something wrong and can correct it immediately.
  
• Audit: All administrative activity is logged. Any activity that is not anticipated (such as an admin creating accounts with privileges) causes alerts to be triggered that cause us to do deep inspection on that action to make sure it not abnormal.
  

And did we say we encrypt all your data in Azure AD? Yes, we do – we use BitLocker to encrypt all Azure AD identity data at rest. What about on the wire? We do that as well! All Azure AD APIs are web-based using SSL through HTTPS to encrypt the data. All Azure AD servers are configured to use TLS 1.2. We allow inbound connections over TLS 1.1 and 1.0 to support external clients. We explicitly deny any connection over all legacy versions of SSL including SSL 3.0 and 2.0. Access to information is restricted through token-based authorization and each tenant’s data is only accessible to accounts permitted in that tenant. In addition, our internal APIs have the added requirement to use SSL client/server authentication on trusted certificates and issuance chains.

A final note

Azure AD is delivered in two ways, and this post described security and encryption for the public service delivered and operated by Microsoft. For similar questions about our National Cloud instances operated by trusted partners, we welcome you to reach out to your account teams.

(Note: As a simple rule of thumb, if you manage or access your Microsoft Online services through URLs ending with .com, this post describes how we protect and encrypt your data.)

The security of your data is a top priority for us and we take it VERY seriously. I hope you found this overview of our data encryption and security protocol reassuring and useful.

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

[updated 10/3/2017 to add specific version information about our use of TLS and SSL]