Townsend Security Data Privacy Blog

MongoDB World 2019 Encryption Survey

Posted by Ken Mafli on Aug 8, 2019 8:42:34 AM

This June we had a chance to participate in MongoDB World 2019 in New York City as an exhibitor. It was a great time as MongoDB professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

 

MongoDB-Survey-2019

 

If you are looking to protect your encryption keys for your sensitive data in MongoDB, you need a FIPS 140-2 compliant centralized key manager that:

  • Never charges you additional fees for connecting a new end-point.
  • Never limits the number of end-points based on the model of the KMS.
  • Never limits the number of encryption keys generated or stored.
  • Never forces you to pay extra fees for software patches.
  • Never forces you to pay extra fees for routine software upgrades.
  • Always gives you unmatched customer service.
  • Always protects your keys, 24/7.

You need Alliance Key Manager for MongoDB.

Encryption and key management for MongoDB

 

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

Scaling Encryption Key Management with MongoDB

Posted by Patrick Townsend on Dec 13, 2018 8:45:20 AM

MongoDB is revolutionizing the world of ‘Database’ with its scalable, secure, replicating database. With MongoDB Enterprise Advanced customers get the ability to protect sensitive data with built-in encryption, and a convenient, standards-based interface for encryption key management based on the industry standard Key Management Interoperability Protocol, or KMIP. Here at Townsend Security we fully support the MongoDB Enterprise Advanced key management architecture, and have certified our Alliance Key Manager with MongoDB for both Intel and IBM Power architectures. And, Alliance Key Manager supports real-time key mirroring between one or more failover key servers to ensure that you never have a service interruption because of a failed connection to a key server!

Customers often ask us how to design a resilient key management strategy with MongoDB. So let’s look at three common scenarios.

First, a note about the use of a load balancer

The key management interface for MongoDB Enterprise Advanced only allows for the definition of one key management server. In order to define one or more failover key servers, the following scenarios use a load balancer to allow connecting to the failover key server. As their name implies, load balancers are normally used to balance workload requests among multiple servers, and are available in all platforms where MongoDB is supported (VMware, cloud, etc.). In this case you use a load balancer to provide a failover mechanism. Future versions of MongoDB may support the definition of multiple key servers in the MongoDB configuration file - if that occurs the use of a load balancer would not be required.

Scenario 1: A primary and one local secondary replication set

Imagine a simple implementation of MongoDB that involves one primary node and one secondary node to provide for data recovery and high availability. In this scenario the secondary node is deployed locally, or in the cloud across regions or availability zones,  to the primary node. However, many MongoDB customers deploy the secondary node in a remote location to improve business recovery (see the next session).

Our goal in this scenario is to minimize or eliminate business interruption in the event the primary node fails or the key server for the primary node fails. To achieve this, we leverage the KMIP interface of MongoDB, a load balancer, and the key mirroring capabilities of Alliance Key Manager. 

Primary and secondary key manager

 

From the mongod.conf configuration file:

mongod.conf

It is important to note that we don’t have to worry about redundancy and failover of MongoDB itself. This is very nicely handled by MongoDB. What we are striving to achieve is to implement an equally resilient interface to key servers.

The primary MongoDB node has a KMIP configuration that points to the load balancer. The load balancer itself is configured to connect to the primary key server and a failover key server. Note that the failover key server is actually the key server for the secondary MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.

Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if the primary key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.

The result of this type of implementation is a fully redundant key server deployment to protect both the primary MongoDB node as well as a fully redundant key server deployment for the secondary MongoDB node.

Scenario 2: A primary and multiple secondary replication sets

MongoDB customers often deploy more complex implementations with multiple secondary replication sets. This might be done to provide high performance for data ingestion (writes) into the primary node, while secondary nodes provide high performance query support and data redundancy. This type of scenario involves multiple nodes each with its own availability and recovery requirements. There can be many key managers involved in supporting this environment.

Primary and multiple secondary replication sets

This scenario also leverages the use of load balancers to provide for automatic failover to a secondary key server. See the notes above about load balancers.

Primary and secondary MongoDB nodes have KMIP configurations that point to a load balancer. The load balancers are configured to connect to the defined failover key server when needed. Note that the failover key server is a different key server on another MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.

Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if a key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.

The result of this type of implementation is a fully redundant key server deployment to protect both of the MongoDB nodes.

Scenario 3: Complex, geographically distributed nodes

