|
||
SecureMyi.com Security and Systems Management Newsletter for the IBM i
April 23, 2014 - Vol 4, Issue 7
|
||
|
||
|
Feature Article
|
|
In This Issue
Quick Links
Our Newsletter Sponsors
Platinum Sponsor |
IBM i Security ResourcesIBM i Security Videos - SecureMyi RedBook - Security Guide IBM i Open Security Foundation - DataLoss DB National Vulnerability Database - NIST |
|
Featured YouTube Educational VideoIBM i Security
Cannot Access YouTube from your office? Download the video in wmv format. |
||
|
|
|
Security Shorts - Gain Flexibility with Authorization ListsBy Dan Riehl The Feature Article in this issue of the SecureMyi Newsletter discusses the topic of Authorization Lists, and how they are often misunderstood. I did not mention that additional flexibility can be gained by securing libraries and other objects with an authorization list rather than with a list of private and *PUBLIC authorities. In a recent case, a customer wanted to change the *PUBLIC authorization on certain production libraries from *CHANGE, to the more restrictive *USE. This needed to be done in order to keep users from adding new objects into the production libraries. If a user has *CHANGE authority to a library, the user can add new objects to the library. But, if the user has only *USE authority to the library, they cannot add new objects. The problem in this case, was that the private and *PUBLIC authorities to the production libraries could not be changed while the system was up and running. Since users have these production libraries on the user portion of their job's library lists, a *SHRRD(Shared for read) lock is placed on the library object, prohibiting the authorities from being changed while the system is up and the users logged on. Since this is a 24x7 uptime shop, we needed to wait for several weeks to get clearance for a scheduled outage so we could make the change to *PUBLIC AUT(*USE). Since I wanted to make sure we had flexibility for any future authorization changes to these libraries, the decision was made to use the scheduled outage to change the authorization method for the libraries. Instead of simply changing the *PUBLIC authority from *CHANGE to *USE, we would create an authorization list for each "in-scope" library, and then during the outage, we would change the libraries to be secured by the associated authorization list. Which we did. One of the big advantages of using an authorization list, is that they can typically be changed on-the-fly, during system uptime. This flexibility will come in very handy the next time an authorization change needs to be made to any of these production libraries, Next time, we will not need an outage, we can simply change the authorization list. Some of you are pondering a very good question right now. That is: "Using the new Authorization list scheme, won't you break something when you change the production library authorities on the fly?". The answer is: As long as the change that is being made is not creating a new restriction, nothing will break. If the change to the authorization list is creating a new restriction, that type of change may require an outage. (Note: The System Value QLIBLCKLVL can be used to specify that libraries are NOT locked by a job simply because they are on the job's library list. For more information, see the IBM Information Center discussion on the System Value QLIBLCKLVL. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
|
||
Send your IBM i Security and Systems Management News and Events! Send your Questions, Comments, Tips and Stories Copyright 2014 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |