DEV Community: Rubén Martín Pozo

Enhancing Data Security with MongoDB: A Dive into Cryptography and CSFLE at Ovianta

Rubén Martín Pozo — Mon, 02 Dec 2024 10:20:00 +0000

In the digital age, safeguarding sensitive information is not optional. It's essential. At Ovianta, a SaaS solution empowering doctors with streamlined workflows and intelligent insights, protecting patient data is a top priority. MongoDB's cryptographic tools, particularly Client-Side Field Level Encryption (CSFLE), offer powerful methods to secure data in-use.

In this article, we'll explore MongoDB's CSFLE and share how Ovianta leverages encryption to meet stringent data protection requirements while working within the constraints of serverless environments like Vercel.

What is Client-Side Field Level Encryption?

MongoDB's CSFLE encrypts specific fields on the client side, ensuring sensitive data remains inaccessible to unauthorized parties, even if the database itself is compromised. The approach aligns with compliance standards like GDPR and HIPAA, making it an excellent choice for industries handling sensitive information, such as healthcare.

CSFLE Highlights:

Data confidentiality: Data is encrypted before it leaves the client.
Field-level granularity: Only sensitive fields are encrypted, leaving the rest of the database searchable.
Compliance-friendly: Helps meet data protection regulations.

Automatic vs. Manual Encryption

MongoDB supports two CSFLE modes: Automatic Encryption and Manual Encryption.

Automatic Encryption:
- Simplifies implementation by using MongoDB drivers to handle encryption.
- Requires the installation of an extra library.
- Not compatible with all hosting environments, including serverless platforms like Vercel.
Manual Encryption:
- Offers fine-grained control by letting developers manage encryption and decryption explicitly.
- Does not rely on additional libraries, making it suitable for environments with strict resource constraints, including serverless platforms like Vercel.

At Ovianta, we chose manual encryption because automatic encryption's library is incompatible with Vercel's serverless architecture. This decision ensures we maintain robust security without compromising the performance or scalability of our platform.

Manual Encryption: How Ovianta Secures Data

At Ovianta, we handle sensitive patient information, such as medical histories and consultation records. Using manual encryption allows us to encrypt this data securely before storing it in MongoDB. Here's how we do it:

Key Management:
- We generate and manage Data Encryption Keys (DEKs) using a secure Key Management System (KMS).
- Our KMS integrates seamlessly with MongoDB, providing a secure mechanism for key storage.
Encryption and Decryption:
- Data is encrypted using the MongoDB Client Encryption Library before it is sent to the database.
- Authorized services decrypt data when needed, ensuring only specific application workflows can access sensitive information.

import { ClientEncryption } = from 'mongodb-client-encryption');

// Initialize encryption settings
const clientEncryption = new ClientEncryption(client, {
  keyVaultNamespace: 'encryption.__keyVault',
  kmsProviders: {
    aws: {
      accessKeyId: '<AWS_ACCESS_KEY_ID>',
      secretAccessKey: '<AWS_SECRET_ACCESS_KEY>',
    },
  },
});

// Encrypt sensitive patient data
const encryptedValue = await clientEncryption.encrypt('patientSensitiveData', {
  keyId: 'keyId',
  algorithm: 'AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic',
});

// Store encrypted data in MongoDB
await collection.insertOne({ sensitiveField: encryptedValue });

It's also possible to decrypt using the MongoClient directly without needing to activate full automatic encryption by using the property bypassAutoEncryption


const secureClient = new MongoClient(uri, {
    autoEncryption: {
      keyVaultNamespace,
      kmsProviders,
      bypassAutoEncryption: true
    },
  });

const result = await collection.find().toArray();

Why Ovianta Chose Manual Encryption

Manual encryption provides us with:

Flexibility: By managing encryption directly in our code, we avoid dependencies on libraries incompatible with serverless environments.
Granular control: We can tailor encryption to specific fields and workflows, ensuring efficiency and compliance. Although it is possible to achieve this behavior using schemas, that will force us to work on automatic mode that is not working in serverless environments such as Vercel.
Portability: Since no special libraries are required, our encryption setup can be easily replicated across various environments.

How CSFLE Benefits Ovianta's Users

For our customers—doctors and healthcare providers—CSFLE means:

• Enhanced Privacy: Patient data is encrypted before leaving the client, ensuring it remains confidential even in the unlikely event of a breach.
• Regulatory Compliance: By implementing advanced cryptographic measures, Ovianta adheres to stringent healthcare data protection standards, building trust with users.

Conclusion