In complex MongoDB deployments that involve many geographically dispersed nodes, the same principles can be used to create highly redundant and resilient key management services. In this case the key managers are mirroring encryption keys and access policy across geographically dispersed locations. An encryption key management server and its backup mirrored server are available in all regions. 

Complex, geographically distributed nodes

This scenario uses multiple key management servers to provide a very high level of resilience and redundancy. The primary MongoDB node runs a primary and secondary server in order to ensure a high level of hot failover support. The remote MongoDB nodes also run a primary and secondary key server for the same reason - to provide the maximum availability of the secondary MongoDB databases. It is also important to note that this key server deployment leverages the ability of Alliance Key Manager to replicate keys to more than one additional key server.

In this example there may be many geographic regions that participate in the MongoDB replication group. Note that it is possible that multiple MongoDB nodes can share one set of key servers. There is no requirement that each MongoDB node needs to have its own key server.

This more complex MongoDB configuration demonstrates the scalability of Alliance Key Manager to serve even very complex deployments of MongoDB. And you can start with a simple deployment of MongoDB and scale up the key management deployment as you grow MongoDB.

Summary

Hopefully the above scenarios will help you understand and plan your MongoDB encryption key management needs, and provide a template for the growth of your MongoDB platforms. With Alliance Key Manager it is easy to start with a simple MongoDB deployment and then scale it as you invest more deeply in MongoDB technology. You won’t paint yourself in a corner with your early configurations!

Important note about MongoDB Atlas:

At the time this blog was written there is no support for key management using KMIP for MongoDB Atlas, the cloud-based solution. The MongoDB Atlas service only supports AWS Key Management Service (KMS) and Azure Key Vault.  Full encryption key management support is available by running MongoDB Enterprise Advanced as an AWS EC2 instance, Microsoft Azure virtual machine, or Google Cloud Platform virtual machine. We will update this blog if MongoDB Atlas implements the KMIP interface for key management.

Resources

Alliance Key Manager for MongoDB

MongoDB Security Guide

MongoDB technical guides

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

High Availability Strategies for MongoDB Encryption Key Management

Posted by Patrick Townsend on Mar 2, 2018 10:27:59 AM

The MongoDB database is designed to be resilient and gives you several options for high availability and business continuity. But what about encryption key management - how do we implement high availability when we’ve deployed a key management system for MongoDB encrypted databases? Here at Townsend Security we encounter this question with MongoDB users on a regular basis. Let me share some of the approaches that we recommend.

We can take a GOOD, BETTER, and BEST view of key management high availability. Not every MongoDB database implementation needs extreme high availability, and there are costs and benefits for different approaches. So let’s run down some of the common options:

GOOD

Not everyone uses the MongoDB database for mission critical applications, and hot failover is not needed. But, of course, in the event of a disaster that takes down your data center, network, or servers, you want to be able to recover in a reasonable amount of time. In this case, you can rely on the backup and restore capabilities of Alliance Key Manager for MongoDB. Here is a diagrammatic example of a simple case of a primary and secondary MongoDB implementation that share a single key manager:

MongoDiagram-good.png

In this case we deploy a single key manager to serve both the primary and secondary nodes of a MongoDB implementation. After initializing the MongoDB database for encryption, we perform a key manager backup to archive the master encryption key for the primary and secondary nodes of the database.

Recovery of the MongoDB database may involve migration from the secondary node to the primary node when it is back online, or restoration from a backup image, and a restore operation for the key manager. Alliance Key Manager makes it easy to backup the encryption key database and configuration, and to restore from backup when needed. This is the simplest case of key management recovery when hot failover is not needed.

Remember to follow security best practices when backing up Alliance Key Manager. You will want to save the secret keys separately from the data encryption keys, and ensure separation of duties. See the Alliance Key Manager documentation for guidance on backup and restore operations.

BETTER

For many MongoDB customers the applications built on the MongoDB database represent core, mission critical applications that must be available at all times. These customers need a high availability strategy that guarantees very little loss of availability and rapid recovery. While there are different failover strategies for MongoDB customers, the normal approach would be to failover to a secondary MongoDB node at a geographically independent data center. The primary and secondary nodes would use separate key management systems which would be synchronized. A diagrammatic might look something like this:

MongoDiagram-Better.png

