Rich posted an article on database and media encryption (aka Data at Rest) earlier this week, discussing the major alternatives for keeping database media safe. Prior to posting it, he asked me to preview the contents for accuracy, which I did, and I think Rich covers the major textbook approaches one needs to consider. I did want to add a little color to this discussion in terms of threat models and motivation- regarding why these options should be considered, as well as some additional practical considerations in the use and selection of encryption for data at rest.
Media Encryption: Typically the motivation behind media encryption is to thwart people from stealing sensitive information in the event that the media is lost or stolen, and falls into the wrong hands. If your backup tape falls off the back of a truck, for example, it cannot be read and the information sold. But there are a couple other reasons as well.
Tampering with snapshots or media is another problem encryption helps address, as both media and file encryption resist tampering- both in long-term media storage, and file/folder level encryption for short-term snapshots. If a malicious insider can alter the most recent backups, and force some form of failure to the system, the altered data would be restored. As this becomes the master record of events, the likelihood of catching and discovering this attack would be very difficult. Encrypted backups with proper separation of duties makes this at least difficult, and hopefully impossible.
In a similar scenario, if someone was to gain access to backups, or the appliance that encrypts and performs key management, they could perform a type of denial of service attack. This might be to erase some piece of history that was recorded in the database, or as leverage to blackmail a company. Regardless of encryption method, redundancy in key management, encryption software/hardware, and backups becomes necessary; otherwise you have simply swapped one security threat for another.
External File or Folder Encryption. If you rely on smaller regional database servers, in bank branch offices for example, theft of the physical device is something to consider. In secured data centers, or where large hardware is used, the odds of this happening are slim. In the case of servers sitting in a rack in an office closet, this is not so rare. This stuff is not stored in a vault, and much in the same way file and folder encryption helps with stolen laptops, it can also help if someone walks off with a server. How and where to store keys in this type of environment needs to be considered as well, for both operational consistency and security.
Native Database Object Encryption: This is becoming the most common method for encrypting database data, and while it might sound obvious to some, there are historical reasons why this trend is only recently becoming the standard. The recent popularity is because database encryption tends to work seamlessly with most existing application processes and it usually (now) performs quite well, thanks to optimizations by database vendors. As it becomes more common, the attacks will also become more common. Native database encryption helps address a couple specific issues. The first is that archived data is already in an encrypted state, and therefore backups are protected against privacy or tampering problems. Second, encryption helps enforce separation of duties provided that the access controls, group privileges, and roles are properly set up.
However, there are a number of more subtle attacks on the database that need to be considered. How objects and structures are named, and how they are used, and other unencrypted columns, can all ‘leak’ information. While the primary sensitive data is encrypted, if the structures or naming conventions are poorly designed, or compound columns are used, information may be unintentionally available by inference. Also, stored procedures or service accounts that have permissions to examine these encrypted columns can be used to bypass authorization checks and access the data, so both direct and indirect access rights need to be periodically reviewed. In some rare cases I have seen read & write access to encrypted columns left open, as the admin felt that if the data was protected it was safe, but overwriting the column with zeros proved otherwise. Finally, some of the memory scanning database monitoring technologies have access to cached data in its unencrypted state, so make sure caching does not leave a hole you thought was closed.
Hopefully this went a little beyond specific tools and their usage, and provided some food for thought. You will need to consider how encryption alters your disaster recovery strategy, both with the backups, as well as with encryption software/hardware and key management infrastructure. It affects the whole data eco-system, so you need to consider all aspects of the data life-cycle this touches. And some of you may consider the threats I raised above as far-fetched, but if you think like a criminal or watch the news often enough, you will see examples of these sorts of attacks from time to time.
Comments