Should we bother with cell-level encryption for an ASP.NET/SQL Server web application?

Question

(Cross-posting this here on the advice of a user at stackoverflow...)

Got a philosophical security question for everyone. I'm sketching out an ASP.NET web application design where sensitive data for different organizations/clients will be stored in a SQL Server database. User authentication will use ASP.NET Forms Authentication.

Encrypting the entire database using Transparent Database Encryption (TDE) is a no-brainer. But I'm curious if we should bother with cell-level encryption (using something like the SQL Server Label Security Toolkit found at codeplex.com: SQL Server Label Security Toolkit).

If we were to do cell-level encryption, then we could associate each user of an organization/client to a single SQL user account that has the ability to read/write data for their organization. So, in case a SQL user account was compromised, it would limit the data access to just that single organization.

But let's suppose we created a single SQL user account/password that is only intended for the web application to communicate securely with the database (no direct access to the database for reporting purposes will be allowed). We can set it up with a sufficiently long, randomly generated password, with those credentials stored encrypted in the web.config file.

At this point, have we sufficiently secured access to sensitive data in the the database (assuming the application limits what is displayed, of course)?

In other words, suppose we had multiple SQL user accounts with ridiculously long passwords encrypted in the web.config file. If one of those SQL user accounts were compromised, then that would mean a security flaw exists that would likely mean all the SQL user accounts were compromised. So, no security value-add really exists.

(The most compelling reason I can think of to do cell-level encryption by client-specific SQL users would be to prevent a security hole in the actual web application from displaying data from another client.)

Hope the question makes sense. Be interested to hear other's thoughts on this! Thanks in advance.

Answer 1

I think the answer to your question pivots on a slightly different perceptual view - which is, where does the decryption take place?

Technologies like TDE function at the database level. In practical terms, this often means that a DBA - or someone who has compromised appropriate privileges - can access the decrypted data and structure.

Cell-level encryption, on the other hand, may more commonly be implemented at the application layer. Which means that the DBA will never have the ability to access anything other than an encrypted blob; the key to decrypt it is (should be) sequestered at the application level. This is valuable because, in both security and compliance worlds, dual control is a powerful ally. The application engineers can decrypt data, but only if they grab a lot of it from the database, which is usually not subtle. The database administrators can grab lots of data, usually subtly, but if they can't decrypt it then control is preserved.

When you're thinking about which makes sense, you need to think about the threats you're concerned with. If you're just worried about cold disks and backup tapes, TDE covers your concern. If you're worried about the attack vectors into a live functioning application+database pair, TDE makes less sense and you may want to consider more fine-grained controls that separate the decryption capability from the data store.

If you have multiple co-located applications with different encryption keys which enable access to application-specific encrypted blobs on a shared backend, then yes, that may offer you more security... but it has pits you need to think about. An attacker gaining some control of the app server is the standard worst case scenario. If they gain access to the app server, can it gather decryption keys from the multiple apps and negate the separation? You can't really separate apps with encryption keys if they're all on disk, in memory, and executing on the same app server, at least not as a security control. That's where you'd want other controls, such as separate app servers, to help protect your data.

Please note that I've used weasel words like in practical terms, may more commonly be, should be, and not subtle/subtly. I'm aware I may not be answering your direct question given the technologies you're listing; I'm recasting the question into a more theoretical bent so that you can try and map your options onto concepts and work back from there.

Good luck!