RPGIV @ Work

A unique site for RPG and System i Lovers

Welcome!

Hi, this site will provide all what you need in System i and RPG developments.

My Name is Chamara Withanachchi, System i Expert and RPG Developer. And in the field for last 11 years.

I hope you will find lot of valuable information from this site

Some Security Enhancements in 7.1 Print E-mail
User Rating: / 1
PoorBest 
Written by Chamara Withanachchi   
Some Security Enhancements in 7.1

Automated Profile Disablement

For the average customer, the enhancement of greatest interest may be the new "automated profile disablement" feature integrated into user profiles. The system will not allow anyone to log in with a disabled profile, even if the correct password is provided. In previous releases, the only ways to disable a profile were by a user repeatedly attempting to authenticate using an incorrect password or by an administrator explicitly setting a profile's status to *DISABLED.

The new user profile function allows an administrator to specify the length of time a user profile will remain enabled or, alternatively, the date on which the user profile will be disabled. This will be especially useful for managing profiles for temporary employees, contractors, and IBM support personnel.


Similar support has been available in the Security Toolkit functions available on the IBM i since the mid-1990s. But that function, found in the DSPACTSCD and CHGEXPSCDE commands, was provided on top of rather than integrated into the OS. Many customers were not aware it even existed.

In V7.1, two new, mutually exclusive attributes, USREXPDATE (User expiration date) and USREXPITV (User expiration interval), have been added to user profiles. Both values can be set or changed by an administrator on the CRTUSRPRF and CHGUSRPRF commands. If the USREXPITV attribute is set, the user profile will remain enabled for the number of days specified. If the USREXPDATE attribute is set, the user profile will be disabled on the specified day at about midnight.


The DSPACTSCD and CHGEXPSCDE commands from the security toolkit continue to provide the same function as they always did, but their function is now integrated into the system. You can still delete (rather than disable) an expired user profile, but that function is available only through the CHGEXPSCE command. DSPUSRPRF provides the same information as DSPACTSCD for a specific profile.


All of the user profile expiration information is displayed via DSPACTSCD and DSPUSRPRF. The commands, CHGEXPSCDE and DSPACTSCD, work as they always did but are now tied together, from a code perspective, with the new user profile parms (you can use either). *DELETE is still supported on CHXGEXPSCDE. If you use CHXGEXCPSCDE PAT on a profile and then DSPUSRPRF PAT, you will see the expiration date and option (*DISABLE or *DELETE).


Encrypted Storage Enhancements

Also of potential interest to customers is additional support for encrypted auxiliary storage pools (ASPs). V6.1 introduced software encryption for newly created ASPs. Existing ASPs, however, couldn't exploit encryption. V7.1 allows a customer to turn software encryption on—and off—for existing ASPs, which provides much more flexibility. Encryption keys used to encrypt data on ASPs—and protected by a master ASP encryption key—can also be changed beginning in V7.1. This enables periodic key rotation.

V7.1 supports new hardware-based disk encryption as well. The support requires Tivoli Key Lifecycle Manager (TKLM). Encryption Key Manager (EKM), which is used for encrypting tape drives, is still supported, but TKLM is now considered strategic by IBM. TKLM does not run natively on IBM i. The vast majority of customers run encryption key managers on cheaper Windows or Linux boxes as there are numerous scenarios (especially disaster recovery) where this makes sense. The DS8000 and DS5000 series disk drives provide encryption in the drive. More choices are now available for encrypting tape drives too. The Redbook IBM System Storage Data Encryption is a good reference for more information on this topic.


Database Field Procedures

Of particular interest to ISVs and to the more advanced IT shops is a new database feature IBM calls "field procedures." Similar to triggers, they are user programs called during read, update, and insert operations for defined columns in a database table. Field procedures can be used for any purpose; however, they include an extra twist: an internal data space independent of the I/O buffers used for the "external" column data. This will be especially useful for encrypting database fields holding sensitive data.


Field procedures are defined for specific columns using CREATE/ALTER TABLE SQL statements. During CREATE/ALTER TABLE processing, the system calls the field procedure program. The program returns the length of the data to be stored in the internal data space. The internal data length can be longer or shorter than the length of the data in the field itself.


During update and insert operations, the system calls the procedure with the data intended to be stored in the field. The field procedure can return the same or different data back to the system.


During read operations, the system also calls the procedure. The procedure can return the data currently "officially" stored in the field, or it can return modified or completely different data as long as it matches the field definition.


So how would a procedure use the internal data space? That's easiest answered by an example. Assume you have a column in a table defined as 11 characters and intended to hold Social Security numbers. A field procedure is defined for this field. An application inserts a new row with a valid Social Security number, say, 123-45-6789. The system calls the field procedure, passing it (among other information) the data provided by the application to be stored in the field. The field procedure uses an encryption package to encrypt the Social Security number. The encrypted string is 16 bytes long. The procedure stores the encrypted value in the internal data space. It returns the string ***-**-6789 to the system, and this value is stored in the field. Note that this means that fields don't have to be redefined to accommodate encrypted versions of any data not matching the field definition.


During read operations, the system calls the procedure with the data "officially" stored in the field. In our example, the procedure receives ***-**-6789 from the system. The procedure, however, decrypts the data stored in the internal data space (yielding 123-45-6789) and returns this value to the system, which, in turn, returns this value to the caller.


The Display File Field Definition (DSPFFD) command shows whether a field procedure is defined for the field or not. Queries of the DB Cross-Reference Catalogs will also show defined field procedures.


The SQL Programming Guide offers a sample field procedure and discusses usage and restrictions.


TCP/IP Transport Security Extensions

Since V3R1, the Telnet server has provided a "connection time" exit point. The system passes TCP/IP connection information (e.g., addresses, ports) associated with the accessing (i.e., remote) system and the local system involved in the potential connection. Customers and vendors can build exit point programs that decide whether to allow or deny the connection, based on the information passed to it. This capability was only available to a few system-provided TCP/IP applications.


In V7.1, IBM provides exit point support for the TCP/IP accept(), connect(), and listen() APIs. These exit points allow the same connection time function as is available for Telnet to any arbitrary user-written TCP/IP application.


SSL Support for IBM i Telnet Client

The IBM i Telnet server has long supported SSL connections. However, the Telnet client on the i has not been able to use SSL connections. That is no longer the case in V7.1. New parameters have been added to the Telnet command to allow SSL connections.


Digital Certificate Manager (DCM) is used to associate a client certificate with the Telnet client. This means that a single certificate is used for all Telnet-over-SSL connections originating on the i. This isn't much of a restriction since most Telnet servers only require a valid certificate from a trusted CA and don't use certificates for client-side authentication.


This support is also PTFed to V6.1 and V5.4, although it is enabled through environment variables. By setting the QIBM_TELNET_CLIENT_SSL environment variable, you can force everyone who uses the Telnet client to use SSL connections or you can turn it on for specific jobs.


IBM also added a new encryption mode option, AES-XCBC-MAC, for VPN and updated SNMP to V3 in V7.1.


Something for Everyone

The new field procedure support is probably the biggest security enhancement in V7.1. But the automated profile disablement support might be the most widely used new security function in the release. Given the collection of security enhancements in V7.1, I suspect a lot of customers, Business Partners, and ISVs will be able to find something valuable in the bunch.


<Previous   Next>