Re: Are there inherent or 3rd-party tools for encrypting data in Oracle?

From: Mark Townsend <markbtownsend_at_home.com>
Date: Fri, 23 Feb 2001 05:14:26 GMT
Message-ID: <B6BB31C5.3BE2%markbtownsend_at_home.com>


[Quoted] Oracle8i Release 3 (8.1.7) offers a data encryption package that can be used [Quoted] to selectively encrypt data in the database called DBMS_OBFUSTICATION. [Quoted] However, the operative word is selectively. You do not want to encrypt all data for a number of reasons:-
[Quoted] 1) Encrypting any data column that is involved in an index or a query path [Quoted] will cause a performance degradation. Selective column encryption is designed for sensitive data that needs to be kept private from DBA's, other [Quoted] [Quoted] users etc - i.e Social Security numbers, Credit Card numbers etc. It's not [Quoted] designed to just encrypt all data in the database 2) At this stage, it's not going to be transparent to the application - you [Quoted] will need to manage the encryption keys yourself (i.e outside of the [Quoted] database) and the application will need to be changed to encyrpt and decypt [Quoted] the data on every SELECT and DML operation. You must also back up the [Quoted] encryption keys yourself (if you lose them, the data cannot be decrypted)

[Quoted] For on-the-wire encryption between the client and the database, look at the [Quoted] capabilities provided by the Advanced Security Option in Oracle8i (and also [Quoted] earlier versions). Note that this is a chargeable item

[Quoted] Also look at the virtual private database capabilities in Oracle8i. While [Quoted] not data encryption, it does allow you to apply granular security policies [Quoted] to rows of data, which may be all you need to satisfy your users requirements

[Quoted] For an overview of all of the above, have a look at http://www.oracle.com/ip/solve/security/index.html

For some examples and more technical content, see (you will need a free account)

http://technet.oracle.com/deploy/security/
http://technet.oracle.com/sample_code/deploy/security/sample_code_index.htm
http://technet.oracle.com/doc/oracle8i_816/network.816/index.htm
http://technet.oracle.com/products/oracle8i/pdf/816isdfo.pdf
http://technet.oracle.com/products/oracle8i/pdf/816scnew.pdf
http://technet.oracle.com/products/oracle8i/pdf/eu.pdf


> From: "John Peterson" <johnp_at_azstarnet.com>
> Organization: Posted via Supernews, http://www.supernews.com
> Newsgroups:
> comp.databases.oracle.misc,comp.databases.oracle.server,comp.databases.oracle.
> tools
> Date: Thu, 22 Feb 2001 21:09:06 -0700
> Subject: Are there inherent or 3rd-party tools for encrypting data in Oracle?
>
> Hello, all!
>
> Please forgive my extensive cross-posting, but I wasn't certain what forum
> to post my question. This is my first visit to these groups, but I hope to
> become a "regular" (and better determine where to place my posts in the
> future ;-).
>
> My background in databases has been largely limited to Microsoft SQL Server,
> but I have started a new job with a company that uses Oracle 8i on Red Hat
> Linux 6.2. As such, I'm trying to learn as much as I can about Oracle using
> my knowledge of SQL Server as sort of a starting point. ;-)
>
> I have been tasked to investigate the feasibility of encrypting data in
> Oracle. Are there any tools (off-the-shelf or internal to Oracle) that
> might help to accomplish this? We use JDBC as our data access mechanism, so
> we would prefer to NOT have to change the application, but to arrange for
> the data to be encrypted between the Client Library (JDBC in our
> application) and the Oracle server (we want the data across the wire to be
> encrypted AND the data on the disk to be encrypted).
>
> Also, I would appreciate any thoughts as to the pros/cons of this approach.
> My natural inclination is to NOT encrypt the data in the database, but
> rather to rely on the security safeguards that are in place with the
> operating system and the database server. It seems to me that it would be
> difficult to perform OLAP tasks or determine data patterns on data that's
> encrypted (even partially), not to mention the performance ramifications of
> said. However, our "hands may be tied", as this is a client imperative.
> But, I'm hopeful that with some compelling evidence (one way or another),
> they might change their stance accordingly.
>
> Thank you in advance for your time! :-)
>
> John Peterson
>
>
Received on Fri Feb 23 2001 - 06:14:26 CET

Original text of this message