Re: ODBC Security

First, and strongest wall, should always be object authority.  Now, some
people secure everyone out of an object.  And then the only way to access

a file was via programs that adopted authority.  Knew a fellow who did
this for a company that made body parts for humans.  Like artificial
knees.  If you do this then the only way they can use ODBC is if you copy

the data to a different file that is opened for read.

This is not true.  There are any number of ways to exclude PUBLIC and allow
certain individuals to read through ODBC without copying the file: 1) grant
private authority to those user profiles that are allowed to read,  2)
create a group, add those who are allowed to read via ODBC to that group
and grant the group *USE authority to the file. 3) If you have a number of
files that can be read by certain individuals for reading, an authorization
list can be combined with either 1 or 2 to manage this all in one place, 4)
depending on how these individuals need to "use" the file, a stored
procedure that adopts authority would work well. Authorize the
profiles/groups representing the readers to the stored procedure, but not
the data, 5) If you PUBLIC *EXCLUDE the data AND you only want folks to use
ODBC, you can use the existing ODBC exit point with an exit program that
adopts authority.  The exit point program could have logic to work in any
number of ways to determine if the authenticated user was allowed to
continue.  This allows whomever the exit point program chooses to allow to
access the data, but those same people are prevented from accessing the
data from any other interface. 6) There is a new QIBM_DB2_OPEN (I think
that's the name), exit point that provides a data structure to the exit
point program that represents every file that will be accessed as a result
of an SQL statement as well as how that file will be accessed.  There is no
need to parse the SQL statement as this exit point is called after the
system parses it.  This is another possible option.  It might make sense to
combine some or all of these.

In general, I don't believe it is possible to implement a security policy
that includes "employees are only allowed to access data which they need to
successfully perform their job functions" without setting PUBLIC *EXCLUDE
on all sensitive data.  Whether adopted authority, private authority, group
authority, authorization lists, exit point programs, or other things are
used to allow only those people who should be allowed is a technical
decision based on which method costs the least to implement and manage over
time.  In very few cases, if any, would making a copy of the data be
required much less end up being the most cost effective way to manage those
access policies.

Next wall may be exit points.  Let's say your application vendor is from
the stone age.  And he requires the files to be *ALL for all users
accessing the files.  Now, you can use an exit point to restrict who can
download what data from what file.  For example I can secure Sally from
downloading from the logical that has both name and salary information in

it, but let Susie get both.

This is a common misunderstanding.  No exit point vendor can provide code
that prevents access from all possible interfaces to data which a user is
otherwise authorized. If Sally has *ALL or *CHANGE (either privately or via
PUBLIC authority), there are interfaces that Sally could take advantage of
to access the data.  An exit point program does not protect the data. It
protects an interface that one might use to access data.  If there are any
other interfaces that can be used to access the data (and there are on most
systems, HTTP server, Netserver using UNC naming rather than drive mapping,
WAS-based apps, etc...) that either don't have associated exit points or
that the customer doesn't realize they or the OS itself are using, exit
point software cannot protect the data.  Exit point software is very good
at allowing access to data that would be otherwise be denied by the access
control scheme. It cannot be used to prevent accessing data that is
otherwise allowed.

Exit points are a lot better than nothing if you have PUBLIC *ALL/*CHANGE
on your data, but they are NOT a substitute. You might use them while you
are implementing an exclusionary access control model, and then change how
you use them once that model is implemented.  But they shouldn't be
considered an acceptable alternative to using object level authority along
with various other mechanisms to implement an exclusionary access control
model!  (EACM =  sensitive data is set to PUBLIC *EXCLUDE and authorized
users get their access through other mechanisms such as private authority,
adopted authority, etc., or a combination of these).

Patrick Botz
Senior Technical Staff Member
IBM Lab Services, Rochester
Security Architecture & Consulting, i5/OS Security Architect
(507) 253-0917, T/L 553-0917
CTC Fax # 507-253-2070
email: botz@xxxxxxxxxx

For more information on CTC, visit our website at
http://www.ibm.com/eserver/services
http://www.ibm.com/servers/eserver/services


midrange-l-bounces@xxxxxxxxxxxx wrote on 09/15/2006 02:26:22 PM:

Rather a recent discussion on the security list.  Searching the recent
archives might give some good insight.

Defense in depth is always the best strategy.


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com