|Partner TechTip: Command Access Can Bring Unexpected Consequences|
|Tips & Techniques - Security|
|Written by Robin Tatam|
|Friday, 12 August 2011 00:00|
PowerTech Command Security controls command use on your system.
Recently, I was approached at a tradeshow by the CIO of an organization running IBM Power Systems servers. He asked if I could help with a security dilemma his company had encountered. It seems that they had recently experienced an "unplanned outage" after an administrator inadvertently issued a PWRDWNSYS command while mentoring a new operator.
I cringed as I recalled a few occasions early in my own career when I wished the Enter key had ignored my instruction! While this administrator was authorized to perform this type of system task, there certainly was no desire to run it in the middle of the workday with the IBM default of RESTART(*NO)! The CIO wanted to know if there was any way he could enforce restrictions on users who typically are authorized to run commands. This was similar to a request I had received from another company, asking how they could prevent their programmers from using any of the CRTxxxPGM commands to compile directly into production.
Commands = Power
I explained that commands are objects and that you can grant and revoke authority to them much the same as you can with any application object. Some commands require that the person executing them have certain special authorities (in the case of the embarrassing PWRDWNSYS command, the user needed *JOBCTL special authority.) Unfortunately, once these requirements are met, the operating system does nothing additional to oversee execution of the command. This means that a user who is authorized to a command has total control of when and how it's executed.
Control Command Use with Command Security
PowerTech Command Security is a new rule-based security solution that's designed specifically to audit and control commands. To configure Command Security, you start by selecting which commands you want to monitor. Then, specify the conditions under which the command should be controlled. And finally, define the actions to take when those conditions are met. Conditions can be based on a value specified on a command parameter, the name of the requesting user or group profile, the calling program, the requester's IP address, or a number of other powerful and flexible filters. If a condition is met, Command Security performs the actions you've defined. Actions can include overriding a parameter (like the RESTART parameter!), sending a message, or even preventing the command from executing.
While there are endless ways to use Command Security to control the command use on a system, consider the following common, and simple-to-configure, scenarios:
And last, but certainly not least, for my CIO friend:
There are many companies, just like the one this particular CIO works for, that constantly struggle with managing their most powerful users. By partnering with PowerTech, the leading provider of security solutions for IBM i, you can deploy powerful solutions to secure all aspects of the environment without preventing these critical users from performing their jobs.
It's a win-win for everyone! Click here to learn more about Command Security.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1
|Last Updated on Thursday, 11 August 2011 09:43|