Database encryption is a cryptography method that adds an additional layer of data security which can be used to protect against data breaches from anyone other than authorized users. Sensitive information within your databases, such as credit card numbers or personally identifiable information [PII], can get into the wrong hands even with the most sophisticated and complex protection measures in place. Database encryption ensures that even if someone gains unauthorized access to sensitive data, it will be stored as a sort of "cipher text" that is incomprehensible and therefore, cannot be used because of how difficult it is to decrypt.
Relational databases such as MySQL/MariaDB, Postgres, Microsoft SQL Server, AWS Redshift and Snowflake provide various encrypting and authentication options for both data at rest and data in motion, and most database engineers are using one or more of the many encryption types available today.
The typical form of encryption put in place for most Database Management Systems [DBMS] at-rest known as Transparent Data Encryption [TDE] were designed to protect against physical data theft or database server break-ins.
But to assume that this type of encryption will keep your entire database safe from a data breach or any level of decryption is short-sighted, because today’s data centers and databases in the cloud are not being hacked this way. [See “Why You Can’t Stop Data Breaches”].
What’s needed is a data-centric - rather than a container-based - protection method.
However, that raises another valid concern: don’t these column or field level encryption methods result in reduced performance? Plus, won’t they require changes to the algorithm, application code or complex deployment and management?
Most of the time, the answer is "Yes." Quite often, the impact on development and performance trade-offs rule out this more robust database encryption model. Instead, companies make the decision to expose their data and risk a breach, rather than pay the cost of more performance overhead and additional development resources.
Baffle addresses these trade-offs to provide database encryption options for Postgres, MySQL, MariaDB, Microsoft SQL Server, AWS Redshift, and Snowflake with a simplified no-code data protection model.
Baffle’s invisible data protection layer secures the actual data values and PII in databases, storing encrypted data with no encryption key or key management system present, topped off by virtually no performance overhead or loss in functionality.
Without any application code changes, our solution tokenizes and encrypts data in Postgres, MySQL, MariaDB, and Microsoft SQL Server at the field or row level.
With Baffle Database Encryption, you get:
- Support for Postgres, MySQL, MariaDB, Microsoft SQL Server, AWS Redshift, and Snowflake
- Support for AWS RDS, Microsoft Azure, Google Compute Platform [GCP], IBM Cloud
- Support for database migration services such as AWS DMS and Microsoft Azure
- Out-of-the-box integration with encryption key management solutions - AWS KMS, Azure Key Vault, HashiCorp Vault
- Simplified "no code" deployment model
- Supports cloud native services and container-based environments
- Fast performance with minimal overhead
Baffle’s security contract ensures that the decryption key and encrypted data are never co-mingled, to reduce the risk of insider threat, privileged access and side channel attacks.
Baffle’s solution provides no code approaches for the following for Postgres, MySQL/MariaDB, SQL Server, AWS Redshift, and Snowflake:
- Field Level Encryption
- Record Level Encryption
- Tokenization and Format Preserving Encryption [FPE]
- Dynamic Data Masking
- Data-Centric File Protection
Learn more about Baffle’s Data Protection Services here.
How does data encryption work?
Organizations are generating massive amounts of data, with the World Economic Forum estimating 463 exabytes of data every day by 2025. As a result, securing sensitive data has become more critical than ever before. In addition, because businesses keep data in various databases and locations, having a comprehensive data protection policy is crucial to mitigating risk.
Database encryption offers an extra layer of security that protects sensitive data from unwanted intruders. It means that if someone unauthorized gets their hands on your data, they won’t be able to understand the underlying data. In many cases, encryption is typically a must-have requirement to satisfy compliance regulations such as HIPAA and PCI-DSS and keep security auditors happy.
So, now that we know that data encryption is important, let’s dive a bit deeper to explore how exactly data encryption works, what types of data encryption methods exist, and what is the best approach for organizations to encrypt their sensitive data.
How does database encryption work?
Before we explain how database encryption works, let us define encryption and how it can apply to different types of databases.
Encryption converts sensitive information or data in plaintext, which is easily readable, to ciphertext, which is hard to read. Encryption is a two-way process — plaintext can be encrypted to get ciphertext, and ciphertext can be decrypted to arrive back at the original plaintext. All databases, whether relational, NoSQL, or cloud-based, can use encryption to guard sensitive data stored within them.
Encryption is driven by a key, which is a piece of information, usually a string of numbers and letters that is used by a cryptographic algorithm [such as AES] to process data. The key length and choice of the encryption algorithm are what determines the strength of the encryption. Longer keys are more secure because they are harder to crack using extensive computation. For instance, a 256-bit encryption algorithm is stronger than a 128-bit encryption algorithm because additional compute resources are needed to crack the key. In this case, the attacker needs to figure out which 78-character string of 1’s and 0’s can break the encryption, and this can take a significant amount of time and processing power to get right.
There are two types of encryption – symmetric and asymmetric. In symmetric encryption, the same key is used to encrypt and decrypt the data. It is typically used when there is a lot of data involved [such as in a database] because it is faster. In asymmetric key encryption, a key pair consists of a public key and the private key. The private key is used to perform the encryption, and the public key is used to decrypt the data.
When it comes to applying encryption to databases, there are typically several key methods - using an Application Programming Interface [or API], through database plugins, or by leveraging Transparent Data Encryption [or TDE].
API encryption is a popular method of leveraging application-level encryption across many popular database solutions or integrating it with general security platforms.
Plugin-based encryption leverages an encryption module or agent typically installed on a database management system to perform the encryption. Although this method brings a bit more flexibility, extra management is needed to ensure that the plugin is available and running at all times.
Transparent Data Encryption [TDE] method leverages the database engine itself to encrypt and decrypt data. By virtue of its name, this method is transparent to the database operator and does not require any application-level changes to be implemented.
What is data encryption at rest?
Database encryption at rest refers specifically to the fact that data is encrypted when it's stored [at rest] on disk. An attacker can hack a cloud database or physically steal hardware that the data is stored on -- in either case, having your data encrypted at rest ensures that the attacker cannot understand [decrypt] the stolen data easily.
Databases use TDE to encrypt data, index and log files at rest. When a running database reads these files, data is decrypted on the fly before the database engine uses it. Likewise, data written by the application is encrypted by TDE before it is stored on a disk. All of this happens transparently, without the user noticing.
What is data encryption in transit?
Database encryption in transit refers specifically to the fact that data is encrypted while it is in motion between the database and the applications accessing the data. It can be applied while data travels through a private network or a public network communication channel. For example, suppose an application is accessing data stored in a database over the internet. In that case, the communication channel between the application and the database must be encrypted to ensure data confidentiality. Without adequate encryption in transit, an attacker can intercept the web request and eavesdrop on the data. Using transport-level security [TLS] or Secure Socket Layer [SSL], the communication channel can be encrypted to keep the data safe.
Fauna is a flexible, developer-friendly 100% ACID transactional database delivered as a secure, cloud API. Fauna has a rich security model that combines attribute-based access control with SSL and 3rd party authentication to offer strong security, which can be invoked directly from the browser.