When you consider HIPAA compliant hosting for storing protected health information (PHI), you may wonder if a NoSQL solution such as MongoDB is a strong choice. If using MongoDB, you can take steps to make sure your database stays compliant with the Health Insurance Portability and Accountability Act (HIPAA) – both in choosing the right flavor of MongoDB and understanding its security features.

Healthcare attack on MongoDB

Before we address making MongoDB HIPAA compliant, we should first consider a string of reports from early January last year in which thousands of healthcare firms had their MongoDB databases targeted by cybercriminals – the hackers were exploiting systems that had not been configured properly.  At that time, many healthcare firms had the nasty realization that their MongoDB database had been accessed by unauthorized individuals, copied, and deleted.

Victor Gevers, an ethical hacker, found that there were a huge number of MongoDB databases that were exposed and that could easily be accessed through the web by nefarious parties. There were 13 healthcare firms that had been attacked by January 6, 2017, which Gevers again reported. In each case, the database had been copied and deleted. When the healthcare firm accessed the database themselves, they found a ransom demand instead of their PHI. The attacker noted that the information from the database would be sent back to the organization once the healthcare company paid a 0.2 Bitcoin ransom, which at the time was equivalent to about $175.

The news and urgency of these warnings simply could not spread faster than the hackers’ efforts. By January 11, ransom demands had been received by over 32,000 institutions, one of which was Emory Healthcare.

Chris Vickery, a MacKeeper security researcher, noted that he had found an organization that had not yet been attacked but that had an exposed database: WAMC Sleep Clinic, the company behind militarysleep.org. The database contained information on 1200 veterans that totaled 2 gigabytes. It included sensitive, confidential information such as their home addresses, email addresses, former military ranks, and previous activity on the site.

Given this rash of incidents, many organizations wonder if MongoDB can really be a HIPAA-compliant database option.

How to set up MongoDB for HIPAA-compliant apps

It is important to note that any apps you develop can only be HIPAA-compliant if all layers of the application stack abide by the law’s data security requirements. It really is truly about the setup. “Properly configured, you can use MongoDB to provide the persistence layer of an application that complies with these regulations,” noted MongoDB principal solutions architect Jay Runkel.

To design the database layer of your app to properly safeguard PHI, said Runkel, some of your primary concerns will be that it meets the following core parameters:

  • Authentication – You must be able to securely authenticate user access. Typically the directory server you already have in place will be used to restrict and control access.
  • Authorization – Through the assignment of user roles and privileges, the database should be able to control access so that companies can only see information within the database that applies to their firm (as with an insurance carrier’s database that includes many clients’ data).
  • Auditing – You need auditing set up within the database so you can know right away when authorization has been adjusted and confirm that any changes are aligned with regulations.
  • Encryption – Finally, you want encryption to be in place, both for data that is at rest and in motion between the application and database layers, and among the database components.

MongoDB vs. MongoDB Enterprise

The two editions of MongoDB are MongoDB and MongoDB Enterprise. Note that you can use a security checklist within MongoDB to enhance protection for PHI. However, for a robust HIPAA-compliance environment with a broader set of security features, the Enterprise version is the right choice.


Generally, healthcare firms want to perform authentication via integration with an identity management system. An IMS makes it possible to control user access through a single repository, with determinations applied throughout the entire ecosystem.

If you want to connect your IMS in this manner, MongoDB Enterprise supports the necessary protocols. Active Directory, Kerberos, and LDAP are all supported. Through x.509 client certificates, certificate authorities and your HIPAA-compliant infrastructure can perform authentication.


After user identity for a person or application has been verified, it is necessary to designate the actions they can take and the data they can access. Adequate restrictions should be in place so that people only see what they should. User authentication allows an individual to see their health records. Role authentication allows physicians to change patient records, while those in billing can only view it.

Changing these parameters is simple. There is a built-in library of permissions that you can blend for the various user roles. Once those are established, each user can be given the right role. “A user can perform any of the operations and access the data as defined by the union of the privileges associated with their roles,” explained Runkel.


It might seem that authentication and authorization should allow for proper safeguarding of protected health information on their own. However, auditing is also needed because things will change within the company – such as employees coming onboard, departing, or switching to a different position. Since that’s the case, it is key to monitor your setup and keep everything updated so you maintain HIPAA compliance as time passes.

It is impractical to do a full audit every time you make changes. To streamline and organize this process, you need an audit log in your database layer so you can see every time your configurations are modified. Ongoing validation of user and role changes is simple when the security staff uses this log for monitoring.

It is also a good idea to implement CRUD (Create, Read or Retrieve, Update, and Delete) operations. In order for your security personnel to view data types that various user roles access, they can monitor CRUD. For instance, you may find that billers sometimes can delete healthcare records rather than just access them. Through this process, you can often find gaps in your security configuration that are noncompliant with HIPAA.

Both CRUD operations (see the MongoDB manual) and changes to security are audited by MongoDB Enterprise. For efficiency and manageability, you can add filters so that the log only records events that are relevant to auditing.


As data flows between the application and database, secure sockets layer (SSL) certificates are typically used to encrypt and prevent unauthorized access. To encrypt data at rest, it is important to also implement an additional encryption tool, whether independent or database-native. You also want to have a key management solution that allows you to track, rotate, and secure your encryption keys.

The SSL protocol is supported by MongoDB Enterprise, as is at-rest encryption, through the WiredTiger Storage Engine – with encryption enabled. The key management interoperability protocol (KMIP), used by the majority of key management solutions, is also supported for efficiency and security.

HIPAA-compliant MongoDB hosting

The above steps will help with your MongoDB configuration within a HIPAA compliant database hosting environment. However, you also need highly secure infrastructure for your PHI in MongoDB and elsewhere. HIPAA Compliant Hosting by Atlantic.Net is SOC 1 & SOC 2 certified & HIPAA audited, designed to secure critical data and records.

Learn more about our HIPAA compliant web hosting and HIPAA cloud hosting solutions.