Data that is actively travelling from one point to another, such as via the internet, is referred to as data in transit because the data is in motion. Data that has been stored in a particular destination is called data at rest. Protecting the data at rest (when the data is already on disk) and its storage destination using encryption and appropriate access controls is becoming more and more essential to avoid the risks of unauthorised data access. Most web and mobile applications today store sensitive data collected through user interaction in databases. With the recent spike in database security breach cases, many businesses have started looking at database encryption seriously.
Data that has not been encrypted is referred to as plaintext, and data that has been encrypted is referred to as ciphertext. While numerous security measures exist to protect a system against intrusion or attack, encryption is considered to be a critical fail-safe mechanism that helps in an event of a data breach. This is because encryption does not stop data theft or hacking itself, instead, it makes the data stolen unusable by converting plaintext into ciphertext. This text is impossible to read without a proper decryption key.
Data encryption is considered extremely important, especially for businesses dealing in financial services, health services or eCommerce services. Recently one of our clients working with the finance domain needed a web-based application. The application would store confidential information like the personal details and the financial transactions of its users in a MySQL Database. Because the application would be accessible to anyone on the internet, it was crucial to have a strong protection layer to secure the data. This can be done at the application-level code itself, but this would prove ineffective in an event where the application itself gets compromised. After thoughtful consideration and several discussions with the client, our tech team came up with 2 alternatives to encrypt the data at rest for the MySQL database. The alternatives being considered were Database tables Encryption and Inbuilt Function Encryption. Each of these methods has its pros and cons. It’s important to take into consideration the technical environment and infrastructure while choosing the suitable method that fulfils your requirements.
To help the client make the right decision, our team not only elaborated on the pros and cons, but also presented different use cases for each method. Based on the discussions, both the client team and our technical team mutually decided to go ahead with Database tables Encryption.
Under this method a two-tier encryption key architecture is built through AES 256 Encryption, consisting of a master key and a table space key. Here the table space key is used to encrypt the tablespace of a MySQL database which is running on the InnoDB storage engine. The table space key is further encrypted using a master key and stored in the tablespace header. When a request is made to access MySQL data, InnoDB would first use the master key to decrypt table space key present in the tablespace header. Next, it decrypts the tablespace using the decrypted table space keys and makes the data available for read/write operations. The major benefit of selecting this method is that no changes are required to be done at the application/code level. Moreover, the encryption keys are managed by MySQL itself instead of the database admin. Under a scenario where only a particular set of data needs to be encrypted and the application is assured of being protected from unauthorised access, inbuilt function encryption would be a more preferable option.
We hope that the above article has helped you develop a basic understanding of the MySQL database encryption. Check out our Database Encryption Service page to find out more about how we help our clients in securing their data. In case you are looking for a service provider to encrypt your MySQL Database, our team is just an email away.