The technology enabled by PCs and mobile devices is one of the biggest challenges facing IBM i security administrators.

Editor's Note: This article is excerpted from Chapter 10 of IBM i Security Administration and Compliance: Third Edition

Nothing underscores the inadequacies of menu-based security more than using mobile-device–based software to access IBM i databases. If you still rely solely on menu security to control your sensitive and confidential information (in other words, if you don’t use object-level security), your security configuration has holes. Let’s look at IBM’s Access Client Solutions (ACS) and some of the security issues you’ll have to deal with there.

Access Client Solutions

ACS provides several applications, including Open Database Connectivity (ODBC), data transfer, Navigator for i, and 5250 emulation. ACS is the replacement for the old Client Access or current i Access for Windows products. i Access is not supported on Windows 10 and above, so if you’re currently using i Access for Windows, you will need to change your users over to ACS. ACS has several advantages over i Access for Windows. First, ACS is an executable and is not actually installed on the client; therefore, it’s much easier to stay current with ACS because it can be maintained using the same process you’re using for keeping your desktops up to date. Another benefit is that ACS runs on more than just Windows; ACS runs on Linux and Mac operating systems, as well.

ACS presents some security challenges, but it’s not a security exposure in and of itself. What it does is expose a system that does not have a sound object security implementation. Users cannot access any object through ACS that they don’t have authority to. Depending on how you or your vendor software has implemented object-level authorities, your data might now be accessible through client applications because the default access (i.e., *PUBLIC authority) has been left wide open (i.e., set to something other than *EXCLUDE).

You must couple the use of ACS with good resource security to ensure users can access only the data you want them to access. I encourage you to monitor the IBM ACS website at www-03.ibm.com/systems/power/software/i/ access/solutions.html to stay current with the latest updates and features.

Data Transfer and Remote Command Issues

ACS provides the ability to transfer data and run remote commands. If you let users use these features, you need to be aware of the consequences for the confidentiality of your data. Remember, all files with *PUBLIC(*USE) authority can be downloaded. Files with *PUBLIC(*CHANGE) authority can be downloaded, changed, and uploaded. You cannot guarantee the integrity of the data in files left at *PUBLIC(*CHANGE).

Letting users run remote commands is like letting users submit batch commands: IBM i doesn’t check the user profile’s LMTCPB parameter. If you’re tempted to use an exit program to totally disallow use of the remote command server or to change its auto-start feature and never start it, you’ll effectively disable most of Navigator for i as well because IBM uses the remote command server to implement Navigator. That’s another reason I prefer to use object-level security to protect data.

Host Servers

Running the STRTCP command starts all host servers whose autostart value is *YES. (These are the servers used by ACS to process requests, such as the license manage- ment server, sign-on server, database server, and so on.) You can use Navigator to customize which servers are started when you run STRTCP, or you can edit the QATOCSTART file in QUSRSYS to customize which servers you want to start.

Note that if TCP/IP fails or the ENDTCP (End TCP/IP) command is run, you must use the ENDHOSTSVR (End Host Server) command manually to end the host servers.

Limiting What Users See from the Desktop

ACS provides several ways, including Microsoft Group Policy Objects (GPOs), Application Administration, the ACS Deployment Manager, and client registry settings to limit what users can do from their desktops. Using these methods to ensure users only have access to the functions appropriate for their jobs is a good practice. Let’s look at what’s available.

Microsoft Policies

Support for Microsoft GPOs is inherent to the Windows operating system. Just as an administrator can control whether new software can be loaded onto the PC, an administrator can set a group policy for whichACS functions are allowed.

Application Administration

The Application Administration interface, which is included in both IBM Navigator for i and via the command WRKFCNUSG, lets you administer parts of ACS and Navi- gator for i. The effect is the same as enforcing Microsoft policies, except that an IBM i system administrator rather than a Windows administrator configures Application Administration.

ACS Deployment Manager

System administrators can selectively configure which components of ACS they want deployed. This is a good place to begin to control what function is available from users’ desktops. For example, you may want to have one deployment for administrators that includes all features, another for developers with most but not all features and another for end users that only includes the 5250 emulation feature. Unfortunately, the configuration provided through the deployment manager isn’t foolproof. Unless users’ rights to install software on their workstation are removed, they may be able to download additional features or a full install from either the Internet or another user’s device. In addition, you may also want to modify the registry settings on users’ workstations to ensure they can only use the ACS features required for their role.

ODBC Security Considerations

Open Database Connectivity is a set of standard interfaces developed to provide easy access to databases. Many applications use ODBC or the Java-compatible Java Data- base Connectivity (JDBC). Again, any database file that has public authority of at least *USE can be read through ODBC.

Some organizations attempt to use an exit program to help control unauthorized use of ODBC. The problem is that depending on the function being requested, somewhere between three and five host servers are used. There is no server named “ODBC” for which you can write one exit program and gain control. In addition, vendors using ODBC may use the DDM or DRDA server, or they may write their own server. In other words, it’s difficult to administer and securely control ODBC requests. At the risk of sounding like a broken record, I must remind you that this is a reason to make sure you have a sound object security implementation.

IBM i Access for Web

IBM i Access for Web provides a 5250 emulation session in a browser. If all you want to do is provide your users with a “traditional” sign-on in the context of a browser, this is the product for you. It provides much more administrative control than ACS via its “policies” feature. If the user doesn’t see a function in his or her browser interface, that function is not available to the user.

IBM i Access for Web also eliminates the need for some exit programs because the function runs through the Web server and there are no exit points associated with the Web server. But IBM i Access for Web definitely needs some of your attention. As shipped, it provides access to all its functions. Before deployment, you’ll want to remove access from the *PUBLIC group for all functions you don’t want to provide to your end users. Figure 10.2 shows the window you use to set security policies in IBM i Access for Web.

Figure 10.2: IBM i Access for Web

The configuration files for IBM i Access for Web reside in the IFS. See the manual IBM i Access for the Web available from the Information Center for a description of the policies and the path where the product’s configuration files are stored. (Be sure to get the manual for the version of the OS you’re running to get the current pathnames.)

You’ll want to monitor the permissions to these application files to ensure they remain DTAAUT(*RX) and OBJAUT(*NONE).