[TABLE]In the first part of this three-part series, Andrew Borts discussed the general overview of everything that needs to be considered for a System i security policy. In part two he delved into setting up the system to allow specific user access and authority and maintain a secure i. Here he directs you through the process of tightening up your system environment.
Now that we've created the concepts for an AS/400 security policy and created a corporate-wide security solution, let's see what we need to do to secure our computers.
Reviewing what we did thus far:
We're now going to investigate how we tighten up our environments for security starting with the system and what needs to be done before we step into the environment.
We authenticated when we got to the office using our PC's -- can we utilize this so we don't need to sign on anymore? In some cases, yes, some no. The area you need to investigate further is a standard server for "directory services" called LDAP. This is a "directory" protocol which has been on the i5 since way back in V4R3 days. LDAP is a fancy data lookup service into a database of centrally stored users and their associated objects. The i5 can see if the user has been authenticated, and in some cases, bypass a sign-on page avoiding one of the MANY prompt for user ID and password. This second sign-on could be an "Achilles heal" for your users, causing them to write down their many User ID's and passwords and open up more holes in your environment.
What about our systems environment?
At last count, there were 36 security system values dealing with restoring objects and their security when restored to the changing and quality of passwords being create
To continue reading for free, register below or login
To read more you must become a member of Search400.com
d. Here is my favorite aspect that needs to be addressed:
[IMAGE]
Click image for larger version
There is also a seldom-used tool built into the operating system that you can access by typing "go security" and hitting enter. Here you can find many security tools and wizards to help you change your environment to your liking. Warning: you can potentially lock yourself out of your own system! So please read up on these tools. Read the CFGSYSSEC (configure system security) command documentation for more information.
Object level security is a necessity on the AS/400. The idea is that if someone were to "hack" into your system, what would they have access to? Hopefully, not much. So keep your objects secured to a group profile, or to an authorization list.
Also, turn on security auditing so you can review journal entries of changed security items. You can choose events and place them into the QAUTLVL system value and indicate which security events you want audited.
The system ships with minimum security level 40 that "hardens" the operating system against any hands that shouldn't be touching the system objects. The OS also locks out API's that may be harmful.
There you have it, my three part security overview is completed. This is an enormous topic, and can become a full-time job for someone at a larger company. Remember, salt to taste, and take this project one bite at a time. And try not to chew off too much at once!
ABOUT THE AUTHOR: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.
