Encrypting Connection Strings in Windows Azure Applications

Following on from my previous blog post that talked about data encryption in Windows Azure storage, I now want to take a look at the encryption issues around using SQL Azure, and in particular, connection strings.

Before looking at encrypting connection strings, a reminder of some SQL Azure specific security considerations.

SQL Azure Firewall

You can use the SQL Azure firewall to restrict access to your SQL Azure server, either by specifying a range of IP addresses for external access, or by limiting access to other Windows Azure services only. However you should be aware that limiting access to Windows Azure services still means that anyone who knows your SQL Azure credentials could access your database from their own deployed Windows Azure applications. Restricting access to Windows Azure services doesn’t restrict access to just your subscription.

SQL Azure Authentication

SQL Azure only supports SQL Server Authentication, not Windows Authentication. This means that the username and password you use to connect to SQL server will be stored in the connection string in your Web.config or App.config files.

Vulnerabilities

The focus of this blog post is on what you can do to protect your SQL Azure credentials and your SQL Azure databases from unauthorised access.

There are three locations where someone could potentially discover your SQL Azure credentials from your application’s Web.config or App.config files:

1. From your code base before the application is deployed to Windows Azure.
2. From your deployed Windows Azure application. If someone gains unauthorized access to your Windows Azure account, they may be able to read the contents of your Web.config or App.config files.
3. From a disk drive that has left a Windows Azure datacenter.

If someone gains unauthorized access to your Windows Azure account, they will only be able to read the contents of your Web.config and App.config files if you have already deployed your application with Remote Desktop Access enabled. Remember that you can't add the Remote Desktop Access feature to an application after it has been deployed, and it's unlikely you'd want to use the Remote Access feature in a production environment anyway.

In the previous blog post I referred to Microsoft's policies and procedures that relate to hardware disposal. These policies are designed to ensure that all hard disks from Windows Azure datacenters are either securely wiped or securely destroyed at the end of their life.

The key vulnerability in respect of connection strings in your Web.config and App.config files is therefore before you deploy your application to Windows Azure.

Mitigations

There are two ways that you could mitigate the risk of someone discovering your SQL Azure credentials from your application's source code before it gets deployed to Windows Azure.

• You can implement a process that replaces any connection strings for test and development databases with a connection string for your production database as part of a secure build and deployment process. This way, developers and testers don't need to know the connection string for your production database. Developers and testers can work with test databases that use different credentials from the production database.

• You can use the Pkcs12 Protected Configuration Provider. This enables your SQL administrator to encrypt the connection string in the Web.config or App.config file before giving it to the developers and testers. With this approach, no one other than the SQL administrator needs to know the SQL Azure credentials; this might be important of the person responsible for managing deployment to Windows Azure is different from the SQL Azure administrator. This has the additional advantage that the connection string cannot be read even if someone gains access to the configuration file through either Remote Access or by obtaining a physical disk that has not been wiped or destroyed.

Its important to note that both of these approaches depend on correctly designed and executed procedures for developing, testing, and deploying code to Windows Azure. You should also have procedures in place to ensure that all code (and especially data access code) is fully reviewed before it's deployed to your production system to verify that it doesn't inadvertently expose any secure data when it shouldn't.