dj-walker-morgan

2160 results

MongoDB and IONOS: Helping European Organizations in Regulated Industries Move to the Cloud

As MongoDB continues to grow as a company, we remain focused on understanding our customers’ unique needs based on their industry and region, among other factors. With this in mind, we are excited to partner with German cloud provider IONOS to help European organizations in regulated industries harness the power of their data to build first-rate applications that also align with security, compliance, and sovereignty requirements. "We want to offer our customers the opportunity to use best-in-class solutions,” said IONOS chief customer officer Martin Endreß about MongoDB becoming part of IONOS’s database-as-a-service offering. “With MongoDB, we are now integrating with the global leader in the NoSQL segment,” he said. “In addition, our companies share fundamental values such as a commitment to full data portability and a rejection of vendor lock-in." With more than 90K servers across 16 data centers, IONOS has a strong footprint in the public sector and other industries where cloud usage is constrained by compliance or data sovereignty needs. Now IONOS customers can drive application innovation in the cloud using MongoDB’s developer data platform while keeping control of their data, aligning with the strongest initiatives in digital sovereignty. The popularity and promise of cloud computing has led an ever-increasing number of businesses to shift their infrastructures and software, including databases, to managed services, and highly regulated industries are no different. Compliance, security, and innovation need not be at odds with each other. Working together, MongoDB and IONOS provide developers with a platform that lets them build, deploy, and run applications securely. MongoDB and IONOS are working closely to develop this new partnership — which is expected to be on offer in fall 2022 — and support customers during implementation. Both Enterprise Advanced and Community versions of MongoDB will be available with IONOS. Learn more about finding a MongoDB partner or becoming one.

August 18, 2022

How Trust and Collaboration Are Helping Intern Erin McNulty Take On New Challenges

Erin McNulty, a rising senior at Columbia University, is working as a software engineering intern in MongoDB’s New York City office. After interning at MongoDB during the summer of 2021, Erin returned this year to take on a new challenge on a new team — and a new programming language. Read on for more about Erin’s experience and how MongoDB’s engineering culture has enabled her to grow. Sammy Attia: Welcome back, Erin! I know this is your second summer internship at MongoDB. Can you share a bit about why you decided to join MongoDB in the first place and why you decided to come back? MongoDB intern Erin McNulty Erin McNulty: The first time I chose MongoDB, it was because throughout my interview process, I could tell that MongoDB really valued interns’ growth, so I felt like spending my summer here would be a really good investment. I knew that at MongoDB, I would have a meaningful project that truly helped me grow and would make an impact at the company. I also really enjoy the culture of the New York City technology scene, so I was really excited to receive an offer from a company that was created and headquartered in NYC. When I was deciding to come back to MongoDB the second time, I really prioritized working at a place that would let me explore different types of software engineering because I wanted to make the switch from web programming to systems programming. I knew that MongoDB’s supportive, learning-oriented environment would allow me to take that risk of trying something new. In addition, I have become really interested in database technology and took a few classes during my junior year, so I wanted to put that knowledge to use on the server team. It’s great to hear that you are able to explore different types of programming as a MongoDB intern. What does the service architecture team do? My team is responsible for building the “glue” that holds different components of the MongoDB server together. We build internal APIs that simplify intra- and inter-process communication within MongoDB deployments. In practice, this looks like building a lot of libraries that make networking, asynchronous programming, and remote command execution simple for replication, sharding, and other server teams to use. I have really enjoyed working on this team, because our job is basically to write clean, reusable code that makes other developers’ lives easier. I find it really satisfying to refactor messy, one-off pieces of code to use our libraries instead. Considering that you’re a two-time intern, what is your favorite part about MongoDB’s internship program? Interns are given a lot of trust at MongoDB, which allows us to not only learn technical skills, but also develop our working styles and take risks during the internship. As the summer has progressed, I have been given more and more trust in terms of designing my own solutions to issues without obvious solutions. Even if I make a decision that might not be the best way to solve the problem, I am given the space to discover and correct that on my own. Because of this, I feel like the MongoDB internship program has helped me grow as an engineer who is responsible for design and execution, not just as somebody who writes code that I am told to write. In addition, the internship has allowed me to explore different aspects of MongoDB through reading documentation from other teams. I’ve also had the opportunity to have coffee chats with other engineers and look through the codebase overall. This makes me feel like I am really valued as a growing engineer, rather than just somebody who is around to do some extra work for the summer. It sounds as though you’re really enjoying our strong engineering culture and are taking advantage of the resources we provide to interns at MongoDB. Could you speak a little more about the overall culture? The first thing that comes to mind when thinking about MongoDB’s culture is collaboration. Curiosity and intellectual humility are cornerstones of our engineering culture, and that leads to really productive engineering. When discussing technical decisions within my team, it is very common to hear, “I thought X, but after listening to you walk through your thinking, I am leaning toward Y.” The culture makes it feel like everyone can contribute, and that every idea is worth hearing because it will be given a fair shot. I also really like the intellectual curiosity of MongoDB engineers. It seems that everyone has a little side interest in another team’s work, and you frequently hear engineers ask each other questions about the inner workings of their projects. It seems that you've really embraced one of our most important company values, "build together." Do you have any advice for students who might be considering interning at MongoDB? I would encourage students considering a MongoDB internship to try new things when choosing their teams for the summer. The first summer I was here, I wanted to stick with what I knew by working on a team that used React and Java. This summer, I had to learn an entirely new language, C++, in order to work on my team, and I think that I have grown so much through this experience of trying something new in my internship. Interested in opportunities for college students at MongoDB? Find out more .

August 17, 2022

Better Inventory Management With MongoDB Atlas, Atlas Device Sync, and WeKan

