|
This is really one of those "it depends" questions. Attempting to secure your system by securing certain commands -- especially commands like the ones you've listed here is a bit like attempting to secure your system using exit points. There are many ways around either method. Prudent use of object level security and controlling who is given special authorities is a much more robust way to secure your system rather than using either exit points or securing commands. For example, if you control the users who have special authorities such as *SECADM to just the users that need to create or manage user profiles, there's really no need to secure the command, CRTUSRPRF, because this command requires *SECADM special authority to run. The STRSST command requires *SERVICE special authority so again, if you control who has *SERVICE to just the users that have a business justification to have it, then you shouldn't have to secure the command. Likewise, if you have used object level security, you shouldn't have to secure the EDTOBJAUT command because, unless the user somehow has *OBJMGT to an object, they can't edit the authority of the object. Now if your system is wide open from an authority point of view and most users have more special authorities than is appropriate, then maybe, as a stop-gap measure, it would be appropriate to secure the commands. But, in general, I would put my efforts into securing the objects appropriately and making sure special authorities are only given to the appropriate users rather than trying to make sure all the commands you've listed are secured. However, this method is very error prone -- you have to make sure to secure all instances of the commands and make sure you review all new commands added each release. Securing the objects and limiting special authorities is much more robust approach.
|
