Data Security in SQL Server (and other databases)
If you have sensitive data (e.g. HIPAA data), you need to consider both encryption as well as SALTING of your data at the database level.
Encryption
Prior to 2008, SQL Server data encryption was a somewhat involved process. With the introduction of TDE (transparent data encryption), SQLServer encryption is now a matter of a simple configuration change.
In TDE, only the data in memory (buffer cache) is unencrypted. Anytime memory writes out to disk, encryption kicks in. And when reading data from disk, decryption kicks in. It’s a simple and highly effective solution.
Applications are unaware that this is happening – they retrieve data as before – and are able to see decrypted , plain text data. A hacker who makes it to your filesystem will see only encrypted data.
— TDE (transparent data encry) operates at the I/O level.
— It is designed to provide protection for the entire database at rest without affecting existing applications
Salting
Salting data is a hashing technique – a 1-way hash that makes the salted data undecipherable. Once data is salted , it cannot be recovered (in its original plain text form). All that can be done is the salted hash can be compared against a similar hash – to ensure that both hashes match. A password is an example of a field you would want to SALT – even the original user will not be able to recover their plain text password. Once salted , it is no longer stored in its original form –it is hashed irretrievably. The only thing the user can do now is CHANGE Their password.
These are some of the common strategies for securing your data in SQL Server (or any database that supports encryption and salting).
Leave a Reply