7 Database Security Best Practices
Database security has never been more important, given the high value hackers place on data. These database security best practices will help protect your data.
Databases - by definition - contain data, and data such as credit card information is valuable to criminals. That means databases are an attractive target to hackers, and it's why database security is vitally important.
In this article we cover seven useful database security best practices that can help keep your databases safe from attackers:
- Ensure physical database security
- Use web application and database firewalls
- Harden your database to the fullest extent possible
- Encrypt your data
- Minimize value of databases
- Manage database access tightly
- Audit and monitor database activity
In the traditional sense this means keeping your database server in a secure, locked environment with access controls in place to keep unauthorized people out. But it also means keeping the database on a separate physical machine, removed from the machines running application or web servers.
A web server is more likely to be attacked since it is located in a DMZ and therefore publicly accessible. And if a web server is compromised and the database server runs on the same machine, the attacker would have access as a root user to your database and data.
Your database server should be protected from database security threats by a firewall, which denies access to traffic by default. The only traffic allowed through should come from specific application or web servers that need to access the data. The firewall should also protect your database from initiating outbound connections unless there is a specific need to do so.
In addition to protecting the database with a firewall, you should also deploy a web application firewall. That's because attacks such as SQL injection attacks directed at a web application can be used to exfiltrate or delete data from the database. A database firewall won't necessarily prevent this from happening if the SQL injection attack comes from an application which is an allowed source of traffic, but a web application firewall may.
Clearly it's important to ensure that the database you are using is still supported by the vendor or open source project responsible for it, and that you are running the most up-to-date version of the database software with all database security patches installed to remove known vulnerabilities.
But that's not sufficient. It's also important to uninstall or disable any features or services that you don't need to use, and ensure that you change the passwords of any default accounts from their default values - or better still, delete any default accounts that you don't need.
Finally, ensure that all database security controls provided by the database are enabled (most are enabled by default) unless there is a specific reason for any to be disabled.
Once you have done all this, you should audit the hardened configuration -- using an automated change auditing tool if necessary -- to ensure that you are immediately aware if a change to the hardened configuration is made that compromises your database security.
It is standard procedure in many organizations to encrypt stored data, but it's important to ensure that backup data is also encrypted and stored separately from the decryption keys. (Not, for example, stored in encrypted form but alongside the keys in plaintext.) As well as encrypting data at rest, it's also important to ensure confidential data is encrypted in motion over your network to protect against database security threats.
Attackers can only get their hands on what is stored in a database, so ensure that you are not storing any confidential information that doesn't need to be there. Actively manage the data so you can delete any information that you don't need from the database. Data that must be retained for compliance or other purposes can be moved to more secure storage – perhaps offline -- which is less susceptible to database security threats.
In a similar vein, ensure you delete any history files (such as the MySQL history file ~/.mysql_history) that are written by a server during the original install procedure. While these files are useful to analyze if the install fails, if installation is successful they have no value to you but can contain information which is valuable to attackers.
You should aim for the least number of people possible to have access to the database. Administrators should have only the bare minimum privileges they need to do their job, and only during periods while they need access. For smaller organizations this may not be practical, but at the very least permissions should be managed using groups or roles rather than granted directly.
If yours is a larger organization, you should consider automating access management using access management software. This can provide authorized users with a temporary password with the privileges they require each time they need to access a database. It also logs the activities carried out during that period and prevents administrators from sharing passwords. While admins may find sharing passwords convenient, doing so makes proper database security and accountability almost impossible.
On top of this, it is wise to ensure standard account security procedures are followed:
- Strong passwords should be enforced
- Password hashes should be stored encrypted and salted
- Accounts should be locked after three or four login attempts
- A procedure should be put in place to ensure that accounts are deactivated when staff leave or move to different roles
This includes monitoring logins (and attempted logins) to the operating system and database and reviewing logs regularly to detect anomalous activity.
Effective monitoring should allow you to spot when an account has been compromised, when an employee is carrying out suspicious activities or when your database is under attack. It should also help you determine if users are sharing accounts, and alert you if accounts are created without your permission (for example, by a hacker).
Database activity monitoring (DAM) software can help with this by providing monitoring which is independent of native database logging and audit functions; it can also help monitor administrator activity.
Read about why it can be tough to get database security into IT budgets and how to fight SQL injection, the top database security vulnerability.
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.