This post will introduce a generic set of database / datastore security requirements that be used as a starting point when developing a database security strategy.
I use the phrase “Datastore” in the title. I’m trying to cast a wider net than traditional databases. By datastore, I include:
- Traditional SQL databases.
- NoSQL databases
- In-Memory Caching layers
- Your secrets secure storage system
- Proprietary data storage systems for whatever product that you can’t upgrade and can’t run the business without.
I keep writing database security requirements for new projects. I’ve reproduced the following list in one-form-or-another many times.
These requirements are relatively generic, but important.
Not every requirement will be relevant to every situation, architecture, database product. For example, if you have a Redis caching layer and nothing is written to disk backup / restore capabilities and encryption at rest are probably not that important.
Please note that this list is not a substitute for your organization developing its own comprehensive data security strategy.
- Use the latest Long-Term Support (LTS) release and the latest patch level.
- Availability
As a minimum database deployment, I prefer to run a primary / active node and a read-only backup-node with a continious update feed from primary to backup.
In the event that the primary goes down, the read-only node can be promoted to the primary, a new backup node constructed, and downtime minimized. How clients connect to the new database instance depends on the product and architecture.
I like to run this setup in non-production environments as well. It costs more, but minimizes downtime in development environments that your developers need.
3. If possible, use the available database SaaS solution — it makes just about everything much easier.
4. All database access must be authenticated.
5. Database user credentials must be stored securely in a Password Management System of some type.
6. The database listener must be facing an internal, private network. Not the internet.
If your database SaaS solution is only accessible over the public internet, I recommend reevaluating the choices you’ve made.
Most third-party database SaaS solutions will have support for a VPN connection, VPC peering, to eliminate the public-facing listener and problems that go with it.
You will likely need to provide some type of jump server that allows for developer or operations team access to database. This includes production. Proper access control must be taken into account.
7. Encryption at REST.
At a minimum, file system level encryption must be used.
The encryption key must be stored securely in some type of Key Management System (or equivalent).
The encryption keys must be periodically rotated.
The encryption algorithm must be AES256 or better. An equivalent encryption algorithm could be used, but the vast majority of at rest encryption mechanisms today use AES. The world is changing fast; so, stay tuned.
If this is a cloud platform, use the KMS system that it provides, allow it manage the encryption keys, allow it to periodically rotate the encryption keys. If your organization uses CyberArk or Hashicorp, that would also satisfy the requirement. There are other options. Please don’t store the encryption key in a plain text file.
If your organization insists on managing its own encryption keys, so be it. The same requirements must be satisfied.
Encryption of data elements at rest higher up the technology stack could be used depending on the product or security needs of the data. The most common example of this is separately encrypting individual database fields / columns stored in the database. Most of the major database products have some type of support for this. Sometimes, applications will encrypt / decrypt such data at the application layer just before data access /writing. Use the out-of-the-box database features when available. Ensure that the key management requirements above are meant.
8. Encryption in flight.
This can often simply be addressed by enabling TLS v1.2 or better on the database listener.
If the entire application and database access is deployed on top of a Kubernetes-based platform (OpenShift, EKS, GKE, AKS, etc, etc), then Istio’s support for mutual auth SSL / TLS between pods with sidecar patterns could be used.
The X509 certificate and private key must be stored securely. This can be accomplished using a cloud provider’s Certificate Management System (CMS), Hashicorp Vault, CyberArk, or similar product. This CMS or secure storage mechanism must provide an access control layer.
Some database products bypass TLS and implement a custom encryption scheme over the products proprietary wire protocol. I recommend avoiding this approach.
9. All credentials and sensitive values must be stored securely.
This means encrypted at rest with an access control layer.
This can be accomplished with some type of application-friendly (no-human user’s needed) Password / Secrets Manager system, Hashicorp Vault, CyberArk, etc.
Regular users and, generally, administrator users shouldn’t be able to access the credentials.
All credentials should be rotated periodically. Your secrets management system might be able to help with this.
10. Backup and Recovery.
If there is an automated or low-touch backup and recovery system available to your database systems,use it! Do not roll your own.
If you are running databases on top of Kubernetes, there are various products / mechanisms that can backup and restore Persistent Volumes (PVs). Use what is available.
Most products do not automatically coordinate with backup systems to generate a clean backup, maintain consistency, and remain available during the backup. Understanding what the needs of the backup system are.
Read the fine print of your database SaaS providers Terms and Conditions. Do you need to backup the data from that database yourself? Hopefully not, but check anyway
How often are backups generated? What happens to the transactions that weren’t part of the most recent backup? Can those be recovered from a transaction log and reapplied? Or, does the business need to manually reenter transactions between two points in time to restore the database to its most recent state? The answers to these questions vary widely, but give you an idea of what needs to be thought through.
11. Disaster Recovery.
Define the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Develop a comprehensive Disaster Recovery / Business Continuity Strategy around that RTO & RPO.
How is data going to be replicated / copied from the primary site to the backup site?
How much of the backup site is built out ahead of time?
Systems deployed to cloud platforms need DR plans too.
Practice this DR strategy / plan once a year. Once a quarter is better.
Note, I’ve heard many excuses why this isn’t a priority or not testing the DR plan is an acceptable risk. Most organizations living this philosophy eventually come to regret it.
This topic is its own series of books; so, I’m not going to attempt to add more detail. But, I encourage the reader to put the needed effort into DR planning prior to actually needing it.
12. Develop a monthly security patching plan. Keep up to date with patches.
Product-Specific Security
I will update this section periodically with links for specific products. Note, this isn’t the original intention of this blog post, but may be helpful to someone.
postgresql: https://www.postgresql.org/support/security/
redis: https://redis.io/docs/latest/operate/oss_and_stack/management/security/
MongoDB: https://www.mongodb.com/docs/manual/security/
Oracle: https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html
MariaDB: https://mariadb.com/kb/en/securing-mariadb/
MySQL: https://dev.mysql.com/doc/refman/8.4/en/security.html
SQLServer: https://learn.microsoft.com/en-us/sql/relational-databases/security/securing-sql-server
If your favorite database isn’t listed here, that means I haven’t used it in my day-to-day work.