By Dana Boehler
Securing an expansive platform like an IBM i system can be an intimidating task, a task that many times falls into the hands of a systems administrator when more specialized help is not available in-house. Deciding what tasks and projects will add value, while reducing administrative overhead, is also difficult. In this article I have chosen three things you can do in your environment that can get you started in ascending order of time and effort.
1. Run the ANZDFTPWD Command
Run the ANZDFTPWD command – This command checks the profiles on your system for passwords that are the same as the user profile name and outputs the list to a spooled file. Even on systems with well controlled *SECADM privileges (the special authority that allows a user to create and administer to user profiles), you will find user profiles that have either been created with or reset to have a password that is the same as the user profile name, which could provide an unauthorized user a method for gaining access to system resources. Additionally, the command has options to either disable or expire any user profiles found to have default passwords if desired.
2. Use SQL to Query Security Information from Library QSYS2
In recent updates to the supported IBM i OS versions, IBM made a very powerful set of tools available for querying live system and security data by using SQL statements. This allows users with the appropriate authority to create very specific reports on user profiles, group profiles, system values, audit journal data, authorization lists, PTF information and many other useful data points. These files in QSYS2 are table views directly accessing the information they are querying so the data is current every time a statement is run. One of the best things about creating output this way is there is no need for creating an outfile to query from or refresh re-querying. A detailed list of the information available and the necessary PTF and OS levels required to use these tools can be found here.
3. Implement a Role-based Security Scheme
The saying used to be the IBM i OS “is very secure”, but that statement has changed to the more accurate “is very securable”. This change in language reflects the reality that these systems are now very open to the world as shipped but can be one of the most secure systems when deployed with security in mind. For those who are not aware of role-based authority on IBM i, it is basically a way of restricting access to system resources using authorities derived from group profiles. Group profiles are created for functions within the organization, and then authorities are assigned to those group profiles. When a user profile is created it is configured with no direct access to objects on the system, instead group profiles are added to allow access to job functions. Although implementing role-based security may seem like a daunting task it pays huge dividends in ease of administration after the project is in place. For one thing having role-based security in place allows the administrator to quickly change security settings for whole groups of users at once when needed, instead of touching each user’s profile. It also allows for using group profiles as the object owners instead of individual user profiles, which means the process of removing users who create large numbers of objects or objects that are constantly locked is much easier. Using role-based security also relies on group profile for authority, so the likelihood of inadvertently granting a user too much or too little authority by copying another similar user is far less likely.
These a just a few of things you can do to get started securing your IBM i. In future posts, I intend to delve into more depth, especially regarding role-based security.