The 3 Levels of Encryption Your Data Needs

CK Krishna - 15 July, 2018

Data encryption is a key component of a comprehensive security strategy to protect sensitive data. However, the high-cost resources and performance-intensive operations involved in data encryption and decryption often keep architects and developers from using these methods. It’s so much easier to find errors in plain text as opposed to encrypted – but for the same reason, encryption is necessary. No one wants their data handed on a silver platter to hackers – encryption prevents that from happening.

There are three levels of encryption that are necessary to assure data security:

  1. Storage
  2. Database
  3. Log

View the xOverTime security white paper to learn how our engineers have architected and implemented security measures deep down to the data element level to assure the integrity of our customer’s enterprise spreadsheet data.

CSOs and IT teams must understand each and how they apply to their data. Security is a pivotal and crucial component of xOverTime where we have implemented all three levels of encryption to assure the security of our customer’s data.

1. Storage Level Encryption

It’s a standard security practice for most organizations to use hard drive encryption on laptops to minimize risk should they be stolen or seized without knowledge. Cloud storage is more vulnerable and open to threats of this type when not encrypted. Enforcing encryption at the Elastic Block Store (EBS) volume level is one of the fundamental measures that cloud and system architects should perform. This is commonly referred to as the EBS encryption. An encrypted EBS volume, when attached to an instance, supports the following types of data to be encrypted:

  • Data at rest inside the storage volume
  • Data moving between the storage volume and instance
  • All snapshots (backups) created from the volume

EBS volume encryption provides protection against incidental issues associated with attaching the volume to a different server instance. In the event the volume is attached to a different instance, then the instance cannot access the data unless a key pair is provided. xOverTime has storage level encryption turned on as a default.

2. Database Level Encryption

While not commonly implemented by most architects for fear of application performance bottlenecks, database level encryption is key to securing sensitive corporate information over and beyond the EBS volumes. 

Database encryption, commonly referred to as encryption at rest, when used in conjunction with transport layer encryption (TLS/SSL) and robust security policies protecting user IDs, passwords and encryption keys, can help ensure compliance with some of the stringent security and privacy standards, including HIPAA, PCI-DSS and FERPA. 

xOverTime database encryption leverages the AES256-CBC (256-bit Advanced Encryption Standard in Cipher Block Chaining mode) via OpenSSL. AES-256 uses a symmetric key; i.e. the same key to encrypt and decrypt text. xOverTime database encryption includes:

  • Generating a master key
  • Generating keys for each database
  • Encrypting data with the database keys
  • Encrypting the database keys with the master key

3. Log Level Encryption

Log files (application logs, debug logs, audit logs, and database logs), could potentially contain sensitive data, system configuration, system resources, or transaction details that could be easily accessed by attackers. In addition to stringent access control policies, encryption plays a pivotal role in the data protection of corporate information, providing an extra layer of protection and safeguarding data at rest. As an additional security measure, access to log files need to be strictly governed.

So how do these three types data security become part of the way spreadsheet data is secured? In xOverTime we limit writing customer sensitive information to the log files, period. In addition, we ensure log files have encryption turned on by default. Finally, xOverTime log files are recycled and archived at short turnaround times to prevent them from overgrowth and causing performance drag.

As a result, when using xOverTime with spreadsheet applications like Excel, users remain in control of their data because they can rely on their Excel skills for calculation and reporting, and on xOverTime for assuring their data is accessible and secure.

Contact us to learn more about how we can help protect your enterprise spreadsheet data.

 New call-to-action

Subscribe to the Enterprise Spreadsheet Performance Blog

Request a demo to get started today!

See how our Excel-enabled cloud database can help you better manage data to drive business decisions.