Security considerations when installing and using the Db2 database manager
Security considerations are important to the Db2 administrator from the moment the product is installed.
- On UNIX and Linux operating systems, if you choose to create a Db2 instance in the
instance setup window, the Db2 database install
program creates, by default, the instance owner (
db2inst), and the fenced user (db2fenc). Optionally, you can specify different user namesThe Db2 database install program appends a number from 1-99 to the default user name, until a user ID that does not already exist can be created. For example, if the users
db2inst1anddb2inst2already exist, the Db2 database install program creates the userdb2inst3. If a number greater than 10 is used, the character portion of the name is truncated in the default user ID. For example, if the user IDdb2fenc9already exists, the Db2 database install program truncates thecin the user ID, then appends the10(db2fen10). - On Windows operating systems, the Db2 database install program creates, by default, the instance owner, and fenced users (you can specify a different user name during setup, if you want). Unlike Linux and UNIX operating systems, no numeric value is appended to the user ID.
Passwords are very important when authenticating users. If no authentication requirements are set at the operating system level and the database is using the operating system to authenticate users, users will be allowed to connect. For example on Linux and UNIX operating systems, undefined passwords are treated as NULL. In this situation, any user without a defined password will be considered to have a NULL password. From the operating system's perspective, this is a match and the user is validated and able to connect to the database. Use passwords at the operating system level if you want the operating system to do the authentication of users for your database.
When working with partitioned database environments on Linux and UNIX operating systems in releases of Db2 prior to version 11.5.6, the Db2 database manager by default uses the rsh utility to run some commands on remote members. The rsh utility transmits passwords in clear text over the network, which can be a security exposure if the Db2 server is not on a secure network. You can use the DB2RSHCMD registry variable to set the remote shell program to a more secure alternative that avoids this exposure. SSH is a more secure alternative, and is used by default starting from version 11.5.6. See the DB2RSHCMD registry variable documentation for restrictions on remote shell configurations.
- Linux and UNIX operating systems
- To a valid Db2 database user name that belongs to the primary group of the instance owner.
- Windows environments
-
- To members of the local Administrators group.
- If the Db2 database manager is configured to enumerate groups for users at the location where the users are defined, to members of the Administrators group at the Domain Controller. You use the DB2_GRP_LOOKUP environment variable to configure group enumeration on Windows operating systems.
- If Windows extended security is enabled, to members of the DB2ADMNS group. The location of the DB2ADMNS group is decided during installation.
- To the LocalSystem account
By updating the database manager configuration parameter sysadm_group, the administrator can control which group of users possesses SYSADM privileges. You must use the following guidelines to complete the security requirements for both the Db2 database installation and the subsequent instance and database creation.
Any group defined as the system administration group (by updating sysadm_group) must exist. The name of this group should allow for easy identification as the group created for instance owners. User IDs and groups that belong to this group have system administrator authority for their corresponding instances.
The administrator should consider creating an instance owner user ID that is easily recognized as being associated with a particular instance. This user ID should have as one of its groups, the name of the SYSADM group created previously. Another recommendation is to use this instance-owner user ID only as a member of the instance owner group and not to use it in any other group. This should control the proliferation of user IDs and groups that can modify the instance.