While organizations of all sizes are required to operate cost effectively in a 24/7 global economy, operating in the cloud has become popular. To meet the needs of their customers, cloud infrastructure providers offer robust security controls. With multiple layers of security controls, ranging from instance protection, key management, to network protocols/IP boundary, storage management, availability and encryption with region based fail-over, it often ends up being a nightmarish experience for the new cloud seeking customers. Security is a pivotal and crucial component of xOverTime, where our engineers have architected and implemented security measures deep down to the data element level to assure the integrity of our customer’s data.
Data encryption is a key component of a comprehensive security strategy to protect sensitive data. 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. At xOverTime, we have implemented three levels of encryption to assure the security of our customer’s data: storage level, database level and log level encryption.
STORAGE LEVEL ENCRYPTION
It’s a standard security practice for most organizations to use hard drive encryption on laptops to minimize the risk should they stolen or seized without knowledge. Cloud storage is more vulnerable and open for threats 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.
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. xOverTime provides database encryption as an option with storage level encryption turned on by default.
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:
LOG LEVEL ENCRYPTION
- Generating a master key
- Generating keys for each database
- Encrypting data with the database keys
- Encrypting the database keys with the master key
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.
Regarding log files, xOverTime limits writing customer sensitive information to the log files. 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.
Where xOverTime is involved, customers and end users will 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 secure.
For more about xOverTime security, contact us
to access our detailed white paper.