MongoDB Monitoring, Auditing & Authentication: 3 Steps to Secure Your Database

See: An avoidable situation

If you are running a database service in a development environment, it pays every which way to aim at a secure installation. When that database system is providing a service for an organisation then it must be made secure.

Any organisation, however small, is required to protect its data from security threats and to mitigate risks that cannot be countered directly. Everyone within the organisation has to be aware of current relevant legislation and understand their personal responsibilities. Everyone has to protect the confidentiality and integrity of the data that they access.

However, security isn’t just about legal obligations and the heavy fines that can be the consequence of a data breach. It is also about safeguarding the reputation of the organisation and protecting its ability to function properly.

In addition, the paperwork and bureaucracy that follows a breach, even one that is relatively harmless, can sap the energy of any organisation. Employees of any business that is being held up for public ridicule feel it personally. Trying to hire in the glare of scandal just adds to the sense of a vicious circle.

We can divide the security task into eight categories. We should then treat them as being of equal importance because, if one fails, then they all fail. By no means do all database people regard them all as being strictly security topics but because of their interdependence, many do.

Here’s the list:

• Monitoring
• Auditing
• Authentication
• Security of Access
• Security of Data In Transit
• Security of Data at Rest
• Application Security
• Infrastructure Security

We’ll cover monitoring, auditing, and authentication below.

Monitoring your MongoDB service

Imagine that you are defending a fort. You’d have lookouts, watchmen, early warning from surrounding villages and perhaps a system of beacons. Your last resort may end up being boiling oil, but far better if you can nip the incursion in the bud at the earliest point.

By analogy, you need to be able to check generally on the activity of a MongoDB service, and to archive the values from the logs to the point that you can compare activities at different times. Monitoring defined periods of time is even better, so that all potentially suspicious activities, such as login failures, are recorded.

Insider threats are surprisingly common. These can be normal users or attackers gaining access to privileged user accounts. You need to know what is normal and what isn’t and the system needs to be able to fire off alerts if anomalies require investigation. Beyond the MongoDB service itself, the server that is hosting it also needs attention, particularly the security events.

Knowing when the server is starting to get massively scanned allows you to prevent subsequent advanced attacks. Everything needs to be visible: the more visible it is, the sooner you can spot when things go wrong.

Auditing your MongoDB system

In our imaginary fort, we have valuables. You have to check you’ve still got them. If you lend them out, you need to know they’re returned. You need to know who has been visiting to take a look or clean them. All visitors to the database must feel that they are being observed. It’s the same with auditing.

There has to be a record of business activities and commercial transactions over and above the basic book-keeping, and in a way that is independent of the system being audited. We can thereby detect attempts at fraud, as well as mistakes, exploits of bugs in the software, or intrusions.

All visitors to the database must feel that they are being observed.

Records must always be in sufficient detail to facilitate forensic analysis and allow administrators to verify proper controls. Unlike Monitoring, you are checking definite parts of a mechanism. Only MongoDB Enterprise includes a way of auditing the system that can record system events such as user operations or failed logins on a MongoDB instance.

Authenticating MongoDB clients, processes & servers

Forts have very few entrances, usually manned by mean-looking suspicious people who, if they don’t recognise you, want proof of identity. They know who is legitimately in the building at any one time. Their modern counterparts don’t give you all the keys to the fort, just the access-restricted swipecard that you need.

Likewise in database security. Authentication requires that all clients, processes and servers must provide valid authentication before they can connect to the system, and can be uniquely identified. MongoDB authentication must be enabled and used: In clustered deployments, you need to enable authentication for each MongoDB server, using either the default MongoDB authentication mechanism or an existing external framework such as Active Directory.

Authentication that is shared between users is useless. It should be at a level that allows you to identify a named individual or process. If a process needs to interact with MongoDB, it must have its own credentials, and be assigned to a role that gives it only the access it requires and no more.