Location: BlogsBlogland
Posted by: host	7/18/2008 7:02 AM
Encryption is a valuable tool in protecting sensitive data from those who are not authorized to view it. It is often stated that cryptography is the last line of defense in the myriad of security technology and methods that can be applied to any given system. With encryption comes a collection of new problems and challenges that the developer and DBA will have to face; but certainly these issues pale in comparison to the consequences of disclosing sensitive data to unauthorized entities that may have a less than honorable intent for gaining access to the data. Throughout the internet there are countless examples of how encryption can be implemented in ASP.NET (and other languages such as PHP). I have employed these methods in past projects to obfuscate connection strings in the web.config as well as passing sensitive data to the database. There are also many examples of how encryption can be implemented in SQL Server; although not quite to the volume of our UI friends. A spectacular example of such information is an article written by Eric Peterson and Siging Li at 4GuysFromRolla.com back in February of 2007: http://aspnet.4guysfromrolla.com/articles/021407-1.aspx http://aspnet.4guysfromrolla.com/articles/022107-1.aspx http://aspnet.4guysfromrolla.com/articles/022807-1.aspx The scope of encryption can extend to the entire database or down to the specific column of a table. For the benefit of protecting sensitive data, the scope that I am specifically referring to in this blog entry is at the column level. All of this begs the question: Should encryption occur at the user interface or should it occur at the database engine? I would entertain the response to be that encryption should occur at both locations. The basis of that thought is that the user interface developer cannot depend on the database containing functionality to protect sensitive data. Also, the database developer cannot depend on the data that they are receiving from the user interface to be cleansed and protected. While this approach may introduce redundant efforts; but it also ensures that there are less security vulnerabilities in the system. There are certainly benefits of encrypting sensitive data before sending the data from the user interface to the database. The most obvious would be that if the data that is making the journey to the database is snagged enroute it would be unusable to the perpetrator.  Also the resources that are required to encrypt the data would be housed at the client or web server rather than the database server. As a database developer there are responsibilities of enforcing data security. When data is received, I need to make sure that the user is authorized to do so. I must ensure that the data does not contain any damaging content (ie: SQL Injection). I must ensure that the data meets the constraints that have been defined by the table and columns to ensure data integrity. I also must ensure that the sensitive data that I receive is adequately protected. SQL Server 2005 offers some encryption methods built-in to the database engine. SQL Server Books On-Line (BOL) offers some good information in regard to these methods. Since the topic of sensitive data is the vehicle in which I am writing on the subject of encryption, the advocated method by BOL for such efforts is the use of symmetric keys. SQL Server 2008 offers a feature called Transparent Data Encryption (TDE). The following link provides an introduction to this feature: http://technet.microsoft.com/en-us/library/cc278098(SQL.100).aspx . As I explore this feature I am sure additional blog entries will spawn from that effort.
Permalink |  Trackback