Six Things You Need to Know About Securing Your Database

Whether you store secret government information or standard user data, you don’t want some unknown person to access to your database. Especially if they’re an evil hacker. So what can you do to protect your sensitive information?

Lack of Security Is a Huge Problem

Generally, people want to do the minimum. When they set up the database environment, they often forget about securing it. Or they rely on someone else to do it for them, as many MongoDB users did. Prior to MongoDB version 2.6.0, the default IP binding was on 0.0.0.0. This meant that unless additional security measures were implemented, anyone could connect to the server. Moreover, the database did not require authentication.

What happened next? Reports show that 28,000 databases were hacked; their data was stolen and a ransom note requesting a bitcoin transfer for its return was left.

Aside from the problem of leaking sensitive customer data, this would certainly put the database administrator in a really bad position!

Of course, it’s not just MongoDB users that should thoroughly check their system configuration when installing software. Let’s go over a few things everyone should do to make their database more secure.

1. Securing Your Server

The first thing is to ask a very simple question: Do you need to remotely connect to your database? The answer is usually “No”, but sometimes you do. For example, say you have a DB system running on a network segment – e.g. eight servers in two local networks with the database outside of them. You also want administrative access from your office. That makes three IP addresses (one for each gateway of the server network and one for the office) that you need to whitelist in your firewall.

The firewall is the first thing a packet reaches when coming to your server. For better security, filter out all unused ports and block all IPs that are not part of the system setup.

Also, make sure that remote access to the server’s OS is protected. A secure mechanism like SSH will encrypt all communication between your computer and the server. A separate, low-privilege account should be used for admin duties; using a root account, which has all kinds of access, is a bad idea. And a good strong password is a must.

Alternatively, you could use asymmetric encryption with public and private keys to securely connect to the server (Public Key Authentication).

2. Defending Your Database

The database itself has a lot of security options to consider. For a start, enable SSL (or some other encryption mechanism) for client-database communication. If someone tries to listen in to your communications, they can’t easily do it.

Also, pay attention to the bind address. This defines which local interfaces will be used when listening for incoming traffic. If our database is in two network segments – e.g. it has IP 192.168.1.72 in the local network and 89.124.12.76 open to the Internet – binding on 192.168.1.72 means it will ignore connections that access it by the Internet IP. Note: If we wanted to listen on all interfaces at the same time, then we would bind on IP 0.0.0.0.

3. Minimizing Operating System Risks

When there’s a security problem involving a database, the fault often lies with the operating system. Remember to keep the OS updated. In particular, make sure the system kernel updates are applied, as the system kernel controls all of the application-to-network communication.

Remove any unnecessary accounts and services from your OS, as they provide additional attack surfaces. And every account should only have permission to access whatever parts of the system they need rather than the whole thing.

4. Controlling Database Access

Many databases have their own user permissions, or they may use another way of controlling data access. Ideally, try to apply the principle of least privilege here as well. If an application only reads from the database, then maybe it shouldn’t have write access. Generally, you can limit specific users’ access to a particular subset of executable statements.

Pay attention to default accounts. Always disable outside access to them and make their passwords strong and secure. These accounts are usually tested first during an attack.

5. Protecting the Persistence Layer

The database stores its data on a hard drive. What if the hard drive is stolen? It’s not that common, but it could happen. In that case, you’ll only be safe if the drive is encrypted.

Some databases (like Oracle) can encrypt their data without outside help from the operating system (Transparent Data Encryption). Other databases can use the operating system's built-in support for real-time file encryption, which makes the process quite simple. The database itself won’t know the difference between unencrypted and encrypted file systems because the decrypting happens when opening the file. This may decrease the overall performance of the database, though. Usually, a compromise has to be made between performance and security.

Should the drive become unused for some reason (e.g. it was damaged), it should be erased or physically destroyed. This is especially true if it contained sensitive information. Just formatting the drive isn’t good enough; some data can still be read from it.

Another important part of data security is performing regular backups. There are two types of people: those who are going to do backups and those who actually do them. If something happens to your server (e.g. the hard drive breaks), you’ll need to restore your data from a safe place or else your business will suffer. And this is impossible to do if you don’t have a backup copy.

How often should you backup your data? The advised standard is daily, with an additional copy for every week or month, so that you have some history of the data changes. And remember to encrypt or at least securely store those backups.

6. Keeping Up with Logging and Administration

Many applications log what is happening to them, including your system kernel, your firewall, and your database. These logs may contain simple information about status changes, incoming connections, and user logins. Administrators should check those logs (either manually or with a program) and make sure that there aren’t any abnormalities or attacks going on.

When a security risk is found, it needs to be fixed quickly. Intrusion Detection/Prevention Systems can be used to find and respond to problems; these systems are usually network- or host-based.

Aside from their security usefulness, logs are also great for telemetry. They can provide system stats, like the amount of usage during certain hours. Should your company ever get called into court for some legal proceedings, logs can be used by forensics specialists to determine what exactly has happened.

To sum it all up, securing your database is very important. Breaches can have catastrophic consequences. Remember, something can go wrong at any level. So secure them all: the operating system, the database, the network, and the application.