× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes there are a lot of vendors selling software based solutions to encrypt
your data at rest. However we're talking about two different things here.
One, querying your data from your applications.
Two, being able to use tools to read the disk, even from from another OS,
to see the data (like after a disk sell after an upgrade or whatever)

Keep in mind that if you are using 24 disks your data may be spread across
all 24. To go "NCIS" on them and read the data from disk independent of
the OS, and read the entire data file would require that you can once
again string all the drives together. Now, due to blocking, you may be
able to get small snippets from a drive here and a drive there. One row
from one table may fit into that same block and all be on one drive. And
if that row contains your name, SSN, etc, I can understand how you may be
concerned. Encryption would help.

But as far as encryption from your applications, that's another matter. I
suspect that many people are bombarded from 'regulatory agencies' and
other do-gooders who insist upon encryption. So, you use some built in
disk encryption tool and, yes, your data at rest is encrypted. Big
whoopie. Someone runs this:
select name, mothersmaidenname, ssn, yearlysalary, creditcardnumber from
myfile
and the hardware disk encryption automatically decrypts it and presents
the data.
So, now they go with a more software encryption technique. In which the
columns have to be run through something like
select name, mothersmaidenname, decrypt(ssn, key), yearlysalary,
decrypt(creditcardnumber, key) from myfile
(syntax is incomplete, just go with it)
so now they need the key. This leaves you with a few choices.
You can bury the key in every application. First person to look at the
source now knows the key.
You can externalize the I/O. All the rage from the person who codes
externalized I/O. Not so favored by anyone who has to use someone else's
externalization routines and can no longer use SQL.
You can create a view that has all the decryption performed automatically.
create view myfileVIEW as (select name, mothersmaidenname, decrypt(ssn,
key), yearlysalary, decrypt(creditcardnumber, key) from myfile). So the
table is 'encrypted' and now the person can simply do "select name,
mothersmaidenname, ssn, yearlysalary, creditcardnumber from myfileVIEW".
Probably gets the regulatory agencies off your back because technically
your data is 'encrypted' but is it really that secure?





Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.