At Ovianta, securing patient data is central to our mission of empowering healthcare providers with seamless, AI-driven workflows. MongoDB's CSFLE, particularly through manual encryption, allows us to achieve high levels of security while maintaining the flexibility needed for our serverless architecture.

Whether you're building a healthcare app or managing sensitive user data, MongoDB's encryption options offer a reliable path to compliance and trust. For environments like ours, where automatic encryption isn't an option, manual encryption ensures robust security without compromise.

References:

• MongoDB Documentation: Automatic Encryption
• MongoDB Documentation: Manual Encryption

At Ovianta, we're building a next-generation product for doctors to streamline software for their consultations using NextJS. Follow us on this journey to know more about how we're building.

Why the JavaScript ecosystem is so vibrant (and a bit chaotic) for a backend dev

Rubén Martín Pozo — Wed, 30 Oct 2024 11:00:00 +0000

Why the JavaScript Ecosystem is So Vibrant (and a Bit Chaotic) for a Backend Dev

As a backend developer with a background in Java and Spring Boot, stepping into the world of JavaScript felt like entering a parallel universe. JavaScript's ecosystem is dynamic, brimming with creativity, and driven by innovation. In contrast to Java, which is structured and stable, JavaScript thrives in a state of constant flux, fueled by new ideas and ever-evolving tools. For a backend developer used to a world of well-defined patterns and practices, the JavaScript world can feel like a bit of a wild ride, but that's what makes it so exciting.

1. JavaScript: A Breath of Fresh Air for Backend Developers

Coming from a Java and Spring Boot background, JavaScript was a bit of a shock to the system. Java offers reliability and structure. There's a defined way to approach most problems and a certain consistency in how frameworks evolve over time. JavaScript, on the other hand, feels like an open playground. In JavaScript, there are often multiple ways to approach a problem, and sometimes, no clear “right” way at all.

Contrast with Java: Where Java feels familiar and consistent, JavaScript’s freedom opens up possibilities to experiment with new patterns and creative approaches.
Adaptability: JavaScript gives developers the flexibility to break free from traditional constraints, offering a range of tools and techniques that keep things fresh and exciting.

JavaScript's flexibility isn’t just about syntax. It’s a mindset shift. The language encourages innovation and quick pivots, often leading developers to discover more efficient solutions than they might have imagined in a more rigid backend environment. This freedom allows for a sense of creativity that can be incredibly rewarding.

2. The Pros of a Fast-Moving Ecosystem

One of the most fascinating aspects of JavaScript is the sheer speed at which it evolves. The ecosystem is a hub of innovation, with a steady stream of new libraries, frameworks, and tools being released and adopted by the community. JavaScript is in a constant state of reinvention, pushing the envelope to make development faster, easier, and more efficient. In contrast with Java, where everything needs to go through a heavier and more complex process to be adopted by users.

For a backend developer, this fast-moving ecosystem is a breath of fresh air. It means there's always something new to learn, whether it's a framework like React, Vue, or a server-side solution like Node.js. The community is constantly experimenting and finding better ways to solve common problems, pushing developers to stay up-to-date with the latest advancements.

3. The Cons: Chaotic, Unstable, and Ever-Changing

However, the pace of JavaScript's evolution also has its downsides. While Java's stability allows developers to build on a reliable foundation, JavaScript’s constant change can make it feel unstable. Frameworks and libraries rise and fall in popularity, sometimes within just a few months, making it challenging to commit to a particular stack or tool for long-term projects.

Coming from a much more stable environment, it's difficult to understand what library or solution you should use to solve a particular problem, and that might increase your anxiety while trying out different approaches.

Constantly Changing Tools: The fast pace of updates and new releases can make JavaScript feel like a moving target. Just when you've mastered one library or framework, a new version or a whole new approach might come along.
Steep Learning Curve for New Tools: With so many options and regular updates, developers are always learning, which can be exhilarating but also overwhelming.
Project Abandonment: It’s not uncommon for tools or libraries to lose community support or be quickly abandoned, which can be risky for production projects that need long-term reliability.
Documentation: Frequently, the documentation is not as deep as I'm used to seeing in Java. That means more exploration and testing until you fully understand how the framework works.

JavaScript’s experimental nature means that while the ecosystem is highly innovative, it can also be unpredictable. Developers may invest time learning a specific tool only to find that it’s no longer relevant or actively supported. It’s a landscape where you need to stay flexible and be prepared to switch gears when necessary.

4. Why Embrace JavaScript’s Vibrancy?

Despite its challenges, JavaScript’s vibrant ecosystem has a lot to offer backend developers. It’s an environment that encourages a different kind of problem-solving, one that’s creative, flexible, and always evolving. Working in JavaScript has made me a more versatile developer. And also, the journey is a lot of fun!

