MongoDB Documentation, Release 3.0.4 implement these controls and restrictions for any MongoDB deployment. If you are already familiar with security and MongoDB security practices, consider the Security Checklist (page 431) 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 (page 321) that clients can use to verify their identity. MongoDB supports two mechanisms: a password-based challenge and response protocol and x.509 certificates. Ad- ditionally, MongoDB Enterprise 1 also provides support for LDAP proxy authentication (page 323) and Kerberos au- thentication (page 322). See Authentication (page 320) for more information. Access control, i.e. authorization (page 324), 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 autho- rization (page 324), 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 (page 405) and users can construct specific roles tailored to clients’ actual requirements. See Authorization (page 324) for more information. Auditing provides administrators with the ability to verify that the implemented security policies are controlling activ- ity 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 (page 330) for more information. You can use TLS/SSL (Transport Layer Security/Secure Sockets Layer) to encrypt all of MongoDB’s network traffic. TLS/SSL ensures that MongoDB network traffic is only readable by the intended client. See Configure mongod and mongos for TLS/SSL (page 342) for more information. $^{1}$http://www.mongodb.com/products/mongodb-enterprise?jmp=docs Chapter 6. Security 318 6.1.4 Encryption Transport Encryption 6.1.3 Auditing 6.1.2 Role Based Access Control 6.1.1 Authentication