The primary MongoDB node has a key manager deployed in its data center or cloud location, and the secondary MongoDB node has a different key manager deployed in its data center or cloud location. The two key managers are mirroring encryption keys in real time in an active-active configuration. Both the MongoDB data and the Alliance Key Manager instances are fully redundant in real time.

BEST

Enterprise customers who build mission critical applications on MongoDB databases and who must have full business continuity and high availability failover can achieve this with MongoDB replication and redundant Alliance Key Manager servers. A primary MongoDB node can associate two redundant key servers, and a secondary replicating MongoDB node can associate two different redundant key servers. Since MongoDB configuration only allows for the definition of a single key server, we can use a load balancer to implement the redundant key management pair. A diagram of this configuration would look like this:

MongoDiagram-Best.png

With a load balancer placed between the MongoDB database and the two key managers you can achieve hot failover in the event of a lost connection to the first key server without loss of access to the database. When the connection to the main key server is restarted the load balancer will bring it on line. The two Alliance Key Management servers automatically mirror encryption keys to each other in an active-active configuration.

In the event of a full loss of the primary MongoDB database the failover to the secondary MongoDB database will occur by the MongoDB Arbiter. The fully replicated data will be available and the secondary database will be protected by a pair of Alliance Key Manager servers in the same was as the primary MongoDB database.

Note that there can be multiple secondary MongoDB nodes and each can implement a similar key management failover strategy. With the above strategy MongoDB database customers can achieve a very high level of business continuity and high availability failover.

Additional Considerations

MongoDB database deployments vary a great deal in their overall architecture and implementation. This is a testament to the flexibility of the database and its ability to meet a wide variety of customer use case scenarios. Alliance Key Manager for MongoDB can help improve security and recoverability in any MongoDB deployment.

Alliance Key Manager is available has a Hardware Security Module (HSM), VMware software appliance (virtual machine), and as cloud instances. The interface to all of the key managers works in exactly the same way. This means you can create hybrid deployments of MongoDB and Alliance Key Manager across clouds, and between cloud and on-premise deployments.

At the time this blog was written (March 2018) the MongoDB Atlas cloud platform did not support independent third party key management solutions through the KMIP interface. That is likely to change in the future. For Enterprise customers who must achieve exclusive custody of encryption keys, you can deploy MongoDB in a normal cloud instance and use the encryption and key management capabilities of MongoDB with Alliance Key Manager. You can then migrate to the Atlas service when it supports the KMIP interface for key management.

About Alliance Key Manager

Alliance Key Manager for MongoDB is certified by the MongoDB security team, and supports the MongoDB Enterprise pricing model. Regardless of the size of your MongoDB implementation you will find an affordable and easy-to-deploy Alliance Key Manager for MongoDB solution.

Securing Data in MongoDB

Image Credit:
Load balancer created by AlexWaZa from the Noun Project
Key created by icon 54 from the Noun Project

Topics: MongoDB Encryption

MongoDB San Francisco local conference a big success

Posted by Patrick Townsend on Oct 21, 2017 12:50:03 PM

I just got back from the first MongoDB regional conference in San Francisco and wanted to share a few impressions. I will be blogging more about MongoDB, but here are some first impressions from the conference:

Introduction to Encrypting Data in MongoDB We’ve had support for MongoDB encryption key management for some months now, and the conference in San Francisco last week was a real delight. This is an amazing community of developers and users who are innovating and creating new applications based on MongoDB at a rapid pace. I was happy to give the security session on encryption key management for MongoDB and it was a great success. You can find a replay here.

I spent time talking to some of the hundreds of attendees and learned a lot about how the use MongoDB. Here are just a few take-aways:

MongoDB is Easy to Use

Database development has the reputation of being difficult and requiring extensive expertise. But I met a lot of people who have developed MongoDB databases without much or any database administrative knowledge. For example, I talked to a young scientist (that was the title on her badge) who was not in an IT group at all. She had developed a MongoDB database to store and analyze genetics information from her genome sequencing project. I met a pair of IT administrators from a property management company who had developed three applications on MongoDB because their development team had a long backlog of projects. They were in the network administration group and did not have formal experience with database development, but they built applications in a short period of time. It’s truly amazing to see sophisticated applications being developed by users!

MongoDB is Replacing Traditional Relational Databases

