Advice for Securing Data in Windows Azure
In a recent MSDN article entitled Crypto Services and Data Security in Windows Azure, Jonathan Wiggs provides advice on securing data stored and processed through Windows Azure. InfoQ explored the topic in more detail to understand some of the security ramifications which come with deploying an application to the cloud.
When working with Windows Azure, Wiggs advises the use of the basic cryptographic support offered by Cryptographic Service Providers (CSP):
A consistent recommendation is to never create your own or use a proprietary encryption algorithm...
the algorithms provided in the .NET CSPs are proven, tested and have many years of exposure to back them up.
He also suggests using the RNGCryptoServiceProvider class for generating random numbers because this ensures a high entropy of the numbers generated making it difficult to be guessed.
CSP offers support for encrypting data and signing messages, but all of that is done with the help of encryption keys which are basically strings. Properly storing and protecting these keys is paramount in ensuring adequate data security. Windows Azure does not keep data encrypted by default, while SQL Azure does not provide encryption yet, according to Wiggs. The first rule in using security keys is:
No application should ever use any of the keys provided by Windows Azure as keys to encrypt data. An example would be the keys provided by Windows Azure for the storage service. These keys are configured to allow for easy rotation for security purposes or if they are compromised for any reason. In other words, they may not be there in the future, and may be too widely distributed.
Wiggs proposes using Azure Storage services for storing key libraries to benefit from the security provided by these services. The cryptography keys could be stored in a text file through the blob service API:
You start by persisting a key in a CSP key container. This is a great option for storing a public key that is difficult to retrieve without physical access to the server. With Windows Azure, where the location of applications and data is abstracted, this would make even a public key stored in this manner extremely difficult to find and retrieve.
However, the article does not mention though how to protect the storage keys - this leaves the issue open for the user to solve. In order to protect the cryptography keys, Wiggs proposes several solutions:
- Replace the keys regularly
- Make them available only to the people who need to have access to them
- Diagram the flow of data to be aware how data is consumed and by who, so that you can evaluate the risks involved and determine how to deal with them
Even with the introduction in SQL Server 2008 of Transparent Data Encryption (TDE), a feature that encrypts/decrypts data sent to the database on the fly, SQL Azure does not support database-level encryption. As a result it should not be counted on yet, according to Wiggs. But SQL Azure has a different security tool, a firewall:
It lets you allow or prevent connections from various sources, all the way down to specific IP addresses or ranges. The SQL Azure firewall can be managed via the SQL Azure portal or directly in the master database with the provided stored procedures such as sp_set_firewall_rule and sp_delete_firewall_rule.
The last advice on protecting sensitive data is to avoid using immutable data types like String. Upon creation, such an object remains in memory for a long time, and that piece of memory may be allocated to another application of another user which might try to read through allocated memory to see if there is something valuable to find out. Wiggs suggests keeping crypto keys or other sensitive data in byte arrays which should be overwritten with zero as soon as they are no longer used.
Cloud computing offers new computing opportunities, but it also raises new security issues due to new potential ways for data theft. Cloud companies are likely to consider data security a top priority and do their best to provide it, but users need to contribute to making their applications and data more secure in order to lower the likelihood of their data being stolen.
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014