Apervita: With MongoDB, vital healthcare data stays accessible AND secure

Medicine is, at heart, a data problem. Diagnosis and treatment need as full a picture as possible, but that picture is painted from some of the most intimate, private details of a patient’s life. These must be protected from misuse. They must also be immediately accessible to the caregivers and decision-makers. Squaring that circle of accessibility and security is one of the great issues of modern-day digital life.

Apervita is a specialist cloud-based health infrastructure company that exists precisely to enable the safe communication of records, contracts, and other documents between stakeholders. A MongoDB customer for over seven years, the company adopted document-based database technology because a document model better fits healthcare industry data. In 2018, Apervita made the decision to migrate its entire platform onto MongoDB Atlas on AWS.

The challenge regarding technology architecture design within the healthcare industry is twofold. First, you must account for and maintain compliance in the face of ever more stringent regulations. Second, you need to be cognizant that the wealth of personally identifiable information (PII) in medical records poses an enticing target for malicious cybercriminals. The question of how to secure such databases led to a fundamental architectural decision, as Apervita CTO Michael Oltman says.

‘Only the client can see the data’

“Healthcare is about networking data between and within the clinical and insurance parts of the industry, passing patient records and providing metrics to ensure value,” he says. “Obviously, that data needs to be encrypted when at rest in storage or when in-flight, and most standard relational database models provide that. The server side decrypts the data to work on it, with a separate system securing it when delivering it to clients.”

But that isn’t secure against many breaches, where an attacker can access the data when it's being processed within the server. A better model, Oltman says, is for the data to stay encrypted until it reaches the client.

“Client-side field-level encryption means only the client can see the data,” he explains. “At no other point—including during database administration, backups or transfer—does the data exist unencrypted. An attacker without the right keys to a particular dataset can’t see anything human-readable, as it’s ciphertext at all times outside the client.”

“We wanted to add external keys to eliminate that single-breach model,” says Oltman. By building the system in partnership, Apervita could contribute to the beta testing, the documentation, and integration challenges, with direct reference to its actual data use.

“We give the users a master key, so they can encrypt every field in their databases, and then we destroy our copy of that key. That adds a whole new level of security, which is exactly what the industry needs,” he says. “If you have 50 technologists, 25 are worried about security and how it integrates with what they’re doing. Move that to the client, and they’re free to innovate without worrying about the database implications.”

Having that functionality as an intrinsic part of the database client was the only way to make it work, argues Oltman. “Imagine bringing it in as a separate service, as a third-party solution. Imagine the refactoring it would need.”

Focus on building secure applications without expending additional engineering time

MongoDB’s close relationship with AWS as a platform meant that client key management could be handled by AWS’s own Key Management Service, considerably easing compliance and verification requirements.

“We’ve ended up with a nuclear launch-code level of security,” Oltman says. “To get access, you need our key, their key, as well as the server and the client. We can’t give access away if we don’t have it. We provide the data and ways to use it, but we can’t see it.”

The system is based around standard open-source crypto libraries and OS-integrated services, and Apervita’s provisioning is further secured by following best practices for virtual networks, security firewalls, and tight entitlement controls.

“Everything is behind controlled doors,” Oltman says. “Our default position is that the worst that can happen from our side is that the data is lost—and that’s it. It’s not disclosed. Our clients are fine with that. It’s a relief that they’re the source of record. We aren’t the official source of the data. We’re more than happy to work on other recovery procedures, but as standard, the data with us is completely secure.”

As for the performance implications of multiple-key encryption and management, Oltman says, there is a modest worst-case hit of 10 to 15 percent in throughput.

By utilizing this, customers can focus on building secure applications without expending engineering time to secure where the data resides outside of their app.

Outside of its work with Apervita, MongoDB has grown the client-side field-level encryption capability to work on multiple cloud providers and 19 platforms, with around 15 languages supported, standard libraries, and copious custom access control and key management options. The system can be built into an application in minutes without the developer needing domain expertise. Tutorials and how-to's explaining how concepts like key generation, field and subdocument encryption, and using indexes on encrypted collections are available as well.

MongoDB Client-Side Field Level Encryption is available wherever you run MongoDB 4.2 whether that's the Atlas fully-managed cloud service, or in your own data center with Enterprise Advanced, or the Community server. Additionally, Apervita recently announced a Deep Encryption™ feature, becoming the first healthcare company to offer this level of encryption technology. They can easily enable this feature for any of the 2,500+ hospitals already on the Apervita platform, helping protect the most sensitive workloads in the industry.