Protecting Sensitive Data with Field Level Encryption (FLE)

Introduction

In today’s digital world, protecting sensitive data is more critical than ever. Companies face the daunting task of keeping private information like Personally Identifiable Information (PII), Protected Health Information (PHI), financial records, and intellectual property secure. Failure to properly safeguard this data can lead to disastrous consequences, from reputational damage to hefty regulatory fines. Fortunately, Field Level Encryption (FLE) has emerged as a powerful tool to help companies meet their data security obligations. This article discusses Field Level Encryption.

It explains how it works and its advantages. It also covers how to implement it properly. Additionally, it explains how FLE helps with following regulations.

What is Field Level Encryption?

FLE is a complex way to protect data. It encrypts sensitive data fields to stop unauthorized access. Applications and systems process the data while this occurs. Field Level Encryption allows you to encrypt specific data elements instead of encrypting the entire database or disk.

Common types of data secured with Field Level Encryption include:

• PII like names, email addresses, phone numbers
• PHI like medical record numbers, diagnoses, medications
• Financial information like credit card and bank account numbers
• Confidential business data like sales figures, product roadmaps, contracts

By precisely targeting the most sensitive data for encryption, Field Level Encryption provides robust security while minimizing performance impacts and preserving application functionality. Leading companies like MongoDB and Amazon have implemented Field Level Encryption capabilities into their offerings.

How Field Level Encryption Works

Client-Side Field Level Encryption (CSFLE) encrypts data on the client device. It does this before sending the data over the network and storing it in a database. The server sends the data back to the client in encrypted form for local decryption when needed.

The client uses an encryption key to perform the encryption and decryption. In production environments, store this key separately in a secure key management service. Any clients that can access the underlying database will only see ciphertext in encrypted fields. Decryption requires possession of the encryption key.

Deterministic methods encrypt fields while still allowing them to index and search them. Developers can create indexes on the encrypted fields just like they would for plaintext data. The system will automatically add newly inserted documents to the indexes.

To query the database, the client encrypts the search terms before sending the request. The database processes the query and returns the encrypted results, which the client then decrypts. This process is transparent to the end user.

Benefits of Field Level Encryption

Compared to alternative approaches like whole database or disk encryption, Field Level Encryption provides several key advantages:

1. Targeted Protection: Field Level Encryption gives control over who can access sensitive data by encrypting at the field and document level. Even if an attacker compromises the database server, operating system, or server memory, they still cannot read encrypted data.
2. Separation of Duties: Field Level Encryption architectures cleanly separate responsibilities and access. Server/database administrators can perform their duties without being able to view sensitive data. Clients retain control over who can access protected information.
3. Regulatory Compliance: Granular encryption helps satisfy requirements in privacy regulations like GDPR and HIPAA.

These security benefits come with minimal performance overhead, typically less than 5-10% in read-heavy workloads. And for clients/applications not authorized to access encrypted data, there is no perceptible performance impact at all.

Best Practices

While FLE is a powerful tool, it does introduce some constraints that require careful consideration:

• Users cannot use encrypted fields in reports, business intelligence tools, or regular application functions without decrypting them. This means users cannot search, display, or validate them. To use encrypted fields, you must first decrypt them.
• Encrypted fields have limited configurability (no default values, picklists, etc.)
• Text fields have a max size of 255 characters
• Encryption is one-way – there is no way to permanently revert an encrypted field to plaintext

To succeed with FLE, follow these best practices:

1. Backup your database before encrypting any fields in case issues arise
2. Use a unique encryption key for each object and environment (dev, staging, prod)
3. Securely backup encryption keys
4. Use new custom fields for encrypted data to avoid conflicts with existing application logic
5. Thoroughly test functionality with encrypted fields

Examples Here’s a simple example of querying an encrypted “ssn” field in MongoDB with the official Node.js client:

javascript

// Import the MongoClient
const { MongoClient } = require('mongodb');
// Define the master key for encryption
const masterKey = 'my-secret-key';
// Connect to MongoDB with the encryption-enabled client
const secureClient = new MongoClient('mongodb://localhost:27017', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
  autoEncryption: {
    keyVaultNamespace: 'encryption.__keyVault',
    kmsProviders: {
      local: { key: masterKey },
    },
  },
});
// Establish the database connection
await secureClient.connect();
// Define the query object with the encrypted field
const query = { ssn: '123-45-6789' };
// Execute the query on the 'people' collection in the 'myDb' database
const result = await secureClient.db('myDb').collection('people').find(query);
// Print the query result
console.log(result);

In this example:

1. Import the MongoClient from the MongoDB driver.
2. Define the masterKey used for encryption.
3. Create a new MongoClient instance with encryption enabled by setting the autoEncryption options. The keyVaultNamespace indicates the location of the encryption keys. The kmsProviders indicate the key management service in use, which in this instance is a local key.
4. Connect to the MongoDB database using the encryption-enabled client.
5. Define the query object with the encrypted field ssn.
6. Execute the query on the people collection in the myDb database using the find method.
7. Finally, print the query result.

Client automatically encrypts the query object before sending it to MongoDB. Turning on encryption only requires configuring the client with a key management provider and enabling the autoEncryption option.

Conclusion

Data security is a critical priority for modern businesses. Field Level Encryption gives companies the ability to control encryption of sensitive data at the field level. This helps to enhance security for private information without causing disruptions to application functionality or user experience. FLE is important for protecting data when done correctly and aligned with security goals.

DataSunrise provides a complete set of tools for companies looking to protect their data and comply with regulations. The suite includes security, auditing, masking, and management features. Our powerful solutions integrate seamlessly to protect your most precious information assets. To learn more, we invite you to contact DataSunrise team of experts for an online demo tailored to your needs.