Broader Career Opportunities: JavaScript's popularity across both frontend and backend roles (thanks to frameworks like Node.js) creates career flexibility.
Fresh Perspective on Development: The experience of working in JavaScript provides new insights that can enhance backend development, encouraging a more agile, creative approach.

In the end, the JavaScript ecosystem is a thrilling place to be. It’s unpredictable and sometimes chaotic, but for those who are willing to embrace the changes, it’s also incredibly rewarding. For a backend developer stepping into JavaScript, it’s a journey that promises to challenge, inspire, and expand your horizons—if you’re up for the ride.

Note: Everything said here applies to TypeScript, too. In fact, it’s even wilder and more fun if you choose to go down the TypeScript path.

At Ovianta, we're building a next-generation product for doctors to streamline software for their consultations using NextJS. Follow us on this journey to know more about how we're building.

Redis vs MongoDB, fight!

Rubén Martín Pozo — Wed, 13 Oct 2021 07:36:28 +0000

Redis is an in-memory, distributed database that has typically been used as a cache in multiple projects. The advantage over other types of databases is that it doesn't persist data to disk, so all the elements are always in memory. That should speed up reads and writes.

To understand what having a Redis cluster could offer us, we've run some experiments.

Weather experiment

The idea behind this experiment is to test if MongoDB and Redis have a significant performance difference when accessing a cache by key. That means writing and reading to and from the cache by a key without further manipulating the value.

The weather service uses MongoDB as a cache to store weather forecasts, not to call the weather provider in every single request. We also added a Redis cache using AWS Elasticache. Let's see how those two compare.

This image shows MongoDB and Redis read time when retrieving forecasts from the cache. MongoDB shows 12ms for p99, 5ms for p90, and 2ms for p50. Redis shows 5ms for p99, 1ms for p90, and around 600µs for p50.

Although Redis performs almost 2x as MongoDB, would that difference justify the system's complexity by having another database? Let's see if we can answer these questions with a new experiment.

Ranking experiment

In this experiment, we will use Redis to cache the rankings using one of Redis' data structures. In this case, we're going to use a sorted set. This kind of structure allows us to keep a set of elements ordered by a score. In our case, the score will be either the level or the points of a player.

What we did was to add pages of the ranking when they are read from Mongo to Redis, and then every time a ranking request is received, we calculate the ranking using both Mongo and Redis. Since we don't have all players in Redis, the page calculated using Mongo is always returned to the client. The same calculation is done using Redis to compare the difference in time.

This image shows MongoDB and Redis read time when calculating the ranking. MongoDB shows 350ms for p99, 40ms for p90, 15ms for p50, while Redis shows 9ms for p99, 2.5ms for p90, and 1.5ms for p50. That means almost 40x for p99, 16x for p90, and 10x for p50 for Redis compared to MongoDB.

Conclusions

We've seen with these experiments that MongoDB can work pretty decently as a cache when the element is acceded by a key, and MongoDB has an index on that key with a particular TTL. However, Redis' time is always better.

For those use cases where Redis has its own data structure, Redis has no rival, and we strongly recommend its use.

Next steps

Should we go then and use Redis in production? That's still to be seen. Using Redis as a cache would imply that we have to store the data somewhere else to ensure we can recreate the cache if something goes wrong. We would also need to keep in sync with both the cache and the underlying storing system.

What's clear is that Redis is a useful tool that we could end up needing. We're not sure if we need to start using it just right now, though.

Cover image by Mateusz Wacławek on Unsplash

Time to say goodbye to Docker Swarm

Rubén Martín Pozo — Fri, 17 Sep 2021 08:12:37 +0000

We've been using Docker Swarm almost from the beginning of Playtomic's history. It has performed astonishingly well from day one. We haven't had a significant issue in four years. But, with tears in our eyes, it's time to say goodbye.

Why are we moving away from Docker Swarm? Well, the future of Docker Swarm is not clear. Although Docker Swarm is part of docker-ce distribution, Mirantis (owner of Docker Enterprise since November 2019) said that their main orchestrator would be Kubernetes.

The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users.

It is true that in a later post, Mirantis said that they were going to support Docker Swarm in the future, but clearly, the orchestrator competition is led by Kubernetes.

However, the main reason why we're moving away from Docker Swarm is that we need capabilities that are not easy to get with Docker Swarm at the moment. Playtomic is growing pretty fast, and we need tools that allow us to scale up and down automatically as required.

