As I have worked on Azure before and have an interest in security I found this a very interesting read, with links to some excellent MSDN articles.

Identity Management

The document starts by outlining the best practices within Identity Management and Access Control and how that applies in general and to the cloud. One reference in particular is the use of Windows Identity Foundation or “WIF” along with ADFS and using AppFabric. I have worked with WIF in the past outside of the cloud, and while being quite complicated to understand, when you understand the basics (or play around in Visual Studio with a Secure Token Service for a while) it becomes very powerful quite quickly.

Service Layer

Then the paper starts to look into specific development considerations for the service-layer.

One consideration similar to most cross site scripting issues within web technologies is to use the Anti-Cross-Site-Scripting Library and using the ASP.NET Page.ViewStateUserKey to mitigate against Cross-Site Request Forgery attacks. This article is excellent at explaining how the attack works and what is needed to mitigate against it:

Now specific to Azure, is where the (hosting) Namespace and scopes. As all azure services are hosted on *ServiceName*.cloudapp.net, it is worth pointing out that the best practice is to use a custom domain name which you have full control over, and using a CNAME to do the redirection:

Infrastructure Layer

As Windows Azure deals with a lot of the infrastructure, items here are mostly within the configuration and definition of the service you write. The ports open for example are explicitly defined within your Azure project.

example here of the Web Role:

Due to the nature of the Load Balancer within the Azure environment, Denial of Service attacks are partially mitigated, and the Azure team are also reviewing additional Distributed Denial of Service (DDoS) attacks.

The paper goes into quite deep technical detail around Spoofing, Eves dropping and Information Disclosure on a network level, and explains the Hypervisor’s role and network structure of the hosted solution.

Trust

Azure has both a custom, restricted-privilege trust model called “Windows Azure Partial Trust” and Full trust with Native Code Execution. Though unless you need specific scenarios such as:

The “Gatekeeper” Design Pattern

A recommended design pattern is to use the concept of a gatekeeper running under partial trust as a webrole to accept requests and messages and a KeyMater worker role which acts as a data provider.

The Gatekeeper can talk to the KeyMaster via an internal endpoint over HTTPS if the requests are immediate or via the Azure Storage Queue. This also allows a separation for sanitizing the requests going to the KeyMaster and therefore the final Storage at the Gatekeeper level where the potential service of attack is small. These 2 roles will be deployed on separate VM’s so if the GateKeeper is compromised, no storage information will be.

Sanitizing and processing the requests are still subject to secure design and coding consideration, though this will provide additional levels of security to protect the data at the heart of the application.

Also note that ViewStateUserKey = Session.SessionID; can be made quite a bit less secure if an attacker can force you to have a particular session id that they know of (which asp.net happily accepts any session id cookie and creates a session with the provided id) . If you are looking to mitigate that, ensure you manage the session cookie on login and logout.