Windows Azure: 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.
Joshua Hoffman
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).
.jpg "Figure 1 Creating a new Hosted Service in Windows Azure")
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.
.jpg "Figure 2 Adding new administrators to the subscription")
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, though you can create your own self-signed certificate for development purposes.
Self-signed certificates should be used for testing purposes only, as they will not be trusted by end-user web browsers. You’ll notice during testing that your own browser will point out the non-trusted certificate, or that API calls made using Windows Communications Foundation (WCF) will fail. This does not mean that the certificate isn’t working, but that it isn’t trusted by a root CA. Within a browser, this is generally an accepted annoyance during testing, but certainly not an experience you want your end-users to have.
In order to run testing with API calls, you’ll need to add code to bypass certificate validation, or add the self-signed service certificate’s root CA certificate to the Trusted Root Certification Authorities certificate store using either the Certificate Management MMC, batch commands, or via code. Microsoft’s David Hardin has written more on this issue on his blog.
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).
.jpg "Figure 3 Adding a service certificate in Windows Azure")
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 Authentication 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.”
.jpg "Figure 4 Adding a management certificate in Windows Azure")
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.
Despite having your applications hosted in the cloud, you still have to be fully involved in their security architecture. (For additional resources on this topic, be sure to see the MSDN library page, Security Resources for Windows Azure.) Follow these best practices for both account and certificate management. This will help ensure that your organization can fully benefit from cloud computing, without compromising the safety and security of your critical business information.
Thanks to David Hardin of Microsoft IT and Daniel Odievich of the Microsoft Developer and Platform Evangelism Team, along with the partnership of the Security Talk Series for their assistance in the development of this article.
.jpg "Joshua Hoffman")
Joshua Hoffman* is the former editor in chief of TechNet Magazine. He’s now an independent author and consultant, advising clients on technology and audience-oriented marketing. Hoffman also serves as editor in chief of ResearchAccess.com, a site devoted to growing and enriching the market research community. He lives in New York City.*