Before last week I thought of MongoDB as a big data repository for documents and IoT data. It is that, but it is a lot more. Many of the professionals I talked to at the conference were using MongoDB the way you would use a normal relational database like SQL Server, Oracle, DB2 or MySQL. I had the definite sense that MongoDB has found a way to bridge the worlds of relational databases and unstructured big data repositories. MongoDB users told me that the APIs and toolsets let them do almost anything they wanted to do.

MongoDB Really Scales for Big Data Needs

Well, MongoDB really is a great repository for big data. I talked to a number of larger enterprises from the San Francisco Bay Area who are storing extremely large amounts of data in MongoDB databases. Medical, IoT sensor data, financial data, customer service data and other types of data from a variety of data sources are being collected in MongoDB for business operations support and business analytics. The scalability of MongoDB is truly impressive.

Sensitive Data is Going into Almost All MongoDB Databases!!!

The other thing I learned is that an awful lot of sensitive data is being stored in MongoDB. The database is very flexible, and so there tend to be a lot of data feeds into the database. And those database feeds can include sensitive data that the MongoDB developers do not know about. I heard stories about MongoDB developers being surprised to find credit card numbers, social security numbers, email addresses, medical data and a lot of personally identifiable information (PII) being stored in the database.

MongoDB developers are really aware of the risks of sensitive data in the database. And they were hungry for information on how to protect it. Fortunately MongoDB Enterprise makes it incredibly easy to implement encryption and key management. In my session I was able to show how you can enable encryption in MongoDB with just a few commands. Customers upgrading from the open source Community Edition of MongoDB get access to this encryption facility and it is a delight.

MongoDB is Doing Encryption and Key Management Right

I’ve been impressed with the MongoDB implementation of encryption and key management from the start. First, MongoDB stepped up and implemented encryption right in the MongoDB database. There is no need for any third party file or folder encryption product to sit under the database. The encryption in MongoDB is based on industry standards (256-bit AES) and is tuned for performance. This is exactly what you want - your database vendor taking responsibility for encryption and owning the performance profile.

MongoDB also got the encryption key management part right. They based the key management interface on the open OASIS standard Key Management Interoperability Protocol (KMIP) in order to immediately support a broader community of key management vendors. That made it easier for us to certify our key management solution, Alliance Key Manager, for the MongoDB Enterprise platform. We are happy to support both Intel and POWER chip architectures for MongoDB deployments.

Lastly, just a personal note. I met a lot of MongoDB staff and managers at the conference. What a great bunch of people. They were energized and positive about what they are doing. Every company has its own character, and I found myself happy that we were engaged with this group of people.

Patrick

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

Fundamentals of MongoDB Encryption Key Management

Posted by Liz Townsend on Oct 10, 2017 9:11:00 AM

Encryption key management is the cornerstone of an effective encryption strategy. Without key management, encryption stands alone as only half of a solution. When you leave the keys to unlock your sensitive business and customer data exposed, then you expose your entire organization to the risk of data loss or theft. Luckily, MongoDB was born in the age of modern data security and developed their no-SQL database with the forethought and insight to incorporate strong encryption and key management solutions. This means that today, with MongoDB Enterprise, MongoDB customers can meet encryption and key management best practices fairly easily through implementing native encryption and deploying a third-party enterprise key management solution.

Introduction to Encrypting Data in MongoDB In order to enable customers to seamlessly implement enterprise encryption key management, MongoDB integrated a universal encryption key management protocol called the Key Management Interoperability Protocol (KMIP). Unlike many other legacy databases who have floundered over the years trying to help customers do strong key management, MongoDB enables customers to protect encryption keys out of the door with a number of tested and validated enterprise key management partners. To know if you’re encryption key management solution is compatible with MongoDB, check to see that it has implemented KMIP.

What is Enterprise Encryption Key Management?

Enterprise encryption key management includes both technological and policy-based controls that integrate to provide the highest level of security of an organization’s encryption keys. Both types of controls are important to protecting encryption keys.

On a technological and physical level, encryption keys should be stored in a logically or physically separate hardware or virtual key server, dedicated to performing key generation, storage, and distribution. Keys should be generated with a FIPS 104-2 validated pseudo-random number generator and stored in a secure key database. Keys used for encrypting data (data encryption keys, or DEKs) should be key-wrapped and encrypted using key encryption keys (KEKs)--these keys are only used to encrypt DEKs inside the secure key database.

Once encryption keys are generated and in use, they should be distributed for use over a secure Transport Layer Security (TLS) session using certificates to authenticate the user requesting the encryption key. An enterprise key management server should use the most recent, recommended version TLS--1.2--as vulnerabilities were discovered in TLS 1.1 and TLS 1.0.

