DB2 Security Policy

This DB2 Security Policy sample is a basis for applying  DB2 security  good practise and regular audits. A DB2 environment is characterised by various developers(internal), administrators (internal) and third party access (external). The DB2 security policy should reflect these different requirements.

A DB2 Security Policy  is the foundation for implementing security. Regular audits should be carried out , comparing the environment with the security policy. Any discrepancies can be fixed. Read more on DB2 security audit

 The DB2 security is broken into  separate  categories. Not all policies are relevant for every organisation. As a DBA , it may not be possible to fulfil all these policies. For example, reviewing all 3^rd DDL and DML can be a time consuming process.

Access to accounts with elevated privileges in DB2

 Linux servers:

• Access to the Linux DB2 UDB instance account is controlled by the DBA and granted as a service request when required.

• Linux DB2 UDB servers must have an alias id, which has the same UID as DB2 UDB instance ID.

•DBA  has ownership of the password on the DB2 UDB instance ID.

• Access to DB2 UDB instance account is by exception only when you cannot use the alias ID. Access is granted to the owner by the DBA as a service request when required

• Access to the DB2 UDB account that own objects (schema owner; e.g., tables, views) has login authority removed upon implementation.  DBA  has  ownership of the password

• Initial setup request and population of the “sysadm” group is fulfilled by DBA

• Initial setup request and population of the “sysmaint” group is fulfilled by DBA.

• Initial setup request and population of the “sysctrl” group is fulfilled by DBA. This group is not used. Population of this group is by exception.

• Addition or deletion of new users to the “sysadm”, “sysmaint”, and “sysctrl” groups is done through DBA using a change ticket .

• All Linux UDB servers have an id, dbbackup, defined for backup access and it is a member of the “sysmaint” group.Password is maintained by DBA.

• All Linux UDB servers have an id, dbaread, defined for READ ONLY access for both UDB and Linux files.

For Windows servers:

• Windows user db2admin is created during DB2 UDB software installation and is a member of the DB2ADMNS and local administrators group.

•DBA  has ownership of the password for the db2admin user on UDB database servers.

• DB2ADMNS and DB2USERS are created by DB2 during installation. The group DB2ADMNS has the description: “This group and local administrators will have complete access to all DB2 objects through the operating system.”

• The group DB2USERS has the description: “This group will have read and execute access to all DB2 objects through the operating system.”

• Initial setup request and population of the DB2ADMNS group is fulfilled by DBA

• Security adds Windows users and groups to the DB2ADMNS group using a service request ticket from DBA Team Only.

• Initial setup request and population of the “sysadm” group is fulfilled by DBA .

• Initial setup request and population of the “sysmaint” group is fulfilled by DBA.

• Initial setup request and population of the “sysctrl” group is fulfilled by DBA. This group is not used. Population of this group is by exception.

• Access to db2admin account is granted by exception. Access is granted to owners by DBA as a service request .

• Windows group DB2READ is to be defined to every DB2 UDB server.

• Windows group DB2READ is populated with the DBA group.

• Access to DB2 UDB accounts that own objects (schema owner; e.g., tables, views) is locked upon implementation. These accounts are unlocked by DBA as a service request. The appropriate id is identified based on the requirements and the limitations of each application.

Strong Passwords

All DB2 passwords are enforced by organisational guidelines for relevant operating systems.

Access to Database Objects

• No public access (i.e., select, insert, update and delete) is granted to database objects. Vendor packages may require exceptions.

• DB2 UDB servers have an “update” group which is granted update authority to tables. Users are defined to that role by the application area with a corresponding Service Request.

• Users are placed into database groups by function (e.g., web user, administration).

Creating Database Table Objects

• DBA  creates all tables, including those defined by vendor packages. The centralisation of this function ensures that tables are defined appropriately according to design and performance, particularly under high volume conditions.

• All tables are to be data modelled and access modelled. Vendor package models will be reviewed

DB2 Audit Trail

All DB2 UDB servers must have the DB2AUDIT program active to track changes to users and privileges. Any SQL statements which are executed to do the following are written to DB2AUDIT log and purged yearly. DBA regularly monitors the log.

• Addition / deletion of users to the database

• Changes to user privileges

• Role creation / deletion

Batch processing and Utilites

• Passwords are never embedded within a batch script. Passwords, where required, must be contained in a separate file, rather than being hard coded in scripts. Another option is to encrypt the password using built-in Linux functions. Read more on Linux useradd not creating password

Read more on DB2 security

DB2 - A Security Primer - DBA DB2

How to prepare a Database audit - DBA DB2

DBA Interview Questions and Answers – DB2 Security Management