User security

From a user's point of view, security affects how they use and complete tasks on the system.

User security includes how users interact with the system to complete their tasks. It is important to consider how a user will view security. For example, setting passwords to expire every five days might frustrate and interfere with a user's ability to complete his or her job. However, too lax a password policy might cause security problems.

To provide the right security for your system, you need to divide security into specific parts that you can plan, manage, and monitor. From a user's point of view, you can divide your system security into several parts.

User security includes all areas where security affects the users and where users can affect the system. Key components of user security include:
  • Physical access to the system

    Physical security protects the system unit and all system devices, including backup storage media, from accidental or intentional loss or damage. Most measures you take to ensure the physical security of your system are external to the system.

  • How users sign-on

    Signon security prevents a person who is not identified on the system from signing on. To sign on, an individual must present valid credentials, such as entering a valid combination of user ID and password. You can use both system values and individual user profiles to make sure that your sign-on security is not violated. For example, you can require that passwords be changed on a regular basis. You can also prevent the use of passwords that are easy to guess.

    Besides using a user ID and password, most interfaces on IBM i support a second type of authentication known as Network Authentication Service (NAS). NAS uses the Kerberos protocol to authenticate users to the IBM i. Using NAS, a user would have an Authentication Service (AS) create a Service Ticket (ST) to grant access to the IBM i. The Authentication Service runs on a network device known as a Key Distribution Center (KDC). In many modern networks, Microsoft's Active Directory performs this role of being the KDC, although the KDC can run on many different platforms. This service ticket contains the user's identity to the KDC and is digitally signed. When a connection is made to the IBM i, rather then entering a user profile and password, the client software sends this digitally signed service ticket instead. Once the IBM i verifies the digital signature ensuring the ticket was not altered and was sent from a trusted source, the IBM i then maps the KDC identity sent in the service ticket to an IBM i user profile, since the user may not have the same account name on both systems. The user is then allowed to start the connection without prompting for passwords. While this option does take some initial setup and requires a Kerberos supporting client, this then allows users to access the IBM i without maintaining a separate password on the IBM i. There is essentially one password repository in the KDC. The password for theIBM i user profiles can be *NONE. The digitally signed service ticket is used in place of the password.

    Modern authentication policies often require more complex pass phrases rather than traditional passwords. In addition, many recommend or require the use of multi-factor authentication (MFA). MFA involves using more than one factor type to verify a user. Factors generally fall into three categories:
    1. Something you know (user name, password, PIN).
    2. Something you have (authentication code, mobile device).
    3. Something you are, biometrics (finger print, facial recognition).
    Traditional system access involved both a user name and a password. Both of these items are of the same factor type - something you know. These are things that could be guessed or written down or compromised in other ways. Adding MFA to IBM i involves having more than just items that are known. IBM® offers MFA support for IBM i via the IBM PowerSC product. This offering allows for MFA support not only on IBM i but all operating systems that run on IBM Power®. For more information see: IBM PowerSC.
  • What users are allowed to do
    An important role of security, and of system customization, is to define what users can do. From a security perspective, this is often a limiting function, such as preventing people from seeing certain information. From a system customizing perspective, this is an empowering function. A properly customized system makes it possible for people to do their jobs well by eliminating unnecessary tasks and information. Some methods for defining what users can do are appropriate for the security officer, while others are the responsibility of programmers. This information focuses primarily on those things that a security officer typically does. Parameters are available in individual user profiles, job descriptions, and classes to control what the user can do on the system. The list below briefly describes the techniques available:
    • Limiting users to a few functions.

      You can limit users to a specific program, menu or set of menus, and a few system commands based on their user profile. Typically, the security officer creates and controls user profiles.

    • Restricting system functions.

      System functions allow you to save and restore information, manage printer output, and set up new system users. Each user profile specifies which of the most common system functions that the user can perform. You perform system functions by using control language (CL) commands and APIs. Because every command and API is an object, you can use object authorities to control who can use them and complete system functions.

    • Determining who can use files and programs.

      Resource security provides the capability to control the use of every object on the system. For any object, you can specify who can use it and how they can use it. For example, you can specify that one user can only look at the information in a file; another user can change data in the file; a third user can change the file or delete the entire file.

    • Preventing abuse of system resources.

      The processing turn on your system can become just as important to your business as the data that you store on it. The security officer helps to ensure that users do not misuse system resources by running their jobs at a high priority, printing their reports first, or using too much disk storage.

  • How your system communicates with other computers.

    Additional security measures may be necessary if your system communicates with other computers or with programmable workstations. If you do not have correct security controls, someone on another computer in your network can start a job or access information on your computer without going through the sign-on process. You can use both system values and network attributes to control whether you allow remote jobs, remote access of data, or remote PC access on your system. If you allow remote access, you can specify what security to enforce. You can find descriptions for all system values in Chapter 3, Security System Values, of the Security Reference.

  • How to save your security information.

    You need to regularly back up the information on your system. In addition to saving the data on your system, you need to save security information. If a disaster occurs, you need to be able to recover information about system users, authorization information, and the information itself.

  • How to monitor your security plan.
    The system provides several tools for monitoring security effectiveness:
    • Messages are sent to the system operator when certain security violations occur.
    • Various security-related transactions can be recorded in a special audit journal.
    Monitoring security discusses the use of these tools in general terms. You can find more details on security auditing in Chapter 9, "Auditing Security on the System," in the Security Reference.
  • How to customize the security on your system.
    You can customize your system to help your users accomplish their daily work. To best customize your system for your users, think of what they need to accomplish their work successfully. You can customize the system to show menus and applications in several ways:
    • Show users what they want to see.

      Most of users arrange their desks and their offices so they can easily reach the things that they need most. Think of your users' access to the system in the same way. After signing on to the system, a user should first see the menu or display that person uses the most. You can easily design user profiles to make this happen.

    • Eliminate unnecessary applications.

      Most systems have many different applications on them. Most users only want to see the things they need to do their jobs. Limiting them to a few functions on the system makes their jobs easier. With user profiles, job descriptions, and appropriate menus, you can give each user a specific view of the system.

    • Send something to the right output location.

      Users should not worry about how to get their reports to the correct printer or how their batch jobs should run. System values, user profiles, and job descriptions do these things.

    • Provide assistance.

      No matter how well you succeed in customizing the system, users may still wonder Where is my report? or Has my job run yet? Operational Assistant displays provide a simple interface to system functions, which help users answer these questions. Different versions of system displays, called assistance levels, provide help for users with different levels of technical experience. When your system arrives, Operational Assistant displays are automatically available for all users. However, the design of your applications may require you to change the way users get access to the Operational Assistant menu. The system provides tools which allow you to customize your system security to protect your resources while allowing users to access those resources.