Mobile technologies can be powerful enablers of an improved retail experience, both for customers and for employees. Using mobile devices, staffers can check in on an app rather than physically signing into their workplace. Order management and order tracking can be greatly improved with mobile technologies, offering customers increased assurance and predictability. One of the largest challenges faced by retailers — and one where mobile technologies are ideally suited to help — is inventory management. Poor inventory management leads directly to lost revenues, because retailers cannot fulfill orders if they don’t know what they have. Some 70% of store associates are unable to fulfill an order that is out of stock at their location. In this article, we’ll look at how mobile technology, connected to a central database, can improve inventory management and provide key functionality throughout an organization. Inventory challenges Inventory management is exceptionally complicated, especially for retailers that have roots in brick and mortar. Even a medium-size retailer may have dozens of physical locations and multiple warehouses. When an order comes in, the information must be sent to the appropriate warehouses, and the warehouse managers need to know which items should go to which stores. When e-commerce is layered on top of that, workers pick and pack items directly from the warehouse, in addition to managing returns. Worse, more than 16% of online orders are typically canceled . If a store manager orders a particular style of shoe, for example, they want to be able to see when those shoes are going to arrive. However, this information is typically compiled in batch mode at the end of the day, which can result in lags and inaccuracies. Additionally, if the various inventory systems aren’t communicating well, a store manager may not see that an order has been returned or canceled. They may think the item is out of stock — even though it could be sitting on a shelf. Such difficulties can be the result of fragmented technologies. Warehouses may have their own systems, point-of-sale systems may be a separate technology, and inventory management may be completely independent. This fragmentation doesn’t even begin to take into account the systems that help the store managers with operations and the delivery infrastructure. Some of these systems may be modern, some may be legacy, but without being connected to a central data layer, the information contained within them remains siloed and therefore of limited value. Mobile technology, connected to a central database, can unlock that information and provide important new functionality to employees throughout an organization. It can tell the shop manager that their shoes will arrive in the next hour. And it can tell them that, based on data from the point-of-sale system, they’re running out of women’s socks in size small, for example, and need to replenish their stock. Central data layer Conceptually, the solution is simple: A central data layer that is able to talk to all these different components on a real-time basis and then cascade the information to different applications using mobile devices to feed off of the database. The data layer and the local clients must be interoperable and available regardless of network availability and other challenges. The data required for the mobile app should be on-device and should be synced with the database server. The data layer is the backbone of this entire system. It needs to be flexible, because it will be asked to ingest wildly different forms of data. A retailer may have millions of SKUs that need to be managed, along with prices and special promotions. This information changes frequently, so the data layer must be able to manage a very high volume of data, and the data must be easily transformed to work in one central system that other devices can easily access. According to research from Incisiv, 70% of workers do not sit at a desk, and 79% of the retail workforce are digital natives, meaning that the data layer must be interoperable with any number and type of mobile devices. MongoDB and WeKan , working together, use MongoDB Atlas as that central data layer with Atlas Device Sync to connect data between mobile devices and the cloud. WeKan — an IT consulting company offering end-to-end transformation and technology innovation services — has been building mobile solutions since 2015, and has deep experience with Atlas and Atlas Device Sync. MongoDB has partnered with WeKan because of its consistent success in helping customers in industries such as retail, manufacturing, and automotive modernize their tech stacks and their business ecosystems, paving the way for valuable innovations. The combination of MongoDB Atlas and Atlas Device Sync provides significant advantages to joint customers, including: Out-of-the-box, robust sync protocol: When a sale is made, data from the point-of-sale system is synchronized to the cloud and then sent to all the other devices that need the information in real time. No matter how an employee is accessing the data, they can be assured that it is the most up-to-date. Efficient data consumption from the mobile client: It’s important that any solution be specifically tailored for mobile devices. A generic cloud-based solution is not necessarily mobile-friendly, which means that it may not be efficient in terms of data consumption, battery-life or storage optimization. Flexible schema: A flexible data structure allows businesses to ingest data quickly, innovate, and be free from the rigidity of relational systems. Warehouse teams may need one view of the data, while delivery teams need a completely different view. A flexible schema allows for fluid processes and helps each team get the data access it needs. GraphQL and auto-generation of endpoints: Endpoints talk to the data layer so that an API can fetch data from it. Most developers have to build those endpoints, but with Atlas Device Sync clusters, the endpoints are generated automatically. Triggers and functions: Certain aspects of MongoDB Atlas and Atlas Device Sync can be set up to be serverless. If you want to move data between Atlas and another system, you can use triggers to send the data and then send notifications based on the changes. Data access permissions and user authentication: This functionality is available out of the box with Atlas and Atlas Device Sync, which saves developers valuable time. Because MongoDB Atlas and Atlas Device Sync provide a fully managed, out-of-the-box implementation of device-to-cloud data synchronization, creating and maintaining a high-quality, reliable application fit for business-critical use cases is simple. Below, we illustrate how updates from client and server are handled automatically: Enabling e-commerce at a leading retail chain In one successful use case, a massively complex retail organization that operates, franchises, and licenses thousands of stores globally used MongoDB Atlas with Atlas Device Sync to build innovative functionality for its e-commerce application. The application allows customers to browse a product catalog connected to their local store’s inventory, make purchases on their mobile devices, and schedule in-store pickup or delivery. To provide the best customer experience, the mobile app obviously requires accurate, timely, and granular inventory data. As part of their technology modernization initiative, this retailer also brought custom mobile devices into 10,000 stores across the United States and Canada to better scan and manage inventory. With the new functionality, store employees can now call customers directly about order statuses and clarifications. The result is a better customer experience, increased mobile sales, and extensive data analytics capabilities that can foster further improvements. Inventory management is exceptionally complicated and frequently made worse with separate, fragmented technologies. Could improved inventory management bring in more revenue for your business? Learn more about WeKan or contact MongoDB at bd@mongodb.com .

August 16, 2022

Hear From the MongoDB World 2022 Diversity Scholars

