Removing *ALLOBJ access and raising system security levels

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT iSeries Security Changing password security levels and upgrading operating systems on the IBM i Determine the value of parameter UPPWEI in the DSPUSRPRF field Define journal code value "K" Modify content within a journal receiver file Change password parameters on the AS/400 without deactivating user's passwords Prevent insiders with *READ or *USE access from circumventing object authority on IBM i Prevent insiders from obtaining user ids and passwords on the IBM i Change the IBM i system to allow only certain types of SSL protocol versions Authorize a specific user to select files in a separate library Allow a user to view a library prod without granting full access to all data

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

As you are well aware, this security level is wide open. That's because, by default, at security level 20, i5/OS creates all profiles with *ALLOBJ special authority. To move from security level 20, some planning is required.

When moving to a higher security level, i5/OS will strip *ALLOBJ from all profiles except those in the *SECOFR user class. Therefore, you're going to have to decide how users are going to get enough authority to access and, where appropriate, modify the application data since it will no longer come from users having *ALLOBJ. Although several options exist, my preferred method is to have sufficient authority come from adopted authority. This allows you to set the appropriate authority on the database files – either *PUBLIC authority of *USE or *EXCLUDE. Yet, because the application adopts authority, users will still be able to perform their job functions when they come through the application menu. Accommodations will have to be made for any interface that accesses the data through something other than the application menus. To accommodate these database accesses, I usually secure the database files with an authorization list and grant authority to these "outside" processes so they can access the application files.

The interesting thing about security level 20 is that you can test changing the application's security scheme even before you change security levels. This is helpful because changing the security level requires an IPL before it takes effect. While it may appear that there is no security checking at security level 20, in reality, the same algorithm is run regardless of the security level. It just looks like there is no security checking because every profile has *ALLOBJ, so no profile is ever denied access. But you can remove a user's *ALLOBJ, even at security level 20. So you can test your new security scheme by creating a profile, removing its *ALLOBJ special authority and verifying that the application still works properly by running as this newly-configured profile.

I encourage you not to stop at security level 30, however. You really want your system running at security level 40 or 50. The steps to move to security level 40 are clearly explained in Chapter 2 of the iSeries Security Reference manual, available from the IBM Information Center.