Data Set Protection

The data in a DB2 subsystem is contained in data sets, which might be accessed without going through DB2 at all. If the data is sensitive, you want to control that access route.

If RACF or a similar security system is being used to control access to DB2, the simplest means of controlling data set access outside of DB2 is to use RACF for that purpose also. That means defining RACF profiles for data sets and permitting access to them for certain DB2 IDs.

If the data is very sensitive, you may want to consider encrypting it for protection against unauthorized access to data sets and backup copies outside DB2. You can use DB2 edit procedures or field procedures to encrypt data, and those routines can use the Integrated Cryptographic Service Facility (ICSF) of MVS. Use of these routines to encrypt data only protects that data from inappropriate access outside of DB2. Any data retrieval using an SQL statement would access encrypted data values.

Data compression is not a substitute for encryption. In some cases, the compression method does not shorten the data, leaving it uncompressed and readable. If you both encrypt and compress data, compress it first to obtain the maximum compression, and then encrypt the result. When retrieving, take the steps in reverse order: Decrypt the data first, and then decompress the result. Many encryption algorithms compress data before encrypting it. DB2 also provides built-in functions to encrypt and decrypt data values where each column or row could use a different encryption phrase or password.