时间：2021-07-01 10:21:17 帮助过：17人阅读
By Andreas Nilsson, Lead Security Engineer at MongoDB With increased regulatory compliance, heightened concerns around privacy and growing risk from hackers and organized crime, the need to secure access to data has never been more urgent.
By Andreas Nilsson, Lead Security Engineer at MongoDB
With increased regulatory compliance, heightened concerns around privacy and growing risk from hackers and organized crime, the need to secure access to data has never been more urgent.
MongoDB 2.6 provides a number of features to facilitate building secure applications, such as auditing and authentication with Kerberos and LDAP. MongoDB now features a more competent and complete role-based access control system, x.509 authentication, an improved SSL stack and revamped security documentation.
In a short series of blog posts I will attempt to explain the philosophy and design of the security model of MongoDB. The first post covers the basics of securing a MongoDB server and application and gives an overview of the options available. The second post lists the most common security mistakes when configuring MongoDB. The final post is a deep dive into the authentication and authorization subsystems, specifically covering sharded systems with multiple databases and how to use the new Role-Based Access Control system.
For details of the MongoDB security architecture and a complete list of features, please refer to the MongoDB Security Architecture Whitepaper.
Before going into details let’s start with the basics. A database security model needs to offer a basic set of features:
These security requirements can be achieved in different ways. A disconnected database server in a locked room would constitute a secure deployment regardless of how the database was being protected. However, it would not be very useful. A database is often placed unprotected on a “secured”, internal network. This is an idealized scenario since no network is entirely secure, architecture changes over time, and a considerable number of successful breaches are from internal sources. A defense-in-depth approach is therefore recommended when implementing your application’s infrastructure. While MongoDB’s newest security features help to improve your overall security posture, security is only as strong as the weakest link in the chain.
A conceptual view of the MongoDB security architecture is represented in the image below. The security model is divided into the four pillars of authentication, authorization, auditing and encryption.
In the discussion below we will assume a simple web application which reads from and writes to a replicated database. Each of the steps below is described in detail in the documentation. The steps are described in greater detail in the MongoDB Security Checklist. The focus is primarily on enabling access control and transport encryption.
Design the application to work in a multilayer fashion, and place the database server(s) on a dedicated network segment, isolated from the DMZ where the web application resides. Configure firewall rules to limit network access to the database server. Lock down MongoDB user and file permissions. The database files should be protected from unauthorized access and the mongod/mongos daemons should be running with minimum privileges, specifically not as root.
By default there are no users configured in MongoDB. In order to enable access control users needs to be created and assigned appropriate privileges. Access control is enabled using the command line —auth or —keyfile flags. When access control is enabled, clients and drivers are required to authenticate to the server, and servers are required to authenticate to each other.
The following is the recommended series of steps to enable access control.
Design Determine which type of authentication methods to use for client authentication. The options are challenge-response based username/password (MONGODB-CR), x.509, LDAP and Kerberos. Determine which type of authentication method to use for server-server cluster authentication. The options are username/password and x.509. Please note that x.509 requires the use of SSL. List the different user types that will exist in the system; administrators, support staff, different type of application users etc. For each of the user types, determine which built-in roles are required. Optionally create customized roles tailored for your deployment.
Deployment Configure a keyfile or x.509 certificates for the cluster nodes. Start the mongod servers with the —auth flag set and appropriate cluster authentication options as determined in 3. Start mongos servers with appropriate cluster authentication options. Create the desired users with correct permissions. Please note that after creating the first user access control is enabled. Therefore, at a minimum the first user should have the userAdminAnyDatabase or root roles in order to be able to create other users.
In order to protect the network traffic, SSL should be enabled between clients and the server and in between servers. Enabling SSL is well described in the security documentation http://docs.mongodb.org/master//tutorial/configure-ssl/
MongoDB supports the use of any server SSL certificate as long as the corresponding root CA certificate is provided with the configuration parameter —sslCAFile. If no CA certificate is specified, no certificate validation is performed and the certificate is only used for encryption purposes. Although supported, use of self-signed certificates is not recommended, since there is no basis for trust, and hence no certificate validation can be performed.
There are several different ways to configure SSL with MongoDB. Mutual Validation In MongoDB 2.4 the recommended configuration was to issue SSL server certificates to the server, and to the clients connecting to enable mutual validation. The server certificate is validated against the CA certificate file provided on the client side, and the client certificates are validated against the CA certificate provided on the server side. However no authentication is performed.
In order to allow clients to connect without a certificate, the server can be started with the command line flag —sslWeakCertificateValidation.
Mutual validation is still supported but in MongoDB 2.6 several new SSL options are included. X.509 Authentication If SSL is enabled clients can use the new authentication mechanism MONGODB-X509 to authenticate using x.509 certificates.
It is also possible to use x.509 authentication between the servers in a cluster. From a security perspective this is a great improvement to the default keyfile solution.
Mixed mode SSL MongoDB 2.6 introduces the option of mixing encrypted and non-encrypted connections. That is, the server will listen for and detect both SSL and non-SSL inbound connections.
This feature enables cluster members running SSL to talk to non-SSL nodes and vice versa. It also enables a rolling configuration “upgrade” from a non-SSL to an SSL cluster without downtime.
The mixed mode behavior is controlled by the —sslMode parameter. From a security hardening perspective SSL mixed mode should be turned off, unless explicitly needed for one of the two scenarios discussed above.
Disable sensitive interfaces and functionality that is not needed.
MongoDB supports the execution of JavaScript code for certain server-side operations: mapReduce, group, eval, and $where. If you do not use these operations, disable server-side scripting by setting —noscripting to true.
Use only the MongoDB wire protocol on production deployments. The following interfaces are disabled by default in MongoDB 2.6: —httpinterface, —jsonp, and —rest. Leave these disabled, unless required for backwards compatibility. If using MongoDB 2.4 disable the HTTP interface using —nohttpinterface.
The bind_ip setting for mongod and mongos instances limits the network interfaces on which MongoDB programs will listen for incoming connections. Configure the server only to bind on desired interfaces.
MongoDB Enterprise logs all administrative actions made against the database. Schema operations (such as creating or dropping databases, collections and indexes), replica set reconfiguration events along with authentication and authorization activities are all captured, along with the administrator’s identity and timestamp of the operation, enabling compliance and security analysis.
By default, MongoDB auditing logs all administrative actions, but can also be configured with filters to capture only specific events. The audit log can be written to multiple destinations in a variety of formats including to the console and syslog (in JSON format), and to a file (JSON or BSON), which can then be loaded to MongoDB and analyzed to find relevant events.
MongoDB Maintains an Audit Trail of Administrative Actions Against the Database
Each MongoDB server logs events to its local destination. The DBA can then merge these into a single log, enabling a cluster-wide view of operations that affected multiple nodes.
The MongoDB auditing documentation includes information on how to configure auditing and all of the operations that can be captured.
Securing the database layer of an application is a necessary step to protect the data from unauthorized access. MongoDB offers a flexible and competent security model but as with all security solutions, care should be take to enable and configure the system correctly.
In part 2, we will closely examine some common configuration mistakes and security pitfalls based on a number of existing MongoDB deployments and users.
MongoDB subscriptions provide access to additional enterprise grade capabilities. The subscription includes all the ease-of-use, broad driver support and scalability features of MongoDB, while addressing the more demanding security and certification requirements of corporate and government information security environments. To see more, download the development version of the MongoDB Enterprise edition here
原文地址：MongoDB Security Part 1 - Design and Configuration, 感谢原作者分享。