Authority on Demand Flexible Access Control Solution. The Challenge. Emergency access to critical application data and processes is a very common security breach which is uncovered in System i audits.
Emergency access to critical application data and processes is a very common security breach which is uncovered in System i audits.
Currently, manual approaches to this problem are not only error-prone, but do not comply with regulations and auditor’s often stringent security requirements.
System i sites define user’s security levels and allocate security rights corresponding to the different job responsibilities in the organization.
Authority Request Rejected
Busy IT Manager
Has authorities for Test & Development
Needs authorities for Production once a week
Hi Sam… temporary authorities for the Production folder? Hmmm, I don’t have time now… maybe next week.
Let’s define authority rules: When Sam Evens requests authority for Production Folder between
8AM-16:30PM, the system will automatically grant it…
Uh, Richard, I need authorities for the Production folder again…
Now that we have AOD, I’ll request authority… Wow, this is so much easier than calling up Richard…
Got the authorities!
Finally, I don’t have to waste my time on granting special authorities… the whole process is automatic and I can see a full log of Sam’s authority requests and even screen captures!
DANA start add authority of user QSECOFR in job 456789/DANA/QPADEV0003.
Reason: Need to check problem in production system.
Confirmation ID: 5634
Time: 11/03/08 22:40
Attachment 1 – Command entered
Attachment 2 – Captured Screens
Attachment 3 – DB Records changes
DANA end add authority of user QSECOFR in job 456789/DANA/QPADEV0003.
Time: 11/03/08 23:19
ID: 653, Attachment 1
ID: 653, Attachment 2
DB Records changes
ID: 653, Attachment 3
* Other attachment options available (all QAUDJRN information, summary of changes made by Ad-Hoc utilities…)
Select Authority Rule to modify.
Each field needs to be explained individually;“Add authority of Provider” is unique to AOD & ensures that logged info relates to requester .
Important note below .
Select an Authority Provider to modify.
Requestor must enter the name of theAuthority provider and either a PIN Code (with Reason *BYPIN) or Reason text.
Feedback message below.
Feedback message below.
Option 41 from the Main Menu is used to DisplayAOD log entries; can be filtered by requester or provider.
Sample AOD Log Entries; F10 provides details.
Note the numerous possibilities for displaying AOD log entries.
This is the QAUDJRN log for one AOD request.
AOD log contains “pointers” (i.e. attachments) to the appropriate QAUDJRN log.
This is the printed QAUDJRN log for a singleAOD request.
This is an actual screen “Capture” of using AOD (back version).
This is one of the user screens “Captured”(frame 11 in the Capture log file).
Option 81 from the AOD Main Menu.
Note various general definition parameters.
AOD allows for site-specific exit programoverrides.
Set the Log Retention period using this screen.
An appropriate license must be signed witha local ISP.
SYSLOG attributes are defined using Option 8121 from the main menu.
These are the SYSLOG messages writtenwhen authority was added.
Select an AOD Operator to modify.
Full product usage, Emergency usage or useas an Auditor (read-only).
Current user has been defined as Emergencyoperator, only 1 rule can be modified.
Modify the rule which relates this Emergencyoperator; other rules cannot be modified.
No changes may be made to rules.
All input fields are disabled in this mode.
Please visit us at