I have Powerlock exit programs running and have recently started journaling on most (but not all) files on our...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
system. I would like to know who is accessing what files outside of programs. In other words the adhoc qrys, etc. from PC access. Several people are authorized to do this, but it would help coordinate modifications if we knew who was accessing what. I thought about the 'OP' code for journaling, but would like to know what you think would be the best approach. Powerlock does write 'U' entries into the QAUDJRN, but it is difficult to determine the files accessed in many cases.
For auditing specific access to specific objects, go with the facilities provided by IBM with the operating system. Although it is generally possible for exit programs to provide object-level auditing, OS/400 already does it with much more certainty. Here is my reasoning...
Exit programs for network servers can provide added granularity to the control of access as well as added support for auditing network transactions. However, exit programs can have trouble determining what objects are being accessed under numerous circumstances. I'll mention three that seem related to your needs (ignoring others beyond those three).
SQL provides ways to access tables indirectly. One way is through defining an ALIAS; another is through stored procedures; and a third is through RUNSQLSTM.
If access to a table is done through an ALIAS, an exit program must do additional processing to determine what actual object is involved. Some of that processing might include I/O against the system catalog, possibly even more I/O than the remote request itself. Extensive disk I/O such as this could have a very negative impact on your system performance.
Or if access to a table is through a stored procedure, which might even be created in the same session, it would be somewhere between extremely difficult and impossible for the exit program to determine what objects are accessed at all. If the stored procedure exists on the AS/400, the exit program would have to disassemble it, parse it and then resolve any ALIAS issues. As you can see, trying to do object level authority with exit programs can quickly lead to a performance nightmare.
Finally, non-SQL servers can complicate the issue. A source member can be uploaded with FTP and then passed to a RUNSQLSTM command by the RCMD subcommand. Just as outlined above, an exit program would have trouble detecting any of the underlying database activity.
These are only a few of the most obvious examples, ones that might be reasonable even in normal activity. To handle these and more subtle examples, rely on OS/400. Rely on PowerLock NetworkSecurity to monitor the transactions themselves rather than any objects mentioned within the transactions; this applies especially to the transaction 'envelope' -- attributes such as source or destination IP address, server name, user profile, etc.
In short, use the tool that fits the task. Use PowerLock NetworkSecurity for network access control and use standard OS/400 journaling to audit object access.
MORE INFORMATION ON THIS TOPIC
The Best Web Links: Tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Read this Search400 Featured Topic: Secure your iSeries
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.