Lastly, enterprise key managers should perform real-time backup and high availability functions to prevent downtime and ensure business continuity. This means that each key server should perform active-active mirroring to one or more high availability server as well as perform routine, automated backups to secure storage drives.

All of these functions are critical to meeting best practices and securing encryption keys. However, beyond the technology, an enterprise key manager should implement user rules and administrative options that enforce particular policies and policy-based best practices.

Encryption Key LifecycleA critical administrative component to encryption key management is the ability to manage the complete encryption key life cycle. The encryption key lifecycle is defined by the National Institute of Standards and Technology (NIST), which outlines all aspects of a key’s life including key generation, pre-activation, activation, distribution, revocation, post-activation, backup, and deletion.

The administrative console that allows access to these functions should also give the IT or security administrator the option to designate key users or user groups as well as set keys to automatically rotate after a certain number of days, months, or years. This is just one requirement for organizations who fall under security standards for some regulated industries such as the payment card industry. The Payment Card Industry Data Security Standard (PCI DSS) outlines key management requirements for card holders or processors that can typically only be met using an enterprise-level encryption key management solution.

To learn more about PCI-DSS and encryption key management, view this webinar.

Beyond managing the key lifecycle, an enterprise key manager should actively audit and log all activity and functions performed on the key management server and record these logs to an external event monitoring or logging server so that malicious activity can be detected in real time. Your key management solution should be compatible with common event monitoring solutions and export logs in standardized formats in real time.

Lastly, your key management solution should inherently enforce policy-based security functions that meet key management best practices such as separation of duties and dual control. Separation of duties ensures that no single person is in control of multiple key management procedures such as the client request and subsequent distribution of an encryption key. The person requesting the key and the person distributing the key should be two different people. Dual control prevents any key management process to be controlled by a single person; for example, two security administrators should be needed to authenticate access to the key server. While these policy-based controls are sometimes optional, they should always be available and easy to implement in your encryption key management solution.

MongoDB Likes Centralized Key Management

When MongoDB decided to implement KMIP, the decision was likely a deliberate strategy to help users to either leverage the enterprise key management solution they already have, or to use common key management solutions that are KMIP-compatible. The power of KMIP is that it enables users to truly achieve centralized key management. A historical problem surrounding key management was the difficulty of an organization to store and manage encryption keys across multiple platforms, operating systems, and often departments. By implementing KMIP, MongoDB continues to make implementing key management across an organization more and more easy and effective, and therefore more user-friendly, which is what MongoDB is best known for.

Without deploying a strong encryption key management solution, encryption of sensitive data on its own is considered ineffective. In the age of the cloud, deploying a key management solution alongside your data is equally important, and therefore having options for where you deploy it is an important factor in your key management strategy. An effective key management solution should not only be centralized across your organization, but it should meet your data where it’s at, whether that is the cloud, a virtual environment, or on-site hardware.

KMIP also enables MongoDB customers to choose their own KMIP compliant key management solution and maintain complete custody of the key management server, and therefore the keys. Whether deploying the key manager in the cloud, in a virtual environment, or on-site, owning a third-party KMIP compliant key manager allows users to retain total control of their keys without sharing access with cloud service provides or software vendors.

Lastly, when researching professional or enterprise key management solutions, check to see if the vendor has validated their solutions with NIST such as to the NIST FIPS 140-2 standard, uses standardized technology, and has been validated to meet PCI DSS or other regulatory certifications. These validations ensure that the technology has been tested by independent labs to the highest security standards.

In combination with a robust database encryption solution from MongoDB, your encryption key management solution will elevate your security position and total level of control.

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

MongoDB and Encryption Key Management for Compliance

Posted by Patrick Townsend on May 9, 2016 1:00:00 AM

MongoDB: Encryption Best Practices 

As the importance of encryption increases across the regulatory spectrum, it is heartening to see database vendors implementing encryption and encryption key management that meet security best practices. MongoDB Enterprise is one of the most popular modern databases and has given its customers the ability to quickly and effectively implement encryption and good key management at the level of the database itself. This means that MongoDB Enterprise customers can transparently implement encryption directly in the database without deploying third party file or volume based encryption products to accomplish this task. MongoDB customers enjoy rapid deployment of encryption, a unified management interface to the database, high performance encryption, and integrated encryption key management based on the industry standard Key Management Interoperability Protocol (KMIP).

