|
|
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: Administrators
Users and user groups need to be configured in order to ensure an appropriate allocation of access rights (refer to S 2.129 Controlling access to database information) as well as correct and controlled operation. For this purpose, every database user generally receives an internal database ID with which the database identifies the user. This ensures that only authorised persons can access the database.
As described in S 2.30 Provisions governing the designation of users and user groups, a form should be prepared for the purpose of gathering details pertaining to each user and user group:
A limited number of authorisation profiles must be specified. New users are assigned to one or more profiles, thus receiving precisely those rights which are required for performing their individual activities. Database-specific possibilities of configuring users and user groups need to be considered here. It is advisable to specify naming conventions for user IDs and group IDs (e.g. user ID = abbreviation of organisational unit || serial number).
User, role, and group profiles can be used here. If possible, user-specific profiles should not be employed, as a high number of users would require a great deal of administrative effort. A balance needs to be struck between restrictive and liberal authorisation profiles when defining group profiles. If group profiles are made too restrictive, a large number of groups will need to be maintained, thus requiring a lot of administrative effort. 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.
As a rule, every user should be assigned a separate database ID; several users must not be allowed to operate under the same ID.
Normally, there is no association between a database ID and the user ID of the underlying operating system. However, some database software packages offer the possibility of copying the operating-system ID to the database system. This eliminates the need for users to answer the password prompt for database access if they have already logged in with their operating-system ID.
Oracle allows the use of OPS$ IDs, for example. This type of ID is composed of the prefix "OPS$" and the operating-system ID of the user. If a user logs into the database system with his operating-system ID, the database management system does not request the entry of a password. If a user logs in with a different ID though, a password is required.
However, this possibility poses a 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). Consequently, the security of the database relies heavily on the security of the underlying operating system. This does not generally imply the operating system of the database server - which is usually reliable - but that of the client, which is protected to a much lesser degree in some cases. Consequently, it is not advisable to make use of this possibility; instead, the use of an add-on product for central user management throughout the IT operation (e.g. ISM Access Master by Bull) should be considered in order to facilitate handling for users (keyword: Single-Sign-On). Here too though, harmonisation is required between the selected add-on product and the applicable security requirements.
Additional controls:
| © Copyright
by Bundesamt für Sicherheit in der Informationstechnik |
July 1999 |