Practical App

Cloud Security: Understanding Security Account Management in Windows Azure

Cloud computing relieves some of the security burden, but you still have an active role in managing access, securing communications and ensuring data protection.

• By Joshua Hoffman
• 04/04/2011

Cloud computing is the closest thing to a major paradigm shift the IT industry has seen since the Internet itself. Faster bandwidth, cheaper storage, and robust virtualization technology have made the vision of Software as a Service a reality. The cloud delivers scalable, elastic, pay-as-you-go systems that meet the demands of the "do-more-with-less" generation.

While cloud computing relieves much of the infrastructure-management responsibility, security remains a critical concern. Security still requires the same degree of thought and attention as a physical datacenter. As applications and services migrate to cloud computing platforms such as Windows Azure, you must continue to play an active role in managing access, securing communications and ensuring the protection of critical business data.

There are several recommended approaches to security management for applications and services hosted on Windows Azure. There are also best practices for creating and managing administrative accounts, using certificates for authentication, and handling transitions when employees begin or terminate employment.

Account Ownership
The Microsoft Online Services Customer Portal (MOCP) handles all Windows Azure account management and billing. Through the MOCP, you can sign up for Windows Azure services, add additional services such as SQL Azure and create new instances of existing services (referred to as subscriptions).

Subscriptions are really the "billing boundary" for Windows Azure services. You'll want to maintain separate subscriptions for each application (or collection of applications) that require a different billing structure. For example, you can create separate subscriptions with individual billing details if you have different departments all hosting applications on Windows Azure, but requiring separate billing.

You'll need to identify an "account owner" account and a "service administrator" account for each subscription. Each of these accounts is associated with a Windows Live ID. The account owner is responsible for managing the subscription and billing through the MOCP. The account admin has to manage the technical aspects of the subscription, including the creation of hosted services, through the Windows Azure Management Portal.

Creating unique accounts for each of these roles is strongly recommended. These accounts should exist independent of individual accounts. In other words, don't use your personal Windows Live ID as the account owner or service administrator account in organizational- or team-based settings. Instead, create unique accounts (perhaps using a naming scheme such as AO[unique ID]@live.com for account owners and AA[unique ID]@live.com for account administrators), with passwords that can be managed, and reset when necessary, at a centralized level.

Once you've created a subscription, your account administrators can manage hosted services through the Windows Azure Management Portal. They can access this using the service administrator account credentials. Once they're logged in, they can start by creating a new Hosted Service (see Figure 1).

[Click on image for larger view.]

Figure 1. Creating a new Hosted Service in Windows Azure.

When creating a new Hosted Service, you'll be prompted to specify a name for your service. You'll also have to provide a URL prefix and deployment options. You can also choose a pre-existing package (.cspkg) and configuration file (.cscfg) from a development environment like Visual Studio (if you already have packaged applications).

From the Hosted Services Tab on the left side of the portal, select User Management. From here, you can add additional co-administrators to the subscription (see Figure 2). This gives you some additional flexibility in providing access to your hosted application administration.

[Click on image for larger view.]

Figure 2. Adding new administrators to the subscription.

Certificate Management
Certificates are a key component of Windows Azure security. There are two different kinds of certificates that play a role in securing your applications or services: service certificates and management certificates.

Service certificates are traditional SSL certificates used to secure endpoint communications. If you've ever configured SSL security for a Web site hosted on IIS for example, you're familiar with this type of certificate. You need service certificates for production deployments issued by a trusted root certificate authority (CA). Therefore, you'll need to purchase them from a third-party like VeriSign or DigiCert.

The list of trusted root CAs is maintained here (for Microsoft Windows) and here (for Microsoft Windows Phone 7). The name of your SSL certificate must match your Web site's domain name. So you'll need a DNS CNAME entry to map yourapp.cloudapp.net (the domain name for your application provided by Windows Azure) to www.yourcompany.com. For security purposes, you can't buy a certificate mapping to the yourapp.cloudapp.net. Only Microsoft can issue certificates for cloudapp.net.

