This is my attempt at writing a few words about the massive amount of security focus in Azure.

I will follow up this post with more posts regarding Azure Security - which will be more technical in nature. I will accept topic suggestions in the comment section :-)

Please do not hesitate to comment if you see errors or other things that I need to change! I am not a Microsoft employee, and I do not represent any organisation when writing this. This is a personal blog.

Please be advised that however much security Microsoft has put into the Azure infrastructure, ultimately you have the responsibility for your deployed resources! All the platform security in the world does not help you if your VM has an associated public IP address, no NSG and disabled Windows Firewall!

First a short summary (TL;DR):

1. Developers are bound to a strict lifecycle (SDL) for application development.
2. Azure datacenters are secret data fortresses, and you will be scrutinized when entering or exiting.
3. All customer tenants are isolated from each other.
4. Microsoft has an enourmous team of security experts, and a huge security budget.

Security Development Lifecycle

All new functionality must be run through the Security Development Lifecycle. This is a set of tools that Microsoft use internally, to make sure applications and features abide by a set of requirements. This toolset is also available to other organizations. SDL is recognized across the industry as a best practice for addressing the development phases of a product.

SDL goes a long way in ensuring security is built into the application from the first few lines of code. Security is not something you should half-ass, or add as an afterthought. Of course you can, and should, be as aware as possible, but the end result will always be better when security is built in from the start.

The framework forces developers - and other teams responsible for developing Azure services - to address encryption, privacy, compliance, etc. in the early stages of development process. This happens before anything at all is put into production, and security will therefore not be an afterthought.

Datacenter Physical security

You would not believe the amount of physical security Microsoft has ensured on all the Azure datacenters around the world.

Some key words:
Access request and approval - Access must be requested before arrival, and your access must be approved.
Facility’s perimeter - Complete control on who enters and exits the facility grounds.
Building entrance - Security Officers ensure proper control of datacenter entries and exits.
Inside the building - You are only allowed where you have explicitly been granted access, and always with multi-factor authentication (Biometrics++).
Datacenter floor - Metal scans and additional security scans before entering and exiting the floor.

Components and boundaries

All customer workloads inside the Azure datacenter are virtualized. They run on a hypervisor, which in turn abstract the hardware into different virtual compartments.

“At the host layer, Azure VMs run a customized and hardened version of the latest Windows Server. Azure uses a version of Windows Server that includes only those components necessary to host VMs. This improves performance and reduces attack surface. Machine boundaries are enforced by the hypervisor, which doesn’t depend on the operating system security.” - Microsoft docs

Microsoft employees (and contractors) are considered internal. All other users are considered external users. All users with access to resources have been associated to a sensitivity level. Please see more information here.

All internal communication is secured with TLS, by using self-signed internal certificates. The fabric controllers use specially managed and protected credentials (certificates) for internal authentication.

All Azure personnel are required to use Secure Admin Workstations (SAW), which customers also can deploy using privileged access workstations. This ensures separation of admin and regular user activities.

Tenant Isolation

One of the main benefits of running workloads in the cloud, is being able to share the hardware between customers. Sharing the hardware enables more efficient utilization of the resources. This, of course, leads to a concern about customer isolation.

The short answer is isolation is based on Azure AD (or tenant) and RBAC. Every Azure AD is a completely separate and dedicated instance of Azure AD. Every subscription is associated to only one Azure AD. Microsoft compares it to an office building, or something, and it can be seen as a secure and unique asset that is associated only with you. Users and administrators from one Azure AD cannot accidentaly or maliciously access or delete data from another Azure AD.

Copied from the isolation page mentioned below:

• Tenants are discrete containers and there is no relationship between these.
• No access across tenants unless tenant admin grants it through federation or provisioning user accounts from other tenants.
• Physical access to servers that comprise the Azure AD service, and direct access to Azure AD’s back-end systems, is restricted.
• Azure AD users have no access to physical assets or locations, and therefore it is not possible for them to bypass the logical RBAC policy checks stated following.

Read more about the tenant isolation here.

Threat response

If there is an actual attack, you can be sure Microsoft will respond with the appropriate counter measures and allocate the correct security personnel.
This is their five step incident response process:

This process will be initiated if there is an incident, and the customer will be informed about what has happened and what is being done in response.

Microsoft has more than 3,500 cybersecurity experts that work across teams such as the Cyber Defense Operations Center (CDOC), the Microsoft Digital Criminal Response Center (MDCU) and the Microsoft Security Response Center (MSRC). These security experts act as human intelligence while working with sophisticated, automated processes to detect, respond, and remediate threats. - Microsoft Security Blog Post

Your on-premises datacenter

Hopefully you have the network security portion of datacenter security locked down after best practices. Explicitly allowing traffic (allow some, deny the rest), single entry point, etc.

What about the physical security? Do you have security officers at the entrypoints? Do you have scanning of guests? Are you recording information on all the guests going in and out?

Do you have proper processes in place for retiring hardware? Do you have processes and guidelines for employee access to datacenter workloads?

Microsoft allocates about $1 billion each year on security (in 2018). How big is your security budget?

“The cloud is really an inflection point where we’re dramatically changing how we think about cybersecurity,” Rathbun said. “We’re not doing a traditional model, this is not paying staff, it is focusing on how can we do better.” - Azure Government CISO Matthew Rathbun, 2018

The security measures mentioned here, are only the tip of the iceberg. You have all the benefits of synergies because of the massive amounts of attacks that are fended off every minute of every day. New security tech features are constantly being developed and published.

Microsoft did a four part series on Azure security back in 2018:

• Azure layered approach to physical security
• The 3 ways azure improves your security
• 3 reasons why azure’s infrastructure is secure
• Four operational practices microsoft uses to secure the azure platform

The posts are pretty thorough and I mention some of what they write in this post, but a good thing can’t be said too often :-)

Still not convinced?

If still need to have extra protection for your data (legal purposes, confidentiality, etc.), there are several options:

1. Use encryption with customer managed keys on all the PaaS services.
   - SQL Database Encryption
   - Storage Account Encryption
2. Use App Service Environment with dedicated and isolated hardware.
3. Deploy workloads to IaaS VMs and encrypt the disks with customer managed keys from key vault.
4. Deploy workloads to Azure Confidential Compute, and the workload will also be encrypted when processing.

This could be a blog post of its own, and I will not go further into the encryption matter. For Key Vaults protecting extremely confidential data, you should consider Premium SKU (backed by hardware HSM). Here you can bring your own keys from on-premises HSM, if necessary. Keys will never leave the HSM boundary.

Some Microsoft security pages of interest:

• Microsoft Trust Center
• Security for home users
• Security for Business
• Microsoft Security Blog
• Security resources