OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archives: Client Access from Internet to Oracle Dat

Client Access from Internet to Oracle Databases -SQL*Net or VPN or ...?

Bruce B. Platt (bbpcomport.com)
Mon, 13 Sep 1999 12:13:42 -0400

An interesting topic came up in an internal discussion last week, which
prompts me to ask for comments.

You may view this as off-topic.

The question is how does one give only the members of an aribitary, but
defined set of Internet users access to a database
of proprietary information? And, secondarily, how does one provides these
users an easy way to get the access, while preserving
the integrity of the database as much as possible? The database is updated
several times per minute with new information.

Having an Oracle database available on a protected network, gives a client
on that network access to that
database. We assumed for our discussion that these users were trusted not
to try to ruin the database contents.

If one wanted to extend that access to an arbitrary (but defined and
authorized) class of users (clients) with access to the Internet, and on
the "other side" of the firewall, what would be the best way to do this?

We have at least three different opinions:

1. Use Oracle's SQL*Net proxy and install client sw on each Internet user
wanting access. (Use appropriate user-name, pw, token, etc. security).
2. Use a client to LAN VPN product to let those users on the Internet
"tunnel" into the protected network, thus making them appear to be on the
local LAN.
3. Use an approach where the Oracle 8i web server is on the Internet side
of the firewall, connected by VPN to the database server on the protected
network, and give authorized Internet users a Client certificate to browse
the web-server. I.e., set up the server security so that a client can only
connect with a ceritifcate.

Each approach has the folowing disadvantages:

1. Using SQL*Net proxy requires lots of co-ordination among roles on the
DBA side. It also requires instalation of sw on the arbitrary client.
2. All the client level VPN products of which I'm aware require
installation of a "pseudo-adapter" to get the IPSEC sw functioning. There
are limitations in Win 95 (at least) which limit the number of network
adapters to four. This approach also requires installation of software on
the arbitrary client which
may require removal of a network adapter, reconfiguring of network-setup, etc.
3. This approach can be handled relatively automatically, in that one can
go to a web-site to get the ceritifcate on presentation of appropriate
credentials, and the Certificate will install itself in the browser
automatically. Yet, the over-all approach seems cumbersome.

The second and third approaches have the advantage that connections can
only be made by someone authorized to do so, and hence can be authenticated
and logged as such.

I would apprciate comments from the group regarding the trade-off of ease
of access versus security of these approaches, or others which are known to
work.

Thnaks and Regards

  
+--------------------------------------+
Bruce B. Platt, Ph.D.
Comport Consulting Corporation
78 Orchard Street, Ramsey, NJ 07446
Phone: 201-236-0505 Fax: 201-236-1335
bbpcomport.com, bruce bruce.platt
OR, brucebbplatt.com

This archive was generated by hypermail 2.0b3 on Tue Sep 14 1999 - 20:52:01 CDT