June 28-29, 2016
New York, NY
We asked you to share your giant ideas, and you listened. This year we’re excited to announce our first round of sessions.
A few topics our engineers will present on are:
- Debugging MongoDB Performance in 3.2
- Big Data with MongoDB & Spark
- Financial Transaction Management and Analysis
- Using the Cloud Manager / Ops Manager API to Scale MongoDB With Your Application
MongoDB community members and customers will share their stories, including:
- Data Analysis and Visualization with MongoDB
- Containerizing MongoDB with Kubernetes
- Creating a Single View of the Customer
- From Story to Document: Modeling Common Business Problems with MongoDB
View our list of sessions stretching across a wide range of topics list below. New talks are added every week, so keep checking back!
Need more reasons to come? At MongoDB World 2016 in New York City, you’ll experience first-hand how the world’s fastest-growing database is powering today’s innovations and can help you gain a competitive advantage. Learn how large enterprises have delivered new applications to market at the speed of a lean startup, and how startups scale and execute on their giant ideas like an enterprise.
Securing MongoDB Part 2: Database Access Control
Welcome back to our 4-part blog series presenting the best practices and controls available in MongoDB to help you create a secure, compliant database platform. In this installment, we’ll be discussing database access control – covering both authentication and authorization. In part 1 , we took a look at the general requirements for data security and regulatory compliance. Looking ahead, in part 3 we’ll cover auditing and encryption. And in part 4 , we’ll wrap up with environmental control and management. If you want to get a head-start and learn about all of these topics in one installment, just go ahead and download the MongoDB Security Architecture guide . Enable Access Control and Enforce Authentication The first step in securing your MongoDB database is to enable access control. As new apps and services are in development, it is typical that access control is not enforced. But once these applications are ready for test and QA, then it is important to specifically enable it, thus requiring all clients and servers provide valid credentials before they can connect to the database. This ensures that you are not deploying exposed instances when you launch your app into production. Refer to the documentation for a tutorial stepping through how to configure authentication . Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available. See the Security Hardening section of the documentation to learn more about reducing the risk of exposure. MongoDB Authentication The authentication of entities accessing MongoDB can be managed from within the database itself, or via integration with an external mechanism (i.e. LDAP, x.509 PKI certificates, or a Kerberos service). MongoDB Enterprise Advanced , the certified and supported production release of MongoDB is required when using LDAP or Kerberos. In Database Authentication MongoDB authenticates entities on a per-database level using the SCRAM-SHA-1 IETF standard. Users are authenticated via the authentication command, while database nodes can be authenticated to the MongoDB cluster via keyfiles. Review the authentication documentation to learn more. MongoDB Atlas Authentication MongoDB Atlas is a database as a service for MongoDB, providing all of the features of the database, without the operational heavy lifting required for any application. MongoDB Atlas has been engineered to deliver robust access controls. Authentication is enforced for all MongoDB Atlas clients via the SCRAM-SHA-1 mechanism. User and administrator roles can be defined to ensure a separation of duties between different entities accessing the database and the MongoDB Atlas service. Clients are prevented from accessing the database unless their IP address has been added to the IP whitelist for your MongoDB Atlas group. Review the MongoDB Atlas documentation for more information on configuring the in-built security controls. LDAP Authentication LDAP is widely used by many organizations to standardize and simplify the way large numbers of users are managed across internal systems and applications. In many cases, LDAP is also used as the centralized authority for user access control to ensure that internal security policies are compliant with corporate and regulatory guidelines. With LDAP integration, MongoDB can authenticate users directly against corporate LDAP infrastructure to enforce centralised access policies. Note that MongoDB currently supports LDAP authentication, and not authorization. See the following section of this post to learn more about the authorization controls available in MongoDB. Administrators can configure MongoDB to authenticate users via Linux PAM or by proxying authentication requests to a specified LDAP service. A tutorial on configuring LDAP authentication is available in documentation. Kerberos Authentication With MongoDB Enterprise Advanced, authentication using a Kerberos service is supported. Kerberos is an industry standard authentication protocol for large client/server systems, allowing both the client and server to verify each others' identity. With Kerberos support, MongoDB can take advantage of existing authentication infrastructure and processes, including Microsoft Windows Active Directory. As with LDAP and x.509 certificates, before users can authenticate to MongoDB using Kerberos, they must first be created and granted privileges within MongoDB. The process for doing this, along with a full configuration checklist is described in the MongoDB and Kerberos tutorial . x.509 Certificate Authentication With support for x.509 certificates MongoDB can be integrated with existing information security infrastructure and certificate authorities, supporting both user and inter-node authentication. Users can be authenticated to MongoDB using client certificates rather than self-maintained passwords. Inter-cluster authentication and communication between MongoDB nodes can be secured with x.509 member certificates rather than keyfiles, ensuring stricter membership controls with less administrative overhead, i.e. by eliminating the shared password used by keyfiles. x.509 certificates can be used by nodes to verify their membership of MongoDB replica sets and sharded clusters. A single Certificate Authority (CA) should issue all the x.509 certificates for the members of a sharded cluster or a replica set. Instructions for configuration are described in the MongoDB and x.509 certificates tutorial . MongoDB and Microsoft Active Directory MongoDB Enterprise Advanced provides support for authentication using Microsoft Active Directory with both Kerberos and LDAP. The Active Directory domain controller authenticates the MongoDB users and servers running in a Windows network. MongoDB Authorization MongoDB allows administrators to define the specific permissions an application or user has, and what data they can see when querying the database. User Defined Roles MongoDB provides over ten built-in roles supporting different user and administrator privileges. These can be customised through User Defined Roles, enabling administrators to assign fine-grained privileges to users or applications. Authorization privileges can be based on the specific functionality a user needs in their role, or to reflect their organizational structure. MongoDB provides the ability to specify user privileges with both database and collection-level granularity. **Figure 1**: MongoDB User Defined Roles Permit Separations of Duty Privileges are assigned to roles, and roles are in turn assigned to users. For example: Classes of users and applications can be assigned privileges to insert data, but not to update or delete data from the database DBAs may be assigned privileges that enable them to create collections and indexes on the database, while developers are restricted to CRUD operations Certain administrator roles may have cluster-wide privileges to build replica sets and configure sharding, while others are restricted to creating new users or inspecting logs Processes for monitoring MongoDB clusters can be restricted to run just those commands that retrieve server status, without having full administrative access to perform database operations Within a multi-tenant environment, “landlord” developers and administrators can be assigned permissions across physical databases, while “tenant” developers and administrators can be granted a more limited set of actions across logical databases or individual collections. This functionality enables a clear separation of duties and control, both between and within organizations. To ensure ease of account provisioning and maintenance, roles can be delegated across teams, ensuring the enforcement of consistent policies across specific functions within the organization. Review the Authorization section of the documentation to learn more about roles in MongoDB. When combined with the auditing capabilities available with MongoDB Enterprise Advanced, customers can define specific administrative actions per role, and then log all of those actions. As a result, the organization is able to enforce end-to-end operational control and maintain insight of actions for compliance and reporting. MongoDB Field Level Redaction MongoDB’s field level redaction allows building access control to individual fields of document, working in conjunction with client-side code. Implemented via the redaction stage of MongoDB’s Aggregation Pipeline , developers are provided with a method to restrict the content of a returned document on a per-field level. Permissions can be based on both the content of the document and on specific user privileges, based on security labels. Access control policies can be described using the MongoDB query language, making it simple for developers to implement the required controls. Since data is redacted before it is returned to the application, exposure of sensitive information is reduced. Field level redaction is applicable to a wide range of sensitive data including personally identifiable information such as names, social security numbers, birthdates and bank account numbers. By co-locating data with different sensitivity levels within a single document, schema and query designs are simplified. **Figure 2**: MongoDB Field Level Redaction Restricts Access to Sensitive Data The redaction logic must be passed by the application to the database on each request. It therefore relies on trusted middleware running in the application to ensure the redaction pipeline stage is appended to any query that requires the redaction logic. 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 in this blog series. 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. In the third part of this blog post series, we will dive into MongoDB auditing and encryption. You can learn about all of these capabilities now by reading the MongoDB Security Architecture guide. If you want to try them for yourself, [download MongoDB Enterprise](https://www.mongodb.com/download-center?#enterprise), free of charge for evaluation and development. MongoDB security architecture About the Author - Mat Keep Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.
What’s New in Atlas Charts: Easy Organization-Wide Sharing
We’re excited to announce improvements to sharing dashboards in MongoDB Atlas Charts . Data visualization is a powerful tool for discovering insights, and sharing visualizations across your team helps amplify those insights to propel businesses forward. With organization-wide sharing in Atlas Charts, we’re making it even easier to share the insights you discover from your application data across your entire organization. Sharing dashboards Atlas Charts has always made it possible to share visualizations with either individual members or everyone inside your Atlas project. Assuming a user had access to a given data source in Atlas, adding a user to a Charts project was effectively a one-click process. However, many teams do not broadly share database access unless an individual specifically needs it. And, if you want to share data with many members of your team, provisioning users one by one is tedious. Once users are in a Charts project, however, sharing a dashboard with everyone inside the project becomes relatively easy — you can invite all users in your project to view your dashboard with a single action. There are probably scenarios in which some members of your organization have Atlas access and others do not. In this case, if your team has enabled Federated Authentication and uses a third-party authentication provider, such as Google or Okta, Charts now makes it simple to turn on sharing dashboards across your entire organization. Granting access This approach makes sharing company-wide information quick and easy. For example, you can keep employees aware of product or platform growth or other key business metrics. Any members of your organization can be granted access to view these dashboards with a single click, as shown in Figure 1. Figure 1: A look at a dashboard shared across an organization. Note that, with these changes to dashboard sharing, your ability to maintain the security of your data remains unchanged. New dashboard viewers still need at least viewer access to any data source behind the charts in a shared dashboard, thereby ensuring that your company's sensitive data remains private. Additionally, project owners can now manage data source access at a deployment level, which means they can give access to their clusters or federated database instances . This capability is in addition to the already available granular control of data source access at a collection level, which was introduced as part of recent improvements we made to data sources. You can read more about managing access to data sources in your organization in our documentation . We hope you find these sharing improvements valuable and start leveraging this capability to share additional insights across your organization. New to Atlas Charts? Get started today by logging into or signing up for MongoDB Atlas , deploying or selecting a cluster, and activating Charts for free.