The MongoDB Diversity Scholarship program is an initiative to elevate and support members of underrepresented groups in technology across the globe. Scholars receive complimentary access to the MongoDB World developer conference in New York, on-demand access to MongoDB University to prepare for free MongoDB certification, and mentorship via an exclusive discussion group. This year at MongoDB World, our newest cohort of scholars got the opportunity to interact with company leadership at a luncheon and also got a chance to share their experience in a public panel discussion at the Community Café. Hear from some of the 2022 scholars, in their own words. Rebecca Hayes, System Analyst at Alliance for Safety and Justice I did an internal transition from managing Grants/Contracts to IT and just finished a data science certificate (Python, Unix/Linux, SQL) through my community college. My inspiration for pursuing STEM was wanting to understand how reality is represented in systems and how data science can be used to change the world. What was your most impactful experience as part of the Diversity Scholarship? Most impactful were the conversations I had with other attendees at the conference. I talked to people from all sectors who were extremely knowledgeable and passionate about shaping the future of databases. The opportunity to hear from MongoDB leaders and then understand how the vision behind the product was being implemented made me feel inspired for my future in STEM. How has the MongoDB World conference inspired you in your learning or your career path? MongoDB World inspired me to understand the real world applications of databases. I left knowing what's possible with a product like MongoDB and the limits of SQL and traditional databases. After the conference, I wrote this article on Medium reflecting on what I learned at the conference. What is your advice to colleagues pursuing STEM and/or on a similar path as you? Embrace what makes you unique. Just because things take time doesn't mean they won't happen. When learning programming and data science, think about how your work relates to the real world and share those thoughts with others. Seek out new perspectives, stay true to yourself, and keep an open mind. Delphine Nyaboke, Junior Software Engineer at Sendy I am passionate about energy in general. My final year project was on solar mini-grid design and interconnection. I have a mission of being at the intersection of energy and AI What inspired me to get into tech is the ability to solve societal problems without necessarily waiting for someone else to do it for you. This can be either in energy or by code. What was your most impactful experience as part of the Diversity Scholarship? My most impactful experience, apart from attending and listening in on the keynotes, was to attend the breakout sessions. They had lovely topics full of learnings and inspiration, including Engineering Culture at MongoDB; Be a Community Leader; Principles of Data Modeling for MongoDB; and Be Nice, But Not Too Nice just to mention but a few. How has the MongoDB World conference inspired you in your learning or your career path? MongoDB World has inspired me to keep on upskilling and being competitive in handling databases, which is a key skill in a backend engineer like myself. I will continue taking advantage of the MongoDB University courses and on-demand courses available thanks to the scholarship. What is your advice to colleagues pursuing STEM and/or on a similar path as you? STEM is a challenging yet fun field. If you’re tenacious enough, the rewards will trickle in soon enough. Get a community to be around, discuss what you’re going through together, be a mentor, get a mentor, and keep pushing forward. We need like-minded individuals in our society even in this fourth industrial revolution, and we are not leaving anyone behind. Video: Watch the panel in its entirety Raja Adil, Student at Cal Poly SLO Currently, I am a software engineer intern at Salesforce. I started self-teaching myself software development when I was a junior in high school during the COVID-19 pandemic, and from there I started doing projects and gaining as much technical experience as I could through internships. Before the pandemic I took my first computer science class, which was taught in C#. At first, I hated it as it looked complex. Slowly, I started to enjoy it more and more, and during the pandemic I started learning Python on my own. I feel blessed to have found my path early in my career. What was your most impactful experience as part of the Diversity Scholarship? My most impactful experience was the network and friends I made throughout the four days I was in New York for MongoDB World. I also learned a lot about the power of MongoDB, as opposed to relational databases, which I often use in my projects. How has the MongoDB World conference inspired you in your learning or your career path? The MongoDB World conference was amazing and has inspired me a ton in my learning path. I definitely want to learn even more about MongoDB as a database, and in terms of a career path, I would love to intern at MongoDB as a software engineer down the line. What is your advice to colleagues pursuing STEM and/or on a similar path as you? My advice would be to network as much as you can and simply make cool projects that others can use. Evans Asuboah, Stetson University I am an international student from Ghana. I was born and raised by my dad, who is a cocoa farmer, and my mum, who is a teacher. I got into tech miraculously, because my country's educational system matches majors to students according to their final high school grades. Initially, I wanted to do medicine, but I was offered computer science. I realized that computer science could actually be the tool to help my community and also use the knowledge to help my dad on the farm. What was your most impactful experience as part of the Diversity Scholarship? The breakout room sessions. As scholars, we had the chance to talk to MongoDB employees, and the knowledge and experiences changed my thoughts and increased my desire to persevere. I have learned never to stop learning and not to give up. How has the MongoDB World conference inspired you in your learning or your career path? Meeting these amazing people, connecting with the scholars, being at the workshops, and talking to the startups at the booths has made me realize the sky is the limit. I dare to dream and believe until I see the results. What is your advice to colleagues pursuing STEM and/or on a similar path as you? 1. Explore MongoDB; 2. You are the only one between you and your dream; 3. Take the initiative and meet people; 4. Never stop learning. Daniel Erbynn, Drexel University I love traveling and exploring new places. I am originally from Ghana, and I got the opportunity to participate in a summer program after high school called Project ISWEST, which introduced me to coding and computer science through building a pong game and building an Arduino circuit to program traffic lights. This made me excited about programming and the possibilities of solving problems in the tech space. What was your most impactful experience as part of the Diversity Scholarship? My most impactful experience was meeting with other students and professionals in the industry, learning from them, making lifelong connections, and getting the opportunity to learn about MongoDB through the MongoDB University courses. How has the MongoDB World conference inspired you in your learning or your career path? This conference has inspired me to learn more about MongoDB and seek more knowledge about cloud technology. What is your advice to colleagues pursuing STEM and/or on a similar path as you? Don’t be afraid to reach out to people you want to learn from, and create projects you are passionate about. Build your skills with MongoDB University's free courses and certifications . Join our developer community to stay up-to-date with the latest information and announcements.

August 12, 2022

AWS and MongoDB: Partners in Reliable, Resilient Cloud Environments

Security is increasingly critical for application development. While the volume of applications developed, distributed, used, and patched over networks is rapidly expanding, so, too, are cyberattacks and data breaches, many of which happen at the web application layer. As more organizations move to the cloud, it’s imperative for customers to know who’s responsible for what when it comes to security. Understanding these roles and responsibilities is crucial for ensuring cloud workloads remain secure and available. MongoDB and AWS are working together to simplify and strengthen data security for our customers so they can focus on developing great applications and user experiences. For more information on shared responsibility, read the first blog in this series . Shared responsibility in the cloud Back when most IT environments lived on premises, the responsibility of securing the systems and networked devices fell squarely on the owner of the assets — usually the business owner or a managed service provider. Today, with the prevalence of cloud applications, hybrid environments, and pay-as-you-go services, it is often not clear who's responsible for what when it comes to securing those environments, services, and the data they contain. For this reason, the shared responsibility model of cloud security has emerged. Under the shared responsibility model, some security responsibilities fall on the business, some on public cloud providers, and some on the vendors of the cloud services being used. When you deploy a MongoDB Atlas database on AWS, the database is created on infrastructure operated, managed, and controlled by AWS, from the host operating system and virtualization layer down to the physical security of the AWS data centers. MongoDB is responsible for the security and availability of the services we offer — and for everything within the scope of our responsibilities as a SaaS vendor. Customers are responsible for the security of everything above the application layer — accounts, identities, devices, and data — plus the management of the guest operating system, including updates and security patches; associated application software; and the configuration of the AWS-provided security group firewall. (See Figure 1.) Figure 1.   Shared responsibility when using MongoDB Atlas. Strategic partners in data solutions MongoDB Chief Information Security Officer Lena Smart delivered a keynote at AWS re:Inforce , an event where security experts offered tips and best practices for securing workloads in the cloud, and was also interviewed by theCUBE . Smart noted how MongoDB and AWS are working together to enable our joint customers to focus more on business objectives while having the confidence in the cloud services and infrastructure they get from us. "You want to worry less about security so that you can focus on application development, performance, availability, business continuity, data management, and access," Smart said. "As the CISO of MongoDB, these concerns are also my top concerns as we work to better serve our global customer base. And we are very appreciative of the opportunity to do this in lockstep with AWS." Jenny Brinkley, Director, AWS Security, agrees that customers stand to benefit through the shared responsibility model. "The shared responsibility model is a huge reason why more customers are deploying in the cloud," Brinkley said. "AWS, combined with marketplace services like MongoDB Atlas, help relieve the customer's operational burden so they can focus on driving their businesses forward." Smart's appearance at the event is just one example of how MongoDB and AWS are working together to deliver scalable data intelligence solutions for enterprise data in the cloud, reduce risk for cloud-native tools, and enable our joint customers to achieve compliance and protect their sensitive data. Thanks to our strategic partnership, organizations around the globe and across a wide range of industries — from banking and airlines to insurance and e-commerce — are better able to discover, manage, protect, and get more value from their regulated, sensitive, and personal data across their data landscape. MongoDB Atlas is trusted by organizations with highly sensitive workloads because it is secure by default. We're constantly innovating with new, breakthrough technologies, like our industry-first queryable encryption, which allows customers to run rich, expressive queries on fully randomized encrypted data, improving both the development process and the user experience. MongoDB Atlas is designed to be secure by default. Try it for free . MongoDB Atlas (Pay as You Go) is now available in AWS Marketplace — try it today .

