RE: Security of Enterprise-Wide Client-Server Oracle Systems

In article <1993Oct13.200926.26765_at_bnr.ca> Jason Lisenchuk <hris_at_bnr.ca> writes:
>I am investigating how to best secure Oracle databases against
>unauthorized access and eavesdropping in the following environment:
>
> - client-server architecture
> - HP-UX Oracle (70%), Sun Oracle (15%), Motorola Oracle (5%), and
>HP-UX Informix (10%) servers

   This could be a problem - I don't know how easy it is to mix'n'match in the Informix product.

> - Mac (60%), Unix (20%), and Windows (20%) clients
> - desktop and telephone pad applications with 20,000-100,000
>registered users
> - ultra high speed enterprise-wide AppleTalk and TCP/IP networks
>
>I have broadly categorized alternative approaches as follows:
>
>1. Use Oracle Stored Procedures throughout, ensuring that the client
>application has execute only privileges on these procedures and must
>pass authentication parameters to each procedure. Under this
>alternative, the client application can login as a 'guest' as it must
>access all data through OSPs.

  I would recommend this for several reasons: 1) Your servers seem to be fairly high-horsepower machines, which can handle the effort of doing what has traditionally been "client side" processing, eg. integrity checks. This may be easier to upgrade than a lot of clients. 2) The tremendous benfits of being able to attach many different client machines and applications to the database, and port/write a minimum of code.
3) The security this gives at the database level - you don't have to worry about the security (other than net snoops grabbing the user's password) outside the database engine; your security/integrity is where it should be - under your tight control; the presentation stuff is on the client.

   The downside is the horsepower required at the DB server, and the fact that the Oracle CASE tool won't generate this code for you- yet.
>2. Establish an Oracle 'security' database which maintains a unique
>Oracle userid for every potential user (i.e. every employee). Under
>this alternative, the client application logs in on behalf of the
>current user. Does anyone have any experience in managing 20-100K
>registered users under Oracle? I had once rejected this out of hand,
>but it might be practical.

   You need to manage them anyway, but I don't know of an easy way to get from the app. signon to the user (it generally must be the other way round).
>3. Buy SecurID (or build equivalent) to provide dynamic password
>generation. Under this alternative, security of login transaction is
>not an issue as login password expires every 60 seconds.
 Could be expensive???
>In all cases, it will be desirable to encrypt some transactions so as
>to protect sensitive data from eavesdroppers. This means that
>specified SQL*Net messages could not be sent in the clear; it would be
>necessary to encrypt/decrypt these messages at the network layer at
>both ends -- client and server. Are there any products available or
>in development which would do this?

   Not to my knowledge, at least from Oracle. Could someone else comment?
>Vis-a-vis encryption, I'm thinking that it might prove very useful to
>be able to call a C function from an Oracle Stored Procedure and/or
>upon firing an Oracle trigger. Is this in the works at Oracle?
 Not to my knowledge.
>Jason Lisenchuk

  Andrew Jones (LRPR_at_UNB.CA) "##include <standard disclaimer>"

|   "Give up, Earthlings!  Your superior   |
|  intelligence is no match for our puny   |
|  weapons!"                               |
|    (The Simpsons' Halloween II Aliens)   |
 ------------------------------------------