Database Hardening

In this article, we will not focus on any specific DBMS, but will consider the tips that are suitable for any database.

Obvious things that are often forgotten

First of all, when placing the server, it is important to remember about physical security. The server should be placed in a server room with restricted access for outsiders, in a lockable server cabinet.

As you know, the level of security of the entire system is determined by the level of security of its weakest link. And DBMS hardening should start with the secure configuration of the server operating system on which we are going to install our database.

First of all, the version of the OS used must be stable; do not experiment with test releases. When installing the OS, you need to select only those components that are really needed for the DBMS to work. It is unlikely that you will need docker or microk8s on the same server for the DBMS to work, so you do not need to specify them when installing the system. After installing the OS, do not forget to check for updates.

When building an application architecture, remember the rule: one server - one role. In our case, this means that nothing else can be installed on our database server. For example, it is a very bad idea to put a web server and a DBMS on the same node. In the event of a web server compromise, an attacker will be able to quickly take over the database. Of course, if we are talking about a development environment, such compromises are acceptable there, but in production, even if it is a web resource for an internal network, this should not be done.

Next, it is necessary to take care of the server's network security. Do not rely on perimeter security measures; it is necessary to configure firewalling on the host itself. It is necessary to determine in advance which ports we will need and leave only them open. All other ports must be closed.

To manage our server, SSH will most likely be required if we are talking about Linux. When configuring SSH access, it is necessary to use certificates, and it would also be good to protect the key with a password to make life more difficult for the attacker.

And, I hope this is obvious: we do not use a privileged account to work with the DBMS. The database installation process is usually performed with elevated privileges, but then it is necessary to use a special account for the direct operation of the DBMS.

The installation process itself should be carried out in accordance with the vendor's instructions. Do not neglect the recommendations given by the developers - as a rule, these recommendations are based on their experience and are really useful.

Removing the unnecessary

After installing the DBMS, it is necessary to disable insecure settings, and here we will give some examples for some systems.

For MS SQL Server, it is necessary to disable xp_cmdshell, xp_dirtree, and other built-in procedures that we do not need for our application. Also, disable Common Language Runtime (CLR), SQL Browser service, and mixed authentication, as this mechanism is not considered secure. Also, in the production environment, it is necessary to delete the Northwind and AdventureWorks sample databases.

For MySQL and MariaDB, after installation, it is necessary to run the mysql_secure_installation script to remove the default databases and accounts. Disable the FILE privilege to prevent users from reading and modifying files.

Also, each DBMS vendor has guidelines for securely configuring their solution after installation. With these recommendations, you can easily harden the necessary DBMS.

Accounts for access

The principle of least privilege should be observed both in relation to the operating system of the node on which we are installing, and in relation to the accounts that are used to work in the DBMS itself. Users should have access to the database only as long as it is necessary to perform their work tasks, and should have only those permissions that are necessary for them to perform their role. When a user no longer needs permission, it must be revoked.

As for the service accounts used to access the backend to the DBMS, it is first of all necessary to use an account that also does not have excessive rights, but has only those rights that are needed to work with the corresponding database.

If several users have access to the DBMS, for example, several developers, it is important to ensure that these accounts are used only as necessary, and then blocked. The fact is that privilege leakage is a fairly common problem in database systems, where additional privileges are granted as needed and not revoked. For example, a developer was given temporary access to create the necessary tables in the database. Then the developer finished his work, but access to his account remained. This is not very good. After the work is completed, access to the account must be blocked.

If you have many accounts, at least several dozen, then a good way to manage excessive privileges is a privileged access management (PAM) system. These systems provide visibility into all permissions granted to systems and can assign just-in-time privileges to users working with the database, automatically revoking them upon completion of work.

Continuing the topic of account management: do not forget to enable automatic account lockout after several login attempts, as well as set an account deactivation policy when employees move to other positions or leave the company.

Also, for the most critical applications, it is necessary to set permissions within the databases themselves. Thus, we can restrict permissions at the table, column, or row level.

Protecting Traffic

Of course, network interaction between the DBMS server and the web server occurs on the local network, and traffic, as a rule, does not leave the controlled zone. But it would also be good to protect it from eavesdropping.

Configure database interaction in such a way as to allow only encrypted connections, preventing traffic from being transmitted in clear text. Install a trusted digital certificate on the server. The client application should connect using TLSv1.2+ with modern ciphers (e.g., AES-GCM). On the client side, there should also be a check of the correctness of the digital certificate used for the connection.

Monitoring Everything

After we have deployed our DBMS, we need to monitor what is happening in the database. This applies to both security event monitoring and general database state monitoring. First of all, track all successful logins and failed authorization attempts, not only in your database but also in the operating system. Regularly review event logs to identify abnormal activity, although it is best to use SIEM solutions to automate monitoring for event analysis and detection of suspicious anomalies. In SIEM, you can also set up an alert system to notify relevant individuals or teams of suspicious activity.

Continuous monitoring allows you to quickly identify compromised accounts if an attacker penetrates your databases or an employee performs suspicious work out of negligence. Monitoring also helps to identify the creation of unauthorized accounts (i.e., a hacker creates an account without your permission) or when users share accounts.

In addition to monitoring security events, it is also necessary to regularly monitor the overall state: the performance of the DBMS as a whole and individual queries, the availability of free space on the disk storage, error messages in the event logs, etc.

Conclusion

The recommendations given in the article are not exhaustive. Depending on the specifics of your database and application, you will most likely need additional security settings.