Re: Has IDS 9.5 been released?
it depends on how its being implemented. Just because you have a feature doesn't mean its optimal or works the way you would want it, or is as secure as you think it is. ;-) Example. You have a column that you want encrypted. So you treat it as a blob, so you encrypt the data but you can't index it. Or if the column in the row is encrypted, and you can index it, is the index of the column also encrypted? Which encryption scheme do you use? Can you allow for a system call to encrypt/decrypt so you can use hardware based encryption for faster throughput? All sorts of design and implmentation decisions that you should think out ahead of time. But hey, what do I know? Its not like I asked this from Informix back in '98.... ;-) Hari Gupta wrote: > Wow !!!!! Col. level ebcryption. What a great feature. This is what I > was looking for a long time as Oracle has it from a long time. Well > done guys. This will be another major step towards implementing best > practice for database security at our work. Would be great to know > more details of new features.
If the data is encrypted by the user (as oposed to by the system) then how could the DBMS index the data without knowing the key? Cheers Serge
Serge Rielau wrote: > If the data is encrypted by the user (as oposed to by the system) then > how could the DBMS index the data without knowing the key? > Well thats exactly the point. Anyone can write an application that encrypts the data and inserts the data in to the DB as an encrypted blob. But how useful is it? You'll need to store other unencrypted data to pull up your encrypted record. Then you have to have the app that stored the data unencrypt the data. Not very useful. Thats why I said it was important in how the feature was implemented. Imagine a law firm. You will want to encrypt your client's information, yet you'll want to limit access to yourself, the firm's partners, and maybe the specific paralegal working on the case. You would then want to restrict access to everyone else. Now you want your billing program to pull data from the database, task description, hours, client id, and rates. All encrypted. You'll have to have unencrypted data, or layers of encryption at the field level. Non trivial yes. Rocket Science no. Why encrypt everything? Simple. Try reading a database page if everything is encrypted. ;-)
Aha, different levels. One level is that I want to encrypt my personal data. that wudl be my password. The data that is not meant to be correlated, joind, mined, etc. and most certainly not to be decoded by even the DBA! And then there encryption of the data in a more general sense. Like on the wire, on disk, etc. I think these are very different requirements. Both valid. Cheers Serge
Serge Rielau wrote: > Aha, different levels. > One level is that I want to encrypt my personal data. that wudl be my > password. The data that is not meant to be correlated, joind, mined, > etc. and most certainly not to be decoded by even the DBA! > And then there encryption of the data in a more general sense. > Like on the wire, on disk, etc. > I think these are very different requirements. Both valid. > I don't see how what you want to do is database specific. Your application will do the encryption and store your "personal" information as a blob of some sort. You already have a mechanism for weak encryption over the wire too. Remember that Tom Cruise movie "The Firm"? They had all those files in that locked closet at the company's tropical retreat? Imagine if they were all electronic and you wanted to secure them in to a data base for easy access, yet you could log who viewed them and restrict what they could see. ;-) Granted thats more of an e-records management scenario, but you get the idea.