Types of Database Encryption Methods

With businesses storing more data than ever (both on-premises and in the
cloud), effective database security has become increasingly important. For many
businesses, this security might not go much further than access controls, but as a
managed services provider (MSP), you likely know it’s not enough to protect data
with basic security measures alone. Without a comprehensive plan, a great deal of
sensitive business data could be at risk. Those that want more robust protection
for sensitive data are smart to turn to an additional safeguard that can protect
against both internal and external threats: database encryption.
Unfortunately, not all businesses make the effort to encrypt their
databases, as doing so is perceived as an “extra” security step that comes with
added design complexity and potential performance degradation. However, this
excuse amounts to a gross oversimplification of the problem, not least because
database encryption methods have improved markedly over time. There are a
number of types of database encryption, meaning businesses can easily find the
right balance between added complexity and stronger security. For many,
choosing the right kind of encryption can be an important step for both peace of
mind and regulatory compliance.

How does database encryption work?

With database encryption, an encryption algorithm transforms data within
a database from a readable state into a ciphertext of unreadable characters. With
a key generated by the algorithm, a user can decrypt the data and retrieve the
usable information as needed. Unlike security methods like antivirus software
or password protection, this form of defense is positioned at the level of the data
itself. This is crucial because if a system is breached, the data is still only readable
for users who have the right encryption keys.
There are a few different options for implementing a database encryption
algorithm, including varying lengths of keys. You will find that different databases
—Oracle, SQL, Access, etc.—offer different data encryption methods, options that
may inform which method you recommend to customers. Longer keys tend to be
more secure since they are harder to discover through computation. For instance,
128-bit encryption relies on a key that is 128 bits in size, and by virtue of this
length, is virtually impossible to “crack” with a computation system. In short, the
system would have to test 2128 combinations to crack the code, which would
take thousands of years. As a rule of thumb, a shorter key length means poorer
security, and standard key lengths may have to continue to grow as general
computational power increases.
That said, a longer key length can reduce the number of sessions per
second, which can have a negative impact on throughput. Many developers hold
off on database encryption precisely because they fear such performance
degradations and potential system slowdowns. Additionally, encrypting a
database will require more storage space than the original volume of data. While
it’s true that database encryption adds some complexity (making tasks like backup
and recovery trickier), it’s possible to ensure good performance by implementing
a range of best practices. For instance, strategically implementing file-level
encryption will have a much lower impact on performance than application-level
or other more granular encryption methods.

Database encryption for business security

Whether large or small, customers of every size may very well be dealing
with sensitive data—data that, in many cases, may be subject to regulations. This
data might include credit cards, Social Security numbers, classified information, or
medical records. Businesses deal with all manner of big data, and any kind of
protected data, financial records, or personally identifiable information (PII) needs
to be secured—not just as it’s used and analyzed, but while it’s in storage.
As an MSP, it’s your responsibility to assess whether a certain kind of data
encryption is a useful or necessary security strategy for a client’s unique situation.
For instance, encryption is typically a necessary step for businesses dealing with
compliance regulations like SOX, HIPAA, PCI DSS, and GLBA. Many states penalize
data breaches, and even if encryption isn’t legally mandated, businesses are often
eager to prevent expensive and inconvenient losses of data.
In a sense, database encryption should be redundant, only becoming
necessary if access controls and other security measures fail. However, hewing too
closely to this mindset is a clear vulnerability, as these other security measures
aren’t failsafe. MSPs can help businesses understand that databases need
additional safeguard protections. For instance, don’t expect SSL to encrypt a
database—that’s only for data in motion. Likewise, firewalls and VPNs are great
protection, but can be breached, leaving data up for grabs. Further, internal bad
actors may have to do little more than figure out a username and password to
steal sensitive data.
When it comes to implementing encryption, it’s important not just to
choose the right algorithm, but to manage encryption keys in a secure, organized
fashion. For instance, keys shouldn’t be kept on the same server as the encrypted
data. What’s more, don’t hesitate to implement database encryption for cloud
storage, too—just be sure that the business itself, rather than the cloud provider,
keeps track of the decryption keys.

Common database encryption methods

It’s possible to encrypt data at a number of levels, from the application to the
database engine. For an MSP considering how to help a customer choose an
encryption method, it’s important to be clear on the purposes and requirements
of these different encryption methods:
 API Method: This is application-level encryption that is appropriate across
any database product (Oracle, MSSQL, etc). Queries within the encrypted
columns are modified within the application, requiring hands-on work. If a
business has an abundance of data, this can be a time-consuming approach.
Additionally, encryption that functions at the application level can lead to
increased performance issues.
 Plug-In Method: In this case, you’ll attach an encryption module, or
“package,” onto the database management system. This method works
independently of the application, requires less code management and
modification, and is more flexible—you can apply this to both commercial
and open-source databases. With this option, you will typically use column-
level encryption.
 TDE Method: Transparent data encryption (TDE) executes encryption and
