In my last tip, I got a lot of good feedback from readers with additional ideas that help address the issue of access controls over your programming staff. Remember, the objective is to empower your programmers to do what they need to do without giving them the ability to damage your production data -- either intentionally or unintentionally. After all, programmers are human and can make mistakes. The unfortunate part is that sometimes when a programmer makes a mistake, it's a whopper. (I should confess here that I once deleted my company's customer master file by mistake. Fortunately, it was during off hours and I realized my goof right away and was able to recover the data before anybody found out about it. I was late for dinner that night!)
|
|
 |
One reader described a situation where he keep the programmers separate from the production environment by keeping them on their own system. That is a great idea and not very hard to do in these days of high-speed processors, LPAR environments and networking. A used iSeries can be picked up fairly inexpensively, but then you have licensing issues to contend with for your operating system and any other licensed products that you need to get programming tasks done. If a second machine is not in the cards, it would not be too difficult to take your current system and split it up into two logical partitions, giving one partition to the programmers. That may result in some additional licensing costs, and further investigation would be called for to sort all of that out with your software vendors.
Once you have your programmers isolated that way, they can do whatever they want in their test domain without a chance of affecting production files or processing. Plus, your programmers will probably love having their own sand box to play in. At one company where we did that, we used that method to train end users on changed applications before they went live and the user's loved it.
With your programmers separated out, you then just need to contend with change control rules. There are some good change control software products on the market, but your company better have deep pockets as many of my readers report that the entry cost is pretty steep.
The things to be concerned about with change control are that you always have a copy of the source code for the applications as they are running in production. When you have a change to a production module, check the source out to the programmer assigned to any changes and then keep track of that until the project is done. When the change is to be implemented, you need to update the various system objects that need to be implemented into production taking care that all ownership and security authorizations are updated to reflect you company's policies. Then, save the current objects in case you need to do a rollback and put the new version in place. When the new versions are implemented, the corresponding source needs to be updated while versioning the prior source code. That's a mouthful, but I think you get the picture. In today's networked world, moving objects from the programmer's system (or partition) over to your production system should be easy and controllable from a security perspective. Consider using a super profile just for that purpose and then track everything done by the profile.
If you have specific questions about this topic, e-mail me at rich@kisco.com. All e-mail 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 iSeries market.
