A comprehensive IBM System i database security plan requires that you take context into account when defining user profile access and authority. This tip examines three methods for implementing contextual security on System i.
My wife and I live in the mountains of northern New York state. We have very few neighbors -- the closest is almost a mile away. On a normal day, only a handful of cars drive down our road. In this context, we're not very concerned about security. We know all of the year-round residents and we all look out for each other. Our biggest security consideration is the local bear population.
In the System i world, context can also define how you handle security. The security of the operating system is not tuned to context, so you have to think about your requirements and take context into consideration.
What is contextual security?
Suppose you have an order-processing application that records credit card information and then processes that information to obtain credit card authorization approvals. Obviously, the clerk entering the order needs access to your customer database in order to enter the credit card information or to validate the information you already have on file. You would have to grant the user sufficient authority to add, change or delete information according to your company's standard security model for those tasks. In this context, the normal OS security works just fine.
For normal order-processing tasks, you can easily configure a user for database access and change authority. But a normal level of access would be inappropriate when changing context to access customer credit card information via FTP or when using iSeries Access download functions. If a user is assigned an incorrect access level, he could copy all of the credit card information on his desktop, then copy it to a flash disk or memory stick and leave the office with all of your customer credit card information. Nobody would be the wiser until the story breaks in The New York Times.
For the clerk in the example above, a single context approach to database security is not going to work. The user needs specific access rights to perform one job requirement, but for other contexts of the job, access must be restricted.
Fortunately, there are several ways to limit user access on System i. In this tip, I'll discuss three kinds of context-based security installations.
Defining context-based security: Three methods
The first and possibly the easiest option -- although not always cheapest -- is to install good exit point security software. The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them. You won't have to change the security setup in the operating system. The extra layer of security from the exit point solution will add the contextual security you need for network-based applications. You could write your own exit programs, but exit point programming is fairly complex, and the rules change periodically as operating systems are updated. It's better to choose a good product from a trusted software supplier.
The second and third methods -- adopted authority and profile swapping -- let you define security on your System i based on context. With both methods, the security in force is not based on the user profile running the application.
If you use adopted authority, your program bases security decisions on the user profile that owns the program, not on the profile that runs the program. This method allows you to control who can use the program. The program itself controls the resources it needs to access. With profile swapping, you can let the requesting user profile control things until different access rights are needed. Then, under program control, you can call an API in the operating system to swap profiles and run under a different profile for a given duration of processing. Either way, the user profile used to determine access rights is different than the user who is signed into the application, giving you contextual control over the situation.
If you have a question about this topic, write to me at rich@kisco.com and I'll give it my best shot. All email messages will be answered.
ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
Did you find this helpful? Write to the editor about your IBM i concerns at Editor@Search400.com.
