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

MongoDB Encryption Key Rotation

Posted by Patrick Townsend on Jul 9, 2018 11:11:00 AM

Every now and then you get something wrong and have to eat crow. Well, it’s my turn. Caw!

Encryption & Key Management for MongoDB eBook At the MongoDB World 2018 conference I gave the security session on encryption key management for MongoDB. I love doing this session because MongoDB really makes getting encryption key management right by exposing a Key Management Interoperability Protocol (KMIP) interface available to plug in a key manager. I talked about the MongoDB interface, about the principles of good encryption and key management, and then demonstrated how easy it is to deploy our Alliance Key Manager with MongoDB. It takes just a few minutes for a complete implementation.

There were really good questions at the end of the session. One of those questions was:

“How do you rotate the encryption keys for MongoDB?” 

Key rotation is, of course, required under the PCI Data Security Standard (PCI DSS) and is a good security practice. The National Institute of Standards and Technology (NIST) addresses this in their Key Management Best Practices document Special Publication 800-57. See the section on crypto-periods for data encryption keys.

This is where I ran off the rails. It was my impression that you had to create a new MongoDB database, encrypt it with a new key, and then copy the data into the new database. And that was not right! That is the procedure for some databases, but not MongoDB.

Luckily Davi Ottenheimer, MongoDB’s head of security, and a MongoDB engineer were right there to set me straight.

Fortunately you do NOT have to create a new MongoDB database in order to roll the data encryption key. It is actually much simpler. Here are the steps you use to roll the data encryption key (extracted from the MongoDB documentation for KMIP key management):

1) Rotate the master key for the secondary members of the replica set one at a time.

a. Restart the secondary, including the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip. If the member already includes the --kmipKeyIdentifier option, either update the --kmipKeyIdentifier option with the new key to use or omit to request a new key from the KMIP server:

mongod --enableEncryption --kmipRotateMasterKey \

--kmipServerName <KMIP Server HostName> \

--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

If using a configuration file, include the security.kmip.rotateMasterKey.

b. Upon successful completion of the master key rotation and re-encryption of the database keystore, the mongod will exit.

c. Restart the secondary without the --kmipRotateMasterKey parameter. Include any other options specific to your configuration, such as --bind_ip.

mongod --enableEncryption --kmipServerName \

<KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem

 If using a configuration file, remove the security.kmip.rotateMasterKey.

2) Step down the replica set primary.

Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

 rs.stepDown()

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, rotate the master key for the stepped down member:

a. Restart the stepped-down member, including the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip. If the member already includes the --kmipKeyIdentifier option, either update the --kmipKeyIdentifier option with the new key to use or omit.

mongod --enableEncryption --kmipRotateMasterKey \

--kmipServerName <KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem 

If using a configuration file, include the security.kmip.rotateMasterKey.

b. Upon successful completion of the master key rotation and re-encryption of the database keystore, the mongod will exit.

c. Restart the stepped-down member without the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip.

mongod --enableEncryption --kmipServerName \

<KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem

If using a configuration file, remove the security.kmip.rotateMasterKey setting.

This is pretty easy. You can find the documentation online at the MongoDB documentation site.

If you attended my class in New York, or if you are implementing encryption and key management for MongoDB, I hope you find this helpful. As soon as the recording of the class is available I’ll send it to you in a new blog.

Thanks to all of the MongoDB team members who put on the MongoDB World in New York! It was an exciting two days and I always learn a lot at the conferences.

Patrick

Encryption & Key Management for MongoDB eBook

Topics: MongoDB Encryption Key Management, MongoDB

Press Release: MongoDB, Townsend Security Announce Certified Encryption Key Management

Posted by Luke Probasco on Nov 16, 2017 9:11:00 AM

Townsend Security, a MongoDB Technology Partner, achieves MongoDB Enterprise Certification for Alliance Key Manager.

mdb-enterprise-certified-technology-partner_300x660.pngToday Townsend Security, a leading authority in data privacy solutions, and MongoDB, the database for modern applications, today announced Alliance Key Manager has certified against MongoDB Enterprise.

MongoDB Enterprise simplifies data protection by providing native encryption of data at rest. When coupled with Townsend Security’s flagship encryption key management solution, Alliance Key Manager, meeting compliance (PCI DSS, HIPAA, etc.) and security standards is even easier and more affordable for large as well as small organizations.      

By centralizing the secure storage of encryption keys and governance with a FIPS 140-2 compliant solution, MongoDB users can easily generate a master encryption key and begin encrypting database keys using native command line operations with Alliance Key Manager.

Alliance Key Manager for MongoDB gives organizations control of key management in a convenient and fast deployment option. With this joint solution it is simple for customers to encrypt their data in MongoDB Enterprise,” said Davi Ottenheimer, Product Security, MongoDB.

Encryption and key management have become a critical aspect of security and compliance management. Protecting encryption keys mitigates the risk of data breaches and cyber-attacks, as well as protects an organization’s brand, reputation and credibility. Alliance Key Manager addresses these needs by helping enterprises reduce risk, support business continuity, and demonstrate compliance with regulations like PCI DSS, HIPAA, GDPR, etc. 

“In the wake of some of the largest data breaches ever, data security is a top concern for businesses large and small. MongoDB has made it easier than ever for enterprises to secure private data with encryption and key management,” said Patrick Townsend, Founder & CEO, Townsend Security. “With Alliance Key Manager for MongoDB, MongoDB Enterprise customers have access to cost-effective, simplified encryption key management.”

Alliance Key Manager supports seamless migration and hybrid implementations, using the same FIPS 140-2 compliant technology. MongoDB users can deploy Alliance Key Manager as a hardware security module (HSM), VMware instance, or cloud-native Amazon Web Services (AWS) EC2 instance or Microsoft Azure virtual machine. Additionally, Alliance Key Manager supports hybrid and cross-cloud deployments. The solution is available for a free 30-day evaluation.

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption Key Management, MongoDB, Press Release

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