To protect data and resources associated with a database server, DB2 uses a combination of external security services and internal access control information. To access a database server, you must pass some security checks before you are given access to database data or resources. The first step in database security is called authentication, where you must prove that you are who you say you are. The second step is called authorization, where the database manager decides if the validated user is allowed to perform the requested action, or access the requested data.
Authentication of a user is completed using a security facility outside of DB2. The security facility can be part of the operating system, a separate product or, in certain cases, may not exist at all. On UNIX based systems, the security facility is in the operating system itself. DCE Security Services is a separate product that provides the security facility for a distributed environment. There are no security facilities on the Windows 95 or the Windows 3.1 operating system.
The security facility requires two items to authenticate a user: a user ID and a password. The user ID identifies the user to the security facility. By supplying the correct password (information known only to the user and the security facility) the user's identity (corresponding to the user ID) is verified.
Once authenticated:
DB2 will obtain a list of groups up to a maximum of 64 groups. If a user is a member of more than 64 groups, only the first 64 that map to valid DB2 authorization names are added to the DB2 group list. No error is returned, and any groups after the first 64 are ignored by DB2.
DB2 uses the security facility to authenticate users in one of two ways:
DB2 administrators can allow others to change passwords on AIX and Windows NT EEE systems through the profile registry variable DB2CHGPWD_EEE. The default value for this variable is NOT SET (disabled). DB2CHGPWD_EEE accepts the standard boolean values used by other DB2 profile variables.
The DB2 administrator is responsible for ensuring that the passwords for all nodes are maintained centrally, using either a Windows NT Domain Controller on Windows NT, or NIS on AIX.
| Note: | If the passwords are not maintained centrally, enabling the DB2CHGPWD_EEE variable may result in passwords not being consistent across all nodes. That is, if you use the "change password" feature, your password will only be changed at the node to which you are connected. |
DB2 UDB on AIX can log failed password attempts with the operating system, and detect when a client has exceeded the number of allowable login tries, as specified by the LOGINRETRIES parameter.
For additional information about the system entry validation checking that is particularly relevant if you have remote clients accessing the database, see Selecting an Authentication Method for Your Server .
Authorization is the process whereby DB2 obtains information about an authenticated DB2 user, indicating the database operations that user may perform, and what data objects may be accessed. With each user request, there may be more than one authorization check, depending on the objects and operations involved.
Authorization is performed using DB2 facilities. DB2 tables and configuration files are used to record the permissions associated with each authorization name. The authorization name of an authenticated user, and those of groups to which the user belongs, are compared with the recorded permissions. Based on this comparison, DB2 decides whether to allow the requested access.
There are two types of permissions recorded by DB2: privileges and authority levels. A privilege defines a single permission for an authorization name, enabling a user to create or access database resources. Privileges are stored in the database catalogs. Authority levels provide a method of grouping privileges and control over higher-level database manager maintenance and utility operations. Database-specific authorities are stored in the database catalogs; system authorities are associated with group membership, and are stored in the database manager configuration file for a given instance.
Groups provide a convenient means of performing authorization for a collection of users without having to grant or revoke privileges for each user individually. Unless otherwise specified, group authorization names can be used anywhere that authorization names are used for authorization purposes. In general, group membership is considered for dynamic SQL and non-database object authorizations (such as instance level commands and utilities), but is not considered for static SQL. The exception to this general case occurs when privileges are granted to PUBLIC: these are considered when static SQL is processed. Specific cases where group membership does not apply are noted throughout the DB2 documentation, where applicable.
For more information, see Privileges, Authorities, and Authorization .
Because a DB2 federated database system can access information in multiple database management systems, additional steps may be required to secure your data.
When planning your approach to authentication, consider the fact that users may need to pass authentication checks at data sources as well as at DB2. In a federated system, authentication can take place at DB2 client workstations, DB2 servers, data sources (DB2, DB2 for OS/390, other DRDA servers, Oracle), or a combination of DB2 (client or DB2 server) and data sources. Even in DCE environments, specific steps may be necessary if data sources require a user ID and password. For more information, see Federated Database Authentication Processing .
Similarly, users must pass authorization checking at data sources and at DB2. Each data source (DB2, Oracle, DB2 for OS/390, and so on) maintains the security of the objects under its control. When a user performs an operation against a nickname, that user must pass authorization checking for the table or view referenced by the nickname.