Search
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique











Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Encrypting columns, rows, indexes and disk in DB2 for z/OS

October 2008 by Ulf Mattsson, CTO, Protegrity Corporation

Different encryption solutions are utilizing fundamentally different methods to encrypt DB2 data on z/OS. Encryption does mean some tradeoffs in function, usability and performance.

An EDITPROC acts on a complete row of a table, as received from the database. The index is stored in the clear (in other words, unencrypted). If it is essential that indexes be encrypted, you should choose another method. A credit card number should not be exposed in the index if you need to be compliant to PCI DSS 1.1. PCI DSS is a set of collaborative security requirements for the protection of credit card transactions and cardholder data for all brands. This issue is not necessarily specific to credit card #s but credit card numbers are one important example of something you’d want to encrypt in an index. A column level encryption solution can be used to solve this issue.

A FIELDPROC transforms a single short-string column and allows the index to be stored as encrypted text. If multiple data elements in table need protection and none are in an INDEX, then EDITPROC is less resource intensive than multiple FIELDPROCs. If only one or few columns need protection then only those are encrypted. FIELDPROC can only be specified on short string COLUMNs, and cannot be specified on ROWID or LOB columns but columns with those data types are allowed in the TABLE. Queries with greater than, less than and range predicates are not supported. A column level UDF based encryption solution can be used to solve some of these issues (see below). FIELDPROC can be added by ALTER TABLE, so no need for unload, drop table, create table, reload sequence.

A User Defined Function (UDF) enables column-level encryption with views and triggers. The enhanced support for these functions in DB2 v.9 provides a higher level of application transparency than earlier DB2 versions. The lack of application transparency in earlier DB2 versions can be an issue when implementing UDF based encryption. UDF based encryption can be attractive if only one or few columns need protection and if support for additional data types is needed. UDF based column encryption also support a wide range of search operations on encrypted columns. Additional overhead, in some cases significant, can be expected if the search is forcing table scans and decryption of a large number of rows during the search operation.

A column level encryption solution can also be used in combination with SECLABEL based row-level security in DB2 V8, but you cannot define an EDITPROC on a table that has a SECLABEL column.

With DB2 V9, you can also use System z disk and tape controllers as a complement to encrypt some of the data at rest directly on these devices.




See previous articles

    

See next articles