Securing MongoDB Part 1: Data Security Requirements for Regulatory Compliance

The frequency and severity of data breaches continues to escalate year on year:

• Research from PWC identified over 117,000 attacks against information systems every day in 2014. That’s an increase of 48% over the previous year.
• Companies reporting losses from security breaches totaling $20m or more doubled over the same period.
• Updated industry regulations will increase penalties on those organizations proven to have not taken sufficient measures to protect their customers’ data against unauthorized disclosure.

It's no surprise that with databases storing an organization’s most important information assets, securing them is top of mind for the business.

In this 4-part blog series, we will present the best practices and controls available in MongoDB to help you create a secure, compliant database platform:

• In this first installment, we’ll take a look at the general requirements for data security and regulatory compliance
• In the 2nd part, we’ll cover enforcing access control to MongoDB
• In part 3, we’ll discuss auditing and encryption
• In the final installment, we’ll highlight environmental control and management

If you want to get a head-start and learn about all of these topics now, just go ahead and download the MongoDB Security Architecture guide.

Requirements for Database Security & Compliance

In light of increasing threats over the past decade coupled with heightened concern for individual privacy, industries and governments around the world have embarked on a series of initiatives designed to increase security, reduce fraud, and protect personally identifiable information (PII), including:

• PCI DSS for managing cardholder information
• HIPAA standards for managing healthcare information
• NIST 80-53 catalogs security controls for all U.S. federal information systems except those related to national security
• STIG for secure installation and maintenance of computer systems, defined for the US Department of Defense
• European Union Data Protection Directive
• Asia Pacific Economic Cooperation (APEC) data protection standardization

In addition to these initiatives, new regulations are being developed every year to cope with emerging threats and new demands for tighter controls governing data use.

Each set of regulations defines security and auditing requirements that are unique to a specific industry or application. Compliance is assessed on a per-project basis, evaluating people and processes alongside technology.

Despite the differences between each compliance standard, there are common foundational requirements across all of the directives, including:

• Restricting access to data, enforced via predefined privileges and security levels
• Measures to protect against the accidental or malicious disclosure, loss, destruction or damage of sensitive data
• The separation of duties when running applications and accessing data
• Recording the activities of users, administrative staff, and applications in accessing and processing data

These requirements inform the security architecture of MongoDB, with best practices for the implementation of a secure, compliant data management environment.

A holistic security architecture must cover:

• User access management to restrict access to sensitive data, implemented through authentication and authorization controls
• Logging operations against the database in an audit trail for forensic analysis
• Data protection via encryption of data in-motion over the network and at-rest in persistent storage
• Environmental and process controls

The requirements for each of these elements are discussed below. 

 ^{Figure 1: MongoDB End to End Security Architecture}

User Access Management - Authentication

Authentication is designed to confirm the identity of entities accessing the database. In this context, entities are defined as:

• Users who need access to the database as part of their day-to-day business function
• Administrators (i.e. sysadmins, DBAs, QA staff) and developers
• Software systems including application servers, reporting tools, and management and backup suites
• Physical and logical nodes that the database runs on. Databases can be distributed across multiple nodes both for scaling operations and to ensure continuous operation in the event of systems failure or maintenance.

Best practices for authentication are as follows.

• Create Security Credentials. Create login credentials for each entity that will need access to the database, and avoid creating a single “admin” login that every user shares.

By creating credentials it becomes easier to define, manage, and track system access for each user. Should a user’s credentials become compromised, this approach makes it easier to revoke the user without disrupting other users who need access to the database.

Developers, Administrators, and DBAs should all have unique credentials to access the database. When logins are shared it can be impossible to identify who attempted different operations, and it eliminates the ability to assign fine-grained permissions. With unique logins, staff that move off of the project or leave the organization can have their access revoked without affecting other user accounts.

Authentication should be enforced between nodes. This prevents unauthorized instances from joining a database cluster, preventing the illicit copying or movement of data to insecure nodes.

• Supporting In-Database and Centralized User Access Management. Databases should provide the ability to manage user authentication either within the database itself, typically via a Challenge/Response mechanism, or through integration with organization-wide identity management systems. Integrating MongoDB within the existing information security infrastructure enforces centralized and standardized control over user access. If, for example, a user’s access must be revoked, the update can be made in a single repository and enforced instantly across all systems, including MongoDB.

