Re: ODBC Security

[rob@xxxxxxxxx]

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.

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.
Leaving all your files for read might not be a good idea.  For example if 
your programs secure who can read certain fields.  For example if your 
employee file has salary information in there with name and address and 
certain people can look up address but only certain other people can look 
up salary and that is all program restricted.  Now accessing that file via 
odbc blasts by that.  Workaround, break the file apart which some vendors 
do.  Or use column level security.  Nice theory but I've not seen people 
use this in practice yet.  Has anyone?  Supported by DB2.
Oh and as far as the "download file", our users quickly figured out that 
they could query most any file they wanted to and overwrite the download 
file and download that.

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.

Rob Berendt