10 Things to know about Azure Security
Security is a key area when looking at Cloud services. Under the hood the Microsoft Azure infrastructure implements a number of technologies and processes to safeguard the environment. This page covers how Microsoft's Global Foundation Services runs the infrastructure and the security measures they implement.
Fundamentally, Azure must provide confidentiality, integrity, and availability of customer data, just like any other application hosting platform. It must also provide transparent accountability to allow customers and their agents to track administration of applications and infrastructure, by themselves and by Microsoft. Drawing on the basic components and relationships described so far, this section will illustrate how Azure provides these classical dimensions of information security.
1. SSL Mutual Authentication for Internal Control Traffic
All communications between Azure internal components are protected with SSL.
2. Certificate and Private Key Management
To lower the risk of exposing certificates and private keys to developers and administrators, they are installed via a separate mechanism than the code that uses them. Certificates and private keys are uploaded via SMAPI or the Azure Portal as PKCS12 (PFX) files protected in transit by SSL. Those PKCS12 files may be password protected, but if so, the password must be included in the same message. SMAPI removes the password protection (if necessary) and encrypts the entire PKCS12 blob using SMAPI's public key and stores it in a secret store on the FC, along with a short certificate name and the public key as metadata.
3. Least Privilege Customer Software
Running applications with least privilege is widely regarded as an information security best practice. To align with the principle of least privilege, customers are not granted administrative access to their VMs, and customer software in Azure is restricted to running under a low-privilege account by default (in future versions, customers may select different privilege models at their option). This reduces the potential impact and increases the necessary sophistication of any attack, requiring privilege elevation in addition to other exploits. It also protects the customer's service from attack by its own end users.
4. Access Control in Azure Storage
Azure Storage has a simple access control model. Each Azure subscription can create one or more Storage Accounts. Each Storage Account has a single secret key that is used to control access to all data in that Storage Account. This supports the typical scenario where storage is associated with applications and those applications have full control over their associated data.
5. Isolation of Hypervisor, Root OS, and Guest VMs
A critical boundary is the isolation of the root VM from the guest VMs and the guest VMs from one another, managed by the hypervisor and the root OS. The hypervisor/root OS pairing leverages Microsoft's decades of operating system security experience, as well as more recent learning from Microsoft's Hyper-V, to provide strong isolation of guest VMs.
6. Isolation of Fabric Controllers
As the central orchestrator of much the Azure Fabric, significant controls are in place to mitigate threats to fabric controllers, especially from potentially compromised FAs within customer applications. Communication from FC to FA is unidirectional - the FA implements an SSL-protected service that is accessed from the FC and replies to requests only. It cannot initiate connections to the FC or other privileged internal nodes. The FC strongly parses all responses as though they were untrusted communications.
In addition, the FCs and devices incapable of implementing SSL are on separate VLANs, which limits exposure of their authentication interfaces to a compromised node that hosts VMs.
7. Packet Filtering
The hypervisor and the root OS provide network packet filters that assure that the untrusted VMs cannot generate spoofed traffic, cannot receive traffic not addressed to them, cannot direct traffic to protected infrastructure endpoints, and cannot send or receive inappropriate broadcast traffic.
8. VLAN Isolation
VLANs are used to isolate the FCs and other devices. VLANs partition a network such that no communication is possible between VLANs without passing through a router, which prevents a compromised node from faking traffic from outside its VLAN except to other nodes on its VLAN, and it also cannot eavesdrop on traffic that is not to or from its VLANs.
9. Isolation of Customer Access
The systems managing access to customer environments (the Azure Portal, SMAPI, and so on) are isolated within an Azure application operated by Microsoft. This logically separates customer access infrastructure from customer applications and storage.
10. Deletion of Data
Where appropriate, confidentiality should persist beyond the useful lifecycle of data. Azure's Storage subsystem makes customer data unavailable once delete operations are called. All storage operations including delete are designed to be instantly consistent. Successful execution of a delete operation removes all references to the associated data item and it cannot be accessed via the storage APIs. All copies of the deleted data item are then garbage collected. The physical bits are overwritten when the associated storage block is reused for storing other data, as is typical with standard computer hard drives.