RE: ODBC Security -- MIDRANGE-L

There are a few ways to approach this problem.  

One that was mentioned yesterday was to use SQL Views/ Logical Files or
Stored Procedures to access the database.  This can require some rather
creative forethought on the DBA/ Programmers end in that generic or
parameter driven access methods must be considered.

Another method which I tend to prefer is to use a programmed DSNless
connection that is based on some generic user and password.  This method
lets the programmer or database developer decide exactly how much access to
the data to grant to the end user.  The generic user name (AS/400 User) can
be associated with a specific library list that limits the user to views /
logicals only and the user sign-on can be granted only limited authority.
The actual end user should not have a sign-on to the AS/400 therefore they
will not be able to create their own ODBC connection.  You can use DSNless
connections in VB, C++, Access as well as several other programs.  The key
to using it in Access is to compile the program into a *.MDE file (object)
therefore preventing anyone from going into the connection string and
discovering exactly what you have done.  The only requirement for using this
technique is that you have to make sure the driver that you coded into your
program is available on the end users PC.  No User/ System or File DSN will
show up on the end user's PC so you do not have to worry about tampering
with the connection.


Regards,
Rick Warren
Database Developer
Burlington Chemical Co., Inc

-----Original Message-----
From: John Earl [mailto:johnearl@400security.com]
Sent: Friday, November 10, 2000 8:33 AM
To: MIDRANGE-L@midrange.com
Subject: Re: ODBC Security




Quazy wrote:

> How does everyone deal with security on the 400 and the ability to use
ODBC?
>
> If production files are set to public authority to *change, what can I
> do.  users don't have access to manipulate the data from the AS/400 (I
have
> taken all those ways away).  But even if a user with basically no
authority
> gets on through ODBC they could do anything they want to the database.

The problem is not ODBC, but rather *PUBLIC=*CHANGE.  If *PUBLIC=*CHANGE
then any
valid user will be able to change your data through any number of interfaces
(ODBC, FTP, DDM, etc.).  You can block access with exit programs to keep
people
from accessing data, but don't stop there.  I would strongly encourage you
to
tighten up *PUBLIC's authority.  In a networked environment, *PUBLIC is
potentially any computer on th eplanet.

jte


--
John Earl                    johnearl@400security.com
The PowerTech Group      --> new number --> 253-872-7788
PowerLock Network Security   www.400security.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---