Architecting for Security : A Guide for MongoDB

The prevalence of data breaches is no longer surprising. Based on the just released FBI cybercrime report, victims of cybercrime have cumulatively lost a whopping $4.2 billion in 2020 which is $700 million more than the reported losses in 2019. In particular, insecure MongoDB databases have been part of the problem leading to significant data breaches. In February of 2019, an email verifications service company had their MongoDB database breached and it exposed 763 million records including email addresses, phone numbers, IP addresses and dates of birth. The reason being, a public facing MongoDB instance with no password. 

Lack of authentication, no restricting of ports on the firewall, or failure to secure data in transmit may lead to a data breach. In this blog, we will discuss how to prepare and secure your MongoDB database in a production environment.

Authentication and Authorization

Authentication and authorization are two different things, but they are correlated. Authentication means the user has access to the MongoDB database while authorization permits the user to access the resource inside the database. 

The default installation for authentication in MongoDB is disabled. MongoDB supports multiple authentications eg: SCRAM, x.509 Certificate Authentication. The default one in MongoDB is SCRAM (Salted Challenge Response Authentication Mechanism), which verifies the supplied credentials access with the username, password, and authentication database.

Before enabling authentication, please create a superuser in MongoDB with the role userAdminAnyDatabase.After it finishes, we just need to open the /etc/mongod.conf file and find the section on security. The default is disabled, we just need to enable.

security:
    authorization: "disabled"

Restart the MongoDB service to apply the configuration changes. We can also configure RBAC (Role Based Access Control) inside the MongoDB database for better security related to the user. So we segregate the access to the database based on the user and privileges.

Network Segmentation

Network segmentation is an important aspect when we design database architecture, it applies to all databases, not only for MongoDB. It is a best practice that we segregate the network for the database. We set up the database server in a private network, where it can not be reached from the internet. 

The communication to the database happens on the private network, and when the user wants to access the database, they can use VPN or a jumphost. Besides network segmentation, restricting the port also plays a key role, we open the database port specific to the segmented network to control the inbound and outbound network traffic. So, we know that the incoming traffic is from the trusted source address.

Data Encryption

Another area we need to take a look at is data encryption. Data encryption is a method where the information is encoded to another form during the transmission and stored in the database.

Data encryption covers:

• Data in transit: data in transmission state 

• Data at rest: data stored on disk. There are various types of data encryption at rest, we can use encryption on the database level, or we can use encryption in the storage layer.

Enabling SSL/TLS from the clients and MongoDB server and between the MongoDB nodes (in replicaset and sharded cluster architecture), will secure the data in transit. The data transfer will not be in plain text.

There are various encryption tools and features for data at rest encryption, for example; AWS provides EBS disk encryption combined with the KMS (Key Management Service) on the storage, while on the database layer, the Enterprise edition of MongoDB provides the database encryption at rest.

Database Auditing

Implementing an audit database for MongoDB gives visibility of what is running inside the database; eg: from which user, and what command that executed, and the source of ip address. We can combine those logs and create rules based on the authorization access. We can detect if there is any unintended user running some script in MongoDB. We can see the section auditLog.

auditLog:
   destination: syslog

We can send the MongoDB audit log into the syslog files and push the logs into Log Management. Want to have more tips on securing MongoDB? Watch this video to get a better understanding on the best practices to secure your MongoDB database

Conclusion

Implementing security standards for MongoDB is a must, especially for a production environment. We can not accept every loss and breach of the data stored in the database.