August 11, 2022

New in Atlas Search: Improve Content Recommendations With “More Like This”

We’re proud to announce the release of More Like This, a key MongoDB Atlas Search feature that allows developers to easily build more relevant and engaging experiences for their end users. With the moreLikeThis operator, you can display documents that are similar to a result document. In this article, we’ll explain how it works and how you can get started using this new feature. Content recommendation done easily People who use travel booking apps, streaming services, and e-commerce websites are likely familiar with “Frequently Bought With,” “Similar Products,” or “You Might Also Enjoy” sections in their search experiences — in other words, content recommendation that guides them toward new or related products to buy, movies to stream, recipes to make, or news articles to read (among other things). Instead of building and tuning a recommendation engine to provide this functionality, developers can create engaging, browsable search experiences by defining a similarity threshold between documents to surface relevant documents. How it works Under the hood, the moreLikeThis search operator extracts the most representative terms from a reference document or documents and returns a set of similar documents. The representative terms are selected based on term frequency-inverse document frequency (TF-IDF), which is calculated by looking at a given term’s frequency in a given document multiplied by its frequency in the corpus. TF-IDF is calculated by looking at a term’s frequency multiplied by its frequency in the corpus. Atlas Search indexes term frequency by default, which means there is less up-front configuration required when compared with other search solutions. Additionally, developers have the ability to define what constitutes sufficient similarity for their use cases, with control over variables such as the number of query terms selected and the minimum and maximum document frequency thresholds. Use cases An example use case might look like this: An online bookstore wants to upsell users who have reached the checkout stage with similar books. On the checkout page, the user is served with a More Like This query result in the form of an “Other Books You Might Like” section that contains an array of book titles based on multiple fields in the document (e.g., title, publisher, genre, author). More Like This can be applied to use cases like ecommerce, content management systems, application search, or anywhere you want to share more relevant content with your users to drive deeper engagement. For more examples of how to configure More Like This, refer to our examples in the Docs . To learn how to get started with More Like This, refer to our documentation . For real-world Atlas Search implementation examples, go to our Developer Center .

August 10, 2022

4 Common Misconceptions About Security That Hackers Hope You Don't Know

I’ve always thought hacking was harder than it looks on TV. But after two years exploring the world of ethical hacking, I’ve learned that almost anyone can hack almost anything if they have sufficient knowledge and think creatively. Practically every week, we hear about another data breach at a large organization or a new vulnerability in a widely used software package. Many of these exploits are the result of misconceptions about security, which often lead to security misconfigurations. In this post, I'll cover the four most common security misconceptions and explain how hackers leverage them to execute attacks. I'll also explain how MongoDB can help you protect your data against these attacks. Watch Dawid Esterhuizen's MongoDB World 2022 presentation, Hack the MongoDB Planet! 1. NoSQL Injection The first rule of secure web development is: Never trust user input. This brings me to the first common misconception: MongoDB doesn’t use SQL, so I don’t have to worry about SQL injection. I’ve spoken with countless developers who have this false sense of security. The truth is, as NoSQL databases gain an increasing share of the database market, attackers are starting to pay attention, and new exploit tools are starting to emerge, like NoSQLmap (a NoSQL version of SQLmap), which allows hackers to perform automated NoSQL injections on vulnerable applications and endpoints. But enough theory. Let’s start hacking (ethically). Shown below is an example of a vulnerable application endpoint. The application uses the req.query.user and req.query.pass , which were provided by the user, as the values for name and password. The query string takes the username and password, builds a query, and checks to see if the user exists. app.get('/', async (req, res) => { query = {name: req.query.user, password: req.query.pass} user = await client.db("secret_bank").collection("users").findOne(query) if (user){ res.send('Success') } else { res.send('Failed') } } Vulnerable application endpoint. This is a fairly basic authentication method, but one that can be easily exploited with some command line tools. If you enter the correct username and password information, you can see the presence of strings on the server. (I’ve added some extra logging so you can see what happens on the server.) Normal login. The username and password are confirmed on the server and everything seems normal. MongoDB queries are usually built with objects and arrays. The question from an attacker’s point of view is, can they inject those onto the server? One of the interesting and not-very-well-known features of URL query parameters is that if you add a square bracket to a parameter in the URL, it is converted into an array. As you can see from this example, I added the password, notRight , as an array on the server. Add square brackets to the parameter to see the presence of an array. Say you’re an attacker and you want to inject a list of two values. You just have to do it twice with the same parameter and you’ll get an array list of values on the server. If you add square brackets to the same parameter twice in the command line, you'll get an array list of values on the server. This would definitely be useful for an attacker seeking to inject NoSQL into the application. The next question an attacker might ask is, can they inject an object on the server? In any programming language, if you set a field name inside the square brackets you get an object. Here, you see the same with an object on the server. If you set the field name inside square brackets, you'll see the object on the server. So the attacker can now send objects to the server, but how do they exploit that? In an SQL injection, the most basic authentication bypass you can do is quote (") or one equals one (1=1) double dash. This query results in true every time. Bypass login in SQL. The SQL query above will evaluate if the user is equal to admin, which in our case is true. Then it checks if the password is equal to an empty string (due to our quote), or if one is equal to one, which is always true. The query will therefore always return the ID of the username if it exists. There are a few NoSQL options that will do the same. If your password is actually set, you can run a query that checks if it's greater than nothing, which it always is, and use that to bypass authentication. Similar to an SQL injection, there are a few NoSQL queries hackers can run to bypass application authentication. This is a vulnerability in the application, not the database. The application assumes that the user is sending a string for the password and user. If the application forces the password and username to a string with .toString() , no matter what input the user gives, it is not parsed. A lot of this is pretty obvious, but let's take it a step further. Shown below are a few lines of Python script that iterate over some characters and play a little with regex, and then do some blind NoSQL injection. By doing that, I'll demonstrate how we can pull some data out of the database. baseURI="http://localhost:3000/?user=admin&pass[$regex]=^" chars=list(string.ascii_lowercase + string.ascii_uppercase + string.digits) count=0 while (not found): currentCharacter=chars[count] url=baseURI + foundString + currentCharacter + "" if requests.get(url).text == "Success": count=0 foundString+=currentCharacter url=baseURI+foundString+"$" found = requests.get(url).text == "Success": else: count+=1 Once we kick off the exploit, the script continuously iterates off every character. This Python script performs a blind NoSQL injection to extract a password. The main objective here is to extract the clear text password, since that was our vulnerable parameter in this case. This exploit is 13 lines of code that took about 10 minutes to write. With NoSQLmap, this could be even easier. Now, I know all you Java and C# developers are out there thinking your applications are safe. You'll be surprised to know that you're still vulnerable. All it takes is a very interesting approach to query building by parsing JSON strings as queries. In 2021, a quite popular open source chat server identified this exploit, using regex blind injection. The attackers in this case pulled out the reset tokens for users. Once they were able to reset a user’s password, they escalated the user’s privileges, making them an admin. Once an admin, they could set up integration, which is a fancy word for running code on your server. And once that happens, you've been pwned. So it bears repeating: Never trust any input from any user, ever! 2. Social engineering attacks People and businesses get hacked every day, and most security attacks and data breaches use social engineering. Great hackers will only let you know about their presence when they want you to know about it. This brings me to the second common misconception: I don't need authentication because the database will always be running on a private network. Authentication is the most basic security feature. Whether you're using SCRAM-SHA, LDAP, x509, or Kerberos, if you do not lock the front door, someone will gain access, and social engineering is the preferred method. All it takes is someone innocently clicking on a malicious file, which results in a macro trojan that gives the attacker access to the network. Once they're in your network, they can scan for open ports, then test if authentication is enabled for the database. Network scan. Once they find a database without authentication, you've been pwned. You've been pwned. It's that simple. 3. TLS and network traffic Let's say you have now enabled authentication, your data is now behind a lock and a strong password (at least 16 characters using both uppercase and lowercase letters, numbers, and symbols). You have even moved credentials into a secrets vault to stop attackers from reading them out of the source code or config files. You're safe, right? Well, this brings me to the third common misconception: We don't need TLS, MongoDB uses a binary protocol. Unfortunately, with the popularity of bring-your-own-device options, employees often install software from unofficial sources without any permission or oversight from IT. Vulnerabilities in third-party software can easily lead to unauthorized access to the network by a malicious actor. Once again, they can perform a scan and check to see if authentication is set up, and it is. Checking authentication. At this point, they can attempt a brute force attack, but that's a lot of work, and hackers prefer easier approaches. Instead, they start sniffing the network and find multiple packets for the MongoDB database. Sniffing the network. They can intercept the traffic and send it to their own machine. Once they have the data on their machine, and if they know their tools well (Tshark or Wireshark would help), they can access a PCAP file. And if they output it as JSON, they can use jq to manipulate it. The example below shows BSON as hexadecimal code. BSON dump. The CyberChef tool has a decoder for BSON. Decoding BSON. No username is required. And once again, you've been pwned. The lesson here is that TLS should always be used to ensure any data that is transferred between two systems is encrypted and, even if intercepted, cannot be decrypted without the private key. Retrieving files after they've been deleted So now you have authentication with strong passwords, the application is safe, the network is safe, and you’re using encryption at rest. You’re totally secure, right? Nope. This brings me to the fourth common misconception: Encryption at rest will protect me against hackers. A 2014 study found that 78% of drives that were sold for reuse after decommissioning and allegedly being wiped still had data on them; 23% of those still had associated social security numbers, and 21% had financial information. Needless to say, this is a problem. Hackers who use a keyfile for encryption at rest can retrieve files from an old, discarded drive or one that was not securely wiped. And once again, you've been pwned. The best defense against this sort of vulnerability is to always use a key management interoperability protocol (KMIP) server for encryption at rest. Malicious insiders It's important to remember that if an attacker gains entry to your system while it's running, they can get ahold of your data, no matter what system you're using. This brings me to an attack vector that is one of the biggest risks for businesses right now: malicious insiders. According to a recent study , 70% of organizations are seeing an increase in insider attacks. It can take up to 200 days to identify these attacks. Around the globe, 35% of businesses have been affected. Imagine a trusted employee accepts a job with one of your competitors and, in the process of accepting a position with them, decides to take your database with them. They don't want to use their credentials to access it for fear of being detected. They could dump the memory and get what's in the cache, but that's a lot of work. They could also dump the memory and look for the encryption keys, which is also a lot of work. Alternatively, they could just use the keyfile and dump the data. And once again, you've been pwned. Running host with KMIP. Insider attacks are some of the hardest to protect against because of the level of knowledge and access of employees. If it seems like no one is safe, that's what I'm trying to show you. If someone makes it onto your server while it's running, all bets are off, especially if they have root access. client-side field-level encryption encrypts the data on the application server before it's sent to the database — not even your DBAs can read the data. The keys that are being used are also in a key management system (KMS). Client-side field-level encryption should be used for all sensitive information. Secure by default Let's face it, security configuration is a full-time job, and you already have one of those. MongoDB Atlas provides a database that is secure by default. At a minimum, it always requires a username and password, it always requires you to use TLS, and there are network and IP access lists that further restrict access to the database. MongoDB Atlas uses a zero-trust design that complies with all the major regulatory frameworks organizations are subject to. When you use client-side field-level encryption for applications outside of mongoDB Atlas and put your data inside of Atlas, which is secure by default, you've added yet another layer between malicious insiders and your data. Try a preview version of Queryable Encryption to encrypt data end-to-end and query on randomly encrypted data. Try MongoDB Atlas for free.

