Illegitimate Legitimate Access to Data
One of the points I made in yesterday’s editorial was that TDE is great for data at rest, but it doesn’t help with "legitimate" access.
A couple of people wrote asking what exactly that meant – legitimate access – I mean, surely there’s authorized access and "everything else," right? Well, sort of. You protect access to your database by providing for user names and passwords, and access rights. Encryption is in place if someone gets to the underlying files.
The issue can come in if you build views, or have transparent encryption approaches you’re using. Where, if the user is valid in the system, you take care of encrypting and decrypting automatically when information is retrieved. While this is handy, it presents an issue. If someone comes in on a user id that is valid, they get the data. This could be from a hacked application, could be from a username and password that became known to them, etc.
In each of these examples, the data would be dutifully decrypted automatically when the user SELECTs against it. This is what I was calling "illegitimate legitimate" access. Someone is using a valid means of getting in (the user name, the application, etc.) but they have no business doing it.
You really have to consider these types of access when you are putting your data protection strategy in place. It’s important to consider these types of access as well. Examples of this include SQL Injection – because the access is happening over a "valid" connection – but has no business in the database.
It’s really important to consider your security in layers. Think about the access controls, items to protect and having many different layers of management and protection.