Fred schreef:
> Thanks a lot for theses explanations .
>
> Ok, for TDE, i don't see interest because any user can see data.
>
> So i can take DBMS_CRYPTO to encrypt data, but i want also that anybody
>
> could see data , is it possible ? (DBA also).
> Just one user can see his own data. do you see what i mean ? each user
> will see their data in clear text, but the whole database will be
> encrypt.
>
> I don't know if it's possible with 10g.
>
> Thanks
>
>
>
> frank.van.bortel_at_gmail.com wrote:
>> Fred schreef:
>>
>>> Hi,
>>>
>>> You're right, just a different key by lines and not an algorithm.
>>>
>>> Is it possible and how to implement it ?
>>>
>>> In fact we want to encrypt an big entire database. advice for that ?
>>>
>>> Also, I don't see the difference between TDE and DBMS_CRYPTO.
>>> In one hand we crypt data into the database but user can see clear
>>> data.
>>> In the other hand how we can use DBMS_CRYPTO to encrypt data of all
>>> columns on one table ?
>> Any idea what TDE does? I'll tell you a secret: it stands for
>> Transparant Data Encryption.
>> Transparant in a way, you can see the "clear data", but only when the
>> Wallet is activated.
>> Try to query your data with the Wallet disabled.
>> I have a write-up on TDE on
>> http://vanbortel.blogspot.com/2005_07_01_vanbortel_archive.html
>>
>> DBMS_CRYPTO needs to be called for every insert/query; you can call it
>> with a different key for eevry row - the problem I see is where to keep
>> your keys; you hardly want to store them in the same row (as I suspect
>> security is the issue here...)
>>
>> >From what I understand, DBMS_CRYPTO is the only way to go. It allows
>> the use of a different key eevry time it is called, and so enables you
>> to do what you propose.
>>
>> But encrypting a whole database?!? Why? Is *all* your data worth
>> encrypting?
>
Hm seems my salutation is gone when posting through google groups, so
I'll respond to this one:
Like Ed said: VPD is what you want - it does not encrypt, but enforces
extensions to the where clause of every select you want.
Effectively, this means user A can only see what you design user A to
see.
I still fail to see why you would like to encrypt your data. Realize
there is a performance penalty in encrypting/decrypting.
It's a CPU intensive process!
--
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
Received on Wed Aug 23 2006 - 12:59:26 CDT
