RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

> From: rob@xxxxxxxxx
> 
> I think you're method would be effective.  Can the before read trigger
be
> done to actually enforce this?  If someone tries to read the file
outside
> of the I/O module will the read be denied?  For example, *BEFORE
cannot be
> associated with *READ.  Thus wouldn't the application already have the
> data on an *AFTER *READ?  And the best you could hope for is notifying
the
> police that someone stole your horse instead of stopping the theft in
the
> first place?

I haven't tried the READ trigger, that's a fairly new option.  My guess
is that the program is still going to blow up if you send an exception,
so while they may be able to read one record, they're not going to be
able to do anything with it.

But it's still better than unfettered ODBC access, right?  And if it's
REALLY sensitive data, you just don't allow access except through the
I/O module.


> I bet this method, however, would make it extremely difficult for
anyone
> to use any existing reporting tools, etc.  The problem I have with
that
> is, once again, the iSeries will be seen as the culprit and not the
> methodology.  And again the corporate answer will be to either
replicate
> all the data, or move the application entirely off of the iSeries, to
> facilitate the reporting tools.

The concept that all data in the system be available to everybody is
indefensible from a data security standpoint (not to mention a data
management standpoint).  It means that somebody has to understand the
relationships between files, the contents of fields, and how various
business quantities are derived from those fields.

By allowing access at this level, you make security an issue, and you
also lock your database down to where you can no longer make changes to
the underlying database for fear of breaking user queries.

While I understand the utility of such queries, in many cases they can
be made from cached data - mirroring data to an offline server in
nightly batches, for example.

But if you assume corporate requirements to be able to access secure
mission critical data without security, then by definition you're
defeating anything I'm trying to put in place.  If you cannot convince
management that unrestricted data access is inherently insecure (and
unlikely to pass HIPAA regulations) then I guess you have a bigger
problem than system architecture.

But at the very least I would make sure that such access goes through a
user profile that has only READ access.  There is absolutely NO valid
business requirement for users to make ad hoc updates to the database.
And once again, by encapsulating the files within servers, this can be
achieved easily without causing security leaks.

Joe