Data Encryption

Is there anyone out there practicing data encryption in
their database ? Column data or table data (Not Stored
P.). If so, how can I apply it to my database too ?
Management wants even the data in the tables encrypted to
the DBA.
If there are any third party utilities out there, can
someone direct me to them ?.
T.I.A
You can find some third party tools listed in the encryption
section of this FAQ:
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=22
-Sue
On Fri, 11 Feb 2005 08:34:10 -0800, "Chris"
<anonymous@.discussions.microsoft.com> wrote:

>Is there anyone out there practicing data encryption in
>their database ? Column data or table data (Not Stored
>P.). If so, how can I apply it to my database too ?
>Management wants even the data in the tables encrypted to
>the DBA.
>If there are any third party utilities out there, can
>someone direct me to them ?.
>T.I.A
|||In message <210201c51057$83d37640$a601280a@.phx.gbl>, Chris
<anonymous@.discussions.microsoft.com> writes
>Is there anyone out there practicing data encryption in
>their database ? Column data or table data (Not Stored
>P.). If so, how can I apply it to my database too ?
>Management wants even the data in the tables encrypted to
>the DBA.
>If there are any third party utilities out there, can
>someone direct me to them ?.
>T.I.A
Personally, I have embedded AES within one of our Utility DLL's and when
I need to protect columns (ie: passwords or pin numbers - anything
really) it is called prior to updating SQL Server (ie: via INSERT or
UPDATE).
Secondly, it is very rare that this data needs decrypting (or else
what's the point) so only ever compare encrypted values in SELECT's.
There are some third party utilities that can help with this issue (try
Google) but from experience I would tell Management that you could
provide encryption to individual columns but its not practical to
implement this for all data (after all there is a big overhead,
specially on large databases).
The best protection for the database from users is for the DBA to set it
up right in the first place by using SQL Logins to restrict access to
only the tables, views and stored procedures they require. This then
means of course that the applications accessing the data use the right
credentials for the each operation, feature and user (ie: by design).
As for protecting the data from DBA's I would suggest this is done by
employing the right people in the first place; adding various clauses to
employment contracts; signing NDA's; and of course threatening with very
serious law suits and of course don't forget the base ball bats <g>.
The ultimate protection for the database from everyone (specially those
in Management) would be to turn the Computer OFF; Lock it in a Nuclear
bunker; destroy the key and then burn the maps to its location. <g>
Alternatively, don't store the data in the first place. <bg>
I think Yukon might have some new features in this area as well, however
someone else will need to answer that one. Besides, Yukon is not hear
yet !
Andrew D. Newbould E-Mail: newsgroups@.NOSPAMzadsoft.com
ZAD Software Systems Web : www.zadsoft.com