decryption within the database engine itself. This method doesn’t require
code modification of the database or application and is easier for admins to
 manage. Since it’s a particularly popular method of database encryption,
TDE is explored in further detail below.

What is transparent database encryption?

The term transparent data encryption, or “external encryption,” refers to
encryption of an entire database, including backups. This is a method specifically
for “data at rest” in tables and tablespaces—that is, inactive data that isn’t
currently in use or in transit. Increasingly, transparent data encryption is a native
function within database engines. It can also be handled through drive or OS
encryption, meaning everything written to the disk is encrypted.
This type of encryption is “transparent” because it is invisible to users and
applications that are drawing on the data and is easily used without making any
application-level changes. It is decrypted for authorized users or applications
when in use but remains protected at rest. Even if the physical media is
compromised or the files stolen, the data as a whole remains unreadable—only
authorized users can successfully read the data. This provides a disincentive for
hackers to steal the data at all. When all is said and done, using TDE can help a
business remain in compliance with a range of specific security regulations.

Encryption levels
When it comes to database encryption, it’s possible to protect data at a
number of particular levels, from columns to blocks of files. All cells within these
units would use the same password for access, so you can choose more
specialized or generalized protection depending on your requirements. Be
warned, however, that more granular encryption can dramatically reduce
performance:
 Cell-Level: In this case, each individual cell of data has its own unique
password—a configuration that comes with a high level of performance
impact. Even so, this configuration may be appropriate in situations in
which you need a highly granular level of protection. Managing the many
associated keys requires careful organization.
 Column-Level: This is the most commonly known encryption level and is
typically included by database vendors. Simply put, it works by encrypting
 columns within a database. This requires less processing than at cell-level,
but could still impact performance, depending on the number of columns
that are encrypted and actions like insertions, queries, and table scans.
Similarly, it’s possible to implement row-level encryption in which each row
of data is encrypted with its own key.
 Tablespace-Level: This method provides a different level of control over
encryption, allowing encryption across tables, even if accessed by multiple
columns. This method doesn’t have as much of an impact on performance
but can cause issues if improperly implemented.
 File-Level: This approach works not by encrypting rows or columns, but by
scrambling entire files. The files can be moved to reports, spreadsheets, or
emails and still retain their protection, meaning fewer transformations or
encryption mechanisms are required. This type of encryption holds the
least potential for performance degradation.

What are symmetric and asymmetric encryption?

Symmetric and asymmetric encryption are cryptography terms that describe
the relationship between ciphertext and decryption keys. These ideas take into
account the fact that users and receivers can be tasked with sharing keys, which
may or may not be a secure process. Encryption algorithms may be designed as
one or the other of these types, or in some cases, both:
 Symmetric: In this case, data is encrypted when it is saved to the database
and decrypted when it is called back. Sharing data requires the receiver to
have a copy of the decryption key. This is the simplest, oldest kind of
encryption, and the most well-known. The disadvantage of symmetric
encryption is that the private key can be shared inappropriately, leading to
leaked data. Examples of this type of encryption include AES, RC4, and DES.
 Asymmetric: In this relatively new and more secure type of encryption,
there is both a private and public key. The public key allows for encryption
by anyone, but that data then requires a private key to be read (the private
keys are different for each user). This is considered more secure for data
shared during communication, as the private keys do not need to be shared.
Asymmetric encryption is used for RSA, DSA, and PKCS, among others.
Which types of database encryption are most secure?
Customers interested in encrypting their database will likely want to know
their options. The following types of database encryption offer varying levels of
protection that must be weighed against their associated performance impact in
order to select a safeguard that is at once practical and effective.
 AES: The Advanced Encryption Standard is a symmetric algorithm and
considered very secure. In fact, everyone from the U.S. government to
software and hardware companies utilizes this algorithm. This method uses
a block cipher rather than a bit-by-bit stream cipher. The block lengths are
either 128, 192, or 256 bits. Users must share the key in order for others to
access the data, which means they must also secure that key to prevent
unauthorized access.
 RSA: Rivest-Shamir-Adleman is an asymmetric algorithm that uses a public
key for encryption and a unique private key for decryption. This method is
typically used for sharing data over an insecure network, which can include
database encryption. The key size is between 1024 and 2048 bits, which
provides higher security but a significantly slower pace than other methods.
 3DES: Triple Data Encryption is another block cipher. It utilizes three 56-bit
keys to encrypt data three times, resulting in a 168-bit key. This option is
fairly secure, but also slower due to the multiple encryptions. While
currently in place for a number of businesses, 3DES likely won’t last much
longer as a standard.
 Twofish: Twofish is also a symmetric block cipher, with keys ranging from
128 bits to 256 bits. It’s a fairly flexible method, especially since it’s license-
free. The number of encryption rounds is always 16, but you can choose
whether you want key setup or encryption to be the quicker process.