[IMAGE]
[IMAGE][IMAGE]
Andrew Borts
[IMAGE]
[IMAGE]
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. Here he delves into setting up the system to allow specific user access and authority and maintain a secure i. In part three he directs you through the process of tightening up your system environment.
Let's review how we were flying around so we can land and accomplish more with our security plan. We started by
- Eliminating signs to our data centers
- Securing the building in which the computers are located
- Making sure the right people have access to the computing machinery
- Making sure we have policies in place for email, Internet access and how the Internet is used
- Making sure everyone is informed of the security plan
Now let's "land" and see what we need to get closer to the completion of this project.
What we need to do now is get the "locks" on the door and give "keys" to the individuals we want to have access, and make sure everyone else stays out. We also want to make sure our applications are secure from intruders and free of problems that may compromise their security. So let's further detail what we need to do to accomplish that.
We need to analyze how we will put the pieces in place, but we still have homework to do. We may need to segregate some environments from each other -- how much security will we need to make sure the people we want to have access can get it while seamlessly keeping others out of trouble, and still functioning as a group?
Passwords, object security, and groups
How complex are our passwords? There are many iSeries syst...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
em values that deal merely with passwords. We can make it impossible to figure out the passwords in our environment by flicking a handful of switches. But while this adds security, it introduces holes from users who aren't as disciplined -- so they write the passwords down or keep them in diaries. This compromises the organization because this is the literal "key" to your organization. Combat this by communication and training. Also verbally give out passwords (if you need to) instead of sending them via email. Email can be compromised, and opening that door exposes other vulnerabilities.
Object security on the iSeries is an amazing way to keep the bad people out while making sure your internal employees have access to what they need. There are ways to apply security to your system objects via individual authorization to each object (programs or files) or by using a system object called an authorization list. Using the latter, you merely need to modify the authorization list to make sure the right people have access.
The other fun part of our lives is the question of how we treat the users: by the group they are a part of in the company or as individuals? As groups, they now can have individual access to files based on their department. Accounting employees can be ACTGRP, or Accounting Group in six-letter speak (we programmers love to complicate things). Since the ACTGRP has certain file access, they can only see their accounting files, but may have read access to the sales files that the sales team may be able to add to and update. This granular approach eases the pain of applying security rules. Why? The users are broken into roles and are given the securities they need.
Website access
We also have a wrinkle to our security plan -- if we have a website on our iSeries, we need to allow two users access so our Internet servers can have access. From the outside world looking at our websites on iSeries, one user is the "show" for the websites -- the one that grants access to see static files we have created. He or she is QTMHHTTP. This user ID needs to have read access to the files we have, but no more. Since iSeries breaks down these activities into two users, the other part of the puzzle is the one that performs CGI tasks. This user needs read and write access, as the CGI program needs to change files. So, a rule of thumb: programs are readable and executable, but not updateable by the CGI process. Files are updated by the CGI process.
Since the website accesses files from your Integrated File System, use the QTMHHTTP user access for read-only access. Someone tried hacking my personal iSeries (doesn't everyone have one?) and couldn't modify the pages nor the graphics on the page. The iSeries separates this roll and thus keeps your system safe from intruders. Apache servers, when configured, are deny-all and allow limited access by default.
Firewalls
Which brings me to the appliance that makes people squirm: the firewall. Firewalls are a necessary evil on the World Wide Web, or the WWW. This device blocks access to the inside of your organization, and simultaneously logs the activity so that people can gain access only by a certain "door" to your company's world. This device can prevent rogue software from penetrating from different angles by limiting how they access your environment. This essentially forces them to take the front door, where you can place a guard to grant and deny access depending on the traffic. Firewalls can also block certain attacks into your environment that can cause iSeries to waste CPU cycles repelling boarders.
When I maintained my personal iSeries on the Internet, I also logged Web errors into a file that I monitored frequently to see what the bad people were doing. This is where you find the Web attacks where people would try to exploit Windows hacks and other command openings. If you want to kick back and get a chuckle, read the many attempts to hack the server.
Soft settings
Many of today's applications should have their own internal security that gives a more granular approach to limiting and granting user access. For example, one user may be able to see order totals, while another user may not have this access. These "soft" settings can be simulated by using a library list and a new logical file that doesn't allow access to certain fields. This is a more "brute force" method, and if you have access to modifying your application, I'd put these soft settings per user access so you can flip their access on and off. Two methods can be employed – a "user level": For example, above level 200 – users can do this; above level 400 – they can do more. Then the software just needs to be modified to say "above 200" do this. But this approach can be too broad for specific needs. You may need to say "Joe has access to reading these files" but "Peter has access to updating these files." Your application would merely check a file using the current User ID and application name, and return the type of access (READWRITE if Peter can read and write) to find out how Peter is supposed to access this.
We've now completed our homework and now know what our scope of work will be. I will show you the internal details of what commands we will use to accomplish this in the final "Dig-em" article.
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.