In a containerized environment, scaling means that you need to automatically scale up the number of instances and the number of nodes in the cluster. That's something that it's not easily achievable with Docker Swarm, unfortunately.

Also, we've grown into different teams, and these teams need a way to manage their services in the cluster autonomously. On the other hand, giving full access to the cluster to every team is risky. That's why we looked for a way of granted access just to the resources the team needs to manage. Again, Docker Swarm doesn't offer a straightforward solution to this problem.

For all these reasons, we've been testing Kubernetes for a while, and although Kubernetes is definitely more complex than Docker Swarm is also more powerful. Once you understand how Kubernetes operates and understand its design, it opens up many new exciting possibilities for us here at Playtomic.

We're running our Kubernetes cluster on EKS. That gives us kind of the same feeling we had with Docker Swarm since setting up the system is pretty straightforward. We don't need to fully understand the internals of the cluster to operate it.

Farewell Docker Swarm, you served us well.

Photo by Ian Taylor on Unsplash

We need to integrate a chat solution in our app. What do you recommend?

Rubén Martín Pozo — Fri, 22 Feb 2019 15:27:54 +0000

We are looking for a chat solution for our app. We are currently evaluating the following products:

Do you have any experience with these frameworks that you can share with us? Would you recommend any others? I'll be extending this post with our experience and findings

Update

If you want to know how the story ended up take a look at this post

Playtomic's chat solution with Firebase Realtime DB

Angel G. Olloqui for Playtomic ・ Jun 24 '19 ・ 8 min read

#firebase #chat #architecture

Cover image by Miguel Á. Padriñán from Pexels

How we built our stack with Docker Swarm

Rubén Martín Pozo — Mon, 07 May 2018 15:37:17 +0000

When we started to think about the kind of architecture we wanted to build for Playtomic we knew what we didn't want to end up with: a huge monolith. Whether we call them micro services or just plain old boring services we wanted a decentralized system that allows us to survive if one or some of the pieces goes down.

We also wanted to be able to independently build and test different parts of the system so different teams could be focused on solving problems that matters to us without having to worry too much about understanding every small detail of the whole system. Being able to compose features by creating and reusing services is key to grow at the pace we currently need.

So, we started to think about the different components we would need in order to put together such a system. Let's see some of them.

How are we going to build services?

We decided to start using Spring Boot to build our services upon. We're using both Java and Kotlin. Most of the people in the team had previous experience with it for building monolithic applications and we thought it would be a good start point. Spring boot has proven itself to be a good tool to build services because of the hundreds of frameworks and tools you can use out of the box (security, monitoring, logging, testing, ...). The main problems we've found are startup time and memory footprint. We're currently trying different things to reduce them both.

Where are we going to run our stuff?

We need something that gives us the ability to deploy services independently, that guarantees us that everything will be continuously up and running without too much pain.

We also don't want to have to depend too much on manual provisioning every time we come up with a new service (at least, minimize it as much as possible). Docker and Docker Stacks seemed like a great solution for us.

We looked at Docker Swarm and we found it was simple to set up, easy to understand and it scales pretty well. I personally had had some experience with Docker Swarm in the past and although I had some serious problem with stability and quality of service those problems were mostly due to the lack of maturity of the system at that time so we decided to give it another try.

We set up a Docker Swarm of 3 manager nodes and 4 worker nodes deployed in our own servers. It's been working smoothly so far without any problem at all. So we're pretty happy with our decision.

For us, Kubernetes seems like too complicated for what we need. We're glad that Docker Swarm supports Kubernetes natively right now though, so we could take advantage of it in the future if we need so.

We're also using Docker Flow Proxy to route traffic from the different applications and APIs to the corresponding service in the Swarm.

How can we be sure that everything is working properly?

In all systems, but specially in a distributed one, it's very important to be able to see the whole picture to understand how the system is behaving. We've built a monitoring system based on Prometheus to gather real-time metrics and Grafana to visualize services and how they are working together.

Logging is also very important to be able to find out fast where a problem is. We started using our own ELK stack but we recently decided to move to logz.io. Setting up our own elastic search cluster and keeping it running in production was too much for us. We thought we were spending too much time doing things we felt we shouldn't be doing (not our focus) so we moved that piece out.

Logz.io also has a great insight feature. Logs are analysed by their AI, comparing them to thousands of articles in different sites to give you valuable insights of your system. We've been able to find bugs in production using this feature that otherwise would have very likely skipped our radar.

We know we still have a lot of things to explore and improve but we're pretty happy with our current setup and we wanted to share it with you. What kind of infrastructure are you using? What ideas do you have to improve ours? Let us know in the discussion below.