3 things to consider when securing data at rest in a MongoDB environment

< View all blog posts
MongoDB
December 15, 2014
Category: Business

This is a guest post by Arun Gowda, Director of Business Development at Vormetric.

Storing or processing a company’s sensitive data requires maintaining compliance and data security, especially for customer names, social security numbers, and health records – the information that hackers often target. Following three data security recommendations can help a company address compliance requirements and raise its overall security posture to derive the most value from its MongoDB environment.

Sensitive Data Extends Beyond Database Files

Where does sensitive data actually reside? Looking beyond just the database files, it becomes clear that sensitive data can also appear in ingress data, egress reports, configuration files, and log files. Many times the summarization provided by non-database files is even more valuable than the information in the database file itself. It is difficult to determine the use cases and destination points of all these files, so why take the risk? Consider protecting not only the database files, but also the associated ingress data, egress reports, configuration files, and log files.

Blind Data to Privileged Users

Two constituents in a company that generally have access to sensitive data housed in MongoDB are intended users and privileged users. Intended users have a legitimate business need to view and use the data. But what about privileged users (e.g. superuser, root)? They have the ability to view the data in a MongoDB environment to perform administrative tasks such as backup & restore, system configuration, and user account maintenance. This poses significant security risks; for example, a rogue privileged user or an APT that compromises a privileged user’s credentials and takes advantage of the user’s ability to view sensitive data. Organizations can easily reduce that risk by blinding data to privileged users. Enable privileged users to have access to meta file information, such as file names and attributes, so they aren’t impeded from doing their job, but blind them from viewing the actual data stored in these files.

Keys to the Kingdom

A MongoDB workload may be on-premise or in the cloud. By having an external key manager, it not only separates key management from the data for additional security, it also allows control of who has access to the keys. With a MongoDB workload in the cloud, external key management becomes even more important. A company can manage the keys that can be used to decrypt the data vs. relying on the cloud service provider. Remember the ability to blind privileged users referenced above? This can be extended to cloud service provider privileged users that have access to a company’s data in the cloud.

Conclusion

Protecting the sensitive information housed in MongoDB is critical not only for compliance and regulatory mandates, but also to prevent exposure of this data to malicious users. Following the recommendations above enables a path to helping address these issues. Want to find out more or have a discussion with a Vormetric data-security team member? Download the joint MongoDB/Vormetric solutions brief or contact Vormetric directly.

comments powered by Disqus