By Rich Loeber,
A reader contacted me not too long ago after reading a tip I wrote that urged IBM i shops to implement object level security using Authorization Lists. This user had been doing just this for years, but was concerned because, “in the heat of the moment”, objects might get created without a thought to making sure that the necessary Authorization List is attached. I could not give the reader any quick answer, but I started mulling it over. This tip will give you one way to check to see if all of the objects in a library are secured by your authorization list.
There are two commands in the IBM i operating system that you can use to create database lists of objects for this audit check. The Display Authorization List Obj (DSPAUTLOBJ) command can be used to create a database list of all objects secured by your Authorization List. The list will include all objects currently on your system, regardless of library used, that are secured by the list. For this audit check, the following command format would work well:
DSPAUTLOBJ AUTL(myautl) OUTPUT(*OUTFILE)
Just substitute the name of your Authorization List where you see “myautl”.
The second command you will need is the Display Object Description (DSPOBJD) command. This command can be used to create a database of all objects in a library. The command can be used for all objects in the library or a subset of objects in the library. You can also run it several times to add objects from other libraries to your database. To create the database for all objects in a given library, the following command format can be used:
DSPOBJD OBJ(mylibrary/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
If you then want to add more objects from another library, use the following command format:
DSPOBJD OBJ(mylibrary2/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/LIBOBJS) OUTMBR(*FIRST *ADD)
Once you have both databases created (note, these examples create the databases in the QTEMP library, but any library can be used), then all you need to do is use your favorite ad-hoc query reporting tool to match the two databases and generate a control report.
My favorite tool is WRKQRY. On my system, I created a report to just list the library name, object name, object type and object text description. The primary file in the query is the list of objects in the library. I then used the list of objects from the Authorization List as a secondary file. For the key matching, I selected the library name, object name and object type as that should be unique. For the type of match, I selected the 3rd option that shows as “Unmatched records with primary file”. This will end up only printing those objects that are in the library but are not secured by the Authorization List.
From start to end, this took me about 15 minutes and, in the end, I created a report that surprised me a little with the number of objects that were not properly secured the way I thought they should be. To be able to recreate the process easily, I went ahead and created a CL program with a command which took another 10 minutes or so. I now have this available and if you’d like to get a copy of the library that contains this utility, just drop me an email message and I’ll send it out to you.
If you find a lot of exceptions or surprises, like I did, you will also want to review your procedures to find out how this is happening and tighten things up.
If you don’t want to create your own monitoring tool, take a look at Kisco’s new iSecMap Security Monitoring tool. It will implement this and many other processes that will monitor security on your system and help you keep your security policy enforced correctly.
If you have any questions about this topic or you would like a copy of the matching utility I created, you can reach me at rich at kisco.com, I’ll give it my best shot. All email messages will be answered.