Modernize the way you find objects that don’t match your security requirements.
By Carol Woodbury
When clients rework their applications’ security configurations, one step I emphasize is that, once the project is complete, they’ll need to routinely check the applications’ objects to make sure they are still secured correctly. If this type of process isn’t in place, it’s quite likely that some of the objects will end up with the wrong security setting. How does that happen? A developer debugs a problem and, rather than promoting the fix through approved change-management processes, creates the program and restores it to the system themselves. Rather than the application profile owning the program, the developer owns it. (This an example of what can happen when developers have too much authority on production systems.) I’ve also seen authorization lists get changed from *PUBLIC *EXCLUDE to *PUBLIC *ALL while attempting to debug a production issue. Because security is always the cause of an issue (NOT!), the authorization list was changed to fix the problem. Of course, it didn’t resolve the problem, but no one remembered to go back and set the authorization list back to the correct setting.
Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. 
