In the strategy for data security, the majority of companies today focus their resources on protecting data in transit. Meanwhile, the issue of securing data within databases (DB) has not received adequate attention.
Evidence shows that security incidents involving databases can seriously affect a company’s reputation and customer relations. The recent security breach involving the theft of 40 million customer credit cards from MasterCard and Visa has heightened awareness of database security solutions.
This article aims to present database security solutions through the implementation of encryption layers. 
The simplest solution to protect data in databases at the file level, against unauthorized access to database files, is encryption. However, encrypting data at this level is a “winner-takes-all” solution, as it does not provide access security at the table, column, and row levels. Another weakness of this solution is that anyone with database access rights can access all data within the database. This poses a significant risk, allowing individuals with administrative rights to access all sensitive data. Additionally, this solution is limited as it does not allow for different permissions for users accessing the database.
The second solution, in contrast to file-level encryption, addresses encryption at the application level. This approach encrypts data before it is transmitted to the database. Key management and access rights issues are supported by the application. Data queries to the database will return results in an encrypted format, which will then be decrypted by the application. This solution effectively separates security permissions and supports role-based access control (RBAC) policies. However, implementing encryption at the application layer requires a comprehensive change to the application’s architecture, potentially necessitating a complete rewrite of the application. This presents a significant challenge for companies with multiple applications running on various database platforms.
From the analysis of the two solutions mentioned above, it is clear that an optimal database security solution needs to support the following key factors:
1. Support encryption at the table, column, and row data levels.
2. Support security policies for access rights at the column data level, supporting RBAC.
3. The encryption mechanism should not impact existing applications.
Below are two models that meet these requirements, especially the third requirement.
1. Build a Middleware Database Layer
In this model, a middleware database (proxy) is created between the application and the primary database (Diagram 1). This middleware database encrypts data before updating it to the primary database and decrypts data before providing it to the application. The middleware database also offers additional functionalities for key management, user authentication, and access permissions.
This solution allows for the addition of various security features for the database. However, the middleware database model requires the development of a database application that replicates all the functions of the primary database.
Currently, in the database encryption product market, Secure.Data by Protegrity (www.Protegrity.com) utilizes the aforementioned proxy model.
2. Utilize Existing Mechanisms in the Database
This model addresses column encryption based on the following mechanisms:
a. Stored Procedures in the database for encryption and decryption functions.
b. Using Views in the database to create virtual tables, replacing the actual tables that have been encrypted.
c. “Instead of” triggers are used to automate the encryption process from View to the original table.
In this model, data in the original tables will be encrypted, and the names of the original tables will be changed. A virtual table (View) will be created with the name of the original table, and applications will access this virtual table.
Data retrieval in this model can be summarized as follows (Diagram 2):
Data queries to the original table will be replaced with queries to the virtual table.
The virtual table is created to simulate data in the original table. When executing the “select” command, data will be decrypted for the virtual table from the original table (which has been encrypted). When executing the “Insert” or “Update” commands, the “instead of” trigger will be executed to encrypt data back to the original table.
Access permissions to the columns will be managed in the virtual tables. In addition to the basic permissions provided by the database, two new access rights are defined:
1. Users are only allowed to read data in an encrypted format (ciphertext). This right is suitable for those who need to manage the database without needing to read the content of the data.
2. Users are allowed to read data in a decrypted format (plaintext).
The aforementioned solution has the advantages of simplicity and ease of development. However, due to limitations regarding view mechanisms, triggers, and data management, this solution has the following drawbacks:
Index columns cannot be encrypted, thus limiting applications that require indexing support.
Encrypted data is larger in size compared to the original data. This difference is negligible for text data, but significant for numerical and binary data. For example, 1 byte of numerical data may increase to 2 bytes after encryption.
Database access speed decreases due to the execution of the encryption layer.
Currently, in the database encryption product market, DBEncrypt (www.appsecinc.com) and nCypher (www.ncypher.com) are developing along the lines of this model.
Phùng Hải – CISSP,
Project Manager, Global Cybersoft Vietnam
