Programmers absolutely do not need *ALLOBJ special authority to perform their normal job functions. However, there are times when more "power" is required. This article describes your options for providing additional capabilities when the situation demands it.
What Constitutes an "Emergency"
The production application has bombed, the manufacturing line is down, and debugging the program reveals that the last enhancement caused an unexpected error. An incoming transmission dies and corrupts a production data file, so the data must be corrected "by hand" through a file editor. The programming staff doubles as the operations staff and is on call on a rotating basis. These scenarios probably sound familiar to you, and all of them constitute the need for programmers to have more authority and capability than they should normally have.
You need the ability to temporarily provide these capabilities rather than give programmers *ALLOBJ all the time.
Why not give *ALLOBJ special authority to programmers all the time? This is not a good idea for several reasons, and one reason is because *ALLOBJ allows programmers to bypass any change management software that you have in place. Another reason is that there is no way to keep programmers from accessing production data if both development and production occur on the same system--as is the case in many iSeries shops. Both of these issues raise data integrity concerns, and auditors are becoming increasingly intolerant of the practice of allowing programmers to permanently retain *ALLOBJ authority. However, I recognize (as do the majority of auditors) that some circumstances require "emergency access"--that is, more power than programmers traditionally have.
Giving and Removing *ALLOBJ
Several methods exist for giving users temporary *ALLOBJ authority if *ALLOBJ is absolutely required:
- One method is for someone with sufficient authority to modify the programmer's profile and give *ALLOBJ special authority. I am not in favor of this method because inevitably there will be a time when the administrator forgets to remove the *ALLOBJ. If this method is used, an automated process needs to be put into place that will automatically remove the *ALLOBJ. For example, a job could be scheduled to run at midnight that removes all programmers' *ALLOBJ.
- Some administrators prefer to provide two profiles for programmers--one without *ALLOBJ and one with *ALLOBJ. Both profiles are enabled, and the programmers are advised that they are only allowed to use the "powerful" profile in case of emergencies. Well, we all know what happens in this case. The administrator never keeps track of when the powerful profile is used, so the powerful profile is the only one programmers ever use! This option rarely works.
- Taking off on the method described above, the administrator provides the programmer with two profiles, but the only time the powerful profile is enabled is when the programmer is on call or when an emergency occurs. This is a far superior option to having the powerful profile enabled at all times, but it still requires that the administrator remember to set the profile to *DISABLED status when the programmer goes off call or the emergency is over.
Swapping to Another Profile
Some tools on the market allow programmers or administrators to "swap" to a powerful profile when they need additional power. These tools make use of the profile swap APIs, which change the profile that the process is running under. For example, Joe signs on and calls a program that has implemented the profile swap APIs. The program is coded to swap to QSECOFR. OS/400 changes the job so that the job is now running under the QSECOFR profile. Now, when Joe performs a task, he is doing so as QSECOFR, not Joe. The problem with this approach and the reason I don't recommend it is because it's difficult to track. The job name stays the same. As you probably know, part of the job name includes the user under which the job started. If the profile swap APIs are run, even though the process profile changes, the user portion of the job name doesn't. So if you're using Work with Active Jobs (WRKACTJOB) to display the status of active jobs, it appears that the job is still running as the original user. This issue flows into the audit entries produced. The user field that you normally monitor will now be QSECOFR instead of JOE. While you can find the user that is actually performing the task in the audit entry, it will cause you to look at the audit journal entries in a way that you are not used to and will absolutely cause you to re-work your queries and any audit journal reporting software that you might have.
Setting a New Group Profile
One technique that is very powerful yet seldom implemented is using the qsysetgid() APIs to change a user's group profile. Using the qsysetgid() APIs is similar to using the swap profile APIs. The difference is that the swap profile APIs swap in all of the user information--the user itself as well as the user's groups. The qsysetgid() APIs change only the user's first group profile and only for the current process. In other words, the user's group is changed only in the current job information, not in the user's profile. This method allows you to make the profile a member of the profile that owns the application that needs to be debugged. Simply call the API during the profile's initial program.
This method is very powerful because the profile is a member of the owning profile only during the time the profile is signed on. For example, the user's initial program is never run when the profile is used for FTP or ODBC. Therefore, if programmers try to use the profile outside of debugging the application, they will only have their own authority, not the authority of the owning group. I prefer this method to giving the programmers *ALLOBJ special authority or swapping to another profile.
Activating Emergency Access
Whatever method you use to give the programmer additional authorities, you have to decide how the emergency access will be "activated."
One method is to have an automated process that creates an emergency access profile "on the fly." I saw an implementation in which the programmer must fill out a Lotus Domino form that includes the justification for requesting the profile access. The form is forwarded to the Security Administration team, where the person on call approves the form. Once approved, the form kicks off a job on OS/400 that creates a profile. When the programmer signs off, the emergency access profile is deleted within an hour by a job monitoring for use of these profiles.
Another method is to have the profile created but always set to PASSWORD(*NONE) so it can't be used. Upon receiving the programmer's request and approving it, the administrator gives the profile a password and then changes it back to *NONE when the programmer is through. Or, better, an automated process can be put into place to automatically reset the password back to *NONE after a prescribed period.
For small shops with only a handful of programmers and one or two administrators, the emergency access process needs to be simple. One method that can be used is for the administrator to create an emergency access profile for each programmer. The profile can be configured to have a password that is placed in a data area for that profile. The data area is set to *PUBLIC *EXCLUDE and is authorized for access only by the particular developer. (All programmers would have their own profiles and data area combinations.) This solution is simple, but it has a couple of problems. The obvious issue is that the password is in cleartext. The way around this issue is through a bit of programming. Using the validation list APIs, tools can be written for the administrator to set the password and for the programmer to retrieve the cleartext password. To ensure that one programmer cannot retrieve the password of another programmer, a separate validation list is used for each programmer. The programmer is only authorized to the validation list containing the password for his or her emergency access profile.
The other issue that needs to be addressed is shutting off the programmer access to the profile. In other words, if the profile's password never changes, the programmer can use the profile indefinitely. To address this issue, you can turn on object auditing. Then, use message handling/monitoring software that monitors QAUDJRN audit journal for an audit journal entry that indicates that the validation list has been accessed. The next day, the administrator can reset the password and populate the validation list with the new password. Or, once again, you can implement an automated process that the administrator would kick off after being notified that a validation list had been accessed.
Monitoring What They Do
Despite the fact that the programmer has extra "power" only occasionally, you will want to monitor what the programmer does during this time. I recommend that you use the Change User Audit (CHGUSRAUD) command to turn on *CMD and *PGMADP auditing after the profile is created. *CMD causes all command strings run during an interactive sign-on session to be logged to the audit journal. Turning on *PGMADP causes an audit entry to be generated if adopted authority is the authority used to access an object. This will help you detect whether adopted authority is used inappropriately.
While logging the emergency access profile's actions is good, auditors are going to expect that a security administrator is reviewing and monitoring the logs--both the log that is kept for the emergency access requests as well as the activity logs generated. Depending on the organization, these tasks can be quite time-consuming. You may want to determine the inappropriate activities that you want to look for and write some queries to assist you in monitoring the activity.
There is no one right way to allow temporary emergency access for programmers. I hope this article has given you some ideas about what will work best in your environment.
Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services and security assessments, including the risk assessment product, SkyView Risk Assessor for OS/400 and i5/OS. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security.
Carol can be reached at
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online