But for development environments, you can create your own self-signed service certificate. You should only use this certificate for testing purposes, though, as end-user Web browsers won't trust it. You'll undoubtedly notice that during testing, your own browser will point out the untrusted certificate. This doesn't mean the certificate isn't working, it's just not trusted by a root CA. This is acceptable during testing, but certainly not what you want your users to experience.

You'll need to provide Windows Azure service certificates in the Personal Information Exchange (.pfx) format. To create your own self-signed service certificate with "password" as the placeholder password (you can change this in the final command to suit your preferences), open a Visual Studio command prompt and execute the following commands:

makecert -r -pe -n "CN=yourapp.
cloudapp.net" -b 01/01/2000 -e 
01/01/2036 -eku 1.3.6.1.5.5.7.3.1 
-ss my -sky exchange 
-sp "Microsoft RSA SChannel 
Cryptographic Provider" -sy 12 
-sv SSLDevCert.pvk SSLDevCert.cer

del SSLDevCert.pfx

pvk2pfx -pvk SSLDevCert.pvk 
-spc SSLDevCert.cer -pfx 
SSLDevCert.pfx -po password

You can upload SSL service certificates from the Hosted Services tab of the Windows Azure Management Portal by clicking Add Certificate and specifying the password (see Figure 3).

[Click on image for larger view.]

Figure 3. Adding a service certificate in Windows Azure.

Management certificates are the other type of certificate used by Windows Azure. The Windows Azure Tools for Microsoft Visual Studio use management certificates to authenticate developers for your Windows Azure deployment. The CSUpload command-line tool also uses management certificates to deploy virtual machine role images, as do Windows Azure Service Management REST API requests.

The Windows Azure Service Management Cmdlets use management certificates for Windows PowerShell. You can use the Windows Azure PowerShell cmdlets to easily execute and automate Windows Azure-based system deployment, configuration and management.

You must provide Windows Azure management certificates in X.509 (.cer) format. To create your own self-signed management certificates, open a Visual Studio command prompt and execute the following command:

makecert -r -pe -a sha1 -n 
"CN=Windows Azure Authentica-
tion Certificate" -ss my -len 2048 
-sp "Microsoft Enhanced RSA 
and AES Cryptographic Provider" 
-sy 24 ManagementApiCert.cer

Upload management certificates using the Windows Azure Management Platform by selecting Management Certificates from the left-hand panel, then choose Add Certificate (see Figure 4). For more information on creating your own certificates for Windows Azure, see the MSDN library article, "How to Create a Certificate for a Role."

[Click on image for larger view.]

Figure 4. Adding a management certificate in Windows Azure.

Employee Transitions
One of the primary advantages of a cloud computing solution is that it's hosted off-premises by a third party. Right away, this provides a layer of physical redundancy from your own location. However, it also means that when an employee leaves your organization -- whether voluntarily or not -- it's more difficult to restrict access to your resources.

As a result, it's particularly important to follow some key steps whenever there's a change affecting approved access to your cloud computing resources. The first step is to reset passwords for any service administrator accounts to which the former employee had access. If you have established unique and independent account owner and service administrator IDs that you can centrally manage, that will simplify this process.

If you're unable to reset the password for the service administrator account, you can log in to the MOCP as the account owner. Update the account listed as the service administrator. You should also remove any accounts listed as co-administrators through the Windows Azure Management Portal.

The second step is to reissue any pertinent management certificates. These certificates provide a means of authentication to your hosted service through Visual Studio and Windows Azure APIs. Therefore, you can no longer trust these once an employee has terminated employment. Even if the employee's work machine is left behind, they may have taken a copy of the certificate with them through other means.

To reissue management certificates, simply re-execute the command specified earlier and remove the old management certificates from the Windows Azure Management Portal. Upload the new management certificates and distribute them to all authorized employees. You only need to follow these steps for management certificates. You don't need to reissue service certificates because they only provide encryption, not authentication.

Thanks to David Hardin of Microsoft and Daniel Odievich of Xtreme Consulting Group, with the partnership of the Security Talk Series for their assistance in developing this article.