Oracle Security:Anyone Did Encryption of Data in Tables B4 ?

Oracle Security Experts:

Even today, using Oracle 7 etc, the unix account "oracle" or anyone with the Oracle account "sys" & "system" can see all the data that my CEO and CFO puts in my Oracle database. The unix account "root" can also "su - oracle" and see the data in my Oracle database.

The only way out, I think is to encrypt the data as it is "inserted" or "updated" into the database. Has anyone done encryption of data in Oracle before and has some interesting horror stories and war scars to describe ? I am aware that:

1. Searches such as "select * from table where column = 'xxx'" becomes really difficult since every row needs to be decrypted before matching. Is there an easier / ingenious way out ?
2. Encryption Key changes becomes a nightmare. Imagine going thru a 10 gigabyte database and decrypting/re-encrypting the data.

    2(i) who will do this since all private keys are only known

         by the user who encrypted the data ? I can't imagine asking
         my CFO to go thru his data a piece at a time to decrypt
         and re-encrypt.

    2(ii)unless there is a key-escrow system held by a senior level
         person, any key changes may never result in automatic
         batch jobs performing the decryption and re-encryption.

3. Use of regular data types e.g. "int", "char", "varchar" may

    become difficult since data when encrypted looks like garbage     and cannot be stored in "char" datatypes without incurring a     large overhead in size.

4. Implementation complexities become worse when the system has

    a set of structured data can either be left in CLEARTEXT or     in CIPHERTEXT. For example, some payroll data     (salary, date-of-last-payout) must be encrypted for some     employees but not others - which leads to a question as to whether     there is any real gain in storing all employees payroll data in     a single table (versus if we should split CLEARTEXT payroll data     into one table and CIPHERTEXT payroll data into a separate table     instead)

Are there other ways out of this security dilemma...?

Regards and thank-you for all your contributions. Received on Sun Jun 29 1997 - 00:00:00 CDT