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

Hello (again), Mark!

To follow up on my own post, I did a:

select * from v$version

And was returned:

Oracle8i Enterprise Edition Release 8.1.5.1.0 - Production PL/SQL Release 8.1.5.1.0 - Production
CORE Version 8.1.3.0.0 - Production
TNS for Solaris: Version 8.1.5.0.0 - Production NLSRTL Version 3.4.0.0.0 - Production

This seems to imply that we're running the Enterprise Edition of Oracle. However, it doesn't appear that we're running Release 3 (8.1.5 versus [Quoted] [Quoted] 8.1.7). Is the data encryption package that you mentioned (DBMS_OBFUSTICATION) only available in Release 3?

Thanks again for your help!

John Peterson

"John Peterson" <johnp_at_azstarnet.com> wrote in message news:t9d17mjo3v5mca_at_corp.supernews.com...
> Hello, Mark!
>
> Thank you for your detailed reply! I had a couple of additional
 questions,
> please see inline:
>
> "Mark Townsend" <markbtownsend_at_home.com> wrote in message
> news:B6BB31C5.3BE2%markbtownsend_at_home.com...
>
> > Oracle8i Release 3 (8.1.7) offers a data encryption package that can be
 used
> > to selectively encrypt data in the database called DBMS_OBFUSTICATION.
>
> Aha! That sounds promising! I'd much prefer to use something inherent to
> Oracle8i, if at all possible. I haven't yet begun searching for a
> third-party tool to help with our encryption scenario, but maybe it will
 be
> moot. :-)
>
> > However, the operative word is selectively. You do not want to encrypt
 all
> > data for a number of reasons:-
> > 1) Encrypting any data column that is involved in an index or a query
 path
> > will cause a performance degradation. Selective column encryption is
> > designed for sensitive data that needs to be kept private from DBA's,
 other
> > users etc - i.e Social Security numbers, Credit Card numbers etc. It's
 not
> > designed to just encrypt all data in the database
> > 2) At this stage, it's not going to be transparent to the application -
 you
> > will need to manage the encryption keys yourself (i.e outside of the
> > database) and the application will need to be changed to encyrpt and
 decypt
> > the data on every SELECT and DML operation. You must also back up the
> > encryption keys yourself (if you lose them, the data cannot be
 decrypted)
>
> Agreed. Good point about the concerns regarding disaster recovery and
> encryption. I hadn't considered that.
>
> > For on-the-wire encryption between the client and the database, look at
 the
> > capabilities provided by the Advanced Security Option in Oracle8i (and
 also
> > earlier versions). Note that this is a chargeable item
>
> Ah! That's interesting! I'll refer to the URLs you provided and see how
> the pricing is structured with this Advanced Security Option. If it isn't
> too costly, a combination of this and the DBMS_OBFUSTICATION feature just
> might fit the bill!
>
> > Also look at the virtual private database capabilities in Oracle8i.
 While
> > not data encryption, it does allow you to apply granular security
 policies
> > to rows of data, which may be all you need to satisfy your users
> > requirements
>
> Will do!
>
> > 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
>
> Thank you again for your help! I'll certainly be visiting these URLs for
 a
> more detailed description of these features. :-)
>
> John Peterson
>
> > > 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.oracl
> e.
> > > 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 - 20:23:31 CET