In previous TAM Enterprise Experiences posts, we have outlined typical aspects of utilizing MySQL in an Enterprise environment. One thing we have not yet covered is the topic of database encryption, both from the standpoint of business requirements as well as some of the more technical aspects of encryption.
In this post, we will cover:
- Common enterprise compliance requirements
- Types of MySQL encryption
- Choosing the right encryption
- Vault
Common Compliance Requirements
Beyond the obvious security concerns with sensitive data, most enterprise businesses also need to meet various compliance requirements, with the compliance requirement(s) dependent on the country the business is located in, the type of business, and the type of data being stored. Note that in all cases, the onus is on the business to protect the data based on these compliance requirements. Some of the more common enterprise compliance requirements are:
- GDPR
- Applies to businesses located within the EU.
- 32(1) of the General Data Protection Regulation to implement appropriate technical and organizational measures to secure personal data.
- The GDPR deliberately does not define which specific technical and organizational measures are considered suitable in each case, in order to accommodate individual factors.
- Source: https://gdpr-info.eu/issues/encryption/
- HIPPA
- Applies to the medical industry within the United States.
- The HIPAA encryption requirements for transmission security state that covered entities should “implement a mechanism to encrypt personal health information (PHI) whenever deemed appropriate.
- Source: https://www.hipaajournal.com/hipaa-encryption-requirements/
- PCI DSS
- Applies to protect monetary transactions.
- PCI encryption Requirement 3 of the Payment Card Industry’s Data Security Standard (PCI DSS) is to “protect stored cardholder data.”
- The public assumes merchants and financial institutions will protect data on payment cards to thwart theft and prevent unauthorized use.
- Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable in order to meet PCI DSS Requirement 3.4.
- Source: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf
Outside of compliance, there are of course other very critical reasons for an enterprise business to encrypt and protect data. A breach of security could result in a major negative business impact at best, and complete ruin at worst. Protecting business secrets from the competition, as well as an overall ethical and moral responsibility to protect information and data are other reasons that data security and encryption should always be taken seriously, regardless of business size or industry.
MySQL Encryption
There are several types of MySQL encryption:
- Encryption At Rest
- Full disk encryption
- Encrypted database files
- Encryption In Transit
- TLS + Enforcement of SSL for TCP/IP user and replication accounts
- Use of a UNIX SOCKET connection instead of the TCP/IP mysql connection
- Encryption In Use
- Applications encrypt data before storing it and decrypt it once retrieved.
- The application takes responsibility for data security.
Choosing the Right Encryption
No matter the circumstances, at a bare minimum, encryption in-transit should be utilized to protect data in flight. All replication accounts and all user accounts should be using TLS + enforcement of SSL.
At some point in the future perhaps MySQL will mature to the point where in-use encryption won’t need to be handled by the application and the last bullet point can be dropped from the list. For now, however, the use of debuggers like strace can give access to the unencrypted data in memory on the MySQL server. Adding in this additional layer of application encryption can ensure that data in memory on the database server is encrypted and protected.
Encryption at the Volume/OS/Block Level
Strengths:
- Simple to encrypt the volume or disk
- MySQL isn’t aware of any change
- The application isn’t aware of a change
- Inexpensive
Weaknesses:
- Doesn’t protect from insider threats
- Centralized key storage and compliance can be problematic
Encryption at the Database Level
Strengths:
- Protects from insider threats
- Can encrypt across volumes you don’t control
- Backups and restores are automatically encrypted
- Lower overhead (3-5% performance hit)
- DBA controlled
- Centralized key storage
- Compliance ready
Weaknesses:
- Still vulnerable to in-memory attacks
- More setup / complications
- Loss of keys would be catastrophic
Encryption at the Application Level
Strengths:
- Database servers are protected at all levels automatically since the data is unusable without decryption
- Most flexible
- Little to no overhead on databases
Weaknesses:
- Many applications are not built with this in mind and are not easy to change
- Full text and partial text search can be a problematic
- Application shoulders all the responsibility for key security
What is Hashicorp’s Vault?
Hasicorp’s Vault is software for securely managing secrets. In this case, a secret is anything you want to tightly control access to, such as API Keys, passwords, or certificates. Vault is flexible with administration and can be controlled via a web GUI or the command line. There is also a strong API using curl with various ways to authenticate, and Hashicorp regularly pushes out updates to Vault keeping it up to date.
Vault Strengths:
- One easily managed, centralized location for all keys
- No backups of keyring file needed
- Better security as the key is nowhere on the MySQL server itself
- Powerful auditing capabilities
Conclusion
In a perfect world, your data would never be at risk and would always be protected. In reality, however, it is up to the data owners/administrators to protect their data using the methods outlined above.
