Introduction to Security Compliance
As a Solution Architect at MongoDB, I am often asked a large number of questions by organizations considering using MongoDB as the database layer for an application managing data covered by privacy regulations such as HIPAA, SOX, or PCI. Medical and insurance providers, financial service organizations, and retailers most often ask these types of questions. While I am not an expert on any of these regulations, I have a fair amount of experience answering the questions pertinent to the database layer of such applications.
MongoDB users in a number of industries run applications that must comply with regulations that typically exist to protect sensitive information about individuals:
- Health insurance organizations want to create a “single view” of the patient that aggregates all records, claims, and billing information into a single view.
- Retailers want to aggregate customer purchase, payment, and invoices across multiple channels.
- Financial service organizations wish to manage centrally all customer financial information. In all cases, various government regulations specify how to control and secure access to customer information.
Regulations apply to the entire application stack. One must configure all the layers in tandem to provide the appropriate level of data security. MongoDB by itself does not pose an issue regarding HIPAA or SOX compliance. Properly configured, you can use MongoDB to provide the persistence layer of an application that complies with these regulations.
When organizations design the database layer of an application that must protect customer data and comply with the previously mentioned regulations, they typically require that their database layer meet the following requirements:
- Authentication - The database must securely authenticate users who will have access to data. Most often the organization’s existing directory servers such as Active Directory, LDAP, or Kerberos control user access.
- Authorization - The database must control access to customer information by assigning roles and privileges to users. For example, an insurance provider that manages insurance policies for a large number of companies must insure that each company’s administrators only have access to their employee’s data and not data for other companies employees.
- Auditing - The database must provide auditing so that one may identify immediately any changes made to #2 and validate to ensure that changed user roles or privileges remain in compliance with their policies and governing regulations.
- Encryption - The database must encrypt data. This includes data at rest in the file system, data moving from the application layer to the database layer or among database components. Encryption ensures that some malicious actor cannot bypass the database controls and access information directly.
In the remainder of this blog post, we will examine how MongoDB Enterprise addresses these requirements.
MongoDB Enterprise
MongoDB is available in two editions: MongoDB and MongoDB Enterprise, a commercial edition of the database. MongoDB provides all the core developer productivity, high-availability, and scalability features that we all love about MongoDB. While the manual provides a security checklist for ensuring your MongoDB deployment is secure, there are additional measures that many users wish to take in the areas of authentication, authorization, and auditing that are not included with MongoDB. MongoDB Enterprise expands the security capabilities of MongoDB with features we will discuss in this blog post.
Authentication - Establishing User Identity
Authentication ensures the identity of the users accessing the database. It ensures that only designated users have access to the database. Most organizations concerned about regulatory compliance insist on integrating the database authentication with their organization-wide identity management system (e.g., Active Directory). This system enables user access to be defined (or revoked) in a central repository and immediately enforced across all systems, including MongoDB.
MongoDB Enterprise provides support for a number of authentication protocols enabling MongoDB to integrate with identity management systems. MongoDB provides support for LDAP, Kerberos and Active Directory. Active Directory integration is achieved via Kerberos. Company security infrastructure and certificate authorities can authenticate users via x.509 client certificates.
Authorization - Controlling Access to Sensitive Data
Once a system has confirmed that the person (or application) has established user identity, next they must determine what data to which they should have access and what actions that user is permitted to perform. From a compliance perspective, the system must provide the appropriate controls so each user only has access to the data to which they are supposed to have access. Sometimes the system authenticates at the user level. For example, John Smith has access only to his medical records. More often authentication happens at the role level. For example, all doctors have the ability to modify patient records, but associates in the billing department may only review those records.
Fortunately, MongoDB’s security model makes this type of security configuration straight forward. MongoDB provides a library of fine-grained privileges that then can be combined to define a user role. MongoDB then assigns roles to users. A user can perform any of the operations and access the data as defined by the union of the privileges associated with their roles. For example, in our patient record management example above the following roles may be defined:
Auditing - Ensuring That The System Remains Secure
On the surface, it would appear that if the system performs authentication and authorization properly, we have a secure system. We have effective controls to validate that users are who they say they are. We can grant them the appropriate access privileges so users can only access the data relevant to their role. However, organizations constantly evolve. People change roles. New people get hired and others leave. Therefore, the security settings described above experience constant updating. Just because they are compliant on day one doesn’t mean they are still complaint 3, 6, or 12 months later.
To be compliant with most regulations, an organization must constantly monitor their security configuration. A large and complex security configuration in MongoDB can have many collections, users, and roles. Performing a complete audit each time data or users change be extremely time consuming and expensive.
To make the process of ensuring ongoing regulatory compliance manageable, organizations require their database layer to provide an audit log. The audit log provides a history of all changes made to security settings. The security operations team can then monitor this log and immediately validate that changes to users and roles are regulatory compliant.
Sometimes, organizations will want an additional layer of security by auditing CRUD operations. Monitoring CRUD operations enables the security operation teams to see the type of data accessed by different user roles. For example, a security team may believe that the database allows billers to have read only access to the patient records, but an audit of the CRUD operations may show that in certain situations they can delete records as well. The team may use the log to identify holes in security settings.
MongoDB Enterprise audits both security changes and CRUD operations. MongoDB can monitor a long list of security configuration changes, including access permissions to databases and collections, access to DBA operations on databases and collections like index management, and operations team functions like the administration of replica sets and shards. MongoDB Enterprise also supports CRUD operation auditing. Complex filters can be specified to limit the amount of information written to the log and to ensure only the relevant events are audited.
Encryption - Ensuring That Data Cannot Be Accessed Outside The Database
Encryption ensures that a rogue user or application cannot access data by monitoring traffic between the application and the database or by reading files directly. SSL is widely used for encrypting data in transit between the database and the application. For preventing the direct reading of files, commonly called “data at rest,” a number of third parties provide widely adopted solutions including Vormetric and IBM Guardium. These solutions work by encrypting the database files on disk and ensuring that only the database application has access to the encryption key.
MongoDB supports both these encryption approaches. MongoDB Enterprise has also been certified to work with Vormetric and IBM Guardium.
Summary
If you want to consider using MongoDB for an application that must satisfy a privacy/security regulation like HIPAA or PCI, you should feel very comfortable doing so. MongoDB Enterprise provides the authentication, authorization, auditing, and encryption capabilities required to ensure that you application will be compliant. Download our Security Architecture Guide for additional requirements, features, and a security configuration checklist:
About Jay Runkel
Jay Runkel is a Solutions Architect Manager at MongoDB and has been working with Fortune 500 companies to architect enterprise solutions using NoSQL document databases for over five years. Before MongoDB, Runkel was a Principal Technologist at MarkLogic where he worked with Financial Service, Medical, and Media organizations to develop operational systems for analytics and custom publishing. Runkel has also recently been a Sales Engineering Manager at Venafi where he he assisted large financial institutions, retailers, health care and insurance organizations improve security by securing, protecting, and managing their encryption assets. Runkel has also held various positions developing automated underwriting, product information management, and CRM solutions. Runkel has a BS in Applied Mathematics from Carnegie Mellon and a Masters in Computer Science from the University of Michigan.