A good article providing an overview of Information Security especially from a database professional's prospective is found at DBTA. The author presents a general overview of information security including the concepts of data at rest and data in motion. "Data at rest" is a term that describes data while being stored in a database or other mechanism. This type of data can be vulnerable to theft from external sources through exploits, but more often it is vulnerable to theft by internal sources, knowingly or unknowingly. An example of this would be a rogue employee who knowingly sells a copy of the company database to a competitor or to someone who performs identity theft. Another example might be an employee who unknowingly leaves a laptop unsecured and has the laptop stolen from them. Both examples show how data at rest can be vulnerable.
The question is how do protect such data. Encrypting the data at rest would be a necessary solution, but exactly how and when to encrypt the data would be the question. For instance since Windows 2000 the Encrypted File System (EFS) could be used to encrypt the underlying database file (HOW-TO). This would certainly protect your data from the employee who unknowingly has his or her laptop stolen while housing the database. It would also give a measure of protection from a rogue employee who has network access to the database file system, but who does not have the user account password with which the data was encrypted with. However it does not protect against an intruder who uses a SQL Injection attack to compromise security and it does not protect against a System Administrator who knows the SQL Server service account password.
A solution to protecting against these types of attack would be to put encryption in place inside the database at the column level. Implementing a solution in SQL Server 2000 would have meant writing custom data layer code in order to implement the encryption, but with SQL Server 2005 we have functions to perform column level encryption/decryption (HOW-TO). These functions allow for assymetric (public/private keys) and symmetric (shared key) algorithms. This would mean that even if an unauthorized person were able to gain physical access to the database file the sensititive data within that file could still be protected. This would protect against even a database administrator who knew all the passwords, but did not have access to the encryption key.
Of course there is always a downside. First and foremost is performance. If you use the column level encryption then understand that searching for data in even simple queries will take exponentially longer than unencrypted versions. Balancing performance with information security is also a tradeoff, but when a compromise occurs erring to the side of security never hurts. The same cannot be side of erring to the side of performance.
The second downside is not really a downside but a matter of risk and that is hiding the key. Any encryption algorithm is only as strong as the key and how well it is hidden, however to make use of the data the key has to be available to the database and/or applications. SQL Server 2005 can store the key for you, but again if the key is stored unprotected with the data on a laptop then if the laptop is stolen then the data should be considered compromised. SQL Server 2005 can protect the key and uses 3DES to do so (HOW-TO). Understanding how SQL Server 2005 protects this key should be understood as having the key compromised would unlock the data.
Subscribe to:
Post Comments (Atom)
2 comments:
Nevada legislation requires encryption of data in motion. Legislation pending in Michigan and Washington would require encryption of data at rest.
Thanks for pointing out this good article! It just describes those concepts that are rarely heard from public but Sure, you ask yourself a question 'how you can do that' and when the best you can do that to lessen the impact on the system and avoid abusing security. Of course EFS is once on the first things that occurs to you when you start thinking about securing your data. But encrypted file system is a double-edged sword and it's strongest and at the same weakest side is that it encrypts the whole file system. If you lost your encryption and recovery keys all the encrypted files are lost. At the first glance it looks like 'heck, who forces you lose the keys'. Don't lose the keys and you are safe and cool. But it comes that sometimes that's hard to go this way. If your boot partition goes cranky you'll lose your keys and thus the data. If you reinstall your system and you don't have backup keys you'll lose your data. The answer is that it doesn't matter if your files are stored on your boot drive or not. They may be stored anywhere but since everything is tied to your system and the keys that were generated for you, you lose everything if you lose your 'key'-player - the system and don’t' have a user and revocation keys to restore. You know, the Murphy's "Anything that can possibly go wrong, does". It kinda reminds me of NTFS compression. It's a great stuff when you work with small files but it's a nightmare when you have to handle big files as big as database files are. So I am not saying that EFS is a bad technology. I am about to say that you have to use it smartly. You don't have to use a bazooka if you have nice small army-knife that does all that you want and solves your problem with a minimal excess. That's what I've got myself when I switched from a EFS-based solution to a specialized solution for managing SQL databases from Scriptlogic called LiteSpeed. Not only I love this tool that I can do separated encryption of specific SQL DBs with this tool but I also love that I can further enhancing SQL security since as you've said here this provides for a inject-proof protection. What's more, I can apply compression to a database thus making it even harder to reverse engineer the database structure. Talking about performance of such a solution I'd say that it's probably thanks to a flexible parameter tuning that I can apply to a database by choosing from a dozen of options available for choosing for compression and various configuration settings I can choose while selecting encryption algorithm and the key length used for it. I prefer using AES algo with 256-bit long key when I store a backup to a remote network storage and something like 56-bit RC2 for storing to a local safe place. Then I set compression based on the same idea . I prefer the best available level of compression to store the backup remotely and select something like level 5 or so to compress the databases that I store locally somewhere within the internal network perimeter. By the way, I loved controlling process affinity since recently. That allows me easily redistribute performance on my brand new 4-core Intel E3110.
Post a Comment