Securing Data in MongoDB podcast By basing key management on the OASIS KMIP standard MongoDB is providing real benefits to their customers. These include:

  • Rapid implementation of key management with no need for developer resources.
  • No requirement for server-side software libraries, updates, and patching.
  • Secure encryption key retrieval services based on TLS.
  • Vendor neutrality for encryption key management services.
  • Vendor portability and avoidance of vendor lock-in.
  • Seamless migration from one key management solution to another.

MongoDB Enterprise is a case-study in the benefits of using open standards for encryption and key management. MongoDB’s customers can choose the key management solution that makes the most sense for them, and having choices reduces the cost of encryption key management.

MongoDB: Encryption Key Management Made Easy

Townsend Security's Alliance Key Manager solution works out of the box with MongoDB Enterprise to help customers meet compliance regulations which require encryption of sensitive data. It takes just a few minutes to deploy Alliance Key Manager and to configure MongoDB for key management. On first boot, Alliance Key Manager creates a set of strong encryption keys including a 256-bit AES key that can be used with MongoDB, and it creates a set of PKI certificates used for TLS authentication. The PKI certificates are copied to the MongoDB server to secure the connection to the key manager. A quick command or two from the MongoDB command line console and, Voila! Your MongoDB encryption key is now fully protected by a key encryption key on Alliance Key Manager. You have an encrypted MongoDB database and a highly redundant and recoverable encryption key management infrastructure. From the technical team at MongoDB:

“The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a file system perspective, and data only exists in an unencrypted state in memory and during transmission.”

After installing the key manager certificates on the server hosting the MongoDB database, here is an example of the command to enable encryption:

mongod --enableEncryption --kmipServerName akmmongo --kmipServerCAFile /etc/mongodb-kmip/AKMRootCACertificate.pem --kmipClientCertificateFile /etc/mongodb-kmip/AKMClientCertificate.pem --dbpath /var/lib/mongodb/

It’s that simple.

With Alliance Key Manager you have your choice of network-attached hardware security modules (HSMs), VMware virtual machines, and dedicated cloud instances in Microsoft Azure and Amazon Web Services. The key manager works the same way in all environments so you can even mix and match hardware, VMs, and cloud instances to achieve the level of security that is right for your organization. All instances of Alliance Key Manager are dedicated to you with no access by cloud service providers or third parties. Key custody remains exclusively under your control.

Many MongoDB customers deploy the database in VMware environments. Alliance Key Manager also runs in VMware as a virtual machine. You can deploy the key manager in a VMware security group and protect one or more instances of MongoDB across the entire VMware environment. If you are running on a VMware vCloud platform the same support is provided for key management.

For compliance, Alliance Key Manager is validated for PCI-DSS compliance in the VMware platform. This will help you achieve PCI-DSS compliance for your MongoDB database and applications. The PCI-DSS statement of compliance is here.

MongoDB is rapidly becoming the high performance, scalable, NoSQL database of choice for organizations large and small. As such it becomes a part of the critical infrastructure for business applications. Alliance Key Manager also implements high availability features such as automatic, real-time encryption key mirroring, and backup. For customers deploying the hardware version of Alliance Key Manager, there is redundancy at the hardware level with dual hot-swappable RAID disks, redundant power supplies, and redundant network interfaces. All of these features mean that your key management infrastructure will be resilient and reliable.

Alliance Key Manager will help you will meet common compliance regulations such as PCI-DSS, HIPAA, FFIEC, FISMA, the EU General Data Protection Regulation (GDPR), and other compliance schemes. Alliance Key Manager regardless of platform is based on the same FIPS 140-2 compliant software found in our enterprise level HSM. With no restrictions or license costs for client-side connections, you can protect as many MongoDB databases as you like with one Alliance Key Manager.

The product team at MongoDB did a great job of implementing encryption and key management for their customers. They deserve to be applauded for basing their solution on industry standards like KMIP. This will lower the bar for getting encryption right in the database. With Alliance Key Manager, getting encryption right means rapid deployment, conservation of developer resources, lower administration costs, and provable compliance.

A match made in techno-heaven.

Patrick

Securing Data in MongoDB

Topics: Alliance Key Manager, Compliance, MongoDB Encryption, MongoDB Encryption Key Management, MongoDB