Planning application security

An overview for creating an application security plan for your company.

To plan the right security for your applications, you need to know:
  • What information do you plan to store on the system?
  • Who needs access to that information?
  • What kind of access do people need? Do they need to change information or only view it?

As you go through these application planning topics, you answer the first question about what information you plan to store on your system. In subsequent topics, you decide who needs that information and what kind of access users need. You do not enter the application planning information into the system; however, you will need it when you set up users and resource security.

What is an application?

In the first planning step for application security, you need to describe the applications you plan to run on your system. An application is a group of functions that logically belong together. Usually, two different types of applications can run on your server:
  • Business applications: Applications you buy or develop to perform specific business functions, such as order processing or inventory management.
  • Special applications: Applications you provide that are used throughout your company to perform a variety of activities that are not specific to a business process.
What forms do you need?

Describing your applications

At this point, you need to gather some general information about each of your business applications. Add information about your application to the appropriate fields on the Application Description form as described below. Later you can use this information to help you plan user groups and application security:
Application name and abbreviation
Give the application a short name and an abbreviation that you can use as shorthand on forms and for naming objects that the application uses.
Descriptive information
Briefly describe what the application does.
Primary menu and library
Identify which menu is the primary menu for accessing the application. Indicate the library in which the menu is. Typically the primary menu leads to other menus with specific application functions. Users like to see the primary menu for their main application immediately after signing on to the system.
Initial program and library
Sometimes applications run an initial program that sets up background information for the user or does security checking. If an application has an initial program or setup program, list it on the form.
Application libraries
Each application typically has a main library for its files. Include all libraries that the application uses, including program libraries and libraries that other applications own. For example, the JKL Toy Company’s customer order application uses the inventory library to get item balances and descriptions. You can use the relationship between libraries and applications to determine who needs access to each library.

Finding information about your applications

If you do not already know the information you need about your applications, you may need to contact your programmer or application provider. Here are some methods for gathering the information yourself, if you do not have access to this information about an application that runs on your system:
  • Users of the application can probably tell you the name of the primary menu and library, or you can watch them sign on to the system.
  • If users see the application immediately after signing on, look at the Initial program field in their user profiles. This field contains the initial program to the application. You can use the DSPUSRPRF command to view the initial program.
  • You can list the names and descriptions of all the libraries on your system. Use the DSPOBJD *ALL *LIB. This displays all libraries on your system.
  • You can observe active jobs while users are running the application. Use the Work with Active Jobs (WRKACTJOB) command with intermediate assistance level to get detailed information about interactive jobs. Display jobs and look at both library lists and their object locks to find out which libraries are being used.
  • You can display batch jobs in an application using the Work with User Jobs (WRKUSRJOB) command.
To ensure that you gather all the information you need to plan your application security, you should complete these tasks before continuing:
  • Complete an Application description form for each of your business applications. Fill out the entire form, except the security requirements section. You will use that section to plan resource security for the application as described in the topic Resource security.
  • Prepare an Application description form for each special application, if applicable. Using the form helps you determine how to provide access to the application.
Note: Preparing Application description forms for special applications from IBM, such as IBM Query for i is optional. Access to the libraries used by these applications does not require any special planning. However, you may find it useful to gather the information and prepare the forms.

Planning applications to prevent large profiles

Because of the potential effects to performance and security, IBM strongly recommends using these recommendations to avoid profiles from becoming too full:
  • Do not have one profile own everything on your system.

    Create special user profiles to own applications. Owner profiles that are specific to an application make it easier to recover applications and to move applications between systems. Also, information about private authorities is spread among several profiles, which improves performance. By using several owner profiles, you can prevent a profile from becoming too large because of too many objects. Owner profiles also allow you to adopt the authority of the owner profile rather than a more powerful profile that provides unnecessary authority.

  • Avoid having applications owned by IBM-supplied user profiles, such as QSECOFR or QPGMR.

    These profiles own a large number of IBM-supplied objects and can become difficult to manage. Having applications owned by IBM-supplied user profiles can also cause security problems when moving applications from one system to another. Applications owned by IBM-supplied user profiles can also affect performance for commands, such as CHKOBJITG and WRKOBJOWN.

  • Use authorization lists to secure objects.

    If you are granting private authorities to many objects for several users, you should consider using an authorization list to secure the objects. Authorization lists will cause one private authority entry for the authorization list in the user’s profile rather than one private authority entry for each object. In the object owner’s profile, authorization lists cause an authorized object entry for every user granted authority to the authorization list rather than an authorized object entry for every object multiplied by the number of users that are granted the private authority.