- Security >
- Security Introduction
Maintaining a secure MongoDB deployment requires administrators to implement controls to ensure that users and applications have access to only the data that they require. MongoDB provides features that allow administrators to implement these controls and restrictions for any MongoDB deployment.
If you are already familiar with security and MongoDB security practices, consider the Security Checklist for a collection of recommended actions to protect a MongoDB deployment.
Before gaining access to a system all clients should identify themselves to MongoDB. This ensures that no client can access the data stored in MongoDB without being explicitly allowed.
MongoDB supports a number of authentication mechanisms that clients can use to verify their identity. MongoDB supports two mechanisms: a password-based challenge and response protocol and x.509 certificates. Additionally, MongoDB Enterprise also provides support for LDAP proxy authentication and Kerberos authentication.
See Authentication for more information.
Role Based Access Control¶
Access control, i.e. authorization, determines a user’s access to resources and operations. Clients should only be able to perform the operations required to fulfill their approved functions. This is the “principle of least privilege” and limits the potential risk of a compromised application.
MongoDB’s role-based access control system allows administrators to control all access and ensure that all granted access applies as narrowly as possible. MongoDB does not enable authorization by default. When you enable authorization, MongoDB will require authentication for all connections.
When authorization is enabled, MongoDB controls a user’s access through the roles assigned to the user. A role consists of a set of privileges, where a privilege consists of actions, or a set of operations, and a resource upon which the actions are allowed.
Users may have one or more role that describes their access. MongoDB provides several built-in roles and users can construct specific roles tailored to clients’ actual requirements.
See Authorization for more information.
Auditing provides administrators with the ability to verify that the implemented security policies are controlling activity in the system. Retaining audit information ensures that administrators have enough information to perform forensic investigations and comply with regulations and polices that require audit data.
See Auditing for more information.
You can use SSL to encrypt all of MongoDB’s network traffic. SSL ensures that MongoDB network traffic is only readable by the intended client.
See Configure mongod and mongos for SSL for more information.
Encryption at Rest¶
There are two broad classes of approaches to encrypting data at rest with MongoDB. You can use these solutions together or independently:
Application Level Encryption¶
Provide encryption on a per-field or per-document basis within the application layer. To encrypt document or field level data, write custom encryption and decryption routines or use a commercial solutions such as the Vormetric Data Security Platform.
Encrypt all MongoDB data on the storage or operating system to ensure that only authorized processes can access protected data. A number of third-party libraries can integrate with the operating system to provide transparent disk-level encryption. For example:
- Linux Unified Key Setup (LUKS)
- LUKS is available for most Linux distributions. For configuration explanation, see the LUKS documentation from Red Hat.
- IBM Guardium Data Encryption
- IBM Guardium Data Encryption provides support for disk-level encryption for Linux and Windows operating systems.
- Vormetric Data Security Platform
- The Vormetric Data Security Platform provides disk and file-level encryption in addition to application level encryption.
- Bitlocker Drive Encryption
- Bitlocker Drive Encryption is a feature available on Windows Server 2008 and 2012 that provides disk encryption.
Properly configured disk encryption, when used alongside good security policies that protect relevant accounts, passwords, and encryption keys, can help ensure compliance with standards, including HIPAA, PCI-DSS, and FERPA.
Hardening Deployments and Environments¶
In addition to implementing controls within MongoDB, you should also place controls around MongoDB to reduce the risk exposure of the entire MongoDB system. This is a defense in depth strategy.
Hardening MongoDB extends the ideas of least privilege, auditing, and encryption outside of MongoDB. Reducing risk includes: configuring the network rules to ensure that only trusted hosts have access to MongoDB, and that the MongoDB processes only have access to the parts of the filesystem required for operation.