Securing your workstations

After you secure printer output, you should secure your workstations. You authorize workstations just like you authorize other objects on the system. Use the EDTOBJAUT command to give users authority to workstations.

Your system users have PCs on their desks as their workstations. They use tools that run on the PC, and they use the PC to connect to the server. Most methods of connecting a PC to IBM i systems provide more function than workstation emulation. The PC may look like a display to the system and provide the user with interactive signon sessions. In addition, the PC may look to IBM i systems like other computers and provide functions such as file transfer and remote procedure call.

As an IBM i system security administrator, you need to be aware of:
  • Functions that are available to PC users who are connected to your system
  • IBM i system resources that PC users can access
You may want to prevent advanced PC functions, such as file transfer and remote procedure call, if your security scheme is not yet prepared for those functions. Probably, your long-range goal is to allow advanced PC functions while you still protect the information on your system. The topics that follow discuss some of the security issues that are associated with PC access.

Secure workstation data access

Some PC client software uses shared folders to store information on the server. To access system database files, the PC user has a limited, well-defined set of interfaces. With the file transfer capability that is part of most client/server software, the PC user can copy files between the server and the PC. With database access capability; such as a DDM file, remote SQL, or an ODBC driver, the PC user can access data on the server.

In this environment, you can create programs to intercept and evaluate PC-user requests to access server resources. When the requests use a DDM file, you specify the exit program in the distributed data management access (DDMACC) network attribute. For some methods of PC file transfer, you specify the exit program in the client request access (PCSACC) network attribute. Or, you can specify PCSACC (*REGFAC) to use the registration function. When the requests use other server functions to access data, you can use the WRKREGINF command to register exit programs for those server functions.

Exit programs, however, can be difficult to design, and they are rarely foolproof. Exit programs are not a replacement for object authority, which is designed to protect your objects from unauthorized access from any source.

Some client software uses the integrated file system to store and access data on IBM i systems. With the integrated file system, the entire server becomes more easily available to PC users. Object authority becomes even more essential. Through the integrated file system, a user with sufficient authority can view a server library as if it is a PC directory. Simple move and copy commands can instantly move data from a system library to a PC directory or vice versa. The system automatically makes the appropriate changes to the format of the data.
Note: You can use an authorization list to control the use of objects in the QSYS.LIB file system.
The strength of the integrated file system is its simplicity for users and developers. With a single interface, the user can work with objects in multiple environments. The PC user does not need special software or APIs to access objects. Instead, the PC user can use familiar PC commands or “point and click” to work with objects directly.

For all systems that have PCs attached, but particularly for systems that have client software that uses the integrated file system, a good object authority scheme is critical. Because security is integrated into the IBM i product, any request to access data must go through the authority checking process. Authority checking applies to requests from any source and to data access that uses any method.