August 10, 2022

MongoDB and IIoT: Data Streaming With Kafka

Event streaming has become a cornerstone of the industrial internet of things (IIoT) because it allows people to unleash the power of real-time operational data to drive applications and analytics. In this article, we share how MongoDB Atlas helps you move data seamlessly from the MQTT protocol into MongoDB time series collections using the Apache Kafka MQTT source and MongoDB sink connectors deployed in a cloud environment. Read the first and second articles in this four-part series on MongoDB and IIoT. Data streaming is the second step in our framework for end-to-end data integration in the manufacturing sector. The “connect” step of this framework deals with establishing an interface for interaction with IoT devices . The methodology discussed in this blog was developed and tested using a model factory created by Fischertechnik , but these steps are applicable to any environment that uses the standard MQTT protocol. All the source code for this project, along with a detailed deployment guide, can be found on our public Github repository. Figure 1. &nbsp;Step 2 of the end-to-end data integration framework. The challenge of collecting data On the shop floor, devices and components are continuously generating data related to their activity and environmental conditions at regular time intervals, typically known as time series data. In our factory model production line, there are a variety of sensors collecting data about temperature, pressure, humidity, brightness, camera positions, device/inventory status, and movements. This data is vital to monitor the health and effectiveness of factory equipment and its ability to continue to function without failure. The resulting datasets are often huge and must be efficiently stored and analyzed to detect anomalies or provide insight into overall equipment efficiency. With the advent of powerful event streaming platforms like Apache Kafka — and the wide variety of connectors for all sorts of protocols — it has become increasingly simple to handle the consolidation and export of real-time data feeds. However, dealing with such large volumes of data comes with added challenges regarding scalable storage, cost implications, and data archiving. This is where MongoDB’s time series collections come into play. Time series collections are a distinct type of MongoDB collections, optimized to efficiently store and process time series data by leveraging clustered indexes, columnar compression, and aggregation pipeline stages to facilitate real-time analytics. Learn more about time series collections on our tutorial page . Dream team: MQTT + Kafka + MongoDB Our recipe for collecting real-time sensor data (using the MQTT protocol) combines an MQTT source connector developed by Confluent and a native MongoDB sink connector deployed in a containerized environment. Figure 2. &nbsp;The components of the data streaming methodology. In this instance, we used a similar stack that includes Kafka Connect , a Kafka broker, and ZooKeeper deployed as containers in a single Docker compose file. This setup can be deployed locally, on a serverless backend or even Confluent Cloud. In our case, we have it deployed on an AWS EC2 Linux instance. Read our tutorial on how to set up a Kafka development environment with MongoDB connectors . Here’s a brief explanation of what each container does in this environment: Zookeeper: Acts a centralized controller that manages and organizes all the Kafka brokers. Kafka broker: Allows Kafka consumers to fetch messages by topic, partition, and offset. Kafka brokers can create a Kafka cluster by sharing information between each other. Kafka Connect: Serves as the runtime environment where you can configure connectors to ingest data into Kafka topics, making the data available for stream processing with low latency. It is worth noting that Kafka allows any number of sink and source connectors to be created in its environment as long as there are no server resource restrictions. Once the development environment is set up, all the necessary parameters are configured in the source and sink connectors. The source connector The source connector allows the Kafka broker to subscribe to MQTT topics. It serves to map the MQTT topics that contain the desired data parameters to a chosen Kafka topic. For simplicity, we’ve used Confluent’s MQTT source connector , which supports any kind of MQTT broker connection (self-hosted or otherwise). We’ve also used a managed MQTT service from HiveMQ as our remote broker. In the sample source connector configuration below, we’ve streamed sensor readings from multiple MQTT topics on the factory to a single Kafka topic called sensors using a string list of MQTT topics. We added the necessary access details to the remote broker from which Kafka will consume messages from the MQTT topic and save them as JSON values. Mapping several MQTT topics to the same Kafka topic does not affect the performance of the connector. { "name": "mqtt-source", "config": { "connector.class": "io.confluent.connect.mqtt.MqttSourceConnector", "tasks.max": "1", "mqtt.server.uri": "ssl://<REMOTE BROKER ADDRESS>:8883", "mqtt.username": "<REMOTE BROKER CLIENT>", "mqtt.password": "<REMOTE BROKER CLIENT PASSWORD>", "mqtt.topics": "i/ldr,i/bme680,i/cam", "kafka.topic": "sensors", "value.converter":"org.apache.kafka.connect.converters.ByteArrayConverter", "confluent.topic.bootstrap.servers": "broker:9092", "confluent.license": "", "topic.creation.enable": true, "topic.creation.default.replication.factor": -1, "topic.creation.default.partitions": -1 }} Figure 3. &nbsp;Sensor readings from multiple MQTT topics to a single Kafka topic. The sink connector While the source connector specifies the location from which data is retrieved, the sink connector specifies the destination to which data is sent. We used the MongoDB Kafka Sink Connector , which allowed us to connect to a MongoDB Atlas cluster with the right access information and choose which database and collection the streaming data was stored in. To receive the brightness readings captured in the source connector, the topics property in this connector must be set to match the name of the kafka.topic property in the former. { "name": "mongodb-sink", "config": { "connector.class":"com.mongodb.kafka.connect.MongoSinkConnector", "tasks.max":1, "topics":"sensors", "connection.uri":"mongodb+srv://user:password@address.mongodb.net/database?retryWrites=true&w=majority", "database":"<database name>", "collection":"<collection name>", "key.converter":"org.apache.kafka.connect.storage.StringConverter", "value.converter":"org.apache.kafka.connect.json.JsonConverter", "value.converter.schemas.enable":"false", "timeseries.timefield":"ts", "timeseries.timefield.auto.convert":"true", "timeseries.timefield.auto.convert.date.format":"yyyy-MM-dd'T'HH:mm:ss'Z'", "transforms": "RenameField,InsertTopic", "transforms.RenameField.type": "org.apache.kafka.connect.transforms.ReplaceField$Value", "transforms.RenameField.renames": "h:humidity, p:pressure, t:temperature”, "transforms.InsertTopic.type":"org.apache.kafka.connect.transforms.InsertField$Value", "transforms.InsertTopic.topic.field":"Source" }} Figure 4. &nbsp; The converter properties instruct the connector on how to translate data from Kafka. The converter properties in Figure 4 instruct the connector on how to translate data from Kafka. This configuration also automatically creates a time series collection in the requested database using the timeseries.timefield properties, which allowed us to choose which field in the original MQTT message qualifies as the timestamp and auto-convert that to a MongoDB-compatible date/time value format. Find out more about the configurable properties of our Kafka connectors in our detailed documentation . Smooth sailing with MongoDB Atlas Once the connectors have been configured and launched, Kafka listens on the mapped topics for any change events and translates this to documents in a time series collection. As long as the Kafka environment is running and connection with the MQTT broker remains unbroken, the time series collection is updated in real time and highly compressed (often more than 90%) to accommodate the continuous influx of data. See a sample of the time series collection we created in Figure 5. Figure 5. &nbsp; Streamed data saved in a MongoDB Atlas time series collection. As the expectations of consumability vary across organizations and personas, the underlying data structure can be further tailored for different use cases by using materialized views and simple aggregations. Read the first and second articles in this four-part series on MongoDB and IIoT. Since time series data is hardly ever changed and “cools down” over time, storing it in a hot data tier can become costly. To optimize costs, MongoDB Atlas provides Online Archive , which allows you to configure filter criteria to trigger automatic offloading of “cold” data to cheaper storage while maintaining its queryability. Once you start to receive accurate real-time data from the factory floor, a world of opportunity opens up in terms of getting insights from the collected data. In our next post, we will show you how to leverage the rest of the MongoDB Atlas product suite to run analytics on operational data, including using Atlas Charts for instant seamless data visualizations (see Figure 6). Figure 6. &nbsp; A sample dashboard created from factory sensor data in Atlas Charts. All the source code used in this project, along with a detailed deployment guide, is available on our public Github repo . Feel free to clone it and play around with configuring Kafka and its connectors. Most of the principles discussed in this post are applicable to any device that uses MQTT as a communication protocol. To learn more, watch our webinar session to see the full reference architecture, get tips for configuring your Kafka connectors, and see a live demonstration. If you have questions about other communication protocols or would like to consult with someone from our team about your project, please contact us .

August 10, 2022

How MongoDB Protects Against Supply Chain Vulnerabilities

Software supply chain vulnerabilities became national news in late 2020 with the discovery of the Solar Winds cyberattack. A year later, as if to put an exclamation point on the issue, the Log4j security flaw was discovered. Before these incidents, cybersecurity headlines typically focused on ransomware and phishing attacks, and organizations responded by increasing defensive measures, expanding network security beyond the perimeter, and mandating security awareness training. Protecting organizations from supply chain vulnerabilities, however, is a more complex undertaking. Download Supply Chain Security in MongoDB's Software Development Life Cycle Transparency and testing Few organizations have complete transparency into the software supply chain. The software supply chain includes all components — third-party dependencies, open source scripts, contractors, and other miscellaneous components and drivers — directly involved in developing an application. When dealing with a dozen or more vendors, applications, and service providers, it's hard to know all the elements that comprise your organization's software supply chain. As a backend solutions provider with open source roots, MongoDB is keenly aware of the need for security and transparency in the software supply chain. Long before supply chain vulnerabilities became national news, we implemented numerous safeguards to ensure the security of our products throughout the software development life cycle (SDLC). For example, in the planning stage, we look at our software from an attacker's perspective by trying to find ways to bypass authentication and gain unauthorized access. In the sprint stage, we conduct thousands of CPU hours of tests every week, and we run builds on thousands of compute nodes 24/7 on different combinations of every major hardware platform, operating system, and software language. And in the deployment stage, we perform hundreds of hours of automated testing to ensure correctness on every source code commit. We also invite the MongoDB Community and other third parties to submit reports of bugs found in our products, both open source and enterprise packages. Finally, we conduct periodic bug hunts with rewards for community members who contribute by improving a release. Securing third-party software The area that organizations have the least visibility into is perhaps the use of third-party libraries. Almost all applications use software that was written by someone else. According to some industry estimates, third-party libraries make up between 30% and 90% of typical applications. At MongoDB, all third-party libraries are evaluated and vetted by the security team before being incorporated into MongoDB products. We also use security tools to scan source code, identify known security vulnerabilities, and test against government benchmarks like Common Vulnerability and Exposure (CVE) and Common Weakness Enumeration (CWE), as well as private-entity frameworks like the SANS Institute’s list of software vulnerabilities. If we identify a vulnerability, we use the IETF Responsible Vulnerability Disclosure Process to evaluate and mitigate the issue, communicate with our user base, and perform a postmortem assessment. Details are also published to the MongoDB Alerts page along with release notes and a description of fixes. Using SBOMs To encourage even more transparency within the software supply chain, we've been at the forefront of the push for a software bill of materials (SBOM, pronounced “S-Bomb”). A software bill of materials is a list of ingredients used by an application, including all the libraries and components that make up an application, whether they are third-party, commercial off-the-shelf (COTS), or open source. By providing visibility into all of the individual components and dependencies, SBOMs are seen as a critical tool for improving software supply chain security. MongoDB’s CISO, Lena Smart, recently conducted a panel discussion with a handful of cybersecurity experts on the need for SBOMs in the wake of President Joe Biden’s executive order on supply chain security . Vulnerabilities in software will always exist, and the determination of malicious actors means that some of those vulnerabilities will be exploited. MongoDB believes that secure digital experiences start with secure software development. That means having the proper controls in place, continuously probing for weaknesses, and maintaining transparency in the CI/CD pipeline. For more detailed information, download our white paper Supply Chain Security in MongoDB's Software Development Life Cycle .

August 9, 2022

4 Critical Features for a Modern Payments System

The business systems of many traditional banks rely on solutions that are decades old. These systems, which are built on outdated, inflexible relational databases, prevent traditional banks from competing with industry disruptors and those already adopting more modern approaches. Such outdated systems are ill-equipped to handle one of the core offerings that customers expect from banks today — instantaneous, cashless, digital payments . The relational database management systems (RDBMSes) at the core of these applications require breaking data structures into a complex web of tables. Originally, this tabular approach was necessary to minimize memory and storage footprints. But as hardware has become cheaper and more powerful, these advantages have also become less relevant. Instead, the complexity of this model results in data management and programmatic access issues. In this article, we’ll look at how a document database can simplify complexity and provide the scalability, performance, and other features required in modern business applications. Document model To stay competitive, many financial institutions will need to update their foundational data architecture and introduce a data platform that enables a flexible, real-time, and enriched customer experience. Without this, new apps and other services won’t be able to deliver significant value to the business. A document model eliminates the need for an intricate web of related tables. Adding new data to a document is relatively easy and quick since it can be done without the usually lengthy reorganization that RDBMSes require. What makes a document database different from a relational database? Intuitive data model simplifies and accelerates development work. Flexible schema allows modification of fields at any time, without disruptive migrations. Expressive query language and rich indexing enhance query flexibility. Universal JSON standard lets you structure data to meet application requirements. Distributed approach improves resiliency and enables global scalability. With a document database, there is no need for complicated multi-level joins for business objects, such as a bill or even a complex financial derivative, which often require object-relational mapping with complex stored procedures. Such stored procedures, which are written in custom languages, not only increase the cognitive load on developers but also are fiendishly hard to test. Missing automated tests present a major impediment to the adoption of agile software development methods. Required features Let’s look at four critical features that modern applications require for a successful overhaul of payment systems and how MongoDB can help address those needs. 1. Scalability Modern applications must operate at scales that were unthinkable just a few years ago, in relation to both transaction volume and to the number of development and test environments needed to support rapid development. Evolving consumer trends have also put higher demands on payment systems. Not only has the number of transactions increased, but the responsive experiences that customers expect have increased the query load, and data volumes are growing super-linear. The fully transactional RDBMS model is ill suited to support this level of performance and scale. Consequently, most organizations have created a plethora of caching layers, data warehouses, and aggregation and consolidation layers that create complexity, consume valuable developer time and cognitive load, and increase costs. To work efficiently, developers also need to be able to quickly create and tear down development and test environments, and this is only possible by leveraging the cloud. Traditional RDBMSes, however, are ill suited for cloud deployment. They are very sensitive to network latency, as business objects spread across multiple tables can only be retrieved through multiple sequential queries. MongoDB provides the scalability and performance that modern applications require. MongoDB’s developer data platform also ensures that the same data is available for use with other frequent consumption patterns like time series and full-text search . Thus, there is no need for custom replication code between the operational and analytical datastore. 2. Resiliency Many existing payment platforms were designed and architected when networking was expensive and slow. They depend on high-quality hardware with low redundancy for resilience. Not only is this approach very expensive, but the resiliency of a distributed system can never be reached through redundancy. At the core of MongoDB’s developer data platform is MongoDB Atlas , the most advanced cloud database service on the market. MongoDB Atlas can run in any cloud, or even across multiple clouds, and offers 99.995% uptime. This downtime is far less than typically expected to apply necessary security updates to a monolithic legacy database system. 3. Locality and global coverage Modern computing demands are at once ubiquitous and highly localized. Customers expect to be able to view their cash balances wherever they are, but client secrecy and data availability rules set strict guardrails on where data can be hosted and processed. The combination of geo-sharding, replication, and edge data addresses these problems. MongoDB Atlas in combination with MongoDB for Mobile brings these powerful tools to the developer. During the global pandemic, more consumers than ever have begun using their smartphones as payment terminals. To enable these rich functions, data must be held at the edge. Developing the synchronization of the data is difficult, however, and not a differentiator for financial institutions. MongoDB for Mobile, in addition with MongoDB’s geo-sharding capability on Atlas cloud, offloads this complexity from the developer. 4. Diverse workloads and workload isolation As more services and opportunities are developed, the demand to use the same data for multiple purposes is growing. Although legacy systems are well suited to support functions such as double entry accounting, when the same information has to be served up to a customer portal, the central credit engine, or an AI/ML algorithm, the limits of the relational databases become obvious. These limitations have resulted in developers following what is often called “best-of-breed” practices. Under this approach, data is replicated from the transactional core to a secondary, read-only datastore based on technology that is better suited to the particular workload. Typical examples are transactional data stores being copied nightly into data lakes to be available for AI/ML modelers. The additional hardware and licensing cost for this replication are not prohibitive, but the complexity of the replication, synchronization, and the complicated semantics introduced by batch dumps slows down development and increases both development and maintenance costs. Often, three or more different technologies are necessary to facilitate the usage patterns. With its developer data platform, MongoDB has integrated this replication, eliminating all the complexity for the developers. When a document is updated in the transactional datastore, MongoDB will automatically make it available for full-text search and time series analytics. The pace of change in the payments industry shows no signs of slowing. To stay competitive, it’s vital that you reassess your technology architecture. MongoDB Atlas is emerging as the technology of choice for many financial services firms that want to free their data, empower developers, and embrace disruption. Replacing legacy relational databases with a modern document database is a key step toward enhancing agility, controlling costs, better addressing consumer expectations, and achieving compliance with new regulations. Learn more by downloading our white paper “Modernize Your Payment Systems."

August 8, 2022

Navigating the Future of Data Sovereignty With MongoDB

There are 2.5 quintillion bytes of data created every day , and more and more of that data is being stored in a public cloud. The rise of cloud data storage brings with it a focus on data sovereignty. Governments and industry regulatory bodies are cracking down on protecting user data. At any given time, organizations must know where its data is located, replicated, and stored — as well as how it is collected and processed, prioritizing personal data privacy all along the way. The challenge of GDPR compliance A PwC survey found that 92% of U.S. companies consider GDPR a top data protection priority , and rightly so, as there is pressure from both governments and citizens to protect user data. A recent Vormetric survey found that 85% of American consumers said that if significant personal consequences resulted from their information being compromised as part of a breach, they’d take their business elsewhere. Without a strong handle on data sovereignty, organizations are risking millions of dollars in regulatory fees for mishandling data, loss of brand credibility, and distrust from customers. Where to start with data sovereignty Creating a proper structure for data sovereignty can be complex, and as big data gets bigger, so will the breadth and depth of regulations. The GDPR of today may not resemble the GDPR of tomorrow, and more laws continue to be rolled out at the federal, state, and industry levels. GDPR, while the most notable, is not the only data regulation policy that businesses must consider. California has rolled out the California Consumer Privacy Act, and there are numerous countries that have similar laws in place to protect consumer data and regulate how data is managed, including Japan, India, Egypt, and Australia. And as these regulations continue to be introduced, organizations will need to keep pace to avoid damage to their businesses. Major considerations that impact data sovereignty include: Process: How is your company going to maintain compliance for data sovereignty with efficiency? Infrastructure: Is a legacy infrastructure holding you back from being able to easily comply with data regulations? Scaling: Is your data architecture agile enough to meet regulations quickly as they grow in breadth and complexity? Cost: Are you wasting time and money by leveraging manual processes to adhere to governmental regulations and risking hefty fees attached to incompliance? Penalties: Are your business leaders fully aware of the costs associated with noncompliance? GDPR violations can exact up to €10 million (an average of 2% to 4% of organizational revenue) in penalties. Learn more about strong controls for critical data privacy at our upcoming webinar on queryable encryption . Managing data sovereignty with MongoDB Atlas MongoDB enables you to easily comply with most data privacy regulations. MongoDB Atlas , our cloud database as a service, includes intuitive security features and privacy controls, including: Queryable encryption : Revolutionary to the industry and currently in preview with MongoDB 6.0, queryable encryption enables encryption of sensitive data from the client side, stored as fully randomized, encrypted data on the database server side. This feature delivers the utmost in security without sacrificing performance, ensuring that even the most critical and sensitive workloads are safe and performant in a public cloud. MongoDB Atlas global clusters : It is no longer sustainable or advantageous to build applications across geographic areas and jurisdictions. Doing so requires more infrastructure, more maintenance, more management, and, in turn, more complexity and more resources exhausted. Atlas global clusters allow organizations with distributed applications to geographically partition a fully managed deployment in a few clicks and control the distribution and placement of their data with sophisticated policies that can be easily generated and changed. This means that not only can your organization achieve compliance with regulations containing data residency requirements more easily, but you can also reduce overhead at the same time. Virtual private clouds (VPCs): Each MongoDB Atlas project is provisioned into its own VPC, thereby isolating your data and underlying systems from other MongoDB Atlas users. This allows businesses to meet data sovereignty requirements while staying highly available within each region. Each shard of data will have multiple nodes that automatically and transparently failover for zero downtime, all within the same jurisdiction. Being able to meet data residency requirements is another big technical challenge made simple with MongoDB Atlas . Further, businesses can connect Atlas VPCs to customer infrastructure via private networking (including private endpoints and VPC peering) for increased security. IP whitelists : IP whitelists allow you to specify a specific range of IP addresses against which access will be granted, delivering granular control over data. Client-side field-level encryption (CSFLE) : This feature dramatically reduces the risk of unauthorized access or disclosure of sensitive data. Fields are encrypted before they leave your application, protecting them everywhere: in motion over the network, in database memory, at rest in storage and backups, and in system logs. Dig deeper into data sovereignty To learn more about strong controls for critical data privacy, join MongoDB’s webinar on August 24, 2022 . Our experts will focus on queryable encryption, the industry’s first encrypted search scheme, and how, with MongoDB Atlas, your data is protected with preconfigured security features for authentication, authorization, encryption, and more. Register for our queryable encryption webinar on August 22, 2022 .

August 3, 2022

Introducing the Ability to Independently Scale Analytics Node Tiers for MongoDB Atlas

We’re excited to announce analytics node tiers for MongoDB Atlas! Analytics node tiers provide greater control and flexibility by allowing you to customize the exact infrastructure you need for your analytics workloads. Analytics node tiers provide control and flexibility Until now, analytics nodes in MongoDB’s Atlas clusters have used the same cluster tier as all other nodes. However, operational and analytical workloads can vary greatly in terms of resource requirements. Analytics node tiers allow you to enhance the performance of your analytics workloads by choosing the best tier size for your needs. This means you can choose an analytics node tier larger or smaller than the operational nodes in your cluster. This added level of customization ensures you achieve the performance required for both transactional and analytical queries — without the need to over- or under-provision your entire cluster for the sake of the analytical workload. Analytics node tiers are available in both Atlas and Atlas for Government . A standard replica set contains a primary node for reads and writes and two secondary nodes that are read only. Analytics nodes provide an additional read-only node that is dedicated to analytical reads. Choose a higher or lower analytics node tier based on your analytics needs Teams with large user bases using their BI dashboards may want to increase their analytics node tiers above that of their operational nodes. Choosing a higher tier can be useful when you have many users or require more memory to serve analytics needs. Scaling up the entire cluster tier would be costly, but scaling up just your analytics node tiers helps optimize the cost. Teams with inconsistent needs may want to decrease their analytics node tier below that of their operational nodes. The ability to set a lower tier gives you flexibility and cost savings when you have fewer users or analytics are not your top priority. With analytics node tiers, you get more discretion and control over how you manage your analytics workloads by choosing the appropriately sized tier for your analytics needs. Get started today by setting up a new cluster or adding an analytics node tier to any existing cluster. Check out our documentation to learn more.

August 3, 2022