5 Essential Practices for Database Security

Data breaches are expensive. Between business disruption, loss of customer confidence, legal costs, regulatory fines, and any direct losses that may result from a ransomware attack, for instance, the effects can add up to millions. The best defense is a good offense, so let's look at five key practices to keep your database secure: protect, audit, manage, update, and encrypt.

1. Protect Against Attacks With a Database Proxy

A database proxy, or gateway proxy, sits between your application and your database, accepting connections from applications and then, on behalf of those applications, connecting to the database. An intelligent database proxy such as our own MaxScale provides filters and modules to deliver security, reliability, scalability, and performance benefits.

The MaxScale Database Firewall Filter parses queries as they come through the filter, and can block things that don't match the whitelist of query types that you want to let through. For example, you might say that a given connection can only do updates and inserts and that another connection must match certain regular expressions, etc.

Proxies like MaxScale also protect you against DDoS attacks: when too many connections are coming directly into the database server, it can become overloaded. But a proxy absorbs some of that load to limit the effects of such an attack.

2. Set Up Auditing and Robust Logging

Auditing and logging go hand-in-hand, but audit logs are much more sophisticated than the general log. Audit logs give you all the information you need to investigate suspicious activities and to conduct root-cause analysis if you do experience a breach. Furthermore, audit logs help ensure compliance with regulations such as GDPR, PCI, HIPPA, and SOX. (Learn more about addressing the GDPR with MariaDB TX.)

The MariaDB audit plugin can log a lot of information: all incoming connections, all query executions, and even all accesses of individual tables. You can see who has accessed a table at a given time, and who has inserted or deleted data. The audit plugin can log to a file or the syslog, so if you have existing workflows that rely on the syslog, you can tie straight into those.

3. Practice Stringent User Account Management

It's vital that you manage your database user accounts carefully. This is true for nearly all aspects of your IT ecosystem, so we won't go into detail here. Instead, we'll simply remind you of the key aspects of user account management:

• Allow root access only from local clients.
• Always use strong passwords.
• Have a separate database user account for each of your applications.
• Restrict the number of IP addresses that can access your database server.

4. Keep Your Database Software and OS Up-to-Date

We all know the reasons to keep your software up-to-date, but that doesn't stop a great many of us from running legacy operating systems and several-versions-old database servers. Let this serve as a reminder that keeping everything current is the only way to protect your data from all the latest threats.

This applies not only to your server software but to your OS. The WannaCry ransomware attack was made possible by the lackadaisical application of Windows OS security patches, after all.

5. Encrypt Sensitive Data in Your app, in Transit, and at Rest

We've saved the least commonly implemented practice for last. Many organizations give encryption short shrift, but it can be quite valuable. After all, it reduces the incentive for hackers if the work of attempting to break a cipher awaits them after they gain access.

The first phase of encryption happens in the application before the data gets to your database. If the data is encrypted in the application, then a hacker who compromises your database can't see what the data is (this works only for data that is not a key, however).

Next is encryption of data in transit. That means the data is encrypted over the network as it moves from the client onto your database server (or onto a proxy). This is basically the same concept as using HTTPS in your web browser. Obviously, the server can see the information because it needs to read the form you filled out, and you can read the information because you typed it into the form, but no one in between you and the server should be able to read it.

Finally, we come to encryption of data at rest. You can use this to encrypt InnoDB table spaces, the InnoDB redo log, and the binary log. This means that you can encrypt almost everything written to disc on a MariaDB server (10.1 and later - remember what we said about keeping your software up to date?).