Important to the DB2 administrator from the moment the product was installed are Security Considerations.
A user ID, a group name, and a password are required to complete the installation of DB2 database manager. If you install a GUI-based DB2 database manager that only creates default values for different user IDs and the group. Depending on the OS platform different defaults will be created.
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, different users for the DAS (dasusr), the instance owner (db2inst), and the fenced user (db2fenc). Optionally, you can specify different user names The 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 db2inst1 and db2inst2 already exist, the DB2 database install program creates the user db2inst3. 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 ID db2fenc9 already exists, the DB2 database install program truncates the c in the user ID, then appends the 10 (db2fen10). Truncation does not occur when the numeric value is appended to the default DAS user (for example, dasusr24).
On Windows operating systems, the DB2 database install program creates, by default, the user db2admin for the DAS user, 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.
For authentication process passwords are very important. 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, the DB2 database manager by default uses the rsh utility (remsh on HP-UX) 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. One example of a more secure alternative is ssh.
By default, the installation process grants system administration (SYSADM) privileges to the following users on each operating system:
By updating the database manager configuration parameter sysadm_group, the administrator can control which group of users possesses SYSADM privileges.
The administrator should consider creating an instance owner user ID that is easily recognized as being associated with a particular instance.
1. This user ID should have as one of its groups, the name of the SYSADM group created previously.
2. 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.
3. This should control the proliferation of user IDs and groups that can modify the instance.
4. The created user ID must be associated with a password to provide authentication before being permitted entry into the data and databases within the instance.
A user ID, a group name, and a password are required to complete the installation of DB2 database manager. If you install a GUI-based DB2 database manager that only creates default values for different user IDs and the group. Depending on the OS platform different defaults will be created.
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, different users for the DAS (dasusr), the instance owner (db2inst), and the fenced user (db2fenc). Optionally, you can specify different user names The 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 db2inst1 and db2inst2 already exist, the DB2 database install program creates the user db2inst3. 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 ID db2fenc9 already exists, the DB2 database install program truncates the c in the user ID, then appends the 10 (db2fen10). Truncation does not occur when the numeric value is appended to the default DAS user (for example, dasusr24).
On Windows operating systems, the DB2 database install program creates, by default, the user db2admin for the DAS user, 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.
For authentication process passwords are very important. 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, the DB2 database manager by default uses the rsh utility (remsh on HP-UX) 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. One example of a more secure alternative is ssh.
By default, the installation process grants system administration (SYSADM) privileges to the following users on each operating system:
Linux and UNIX operating systems
1. To a valid DB2 database user name that belongs to the primary group of the instance owner.
Windows environments
1. To members of the local Administrators group.
2. 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.
3. If Windows extended security is enabled, to members of the DB2ADMNS group. The location of the DB2ADMNS group is decided during installation.
4. To the LocalSystem account.
2. 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.
3. If Windows extended security is enabled, to members of the DB2ADMNS group. The location of the DB2ADMNS group is decided during installation.
4. To the LocalSystem account.
By updating the database manager configuration parameter sysadm_group, the administrator can control which group of users possesses SYSADM privileges.
The administrator should consider creating an instance owner user ID that is easily recognized as being associated with a particular instance.
1. This user ID should have as one of its groups, the name of the SYSADM group created previously.
2. 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.
3. This should control the proliferation of user IDs and groups that can modify the instance.
4. The created user ID must be associated with a password to provide authentication before being permitted entry into the data and databases within the instance.
0 comments:
Post a Comment