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 the user must prove he is who he says he is. 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, not exist at all. On UNIX platforms, 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 Windows 3.1 operating systems.
The security facility requires two items to authenticate a user: first, the user is identified to the security facility by a user ID; second, the user proves he is this identity by providing a piece of information known only to the user and the security facility; for example, a password.
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 will be added to the DB2 group list. No error is created when this happens, 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 may now allow others to change passwords on AIX and Windows NT EEE systems through the profile registry variable DB2CHGPWD_EEE=<boolean>.
The default for this variable is NOT SET (disabled). Other values for DB2CHGPWD_EEE are 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 will allow for the possibility that passwords may not be consistent across all nodes. That is, if a user uses the "change password" feature, then the user's password will only be changed at the node to which they connect. |
DB2 UDB on AIX has added the functionality to 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.
Selecting an Authentication Method for Your Server provides additional information about the system entry validation checking that is particularly relevant if you have remote clients accessing the database.
Authorization is the process whereby DB2 obtains information about an authenticated DB2 user that indicates the database operations a 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 in which the user is a member, are compared against the recorded permissions. Based on the comparison, DB2 decides whether to allow the user 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 for a given database. 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 for each database; system authorities are recorded by 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 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) and is not considered for static SQL (the exception to this general case being 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 DB2 documentation, where applicable.
Privileges, Authorities, and Authorization presents further details on these topics.
Because a DB2 federated database system can access information in multiple DBMSs, additional steps might be required to secure your data.
When planning your authentication approach, consider the fact that users might 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 might be required if data sources require a user ID and password. See Federated Database Authentication Processing for more information.
Similarly, your 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.