10-point tips on Azure security

When discussing cloud services, security is a key area. In fact, the Windows Azure infrastructure implements a number of technologies and processes to protect the environment. This page describes how Microsoft's global infrastructure services operate the infrastructure and the security measures they implement.

Fundamentally, Windows Azure must ensure the confidentiality, integrity, and availability of customer data, just like any other application hosting platform. It must also provide transparent responsibility to allow customers and their agents to track the management of applications and infrastructure, either personally or by Microsoft. This section describes the traditional properties of how Windows Azure provides information security, based on the basic components and relationships described so far.

1. SSL Mutual authentication for internal control traffic

All communication between Windows Azure internal components is protected by SSL.

2. Certificate and private Key management

To reduce the risk of exposing certificates and private keys to developers and administrators, both the certificate and the private key are installed through a separate mechanism that uses the code to use certificates and private keys. Certificates and private keys are uploaded as PKCS12 (PFX) files through SMAPI or the Windows Azure portal and are protected by SSL during the upload process. These PKCS12 files may be password protected, and if so, the password must also be included in the same message. SMAPI Remove password protection (if required), encrypt the entire PKCS12 Blob with the public key of SMAPI and store it and a short certificate name (the public key as metadata) in the confidential store on the FC.

3. Least-Privileged client software

Running applications with the least privilege is generally considered an information security best practice. To follow the principle of least privilege, customers are not granted administrative access to their virtual machines, and client software in Windows Azure can only be run with a low-privileged account by default (in future versions, customers can choose different permission models themselves). This reduces the potential impact of any attack and increases the difficulty necessary for a successful attack, in which the attacker needs to elevate privileges in addition to exploiting the vulnerabilities. It also prevents customers ' services from being attacked by their end users.

4. Access control in Windows Azure storage

Windows Azure Storage has a simple access control model. Each Windows Azure subscription can create one or more storage accounts. Each storage account has a single key that controls access to all data in that storage account. This supports typical scenarios where storage is associated with an application, and these applications have full control over their associated data.

5. Isolation of hypervisors, root operating systems, and guest virtual machines

An important boundary is the separation of the root virtual machine from the guest virtual machine and the individual guest virtual machines managed by the hypervisor and the root operating system. The hypervisor/root operating system pairing mechanism leverages Microsoft's decades of operating system security experience and Microsoft's recent technology in Hyper-V to provide a strong isolation of guest virtual machines.

6. Isolation of Fabric Controller

There are some important controls that play the role of the central console, largely the central console of Windows Azure Fabric, which mitigates the threat to Fabric Controller, especially from the potentially compromised FA in customer applications. Communication from FC to FA is one-way: FA enforces SSL-protected services (accessed from FC) and responds only to requests. It cannot initiate a connection to FC or other privileged internal nodes. FC has powerful capabilities to analyze all responses as if these responses were untrusted communications.

In addition, FC and devices that cannot implement SSL are located on different VLANs, which limits their authentication interfaces to exposed to the compromised nodes of the hosted virtual machine.

7. Packet filtering

The hypervisor and the root operating system provide network packet filters that ensure that untrusted virtual machines cannot perform the following actions: generating spoofed traffic, receiving targets that are not communicating with them, pointing traffic to a protected infrastructure endpoint, sending or receiving inappropriate broadcast traffic.

8. VLAN Isolation

VLANs are used to isolate FC and other devices. VLANs partition the network so that no communication can be made between VLANs without passing through the router, which prevents the compromised node from forging traffic from outside its VLAN to other nodes on its VLAN, and it cannot eavesdrop on traffic that is not pointing to or from its VLAN.

9. Customer Access Quarantine

Systems that manage access to the customer environment (Windows Azure Portal, SMAPI, and so on) are quarantined in Windows Azure applications running by Microsoft. This logically isolates the customer access infrastructure from the customer application and storage.

10. Delete Data

Where applicable, the data should continue to be kept confidential after the useful life cycle of the data. Once the delete operation is invoked, the storage subsystem for Windows Azure makes the customer data unusable. All storage operations, including deletions, can be aligned instantly. A successful delete operation removes all references to the associated data item, and the associated data item cannot be accessed through the storage API. All copies of deleted data items are then garbage collected. When you reuse an associated storage block to store additional data, the physical bits are overwritten, which is typical for a standard computer hard disk.

10-point tips on Azure security