S 2.126 Creation of a database security concept
Initiation responsibility: Information Security Management, Head of IT
Implementation responsibility: IT Security Officer
The storage of data in databases over a long period of time is usually a central and critical aspect of information management in a government agency and/or company. Therefore, a database security concept must be drawn up early in order to enable the organisation of smooth database operations, with the concept describing the security aspects to be considered during the planning, installation, configuration, operation, migration, and de-installation phases.
When databases are not adequately protected, the result may be a loss of the confidentiality, availability, or integrity of the data stored in the database. In order to prevent such losses, it is essential to create a coherent database security concept.
In particular, the concept must contain statements as to
- how the data access rights for database administration and application administration will be separated,
- how the data will be stored and how the database will be mirrored, if applicable,
- how the data will be backed up,
- which mechanisms will be used in order to monitor and control the database activities, and
- how the database capacity will be monitored.
The security of a database is guaranteed at the software level by the corresponding database management system (DBMS). The following general conditions must be fulfilled in order for the DBMS to provide effective protection.
The DBMS must
- be based on a comprehensive security strategy,
- be integrated into the security concept of the organisation,
- be installed correctly, and
- be administrated correctly.
Direct accesses to the database (for example via an SQL interpreter such as SQL*Plus) must only be allowed for administrative users to prevent manipulations to the data and/or the database objects (for example the tables and indexes) (see S 2.134 Guidelines for database queries). Database objects may only be modified in a controlled manner using special user IDs.
Correspondingly, the DBMS must provide a suitable access concept for access to the data and the database system (see S 2.129 Controlling access to database information and S 2.128 Controlling access to a database system). User IDs only permitted to modify the data through an application must not be able to access the database directly, while user IDs used for administrating the database objects must be granted controlled, direct access.
The physical storage and/or mirroring of the database files (e.g. the DBMS software, the database itself, or the log files), as well as their distribution must be specified to increase the availability and reliability, for example. For availability reasons, the mirrored control files should be stored on different hard disks. In this case, the failure of one disk will not lead to the simultaneous loss of all control files. If the database objects of an application are stored in separate data files, it must be ensured when distributing the data files that the failure of one hard disk will not affect all applications.
Example:
A database administrates the data of two different applications and uses one data file each for the tables and indexes. The data files can be distributed in any manner among four hard disks.
The following is an unfavourable distribution of the data files:
| Hard disk | Type of data file storage |
|---|---|
| Hard disk 1 | Storage of the data files for the indexes of both applications |
| Hard disk 2 | Storage of the data files for the tables of the first application |
| Hard disk 3 | Storage of the data files for the tables of the second application |
| Hard disk 4 | - |
If the first hard disk fails, both applications would be affected and it would be impossible to use either of them.
As opposed, a more favourable distribution of the data files is as follows:
| Hard disk | Type of data file storage |
|---|---|
| Hard disk 1 | Storage of the data files for the indexes of the first application |
| Hard disk 2 | Storage of the data files for the tables of the first application |
| Hard disk 3 | Storage of the data files for the indexes of the second application |
| Hard disk 4 | Storage of the data files for the tables of the second application |
In this case, the failure of any one of the four hard disks would only affect one application.
If hard disks 1 and 2 are additionally mirrored on hard disks 3 and 4 and, vice versa, hard disks 3 and 4 are mirrored on hard disks 1 and 2, any two of the four hard disks could fail without this failure leading to the complete failure of the database for both applications.
Furthermore, the following important aspects must be regulated in a database security concept:
- the volume of data actually stored and the increases in the volume of data stored later on during actual operation must be examined regularly in order to be able to dimension the required memory space adequately for future requirements.
- suitable mechanisms for backing up the data must be used (see S 6.49 Data backup in a database).
- the use of monitoring and control mechanisms must be defined, i.e. whether and to what extent the database activities should be logged. In this case, there is also the question whether only the time of a data modification should be recorded or whether the modification itself should also be logged, for example (see S 2.133 Checking the log files of a database system).
Suitable personnel must also be available to design and operate a database system. The amount of time required to operate a database system should not be underestimated. According to experience, the evaluation of the logged data recorded alone usually takes a lot of time. A database administrator must possess in-depth knowledge of the DBMS software used and must also receive the corresponding training.
Review questions:
- Is there a database security concept describing the security aspects to be taken into account during planning, installation, configuration, operation, migration, and de-installation?