× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.