Home > AS/400 Tips > iSeries security tips > Setting up security for programmers on IBM i
iSeries 400 Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

ISERIES SECURITY TIPS

Setting up security for programmers on IBM i


Rich Loeber, Contributor
08.04.2009
Rating: -4.33- (out of 5)


iSeries news and advice
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


[IMAGE]
[IMAGE][IMAGE]
Rich Loeber [IMAGE]
[IMAGE]

When planning the security policies for an IBM i installation, security officers can often overlook the special requirements that programmers will have. This tip will provide guidance on how to best provide security and programmer flexibility.

Problems with programmers
Whether the programmers for your System i are in-house staff or outside consultants, they will provide unique challenges to security. On one hand, they are almost always an expensive resource so the fewer hoops they have to jump through to get their work done, the more efficiently (and cost effectively) they can do it. On the other hand, giving them full access to your system is a huge security risk and one that you would not grant to anyone else in your organization.

Programmers will always take the position that they need full access to your system in order to work effectively. In some cases, that may even be true; especially in small to medium sized shops where there is only a single programmer or a small programming staff. When problems arise during normal production, someone needs to be able to jump in and fix it, regardless of the system or systems affected. So, full system access may be required.

But, for development projects and for programmers who are working on specific task assignments, full access is never going to be required. Library and object controls can be kept in place and the assignment of all object authority (*ALLOBJ) should be avoided at all costs. The fewer user profiles you have with *ALLOBJ authority, the better. Each user profile with this high level of access authority represents a significant security risk.

How to best deal with programmers
One good approach is to segregate your programmers on a separate system so that they can work in an unrestricted environment, but not work with live data. Many shops I've worked...


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google



RELATED CONTENT
iSeries security tips
Security considerations for IBM i backups
Developing a security incident response system for System i
Tracking remote access users on System i
Controlling remote access on your IBM i
Checking in on your IBM i authorization lists
PCI data security standards and the System i
Securing the integrated file system on IBM System i
Contextual security on IBM i: Limit user profile access
Time for a security checkup for your i
Security monitoring on IBM i: Watching your super users

iSeries system and application security
Developing a security incident response system for System i
Blocking AS/400 DB2 users
Trouble accessing IFS path from Win2k3 server
Checking in on your IBM i authorization lists
Strategies for securing IBM i production files
Changing password security levels and upgrading operating systems on the IBM i
Determine the value of parameter UPPWEI in the DSPUSRPRF field
Define journal code value "K"
Modify content within a journal receiver file
Change password parameters on the AS/400 without deactivating user's passwords

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
midrange  (Search400.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary


in or worked with have maintained a separate system just for programmers. With LPARs, many organizations just carve out a test partition for their programmers. New code can be created, compiled and tested in a test environment without exposure to live data. If you can afford this, it is a great compromise. You have to create a strong change control turnover policy so that new programs and data files get the right security configuration when making the transition from test to production, but that should be easy to control.

For programmers that support daily production, a lot of what they do will not require all object authority. For those situations where it is an absolute necessity, consider setting up a super user profile that can be activated by your security officer as needed. Then, when the situation is found where more than normal access rights are called for, your security officer can activate the super user profile for use by the programmer in question. As soon as the fire is out, the security officer can deactivate the super user profile and all will be secure.

As a last resort, if you can't pry all object authority away from a user profile, then you should at least be journaling activity for each programmer user profile that has this authority granted. While this will only provide after-the-fact reporting, at least you will have a record of events. To set this up, security journaling must be active. Then you can use the change user auditing (CHGUSRAUD) command to configure what you want to track for the user profile in question. For more information on how to set this up, refer to this tip on monitoring your System i super users. Even if you are able to remove all object authority for most of your programming staff, I'd recommend taking this approach for every user profile on your system that has full access to the system.

If you have any questions about this topic, you can reach me at rich@kisco.com, I'll give it my best shot. All email messages will be answered.

ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the IBM i market.

Rate this Tip
To rate tips, you must be a member of Search400.com.
Register now to start rating these tips. Log in if you are already a member.


Submit a Tip




DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



iSeries Security - Security Tools, Physical Security and System Security
HomeNewsTopicsITKnowledge ExchangeTipsBlogsAsk the ExpertsMultimediaWhite PapersProducts
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 1999 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts