For many organizations using MongoDB, implementing strong data security is top of mind. MongoDB leads the pack amongst common NoSQL database providers in providing easy-to-use and easy-to-implement native encryption and options for third-party encryption key management solutions. Utilize this guide to explore the key concepts of encrypting data in MongoDB and protecting encryption keys using enterprise encryption key management.
|Click here to view this eBook offline|
In fewer than ten years, MongoDB has risen to become a top player in nonrelational database providers, outcompeting and upsetting database monoliths such as Oracle Database and Microsoft SQL Server. Built on a model of low up-front operational costs alongside improved performance, MongoDB has become one of the most widely growing databases for organizations across retail, financial, and healthcare as well as startups.
Beyond cost and performance, a key component of MongoDB’s toolset is a robust plan to help customers achieve strong data security through encryption of data in flight and at rest, along with options to secure and manage encryption keys to meet industry compliance requirements and meet data security best practices.
If you are an organization who routinely considers security and compliance when purchasing third-party software, built-in security solutions can be extremely beneficial to your security and compliance strategy. However, like with any new software, questions around deployment and how to get the most out of native encryption tools may still be a barrier to implementation.
In order to paint both a broad and in-depth picture of how to best deploy encryption and encryption key management in MongoDB, let’s first start by discussing your options to encrypt data in your MongoDB database. If you’d like to first learn the fundamentals of encryption and key management before diving in, check out The Definitive Guide to Encryption Key Management Fundamentals.
MongoDB is a non-relational, noSQL database, meaning that users may enter data into MongoDB without defining tables and fields or establishing indexes. This type of data storage has many advantages including the ability to add information about a single entry that does not correspond to a column. NoSQL databases are the preferred repository for big data since they are designed for holding mass amounts of non-relational data and can scale rapidly to meet an organization’s various needs. While neither type of database is better than the other—only designed to perform different tasks—when it comes to encrypting data it’s good to know the similarities and differences.
SQL, or relational databases, are much like a spreadsheet. They have rows and columns, and the columns define the data that is entered into each row. When choosing how to encrypt data, a user can decide to encrypt the entire database file, encrypt individual columns, or encrypt data at the application layer prior to entering the data into the database. Ultimately, the most secure method is encrypting data at the application layer; however, the barriers to achieving this are often large: it is sometimes quite difficult, if not impossible, to embed encryption into a third-party application. For this reason, many organizations choose to encrypt the column or the database file. Encrypting at the column level may seem like the ideal choice since encrypting only a single column, and therefore less data, can decrease latency and overall performance impacts of the encryption. However, the likelihood that your relational database comes with native column-level encryption is low, and the cost of purchasing third-party column-level encryption is usually very high. Therefore, the most common method for encrypting databases is file-level encryption since the database can be transparently encrypted in storage and backup and is easily maintained by the database administrator.
NoSQL databases such as MongoDB run into some of the same issues. The main difference between the two is that since non-relational databases do not categorize data by columns, column-level encryption cannot be performed. Therefore, users may only encrypt data at the application or database-level. Again, since application-level encryption is often difficult and costly, whole database encryption on the storage engine is preferred. Luckily for MongoDB users, MongoDB provides native encryption so that users pay no extra cost to protect sensitive data. MongoDB also underwent extensive testing and has implemented additional features in order to optimize performance.
Encrypting Data in MongoDB
If you choose to encrypt your data, MongoDB offers solutions for encrypting data in motion as well as at rest.
For securing data in motion, all versions of MongoDB support TLS (Transport Layer Security) and SSL (Secure Socket Layer) to send and receive data over networks. TLS and SSL are the types of encryption commonly used to secure website traffic and file sharing. They are cryptographic protocols that secure data while it is traveling from one point to another; however, before the data is sent and after the data arrives at its endpoint, the data appears unencrypted, or “in the clear”. MongoDB provides ample documentation on how to configure TLS and SSL protocols using certificates and public and private key pairs, also called asymmetric key systems.
When considering encryption, MongoDB customers must consider both governmental and private regulations that require protecting sensitive information. For example, the Payment Card Industry (PCI) requires that credit card numbers be encrypted in storage. The Health Insurance Portability and Accountability Act and Health Information Technology for Economic and Clinical Health Acts (HIPAA/HITECH) require protection of Electronic Protected Health Information (ePHI). And there are many other regulations that require proper protection of Personally Identifiable Information (PII). Administrators who know their database stores sensitive data or PII should always encrypt the MongoDB database and use proper key management.
To encrypt data at rest, MongoDB Enterprise offers native, storage-based symmetric key encryption at the file level. Whole database encryption is also called Transparent Data Encryption (TDE). First offered in version 3.2, MongoDB utilizes the Advanced Encryption Standard (AES) 256-bit encryption algorithm, an encryption cipher which uses the same secret key to encrypt and decrypt data. MongoDB also provides the option to turn encryption on in “FIPS mode”, which means the encryption you use in MongoDB is tested to the National Institute of Standards and Technology Federal Information Processing Standard. Solutions validated to NIST FIPS are built to meet the highest standards and compliance. Learn more about the NIST compliance. The NIST FIPS encryption validation is often required for government and Department of Defense contractors; however, today most regulators consider NIST-validated AES encryption an industry standard and regulators typically require this standard of encryption to meet compliance regulations. Data-at-rest AES encryption is only available on MongoDB Enterprise and Atlas editions using the required WiredTiger storage engine.
When encrypting data natively using TDE, it is important to know how encryption keys are stored in MongoDB. When a database administrator encrypts a database file, a unique, private encryption key is generated. Each encrypted database file generates a new private symmetric key, and all keys in the storage device are encrypted using a master key. While database keys are stored alongside the encrypted data, the MongoDB never allows the master key to be stored on the same server as the encrypted data. This means that the database or security administrator must identify a secure storage location for the master encryption key. MongoDB strongly recommends a third-party enterprise key management solution; however, users have the option to store the key locally using a keyfile. This second option carries extreme risk, and is almost never recommended for key protection.
Encryption Performance in MongoDB
When choosing to encrypt your MongoDB database, users should consider performance. Performance impacts can become a primary concern for MongoDB users who store large amounts of data that customers access daily through front-end applications. When a banking or retail application must recall thousands or millions of records from a database daily, any latency or downtime can seriously impact business continuity and operations. This is why MongoDB has conducted performance tests using Intel Xeon X5675 CPUs. Running at its highest load, the encrypted storage engine experiences an average latency between 10%-20%, depending on the amount of data that a user is reading or writing to the database. When the user writes only large amounts of data to the database, the performance impacts fall on the higher side; however, in the more commons scenario of a user performing mostly read-only commands of the data, and the performance for the majority of organizations will likely fall between 5%-10%.
In order to optimize encryption, MongoDB encrypts each database using the encrypted storage engine WiredTiger. MongoDB acquired WiredTiger in 2014, and it became the default storage engine for MongoDB beginning with version 3.2. WiredTiger is optimized for high performance, scalability, and security—all features that align with MongoDB’s value proposition. Additionally, WiredTiger optimizes encryption further by encrypting the database file to the page level. This means that when a user reads or writes data to the encrypted database, the operation will only affect the page on which the data is stored, and not the entire database. This also reduces performance impacts by limiting the amount of data that must be encrypted and decrypted in order to encrypt or decrypt a single piece of data.
In summary, MongoDB offers a robust data-at-rest encryption solution that meets the security and performance needs for the majority of its users. The NIST FIPS options enable users to meet compliance requirements around encryption, and the advanced storage engine WiredTiger automatically supports your changing data security needs. While several third-party encryption solutions are available to MongoDB users, it is unlikely that these solutions will scale easily alongside your MongoDB deployment.
Encryption Key Management in MongoDB
Encryption key management is the method you use to protect and manage your encryption keys. The term “key management” confuses some people since simply writing down your encryption key on a sticky note and placing it in a locked drawer could be considered “managing” a key. However, in the context of this page, encryption key management refers to what data security specialists also referred to as “enterprise” or “professional” key management. Enterprise encryption key management should meet the key management framework and recommendations as outlined by NIST in Special Publications SP-800-130 and SP-800-57.
As defined by NIST, key management is the method in which a user protects encryption keys, manages the entire key lifecycle, distributes encryption keys, and implements additional layers of security to protect keys and limit user access.
MongoDB does not include an enterprise encryption key management solution, and users must purchase a solution from a third-party key management solution provider. MongoDB allows users to manage encryption keys using a third-party key management vendor through a standard key management protocol called the Key Management Interoperability Protocol (KMIP). KMIP is supported in MongoDB Enterprise Editions and enables customers to protect encryption using a number of tested and validated enterprise key management partners.
MongoDB provides the option to manage the master encryption key in a local file; however, this method of key protection is not recommended.
If you have begun to research third party key management solutions that will help you to do strong key management, look to see if the key management server (virtual or hardware) carries a NIST FIPS 140-2 and/or PCI certification. These certifications ensure that the key management software has been tested by third parties to ensure they meet the highest standards in key management technology.
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. Today, with MongoDB Enterprise, MongoDB customers can meet encryption and key management best practices easily through implementing native encryption and deploying a third-party enterprise key management solution.
What is Enterprise Encryption Key Management?
Enterprise encryption key management includes both technological and policy-based controls integrated to provide the highest level of security around an organization’s encryption keys. Both types of controls are important to protecting encryption keys.
Key Management Controls
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 only key management activities such as key generation, storage, and distribution. The key manager should house a FIPS 140-2 validated pseudo-random number generator to create new keys and store those keys 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 generated and in use, encryption keys 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 of 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. To accomplish this, each key server should perform active-active mirroring to one or more high availability servers 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 Lifecycle
A critical administrative component to encryption key management is the ability to manage the complete encryption key life cycle. NIST defines all stages of a key’s life including key generation, pre-activation, activation, distribution, revocation, post-activation, backup, escrow, and deletion. Through an administrative console, security administrators should be able to implement controls that allow access to keys by designating key users or user groups. They should also be able to set automatic key rotation policies so that keys are retired and rolled over after any period of time. These controls help organizations meet data security requirements 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.
Policy Based Controls
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.
Your key management solution should also 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 controls multiple key management procedures and subsequent distribution of an encryption key. The person requesting the key and the person managing the key should be two different people. Dual control prevents any single person from controlling a key management process. For example, two security administrators should be required 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.
KMIP for Centralized Key Management
When MongoDB decided to implement KMIP, the decision was likely a deliberate strategy to help users either leverage the enterprise key management solution they already own, or use a new KMIP-compatible key management solution.
KMIP 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 the KMIP standard, MongoDB contributes to easier implementation of key management throughout organizations, and therefore helps make key management more user-friendly, which is what MongoDB is best known for.
KMIP also enables MongoDB customers to choose their own KMIP compliant key management solution to 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 providers or software vendors.
Centralized Key Management in the Cloud
Without deploying a strong encryption key management solution, encryption of sensitive data on its own is considered ineffective. The same goes for deploying a key management solution alongside your data in the Cloud. Therefore, having options for where you deploy key management is an important factor in your key management strategy. An effective key management solution should not only centralize your key management, it should protect your data wherever it is located, whether in the Cloud, a virtual environment, or on-site hardware.
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.
Meeting Encryption & Key Management Compliance
Implementing data security in your organization can be a massive undertaking if you are trying to connect multiple systems across a dispersed organization. This undertaking can become even more daunting for companies that must meet industry-specific data security regulations. Not only do they have to do data security well, they often have to prove it to an auditor. Along with implementing complicated technology, organizations must keep detailed documentation of how each technology helps to meet different aspects of a certain regulation. A joy for certain detail-oriented, documentation-loving people, and a headache for those who want to implement technology without much fuss or bureaucracy.
Data security regulations serve a useful purpose however, which is to ensure and inform customers, partners, and stakeholders that you have in fact implemented various data security tools to protect not only your own organization, but them as well. Over the past 10 years, several highly-publicized data breaches have revealed that data security does not exist in a vacuum, even when you think it does. The interconnected nature of our businesses, the way they operate internally and externally, and the networks across organizations that ensure we stay connected 24/7 means that the holes into our systems are becoming harder and harder to plug. A small breach in one organization could easily lead to a devastating breach in another. Consider the Target breach of 2013, where hackers were able to enter the retail giant’s network through a network connection to their HVAC provider.
Meeting industry data security regulations improves trust, loyalty and customer and partner retention in industries like retail and banking where a hacker trying to get in is no longer a matter of “if”—it’s “when”. That’s why it’s critical to choose technologies that make your data security plan easier, not harder. Many tech companies strive for security certifications and validations that increase trustworthiness in their brand and help their customers to easily check off boxes in their compliance documentation, helping them to overcome their own headaches of meeting industry regulations.
Like in other aspects of its database, MongoDB does this well when it comes to encryption and encryption key management. By providing their customers with native database-level AES encryption and the opportunity to to use enterprise encryption key management solutions that have been validated by the National Institute of Standards in Technology (NIST), MongoDB helps customers achieve both security and compliance more easily than many of its competitors.
The National Institute of Standards and Technology (NIST)
When evaluating your MongoDB database solution alongside your encryption key management solution, it is important to look for certain certifications and validations. With MongoDB Enterprise, you already know that you will be using NIST-validated AES encryption. When looking at encryption key management solutions, the top validation to look for is NIST FIPS 140-2.
NIST FIPS 140-2
NIST FIPS 104-2 is a NIST standard that outlines security requirements for cryptographic modules (FIPS PUB 140-2). This publication outlines requirements for hardware and software modules that generate cryptographic outputs and are used to protect data. It covers requirements for encryption algorithms, implementation of those algorithms, operator roles and authentication, encryption key lifecycle requirements, physical security of the module, and operating system requirements. Levels of security, which can be assigned to the module, are also defined, and correspond to the physical security of the module, including tamper evident and tamper proof components.
Encryption key management systems that have achieved a NIST FIPS 140-2 validation have been tested to the standard by a third-party chartered under the National Voluntary Laboratory Accreditation Program (NVLAP), which tests and assesses how well an encryption key management solution conforms to NIST standards. These tests are notoriously difficult to pass, and take many months, or years, as well as many iterations of the module to achieve a passing grade. Encryption key management solutions that have passed these tests are considered the best solutions across the industry.
The Organization for the Advancement of Structured Information Standards (OASIS) is a standards body that promotes the development and adoption of data standard for technology including data security.
The second and perhaps equally important certification to look for when assessing encryption key management solutions for MongoDB is the OASIS Key Management Interoperability Protocol (KMIP). This protocol was designed to streamline key management integrations and meet consumers’ need to easily switch key management providers. Software providers such as MongoDB who have implemented client-side KMIP code and tested it for protocol conformity can integrate KMIP-compliant key management servers without any additional development. By implementing KMIP, MongoDB has sent the message that they are not only compatible with many enterprise-level encryption key management solutions, but that they respect their customers’ need to choose the key management solution that they prefer due to cost, flexibility of deployment, or features.
Encryption and Key Management Industry Standards and Regulations
NIST certifications cover requirements set forth by other industry-based data security regulations, as these industries look to NIST when developing requirements for encryption and key management. Below is a list of common industry compliance regulations that NIST and other security certifications will help you meet.
PCI DSS: Payment Card Industry Data Security Standards is a set of data security requirements set forth by the Payment Card Industry Security Standards Council for organizations that take and process cardholder data such as credit card numbers and the names and addresses associated with them. PCI DSS sections 3 outlines requirements for encryption and encryption key management protocols.
HIPAA/HITECH Act: The Health Insurance Portability and Accountability Act and Health Information Technology for Economic and Clinical Health Act outlines data security regulations for the healthcare industry. Unfortunately, HIPAA and the HITECH Act don’t specifically require encryption of sensitive data, but a backdoor “safe harbor” mandate states that if a healthcare organization or one of its Business Associates does experience a data breach, and protected health information (PHI) is not obscured using encryption or some other method, then that organization will be heavily penalized.
GLBA/FFIEC: The Gramm-Leach-Bliley Act under the Federal Financial Institutions Examinations Council (FFIEC) requires financial institutions to protect sensitive customer information. The FFIEC is clear that information security controls must be implemented to comply with a written plan to protect consumer data.
GDPR: While the European Union (EU) does not mandate that all organizations immediately encrypt sensitive data as part of the General Data Privacy Regulation (GDPR), there is an exclusion for subject data breach notification and financial penalties for those organizations who use encryption and other security methods to protect the data.
Luckily for MongoDB users across many industries, the ease of implementing encryption and key management tools in MongoDB will ultimately help them to meet specific requirements for most industry-based data security regulations. The important thing is to look for validations and certifications that a key management vendor has achieved to ensure that your solution will help you to meet compliance with ease. Especially look for solutions that have been validated for specific regulations, such as PCI-DSS, as these validations ensure that the technology has been tested by independent labs to the highest security standards and can often act as a “check box” for compliance.
Business Continuity Best Practices for Encryption and Key Management in MongoDB
This section will address business continuity best practices for encryption key management in MongoDB, and how hybrid deployments and autoscaling can improve business continuity in your MongoDB database architecture.
Introduction to Business Continuity
Almost all organizations today rely on software to operate, which means that the idea of software suddenly no longer being available can be a nightmare. Critical components of business operations rely heavily upon continual, real-time availability of both front-end and back-end software throughout the entire business day. Whether relying upon point-of-sale software to process thousands of customer credit and debit cards or utilizing a patient healthcare database from which a hospital must recall hundreds of patient details day in and day out, essential business operations rely almost entirely upon the functionality and availability of software. When encryption and encryption key management come into play in the equation of business continuity, this additional layer of complexity can often scare organizations away from implementing these tools. System administrators often ask, “What if encryption slows down my systems? What if I lose my encryption keys?” While these are reasonable questions, MongoDB customers can rest assured that their database has been built to mitigate these concerns by implementing business continuity best practices and partnering with encryption and key management vendors that integrate and match these best practices seamlessly.
Business Continuity Best Practices
When it comes to business continuity best practices for MongoDB, MongoDB already has you covered. Behind MongoDB’s database is a replica set architecture that provides continuous, real-time high availability (HA) for your data in the event that your database goes offline. In this architecture, your primary MongoDB database will automatically fail over to a secondary or tertiary database replica set. System administrators can deploy these HA databases in data centers across different geographical locations to improve likelihood of availability.
When handling encrypted data sets, system administrators must also consider the deployment architecture of their encryption key management solution. In the event of a MongoDB database failover to a replica set, the key management server must continue to administer and recall encryption keys to the failover database. In addition, the key management production server must deploy its own HA architecture to protect against failure of the key management system itself. In order to meet the same best practices that the MongoDB replica set architecture follows, the key management server must perform real time mirroring, load balancing, and automatic failover of all production key management activities. In addition, all automatic backup and system logging facilities must transfer to the HA architecture in a load balancing or failover event.
Real Time Mirroring
Mirroring a server in real time means that all activity occurring on a production server is replicated identically to an HA server, moment by moment, so that in the event of a failure on the production server, the mirrored server will take over production. Mirroring of both encryption keys and access policies is critical to continued availability. A key management server in a MongoDB environment should utilize real time mirroring to prevent downtime of the key server in the event of a power outage or overload of requests.
In the context of the MongoDB database and the KMIP key management interface, load balancing can be used to provide access to one or more failover key servers. The MongoDB key management configuration allows for only one key manager by definition. By using a load balancer you can easily define one or more failover key servers. This provides an additional layer of business continuity in the event the primary key server fails or becomes unreachable.
Should the production server ever partially or totally fail, automatic failover ensures that the designated secondary or tertiary HA server will begin to operate as production in order to maintain business continuity, until the production server comes back online.
Automatic Backup & System Logging
While a production key server should perform automatic backpacks and record system logs of all key server activity, the HA architecture should be able to continue backups and logging as well. A key management server’s ability to transfer keys from a production to HA server after a load balancing and failover event is critical when business continuity relies on zero production down time of the key management server.
A mixture of hardware, virtual, and cloud deployments of encryption key management production and HA servers has become the most common type of deployment. This is due to the lower start up costs and scalability of virtual and cloud environments. MongoDB users who choose a mixture of hardware, virtual, and cloud to deploy their database and HA architecture should choose a key management vendor that can do the same. One important benefit of deploying both the MongoDB HA servers as well as key management HA servers in a cloud or virtual environment, apart from the low cost and lower barriers to entry, cloud and virtual HA servers can be deployed in different geographical locations in order to protect against downtime caused by a server failure event in one geographical location. Microsoft Azure refers to these geographic locations as Availability Zones, and Amazon Web Services calls these Regions.
Autoscaling and Encryption Key Management
In order to maintain business continuity as the use of a mongoDB database increases and decreases over a period of time, database administrators take advantage of autoscaling. Autoscaling is an important feature of MongoDB that enables the database server to increase and decrease backend resources such as storage and memory as those resources are needed through the day.
Automatic scaling of resources prevents overloading a single server and allows organizations to scale their software operations without fear of disruption. Your encryption key management server should seamlessly integrate with MongoDB KMIP architecture and never interfere with autoscaling.
Generally, the considerations for sourcing encryption key management solutions for MongoDB will be similar to any relationship you develop with a vendor. The limited number of vendors in this space can limit the choices you have, but there are good solutions to choose from.
Vendors take a variety of approaches to licensing their key management solution. The main difference is in licensing constraints on the MongoDB side. You may start your first MongoDB encryption project with a rather limited scope. But as you continue to encrypt more sensitive data you may need to scale. Some encryption key management vendors license software based on the number of MongoDB instances that you place under protection. Others provide unlimited numbers of client – side licenses after you acquire the key manager. Be sure you understand the licensing terms of each solution you evaluate, and be sure to understand your long term needs.
Documentation on your MongoDB implementation will be crucial for long term success. In addition to documentation on the installation and configuration, be sure that your vendor provides documentation on key rotation, applying patches to the key manager, upgrading the key manager to new versions, and problem determination. All of these aspects should be covered in vendor documentation.
While key management solutions have become much simpler over time, you should still expect to receive some operational and technical training from your encryption and key management vendor. Gone are the days when this meant a lot of on-site educational expense. Modern encryption and key management solutions may require only a few hours of coaching and training to deploy and maintain. Be sure your encryption and key management vendor has a program to deliver training in a timely fashion.
Many businesses have devalued the customer support experience and this can present a problem for SQL Server users. When you have a problem with encryption or key management, it is likely to affect your application service levels. Before acquiring your SQL Server encryption solution be sure to schedule time with the customer support group. Do they have a formal problem tracking system? Do you have access to all problem tickets you raise? Does the customer support group respond in a timely fashion? Is there a 24/7 response number? All of the normal customer support questions you might ask are relevant to a MongoDB key management solution. We all know what really bad customer support looks like, be sure there is a good team standing behind the solution you deploy.
The modern Enterprise is often geographically distributed and this can make deployment and training difficult. While MongoDB encryption key management solutions can be simple to deploy and configure, you may want to be sure that you vendor can send staff on site for this type of support.
Alliance Key Manager
“A very cost effective solution in terms of performance, manageability, security, and availability. As a result, my company was quickly able to implement full database encryption leveraging the AKM as our key management solution in weeks. Comparable solutions could have taken months.”
The solution offers unparalleled security, flexibility and a affordability for all users of MongoDB Enterprise database. With no client-side software to install, customers can deploy Alliance Key Manager and install the PKI certificates on the database server to easily begin retrieving encryption keys.
Alliance Key Manager is FIPS 140-2 compliant and in use by over 3,000 organizations worldwide. The solution is available as a hardware security module (HSM), VMware instance, and in the cloud (Amazon Web Services, Microsoft Azure, and VMware vCloud). Townsend Security offers a 30-day, fully-functional evaluation of Alliance Key Manager.