Security Best Practices in Azure
Recently the Azure and security community published the “Security Best Practices for Developing Windows Azure Application” paper on download.microsoft.com:
Outlining the security considerations developers should consider when building a service on Windows Azure.
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.
Guide to Claims Based Identity
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:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
:
}
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:
This way no other applications running under the cloudapp.net domain can script to your service using your custom domain without XSS.
Secure Data
As Azure storage uses a Shared Access Signature to allow your service to read and write to blobs/queue/tables, there is a guideline to minimizing risk of using a Shared Access Signature:
· Generate Shared Access Signatures with the most restrictive set of ACLs possible that still grant the access required by the trusted party.
· Use the shortest lifetime possible.
· Use HTTPS in the request URL so the token cannot be snooped on the wire.
· Remember that these tokens are only used for temporary access to non-public blob storage – as with passwords, it’s a bad idea to use the same ones over and over.
It is also suggested for data protection to encrypt data with certificates as DPAPI is not available, and deploy them using the Azure Certificate Store and not in Azure Storage such as blobs:
My Previous Blog on this subject
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:
· Use of FastCGI or PHP.
· Migration of traditional web services to the cloud.
· Role invocation and spawning Windows sub-processes (native code or managed).
· Calls into native libraries via P/Invoke (Platform Invocation Services).
If these scenarios are not needed then you should have Windows Azure Partial Trust enabled:
To run your role under partial trust, you must add the enableNativeCodeExecution attribute on the WebRole or WorkerRole element and set it to false.
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 workerrole 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.
· Secure design, including the following topics:
· Secure coding, including the following topics:
· Managed code security (transparency, code access security, assembly strong naming, etc.)