S 2.132 Provisions for configuring database users / user groups

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The configuration of users/user groups in a database is a prerequisite for the appropriate assignment of access rights (see S 2.129 Controlling access to database information) and for ensuring proper and controllable operations. In general, every database user is provided with an internal database user ID that is used by the database system to identify the user. This ensures that only authorised users have access to the database.

Operations that change data (update, insert, delete, etc.) but are not executed by the DBMS and are executed by users with administration rights instead pose a high risk since they can lead to the destruction of the database. For this reason, rights that permit changes to the system tables should never be granted in general. Even read-only access should be restricted because all the information in the database can be found using the system tables.

As described in S 2.30 Provisions governing the configuration of users and of user groups, a form should be prepared for the purpose of gathering the data pertaining to each user and user group required for organised user administration:

A limited number of rights profiles should be specified. New users are then assigned one or more of these profiles so that they have exactly the rights necessary to perform each of their tasks. The capabilities available in the database for the configuration of users and user groups should be used and taken into account when selecting the database software package (see S 2.124 Selection of suitable database software). It makes sense to define naming conventions for the user and user group IDs (e.g. user ID = abbreviation of the organisational unit plus a sequential number).

In this case, user, role, and group profiles can be used. If possible, though, no user-specific profiles should be used since this can result in much more administration work when there are a large number of users to administer. A balance needs to be struck between restrictive and liberal authorisation profiles when defining group profiles. If the rights granted to the group profiles are too restrictive, then a large number of groups will need to be administered, which leads to more administrative work. If group profiles are made too liberal, redundancies could arise between the different groups, or granted rights could prove unnecessarily extensive, thus holding a potential for impairing the confidentiality of data.

Every user must be assigned a unique database user ID. Users should not be allowed to share a given database user ID.

In general, it is necessary to differentiate between the database user ID and the user ID of the underlying operating system. However, some manufacturers offer functionality in their database software for using the operating system user ID as the database user ID. This eliminates the need for users to provide authentication when accessing the database if they have already logged in to the operating system using their operating system user ID.

For example, OPS$ IDs can be used in Oracle. Such a user ID is a combination of the prefix "OPS$" and the operating system user ID of the user. The DBMS will not request the user to enter a password if the user logs in to the database system using his/her operating system user ID. However, if the user logs in using a different user ID, then the DMBS will prompt the user to enter a password.

However, this possibility poses the hazard that access to the database might no longer be deniable if a security violation occurs on the operating-system level (e.g. if the related password is cracked). For this reason, it should be examined before using OPS$ IDs if the security mechanisms of the operating system used on the clients provide adequate protection against such incidents.

If a simpler method is demanded for the user (i.e. a Single Sign On or SSO), then the use of an extra product for centralised user administration for the entire IT operation should be considered as an alternative. However, the corresponding additional product still needs to be examined to check if it meets the specific security requirements.

Review questions:

© Federal Office for Information Security. All rights reserved.