I cover this topic extensively in chapter 17 of IBM i Security Administration and Compliance, Third Edition, but I wanted to mention a few things here. That chapter was originally written prior to Authority Collection being available. Some might wonder if I’d replace that guidance with the use of Authority Collection. The answer is no. To configure Authority Collection on all application objects, even if you limit it to just database files, I believe would be very overwhelming.
However, there is a place in this process for Authority Collection. Specifically, when reworking an entire application, the most likely to fail are processes that access data from outside of application interfaces, such as ODBC access from a Windows server or a secure file transfer to an outside source or a data transfer to a user’s workstation. Once you discover these processes, you have to determine what authority to grant the profile to the database file in use, and that’s not always obvious. If my client was running IBM i 7.4, I’d turn on Authority Collection on the objects identified as being accessed via non-application interfaces (ODBC, DDM, etc.) to determine how much authority is required and to make sure no other profiles need access. If they were running IBM i 7.3, I’d still use Authority Collection and turn it on for the profiles you’ve identified as accessing data outside of application interfaces. (The only difference between these two approaches is that you’re not going to get the full list of profiles accessing the object when you turn on Authority Collection for the profiles versus turning it on for the object itself.)
How do I identify which profiles are accessing application data with some interface other than the application itself? As I describe in IBM i Security Administration and Compliance, Third Edition, it’s a matter of turning on object auditing on the database files and examining the ZR and ZC audit journal entries to find the entries that are using a program other than an application program to read and/or update a database file. The other method you can use (if for some reason you can’t turn on object auditing) is to examine the GR and GS audit journal entries. I don’t describe examining those in the other book, so I’ll describe them here.
This method is far less precise than using object auditing, but it will help you identify profiles using “external” interfaces (connections made from another system), perhaps a Windows server, a user’s workstation, or even another system running IBM i. Then you can use Authority Collection for those profiles to discover the details of what they’re accessing. One warning, however: You should not rely on this method as your sole means of investigation if you have two or more applications on your system that are “intertwined,” meaning their use of data overlaps and they often pass data between them and/or share files and data. If you have this situation, you typically know who you are. This method will not catch a program from Application A accessing a database file in Application B’s libraries, for example, and missing that information could mean that Application A could fail when it tries to access Application B’s data if you haven’t made accommodation for that access.
This method uses the GR (Generic Record) audit journal entries. These entries are generated if you’ve changed the default setting for anything in Application Administration (Function Usage). Little did IBM realize that, when they added the ability to control who can use ODBC using settings in App Admin, they were also providing an easy way to find out who’s using ODBC! Same with FTP and DDM/DRDA.
GR audit journal entries are generated when you have either *SECCFG or *SECURITY specified in the QAUDLVL system value and have modified any Function Usage entry. Even if you simply change the default setting for who can access New Nav, for example, the system generates a GR record to log that the setting of the function was checked. While I couldn’t care less whether it was checked or not, what this provides is a simple way to determine who’s accessing the system via ODBC (function name QIBM_DB_ZDA), FTP (function names QIBM_QTMF%), and DDM/DRDA (function name QIBM_DB_DDMDRDA). The following gets all of these entries. I’ve included the IP address of the request in case you need to determine where the access originated.
Get the distinct set of access by profile.
To discover the use of SSH and QShell, use the GS audit journal entries and look for the job name of ‘SSHD’ and ‘QSHSH’ for QShell. (I describe in chapter 12 how to use the GS audit journal entries to discover who’s using SSH.)
Once you find the profiles accessing the system using these various interfaces, you can turn on Authority Collection (as described in chapter 6) to determine which objects they’re accessing. If it’s files in the application you’re securing, you know to add them to the list of profiles for which you’ll need to grant authority.
Again, if you’re reworking an entire application, I encourage you to read chapter 17 of IBM i Security and Compliance, Third Edition for more hints to help make your project a success.