News

Microsoft Releases Windows Azure Security Resources

• By Kurt Mackie
• August 19, 2010

Microsoft provided more information about security for Windows Azure, publishing a talk and white paper.

The latest discussion comes from a recorded chat by Charlie Kaufman, Microsoft security architect for Windows Azure, which was published by Microsoft today. Kaufman described the broad concepts that enable security for Windows Azure customers, although he conceded at one point that Windows Azure security is "secure enough for some applications and not secure enough for others."

Essentially, Windows Azure customers (or tenants) access virtual machines (VMs) that tap into Windows Azure's pooled resources in the Internet cloud. Access to the service is tied to the user's account and the account is established through a subscription portal. Customers gain access to the service through a Windows Live ID. Kaufman said that the "crypto behind Live ID is good."

Windows Azure has three basic components: compute, storage and SQL Azure (which is another form of storage, Kaufman said). All three components run on separate hardware and communication is established via HTTP or SSL requests. A single key controls everything that can be done with storage. Although all of the data on Windows Azure is stored in a single pool, access is only enabled via a secret key for each account, Kaufman explained.

Windows Azure uses a different kind of file system as part of its multitenant architecture. Existing apps need to be modified to use different types of storage, principally blob storage, Kaufman said. The C:, D: and E: drives that users see actually are virtual hard disks in the root operating system. Inputs and outputs go to the root OS and it makes sure that customers can only talk to their own disks. A network packet filter protects users from attacks from the outside, he added.

A few attacks are possible in Windows Azure. The customer administration interface could be used to launch attacks. However, Microsoft typically keeps watch by checking for any malformed requests.

A Windows Azure tenant could try to attack other tenants. However, Microsoft has architected Windows Azure so that the VMs of customers can't talk with the VMs of other customers. Such attacks would have to try to find a flaw in the hypervisor or in the drivers, Kaufman said.

An end user of Windows Azure could try an attack. In such cases, customers have all of the facilities of Windows to protect the VM against such attacks.

Customers have some security controls. They can determine how many role instances are needed. Each role instance creates a new C:, D: and E: drive structure and only one IP address is applied to a role instance. Customers can determine the size of each VM that runs application software. Customers also specify what certificates, passwords and secret keys each VM can use.

If that isn't enough information about how Windows Azure enables security, Kaufman coauthored a white paper, "Windows Azure Security Overview," released this month, that goes into greater detail. The white paper is written for developers and "technical decision makers."

Last month, Microsoft also released "Security Best Practices for Developing Windows Azure Applications." It describes Microsoft's Security Development Lifecycle, a process used internally by Microsoft to create its software products. It also describes specific Microsoft identity technologies used for Windows Azure security, including Active Directory Federation Services 2.0, the Azure App Fabric Access Control Service and Windows Identity Foundation.