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:
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.
As the Windows Azure administrator you need to upload the private key to Windows Azure, here are the steps to do that:
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.
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?