User Rights Management - Authorization

Once an entity has been authenticated, authorization governs what that entity is entitled to do in the database. Privileges are assigned to user roles that define a specific set of actions that can be performed against the database. Best practices include:

• Grant Minimal Access to Entities. Entities should be provided with the minimal database access they need to perform their function. If an application requires access to a logical database, it should be restricted to operations on that database alone, and prevented from accessing other logical databases. This helps protect against both malicious and accidental access or unauthorized modification of data.
• Group Common Access Privileges into Roles. Entities can often be grouped into “roles” such as “DBA”, “Sysadmin”, and “App server.” Permissions for a role can be centrally managed and users can be added or removed from roles as needed. Using roles helps simplify management of access control by defining a single set of rules that apply to specific classes of entities, rather than having to define them individually for each user.
• Control Which Actions an Entity Can Perform. When granting access to a database, consideration should be made for which specific actions or commands each entity should have permission to run. For example, an application may need read/write permissions to the database, whereas a reporting tool may be restricted to read-only permission. Some users may be granted privileges that enable them to insert new data to the database, but not to update or delete existing data.

Care should be taken to ensure that only the minimal set of privileges is provided. Credentials of the most privileged accounts could compromise the entire database if they are hacked internally or by an external intruder.

• Control Access to Sensitive Data. To prevent the emergence of data silos, it should be possible to restrict permissions to individual fields, based on security privileges. For example, some fields of a record may be accessible to all users of the database, while others containing sensitive information, such as PII, should be restricted to users with specific security clearance.

Auditing

By creating audit trails, changes to database configuration and data can be captured for each entity accessing the database, providing a log for compliance and forensic analysis. Auditing can also detect attempts to access unauthorized data.

Encryption

Encryption is the encoding of critical data whenever it is in transit or at rest, enabling only authorized entities to read it. Data will be protected in the event that eavesdroppers or hackers gain access to the server, network or database.

• Encrypt Connections to the Database. All user or application access to the database should be via encrypted channels including connections established through the drivers, command line or shell, as well as remote access sessions to the database servers themselves. Internal communications between database nodes should also be encrypted, i.e. traffic replicated between nodes of a database cluster.
• Encrypt Data at Rest. One of most common threats to security comes from attacks that bypass the database itself and target the underlying Operating System and physical storage of production servers or backup devices, in order to access raw data. On-disk encryption of the database’s data files mitigates this threat.
• Sign and Rotate Encryption Keys. Encryption keys for network and disk encryption should be periodically rotated. SSL/TLS encryption channels should use signed certificates to ensure that clients can certify the credentials they receive from server components.
• Enforce Strong Encryption. The database should support FIPS (Federal Information Processing Standard) 140-2 to ensure the implementation of secure encryption algorithms.

Environmental and Process Control

The environment in which the database and underlying infrastructure is running should be protected with both physical and logical controls. These are enforced in the underlying deployment environment, rather than in the database itself, and include:

• Installation of firewalls
• Network configurations
• Defining file system permissions
• Creation of physical access controls to the IT environment

As manual configuration errors are one of the largest causes of attackers bypassing security mechanisms, there are a series of operational processes that should be adopted to further promote and enforce secure operation, including:

• DBA and developer training
• Database provisioning, monitoring and backup
• Database maintenance, i.e. applying the latest patches

Getting Started With MongoDB Security

With comprehensive controls for user rights management, auditing and encryption, coupled with management controls, MongoDB can meet the best practice and requirements discussed earlier. MongoDB Enterprise Advanced is the certified and supported production release of MongoDB, with advanced security features, including Kerberos and LDAP authentication, encryption of data at-rest, FIPS-compliance, and maintenance of audit logs. These capabilities extend MongoDB’s security framework, which includes Role-Based Access Control, PKI certificates, Field-Level Redaction, and SSL/TLS data transport encryption.

You can learn about all of these capabilities now by downloading the MongoDB Security Architecture guide. If you want to try them for yourself, download MongoDB Enterprise, free of charge for evaluation and development.

In the second part of this blog post series, we will dive into MongoDB access control.

Learn more about MongoDB security features, read our guide.