We’re excited to announce that we are opening nominations for membership in the MongoDB Masters. New members will be announced at the end of January.
What are MongoDB Masters?
The MongoDB Masters program is run by MongoDB to recognize and empower leaders in the MongoDB community. Masters serve as advocates, educators, and experts sharing their first-hand knowledge and experience.
What are the criteria for membership?
Because the MongoDB community is constantly changing, there is no set formula for becoming a MongoDB Master. At a high level, members are recognized as influencers who regularly engage with the community.
We also look at the group as a whole. We want the Masters to represent a diverse range of perspectives: developers and operators, code contributors and evangelists, startups and enterprises, side projects and mission critical apps -- all across the spectrum of race, gender, age, and nationality.
Masters display expertise by actively engaging in some or all of the following activities:
- Operating MongoDB in production
- - Run a large MongoDB deployment
- - Manage a number of MongoDB deployments
- - Examples: Charity Majors, Production Engineering Manager at Parse, who shared her experiences in a keynote at MongoDB World or Jai Hirsch, Senior Systems Architect at CARFAX
- Contributing to open source projects using MongoDB
- - Maintain a third party MongoDB project or a popular open source project that uses MongoDB
- - Contribute directly to the MongoDB drivers, documentation, or server projects, either those maintained by MongoDB Inc or third party
- - Example: Gustavo Niemeyer, author of the Go driver for MongoDB
- Supporting MongoDB users
- - Contribute answers on MongoDB-user or MongoDB questions on StackExchange
- - Provide mentorship to technical staff at a company new to using MongoDB
- - Example: Nuri Halperin, recipient of the Zola Award
- Teaching MongoDB
- - Speak regularly about MongoDB at conferences or local user groups
- - Write educational blog posts, tutorials, books or articles published on the MongoDB blog or a 3rd party blog included on Planet MongoDB
- - Support a local MongoDB community through a user group or similar organizational leadership activity
- - Teach online or university courses on MongoDB
- - Example: Russell Smith, organizer of the San Francisco MongoDB User Group
How are Masters selected?
Masters are nominated by members of the community. To nominate MongoDB Masters, submit your suggestions via the online form.
Masters are re-evaluated each January to ensure the program includes active community contributors. Should a Master not be accepted to the program for a subsequent year, they will be moved to “emeritus” status and will be unable to claim the benefits outlined below.
What are the benefits of membership to the Masters?
MongoDB Masters program benefits include:
- Quarterly Q&A with MongoDB engineering and product management
- Invitation to the annual MongoDB Masters Summit
- Early access to MongoDB products & services
- Profiles displayed on MongoDB.org
- Networking with other MongoDB Masters
- Discounted enrollment in online certification
- Access to on-demand training courses
- Masters designation in the online forums (mongodb-user group)
- Swag :)
We look forward to your nominations!
Community participation provides us with the feedback required to make our product better, for users to share experiences, and for the expansion of knowledge and expertise around MongoDB. We’re looking forward to seeing your nominations and for announcing the next Masters!
Making HIPAA Compliant Applications with MongoDB
Editors note: the content in this blog was revised to include new features available in MongoDB 3.2 . Introduction to Security Compliance As a Solution Architect at MongoDB, I am often asked a large number of questions by organizations considering using MongoDB as the database layer for an application managing data covered by privacy regulations such as HIPAA, SOX, or PCI. Medical and insurance providers, financial service organizations, and retailers most often ask these types of questions. While I am not an expert on any of these regulations, I have a fair amount of experience answering the questions pertinent to the database layer of such applications. MongoDB users in a number of industries run applications that must comply with regulations that typically exist to protect sensitive information about individuals: Health insurance organizations want to create a “single view” of the patient that aggregates all records, claims, and billing information into a single view. Retailers want to aggregate customer purchase, payment, and invoices across multiple channels. Financial service organizations wish to manage centrally all customer financial information. In all cases, various government regulations specify how to control and secure access to customer information. Regulations apply to the entire application stack. One must configure all the layers in tandem to provide the appropriate level of data security. MongoDB by itself does not pose an issue regarding HIPAA or SOX compliance. Properly configured, you can use MongoDB to provide the persistence layer of an application that complies with these regulations. When organizations design the database layer of an application that must protect customer data and comply with the previously mentioned regulations, they typically require that their database layer meet the following requirements: Authentication - The database must securely authenticate users who will have access to data. Most often the organization’s existing directory servers, such as Active Directory, LDAP, or Kerberos control user access. Authorization - The database must control access to customer information by assigning roles and privileges to users. For example, an insurance provider that manages insurance policies for a large number of companies must insure that each company’s administrators only have access to their employee’s data and not data for other companies employees. Auditing - The database must provide auditing so that one may identify immediately any changes made to #2 and validate to ensure that changed user roles or privileges remain in compliance with their policies and governing regulations. Encryption - The database must encrypt data. This includes data at rest in the file system, data moving from the application layer to the database layer or among database components. Encryption ensures that some malicious actor cannot bypass the database controls and access information directly. In the remainder of this blog post, we will examine how MongoDB Enterprise addresses these requirements. MongoDB Enterprise MongoDB is available in two editions: MongoDB and MongoDB Enterprise , a commercial edition of the database. MongoDB provides all the core developer productivity, high-availability, and scalability features that we all love about MongoDB. While the manual provides a security checklist for ensuring your MongoDB deployment is secure, there are additional measures that many users wish to take in the areas of authentication, authorization, and auditing that are not included with MongoDB. MongoDB Enterprise expands the security capabilities of MongoDB with features we will discuss in this blog post. Authentication - Establishing User Identity Authentication ensures the identity of the users accessing the database. It ensures that only designated users have access to the database. Most organizations concerned about regulatory compliance insist on integrating the database authentication with their organization-wide identity management system (e.g., Active Directory). This system enables user access to be defined (or revoked) in a central repository and immediately enforced across all systems, including MongoDB. MongoDB Enterprise provides support for a number of authentication protocols enabling MongoDB to integrate with identity management systems. MongoDB provides support for LDAP, Kerberos and Active Directory. Active Directory integration is achieved via Kerberos. Company security infrastructure and certificate authorities can authenticate users via x.509 client certificates. Authorization - Controlling Access to Sensitive Data Once a system has confirmed that the person (or application) has established user identity, next they must determine what data to which they should have access and what actions that user is permitted to perform. From a compliance perspective, the system must provide the appropriate controls so each user only has access to the data to which they are supposed to have access. Sometimes the system authenticates at the user level. For example, John Smith has access only to his medical records. More often authentication happens at the role level. For example, all doctors have the ability to modify patient records, but associates in the billing department may only review those records. Fortunately, MongoDB’s security model makes this type of security configuration straightforward. MongoDB provides a library of fine-grained privileges that then can be combined to define a user role. MongoDB then assigns roles to users. A user can perform any of the operations and access the data as defined by the union of the privileges associated with their roles. For example, in our patient record management example above the following roles may be defined: Auditing - Ensuring That The System Remains Secure On the surface, it would appear that if the system performs authentication and authorization properly, we have a secure system. We have effective controls to validate that users are who they say they are. We can grant them the appropriate access privileges so users can only access the data relevant to their role. However, organizations constantly evolve. People change roles. New people get hired and others leave. Therefore, the security settings described above experience constant updating. Just because they are compliant on day one doesn’t mean they are still complaint 3, 6, or 12 months later. To be compliant with most regulations, an organization must constantly monitor their security configuration. A large and complex security configuration in MongoDB can have many collections, users, and roles. Performing a complete audit each time data or users change be extremely time consuming and expensive. To make the process of ensuring ongoing regulatory compliance manageable, organizations require their database layer to provide an audit log. The audit log provides a history of all changes made to security settings. The security operations team can then monitor this log and immediately validate that changes to users and roles are regulatory compliant. Sometimes, organizations will want an additional layer of security by auditing CRUD operations. Monitoring CRUD operations enables the security operation teams to see the type of data accessed by different user roles. For example, a security team may believe that the database allows billers to have read only access to the patient records, but an audit of the CRUD operations may show that in certain situations they can delete records as well. The team may use the log to identify holes in security settings. MongoDB Enterprise audits both security changes and CRUD operations. MongoDB can monitor a long list of security configuration changes, including access permissions to databases and collections, access to DBA operations on databases and collections like index management, and operations team functions like the administration of replica sets and shards. MongoDB Enterprise also supports CRUD operation auditing. Complex filters can be specified to limit the amount of information written to the log and to ensure only the relevant events are audited. Encryption - Ensuring That Data Cannot Be Accessed Outside The Database Encryption ensures that a rogue user or application cannot access data by monitoring traffic between the application and the database or by reading files directly. SSL is widely used for encrypting data in transit between the database and the application. Database-native and third-party encryption solutions may also be used to prevent the direct reading of database files, commonly called “data at rest.” Any encryption solution is only effective if the encryption keys are securely managed. Securely managing keys typically involves deploying a central key management application that manages the process of tracking, securing, and rotating keys. MongoDB supports all of these encryption approaches. MongoDB Enterprise provides built in support for SSL and, with the release of MongoDB 3.2, MongoDB Enterprise provides encryption at rest via its Encrypted Storage engine (the WiredTiger storage engine with encryption enabled). To enhance security and to simplify key management, MongoDB Enterprise supports the KMIP protocol, the protocol used by most key management platforms to application encryption administer keys. Finally, MongoDB Enterprise continues to work with encryption at rest solutions from Vormetric and IBM Guardium. Summary If you want to consider using MongoDB for an application that must satisfy a privacy/security regulation like HIPAA or PCI, you should feel very comfortable doing so. MongoDB Enterprise provides the authentication, authorization, auditing, and encryption capabilities required to ensure that you application will be compliant. Read our Security Architecture Guide for additional requirements, features, and a security configuration checklist: Read the Security Guide About Jay Runkel Jay Runkel is a Solutions Architect Manager at MongoDB and has been working with Fortune 500 companies to architect enterprise solutions using NoSQL document databases for seven years. Before MongoDB, Runkel was a Principal Technologist at MarkLogic where he worked with Financial Service, Medical, and Media organizations to develop operational systems for analytics and custom publishing. Runkel has also recently been a Sales Engineering Manager at Venafi where he he assisted large financial institutions, retailers, health care and insurance organizations improve security by securing, protecting, and managing their encryption assets. Runkel has also held various positions developing automated underwriting, product information management, and CRM solutions. Runkel has a BS in Applied Mathematics from Carnegie Mellon and a Masters in Computer Science from the University of Michigan.
Take Advantage of Low-Latency Innovation with MongoDB Atlas, Realm, and AWS Wavelength