Securing Your Connection String in Windows Azure: Part 2 - SQL Azure Team Blog - Site Home - MSDN Blogs

Securing Your Connection String in Windows Azure: Part 2

Securing Your Connection String in Windows Azure: Part 2

Rate This
  • Comments 2

This is the second part in a multi-part blog series about securing your connection string in Windows Azure. In the first blog post (found here) a technique was discussed for creating a public/private key pair, using the Windows Azure Certificate Store to store and decrypt the secure connection string. In this blog posts we are going to cover how to import the private key to Windows Azure.

In this technique, there is a role of the Windows Azure administrator who is the private key holder. His job is to:

  • Create the private/public key pair and choose the password to secure the private key. Find out how to create the key in the previous blog post.
  • Backup the private key and password.
  • Deploy the private key to the Windows Azure Certificate Store.

Because the Windows Azure administrator has access to the private key, he can decode the connection string and figure out the password to the production database. He has the same access as the code running on Windows Azure.

Importing the Private Key to Windows Azure

As the Windows Azure administrator you need to upload the private key to Windows Azure, here are the steps to do that:

  1. Using your browser navigate to the Windows Azure Developer Portal.
  2. Select the Hosted Service component to deploy to. Under the Certificates heading, select Manage.

    clip_image002

  3. Upload the private certificate that we created in part 1 and use the password used when creating the private certificate.

    clip_image004

  4. Copy the thumbprint given by Windows Azure to your clipboard; you will need this for the web.config file.

    clip_image006

The thumbprint is hexadecimal string that contains the SHA-1 hash of the certificate. It can be used by the code running on Windows Azure to gain access to the private keys installed on Windows Azure. We will use this in our web.config to tell the custom encryption provider the certificate that we just uploaded. There is nothing secure about the Thumbprint, it can be seen by everyone but only code with access to the private key can decrypt the connection string.

Summary

In part three of the blog series I will show how the SQL Server Administrator uses the public key to encrypt the connection string. Do you have questions, concerns, comments? Post them below and we will try to address them.

  • In this model, is the db connection string sitting on the Web Role? If yes, are we sure that a compromise of the web role will not result in the access to the DB getting compromised?

  • Julia:  I am getting to that in part 4, however the answer is yes.  The web.config + the private key and you will be able to decrypt the connection string.  So if the attacker is able to deploy code to the web role, then they will be able to gain database access.  However, they can not  just download the private key from the management interface -- so they would have to publish code to the web role to gain access to the private key.  So my question is how do you publish code and not "delete" the web.config?  In other words the attacker would have to have the web.config to publish it with the compromising code, an inside job?

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 1 and 5 and type the answer here:
  • Post