DB2 Database Asset Protection Standards:

From HORSE - Holistic Operational Readiness Security Evaluation.
Jump to navigation Jump to search

When analyzing your DB2 database, there are several areas in the database layer where you should validate security. Remember, it only takes one hole to compromise the entire security model. The areas covered are just a portion of the constant and never-ending process of securing the database server and the entire enterprise.

Authentication types. In DB2, the authentication type is used to identify users. It defines where and how authentication occurs. Several authentication types are available; which one to use should be carefully determined by the environment, operating system, and purpose of the DB2 server.

The authentication type is configured on both the client and server. However, authentication type is defined only on the server in the database manager configuration file. That configuration file is associated with an instance and applies to all databases with that instance as well as all users within the database.

DB2 currently supports the following authentication types:

  • SERVER
  • SERVER_ENCRYPT
  • CLIENT
  • DCE (replaced by KERBEROS with LDAP in v.8)
  • DCS (holds the same meaning as SERVER in DB2 v8, with the exception of federated servers)
  • DCS_ENCRYPT (holds the same meaning as SERVER_ENCRYPT in DB2 v.8, with the exception of federated servers)
  • KERBEROS (for Windows 2000/XP/2003, planned for Unix/Linux expansion)
  • KRB_SERVER_ENCRYPT (for Windows 2000/XP/2003, planned for Unix/Linux expansion).


For CLIENT authentication, two other parameters are used: TRUST_ALLCLNTS and TRUST_CLNTAUTH. When determining a secure mechanism, don't depend on client authentication. You can't assume clients are secure. Even TRUST_CLNTAUTH is ineffective because the client can be spoofed (a term that refers to a hacker observing and modifying a target's Web pages).

You should use either SERVER_ENCRYPT or KBR_SERVER_ENCRYPT for fewer security weaknesses.

IBM DB2 usernames and passwords. For DB2 UDB installed on Windows, make sure you change all default usernames and passwords immediately. Hackers use these default names and passwords as an easy first attempt to break into your database once they've broken through the other layers of security.

DB2 database privileges. IBM DB2 databases don't have database-specific accounts as other databases do. Instead, authentication is performed under the operating system with operating specific accounts. As a result, DB2 doesn't have a table where all accounts are listed. Accounts are stored in the following tables instead:

  • IBMSysDBAuth
  • IBMSysTabAuth
  • IBMSysINDEXAuth
  • IBMSysCOLAuth
  • IBMSysSCHEMAAuth
  • IBMSysPASSTHRUAuth.


You should revoke privileges on the system catalogs I listed in order to help prevent easy access. For security lockdown, you should also remove all permissions granted to public and carefully examine all users within the SYSADMIN group.

INSTEAD OF triggers. In addition to native support for INSERT , UPDATE , and DELETE , Secure.Data supports INSTEAD OF triggers that perform Secure.Data operations transparently.

Control of external routines. Secure.Data user-defined functions (UDFs), methods, and stored procedures can interfere with the execution of other external routines or the database, so security restrictions on these routines are important. DB2 v.8.1 defines new authorities to explicitly control creation of these external routines. The routine EXECUTE can only be used in SQL statements when the routine definer has the EXECUTE privilege on any packages used by the routine.

New authorities for registering external routines. The new CREATE_EXTERNAL_ROUTINE authority is required to register external routines (such as stored procedures, UDFs, and methods).

NOT FENCED routine restrictions. DB2 UDB NOT FENCED UDFs boost the performance of Secure.Data operations. NOT FENCED routines run in the same process as the database manager. The CREATE_NOT_FENCED_ROUTINE authority is required to register NOT FENCED routines, limiting the risk to introduce routines that may corrupt the database manager's shared memory or damage the database control structures. NOT FENCED routines can also corrupt databases and their tables.

Retrieved from "http://horseproject.wiki/index.php?title=DB2_Database_Asset_Protection_Standards:&oldid=4298"