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.
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.
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.
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:
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.
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:
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:
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.
If you’re still relying exclusively on firewalls or access controls to protect sensitive business data—or even if you have an old encryption method in place—it might be time to offer a better solution to your customers. Data encryption doesn’t have to lead to worse performance if you ensure that your encryption types and implementation follow best practices and strike an appropriate balance between security and usability. Interested in finding out more? Speak with a member of our team to see if your current encryption methods are implemented effectively.