With data breaches continuing to occur at an alarming rate, protecting sensitive data is critical for all businesses. As organizations store more data than ever before (on-premises and in the cloud), adequate database security becomes increasingly important. For many organizations, this security may not go further than access control.
Those who want stronger protection for sensitive data turn to an extra layer of protection against internal and external threats: database encryption.
What is database encryption?
Database encryption is the process of using an algorithm to turn data in a database into “ciphertext” (unreadable text). You must decrypt the text using an algorithmically generated encryption key.
Encrypting data renders information unreadable when accessed without proper authorization. The only people that can decrypt it are you or anyone else authorized who has the decryption keys.
Types of Data Encryption
Data encryption is typically of two types:
- Symmetric encryption: Uses a single symmetric key to both encrypt and decrypt data. The key is shared with all authorized users to allow data access.
- Asymmetric encryption: Uses two separate keys to encrypt and decrypt data. One key is made public (shared with everyone), and the other is kept private (known only to the key’s generator). The public key is used to encrypt data, and the private key is used to decrypt it.
Database encryption methods
When it comes to applying encryption to databases, you can consider different encryption methods based on the encryption targets:
-
File-Level encryption
- Cell-Level encryption
- Column-Level encryption
- Row-Level encryption
-
Table space-level encryption
In File-level encryption, individual database files are encrypted as a whole to restrict unauthorized access. However, partial encryption of the database can be performed with more specific targets as follows:
Cell-level encryption: Individual cells are encrypted separately, with their own unique keys
Column-level encryption: Individual columns of data are encrypted separately, with each column having the same key for accessing, reading, and writing data within the column
Row-level encryption: Individual rows of data are encrypted separately, with their own unique keys for their cells
Table space-level encryption: Individual tablespaces are encrypted as a whole. Each tablespace has a unique key for all of its contents.
Can Encrypted Data be Hacked?
Yeap! There are multiple ways attackers can compromise data encryption systems:
- Malware on endpoint devices – many endpoint devices have encryption mechanisms such as full disk encryption. Attackers can compromise an endpoint device using malware, and leverage keys on the device to decrypt the data.
- Brute force attacks – attackers commonly try to break encryption by randomly trying different keys. The chances of success are directly related to the size of the key. This is why most encryption standards specify the use of 256-bit encryption keys. However, some encryption systems use weak ciphers which are vulnerable to brute-force attacks.
- Cryptanalysis – this is a technique in which attackers find a weakness in the cipher itself and use it to gain access to data.
- Side-channel attacks – this involves measuring information a system leaks while it encrypts or decrypts, such as timing, power consumption or electromagnetic emissions, to recover keys or data without breaking the cipher itself.
- Social engineering attacks – possibly the easiest way to hack encrypted data is to use phishing or other social engineering methods to trick a privileged user into providing the key.
- Insider threats – a severe threat to encrypted data is the possibility that a privileged individual will turn against the organization and abuse their privileges to steal data. Insider threats also include negligent users who fail to follow security policies.
This doesn’t mean that you should not encrypt your data-at-rest.
This means that database encryption should be one of your many layers of defense against attackers. You have to make it more difficult for the attacker and less worth his time, to try and bust through many layers to get to encrypted data, which he must dedicate more time to access.
Why is database encryption important?
Security Against Unauthorized Access
There are many security controls to apply in order to protect your information in a defense-in-depthapproach. But at the end of the day, having your valuable data encrypted, will be what prevents an unauthorized person from reading them.
Proper encryption on the public cloud is equally important as data can be exposed to a much broader range of threats, such as accidental exposure to the Internet, access by some cloud tenants, and malicious insiders at the cloud provider.
Consumer Trust from a Privacy Safeguard
Database encryption is beneficial to consumers and not only the organization that implements it. Users trust your organization more when they know that their information cannot be read even when the organization suffers a data breach.
Database encryption opens an opportunity for companies to bolster consumer trust by explicitly stating how they encrypt customer data. Although end-users need to take responsibility as well, enterprises can solidify their reputations by emphasizing a commitment to incorporating the latest encryption technologies into their operations.
Encryption Helps you be Compliant with Regulatory Requirements
The GDPR does not mandate encryption in every case, but Article 32 names “the pseudonymisation and encryption of personal data” as one of the measures controllers and processors must implement where appropriate to the risk. The GDPR applies to organizations established in the EU, and to organizations outside the EU that offer goods or services to, or monitor the behavior of, people in the EU, whatever those people’s nationality.
The HIPAA (Health Insurance Portability and Accountability Act of 1996) Security Rule treats encryption of electronic protected health information as an “addressable” specification: covered entities and business associates must implement it where it is reasonable and appropriate, or document why it is not and implement an equivalent alternative measure if that is reasonable and appropriate.
If your company deals with security standards such as PCI DSS, protecting stored cardholder data is a core requirement. PCI DSS Requirement 3.5.1 requires the primary account number (PAN) to be rendered unreadable wherever it is stored, by encryption with strong cryptography, keyed cryptographic hashes, truncation or index tokens.
Conclusion
Encryption of data-at-rest has become increasingly important and with the help of regulations such as GDPR, HIPAA, and PCI, it tends to be the “norm” for many organizations. Cloud providers and companies developing database management software are making the encryption of databases ever so easy to implement and operate for database administrators and security teams.
Build a solid encryption strategy for both data-in-transit and for data-at-rest because encryption is more than a few clicks of a button. You need to think about encryption key management, and performance among others, and these would become clear when you have a written policy and procedure for the encryption of your sensitive data.
Correction, 26 October 2026: this article said the GDPR has no explicit encryption requirement and protects only EU citizens, that HIPAA requires confidential data to be encrypted, and that PCI DSS requires all cardholder data to be encrypted with algorithms such as AES-256 and RSA 2048; GDPR Article 32 names encryption as a measure to implement where appropriate and the GDPR does not depend on nationality, the HIPAA Security Rule makes encryption an addressable specification, and PCI DSS Requirement 3.5.1 requires a stored PAN to be rendered unreadable by encryption, keyed hashing, truncation or tokenization.