Contactez-nous Suivez-nous sur Twitter En francais English Language

De la Théorie à la pratique

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN



Ulf Mattson Protegrity Corporation: How to Protect Private Data from the Database Administrator

October 2008 by

This is not just a problem of trustiness, it is a principle. Technically, if we allow a DBA to control security without any restriction, the whole system becomes vulnerable because if the DBA is compromised, the security of the whole system is compromised, which would be a disaster. On the other hand, if we have a mechanism in which each user could have control over his/her own secrecy, the security of the system is maintained even if some individuals do not manage their security properly.

Access control is the major security mechanism deployed in all RDBMSs. It is based upon the concept of privilege. A subject (i.e., a user, an application, etc.) can access a database object if the subject has been assigned the corresponding privilege. Access control is the basis for many security features. Special views and stored procedures can be created to limit users’ access to table contents. However, a DBA has all the system privileges. Because of her/his ultimate power, a DBA can manage the whole system and make it work in the most efficient way. In the mean time, she/he also has the capability to do the most damage to the system. With a separated security directory the security administrator is responsible for setting the user permissions. Thus, for a commercial database, the security administrator (SA) operates through a separate middle-ware, the access control system (ACS), which serve for authentication verification, authorization, audit, encryption and decryption. The ACS is tightly coupled to the database management system (DBMS) of the database. The ACS controls access in real-time to the protected fields of the database. Such a security solution provides separation of the duties of a security administrator from a database administrator (DBA). The DBA’s role could for example be to perform usual DBA tasks, such as extending table-spaces etc, without being able to see (decrypt) sensitive data.

The SA could then administer privileges and permissions, for instance add or delete users. For most commercial databases, the database administrator has privileges to access the database and perform most functions, such as changing password of the database users, independent of the settings by the system administrator. An administrator with root privileges could also have full access to the database. This is an opening for an attack where the DBA can steal all the protected data without any knowledge of the protection system above. The attack is in this case based on that the DBA impersonates another user by manipulating that users password, even though the user’s password is enciphered by a hash algorithm. The major DBMS products on the market does not provide a segregation of data administrative roles and security roles. Third party products can solve this requirement and provide the needed secure encryption technology to protect confidential data and careful management of access to the cryptography keys. It is possible to prevent DBAs from accessing sensitive data that is stored in the database if column level encryption is used. It is also possible to give DBAs to access sensitive data and provide full accountability and tracking via the tamper resistant audit log in encryption system.

See previous articles


See next articles