Re: program authority audit.

Hi Rob,

When security is involved, you don't want loopholes. You also don't want
to have to continually re-evaluate call stacks, as applications are changed
over time, or as new applications are added. You also want security rules
that are simple, easy to remember, easy to communicate, and ones that
instill confidence in all the stakeholders that the implementation is
comprehensive.

It has been many years since I've had duties that involved applying
security settings, hence I'm likely to hose up some of the terminology and
details here, but I think a great strategy is to:
* Set all tables / files to default to *USE authority (providing default
read / query access), or to *NONE (default excludes even read / query
access).
* Use a single user profile, e.g. DBOWNER or similar, that will elevate
access above the default of *USE or *NONE to *ALL or *CHANGE.
* Make all programs run as if they are running under the elevated authority
of DBOWNER.
* Ensure your change control system, if you have one, by default,
consistently applies those default security settings to files and programs
upon promotion.
* Ensure your programs do not present a command line.
* Ensure your programs cannot be subjected to injection attacks.
* If you have a program that needs to override that default security
behavior, manually configure that single object in the change control
system to promote differently than the default.

Net result is all production installed programs have full data access,
anything else (like ODBC, JDBC, etc.) access only have the default of *USE
or *NONE access.

Exactly how to do that? I don't remember all the details, but there are
plenty of people here that have those details readily available in their
minds.

Something along those lines should be comprehensive, and have a very good
chance of staying comprehensive over time as your applications evolve.

Mike