Applications frequently use and store sensitive data such as confidential personal details, payment information, or proprietary data. In some jurisdictions, this type of data is subject to governance, privacy, and security compliance mandates. Unauthorized access of sensitive data or a failure to comply with a mandate often results in significant reputation damage and financial penalties. Therefore, it is important to keep sensitive data secure. To protect your corporate data from unauthorized access, there are various methods such as Role-Based Access Control (RBAC), TLS transport encryption and encryption at rest.
Another novel method that prevents unauthorized access of data is Field Level Encryption (FLE). MongoDB and Amazon CloudFront are among the first developers of this pioneering encryption method. This method allows a developer to selectively encrypt individual fields of a document on the client-side before it is sent to the server. This keeps the encrypted data private from the providers hosting the database as well as any user that has direct access to the database.
TLS Machine Identity Management for Dummies
Understanding the Need for Field-Level Encryption
To better understand the security need behind FLE, let us consider a healthcare provider. The customers’ management system stores patients’ personal information, insurance information, and medical records. None of the patient data is public, and certain data such as their social security number, insurance policy number, and vital sign measurements are particularly sensitive and subject to privacy compliance such as HIPAA or GDPR.
It is important for the company and the patient that the data is kept private and secure. The doctors working in this provider should be able to have full access to all patients’ medical records, while other supporting personnel, such as the receptionists, are to have access to a limited set of data, such as contact information and the last four digits of the social security number.
In addition, the healthcare provider has to safeguard this sensitive data from:
- Accidental disclosure
- Direct access to the database by a superuser such as a database administrator
- Capture of data over an insecure network
- Access to the data by reading a server’s memory
- Access to the on-disk data by reading database or backup files
Therefore, how can the healthcare provider balance functionality with security?
One solution would be to use Role-Based Access Control (RBAC) which allows administrators to grant and restrict collection-level permissions for users. With the appropriate role definition and assignment, this solution prevents accidental disclosure of data and access. However, it does not prevent capture of the data over an insecure network, direct access of data by a superuser, access to data by reading the server’s memory, or access to on-disk data by reading the database or backup files.
Further, the provider’s IT security staff could use encryption at rest combined with transport encryption using TLS. When applied together, these two features prevent access to on-disk database files as well as capture of the data on the network, respectively. When combined with RBAC, these three security features offer near-comprehensive security coverage of the sensitive data but lack a mechanism to prevent the data from being read from the server’s memory.
On the other hand, applying Field Level Encryption on the client-side allows the security engineers to specify the fields of a document that should be kept encrypted. Sensitive data is transparently encrypted/decrypted by the client and only communicated to and from the server in encrypted form. This mechanism keeps the specified data fields secure in encrypted form on both the server and the network. While all clients have access to the non-sensitive data fields, only appropriately configured FLE clients are able to read and write the sensitive data fields.
The following image, courtesy of MongoDB, provides a comparison of the various data protection methods.
Figure 1: Comparison of various data protection methods. Source: MongoDB Field-Level Encryption Guide
Field Level Encryption is totally separated from the database, making it transparent to the server, and instead handled exclusively within the client. All encrypted fields on the server—stored in memory, in system logs, at-rest, and in backups—are rendered as ciphertext, making them unreadable to any party who does not have client access along with the keys necessary to decrypt the data.
This is a different and more comprehensive approach than the column encryption used in many relational databases. As most handle encryption server-side, data is still accessible to administrators who have access to the database instance itself, even if they have no client access privileges.
Benefits of Field-Level Encryption
While many security controls exist to encrypt confidential data-in-transit over a network (e.g., TLS and HTTPS) as well as data-at-rest—such as volume or file-level encryption (FLE)—fewer options exist for developers to address data-in-use, that is, data operating inside a running, active database.
By using data-at-rest encryption, attackers obtaining database files from the filesystem would typically be unable to read them. However, privileged users or attackers impersonating privileged users still have access to the data on a live, running instance. Using FLE you can protect individual fields and documents with all key management, encryption, and decryption operations occurring exclusively outside the database server. With FLE enabled, a compromised administrator or user obtaining access to the database, the underlying filesystem, or the contents of server memory (for example, via scraping or process inspection) will only see unreadable encrypted data.
This approach enables greater separation of duties. System administrators, who traditionally have access to operating systems, database server DBA access, logs, and backups, cannot read encrypted data unless explicitly given client access along with the keys necessary to decrypt the data.
In addition, several regulatory obligations may be addressed by leveraging client-side encryption architectures. Complying with the “right to be forgotten” provisions in new privacy regulations such as the GDPR are now much easier. By destroying keys tied to individual application users, the underlying data are irrecoverably destroyed
The above benefits come at no significant overhead. Although there is some additional latency incurred to encrypt and decrypt fields, generally FLE incurs less than 5-10% net impact on high volume read-intensive applications. Most importantly, applications which don't read or write encrypted fields see no change in performance. Applications which encrypt a small number of fields incur smaller latency than ones that encrypt the majority of fields in all documents, particularly when initially generating new data keys en masse.
Conclusion
The security capabilities of Field-Level Encryption are particularly handy when businesses embrace cloud services. The level of control and management of encryption keys provided by FLE eliminates common security concerns when moving database workloads to managed services in the cloud. This is because businesses can both control and manage the encryption keys, rather than having the database operator manage the keys for you.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts