These days organizations are storing, accessing, and analyzing more data than ever, both on-premises and on the cloud. As this trend accelerates, the need for effective database security grows right along with it.
Basic security controls like login/password credentials aren’t adequate to safeguard sensitive data from today’s increasingly sophisticated external and internal attacks. To reduce cyber risk, comply with regulations and give customers and other stakeholders peace of mind, many organizations need a holistic security approach that includes database encryption.
The view that database encryption comes with burdensome costs, added IT complexity and degraded performance is outdated. With today’s solutions, database encryption can be among the easiest, most affordable, and most effective security steps you can take. Multiple database encryption approaches are available, so choosing the right one for your needs is essential.
How does database encryption work?
When you encrypt all or part of a database, an encryption algorithm (there are many) converts the data from human-readable characters to ciphertext, which completely obscures the content and renders it useless to attackers. To decrypt the data and use it, you need the correct key, which the encryption solution generates.
Unlike many other security controls, like firewalls or anti-malware tools, most database encryption operates directly on the data where it is stored, often termed “data at rest.” At-rest encryption keeps your data secure if your network or database server is compromised, or if a malicious insider or cybercriminal with privileged access attempts to exfiltrate your data. Only users who have the right key can make use of the encrypted data.
What types of encryption are available?
To balance your users’ needs for access and performance with the value of your data and the risks it faces, you can choose from a range of database encryption options. These include:
- Full database encryption, where all the data in the database is encrypted.
- Column-/field-/table-level database encryption, where the most sensitive data elements are encrypted but others are not. This option can improve application performance and reduce system overhead by impacting only queries against encrypted data.
- Client-side encryption encrypts the data on a user’s system before it is stored in the database. This approach puts the computational overhead of encryption on the client system, which often has cycles to spare. A further advantage is that data encrypted in this way is safe even from malicious code running on the server or within the RDBMS environment.
- Homomorphic encryption uses complex mathematical computations to analyze encrypted data in various ways without decrypting it. This approach preserves privacy for sensitive data like health or educational records. It allows cloud service providers (CSPs), remote database administrators (DBAs), and other third parties to process data while maintaining regulatory compliance and full security.
- Hardware encryption, where the encryption mechanism is built into the hardware (e.g., a disk drive) where the database resides. The primary benefit of hardware encryption is that if the database environment or server is compromised, the data will remain inaccessible to attackers.
How does Oracle handle encryption?
Oracle has long supported a feature called Transparent Database Encryption (TDE), which is both effective and straightforward to implement. TDE lets you encrypt the whole database, or only specific tables or columns.
Oracle stores the database encryption keys in a separate Oracle Key Vault, which helps you govern your keys so that they’re secure from unauthorized access and available automatically (“transparently”) for authorized users and systems. This makes TDE a great option where you need to protect data from attacks that compromise your database servers and/or Oracle RDBMS, or where hackers gain access to the physical storage media.
How does Microsoft SQL Server handle encryption?
Like Oracle, Microsoft SQL Server also has the capability to encrypt data at rest, which it calls Transparent Data Encryption (TDE). SQL Server’s TDE offers many of the same data encryption capabilities as Oracle’s TDE. But its default key storage is different. Instead of a separate vault, SQL Server stores the database encryption key (DEK) in the database boot record for availability during recovery.
SQL Server also offers the Always Encrypted feature, which lets you encrypt highly sensitive data inside client applications and never reveal the encryption keys to the database engine. Because it segregates those who own the data from those who can view it or need to manage it Always Encrypted is ideal for maintaining security and compliance for high-value data in cloud environments, for instance.
How do open-source databases handle database encryption?
MySQL, PostgreSQL and most other popular open-source databases support third-party encryption libraries, such as pgcrypto or MyDiamo. There are also open-source toolkits for specialized types of database encryption like homomorphic encryption.
Database operations can also call on encryption functions available at the file system level in Windows, Linux, MacOS, etc. With this type of encryption, the server encrypts entire files as they are stored, potentially adding to system overhead but saving the cost of a separate solution.
Important considerations with managing encryption keys
Your encrypted data is only as secure as your encryption keys. Since they control access to encrypted data, you should store your keys separately from the database when possible. For example, both Microsoft Azure and IBM Cloud offer a “key vault” service that stores encryption keys in a hardware module for an extra level of encryption.
Your key management also needs to factor in backups, because backing up encrypted data without protecting the associated keys could be futile. One option is to consolidate your database encryption keys into a centralized key manager solution, and back them up from there.
Another consideration with encryption keys is their length. Different encryption methods rely on different key types. Longer keys, like longer passwords, are generally more secure. For example, 128-bit encryption schemes use a 128-bit key, which are deemed virtually impossible to break using today’s (non Quantum) computer systems.
The downside of longer keys—and potentially encryption overall—is higher overhead and reduced data throughput, as well as increased storage needs for the database. However, applying best practices in your implementation can reduce or eliminate many undesirable impacts.
Next steps
In response to customer demands and/or emerging security and privacy compliance requirements, more businesses are encrypting more databases in more ways than ever before. But the more data you encrypt, the more encryption keys you need to manage and the more you need to be concerned with performance impacts.
For optimal benefit to your organization, your database encryption strategy should reflect a holistic view of present and projected business needs, including cybersecurity and compliance risks, plus expert knowledge of best practices and technology options. A security risk assessment to identify weak spots is a great place to start.
If you are considering database encryption or want to optimize your current encryption approach, Buda Consulting can help you secure your business-critical data, comply with regulations and address database performance and cost issues.
Contact us to connect with an expert about a security risk assessment and related services.