ENCRYPTION & KEY MANAGEMENT FOR MONGODB · 2014, and it became the default storage engine for MongoDB beginning with version 3.2. WiredTiger is optimized for high performance, scalability,

ENCRYPTION & KEY MANAGEMENT FOR MONGODB

THE DEFINITIVE GUIDE

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.

“

Page 2

Page 3

CONTENTS

Introduction 4

NoSQL Databases 5

Encrypting Data in MongoDB 6

Encryption Performance 8

Encryption Key Management in MongoDB 9

What is Enterprise Encryption Key Management? 10

KMIP for Centralized Key Management 12

Meeting Compliance 13

Business Continuity 17

Vendor Considerations 20

Alliance Key Manager 22

Page 4

INTRODUCTION

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.

eBook:The Definitive Guide to Encryption Key Management Fundamentals

DOWNLOAD

Page 5

NOSQL DATABASES

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.

Page 6

ENCRYPTING DATA IN MONGODB

IF YOU CHOOSE TO ENCRYPT YOUR DATA,

MongoDB offers solutions for encrypting data in

motion as well as at rest.

DATA IN MOTION ENCRYPTIONFor 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.

DATA AT REST ENCRYPTIONTo 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. 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.

Page 7

ENCRYPTING DATA IN MONGODB (CONT)

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.

WHITE PAPER:

Introduction to Encrypting Data in MongoDB

DOWNLOAD

White Paper

www.townsendsecurity.com

724 Columbia Street NW, Suite 400 • Olympia, WA 98501 • 360.359.4400 • 800.357.1019 • fax 360.357.9047 • www.townsendsecurity.com

MONGODB WHITE PAPER

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

Page 8

PERFORMANCE

ENCRYPTION PERFORMANCE

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.

[Read more about MongoDB’s performance testing]

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.

“The performance for the majority of organizations will likely fall between 5-10%.”

Page 9

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.

Encryption & Tokenization:

Key Management:

Secure Communications:

Logging:

Authentication

eBook

Podcast

Video

Blog

White Paper

Solution Brief/Data Sheet

Case Study

Resource Kit

Page 10

WHAT IS ENTERPRISE 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 CONTROLSOn 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 LIFECYCLEA 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.

EncryptionKey

Lifecycle

Key Generation

Pre-Activation

Activation

Expiration

Post-Activation

Escrow

Destruction

Page 11

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 CONTROLSBeyond 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.

WHAT IS ENTERPRISE KEY MANAGEMENT? (CONT)

“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.”

Page 12

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 CLOUDWithout 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.

Alliance Key Manager

CloudOn-Premise

VM

Virtualized

Your Key Management Provider Should Foster Growth

For greatest flexiblity, choose an EKM Provider that works well on-premise,in virtualized, and in cloud environments

Page 13

MEETING 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.

Page 14

MEETING COMPLIANCE (CONT)

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-2NIST 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 life cycle

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.

OASIS KMIPThe 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.

Page 15

MEETING COMPLIANCE (CONT)

ENCRYPTION AND KEY MANAGEMENT INDUSTRY STANDARDS & REGULATIONSNIST 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

WHITE PAPER:

What Data Needs Encrypted In MongoDB? A Checklist for Meeting Compliance

DOWNLOAD

White Paper

www.townsendsecurity.com

724 Columbia Street NW, Suite 400 • Olympia, WA 98501 • 360.359.4400 • 800.357.1019 • fax 360.357.9047 • www.townsendsecurity.com

MONGODB WHITE PAPER

Page 16

MEETING COMPLIANCE (CONT)

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.

“When evaluating your MongoDB database solution alongside

your encryption key management solution, it is important to look for

certain certifications and validations.”

Page 17

BUSINESS CONTINUITY

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 CONTINUITYAlmost 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.

“When it comes to business continuity best practices for MongoDB, MongoDB already has you covered.”

BUSINESS CONTINUITY BEST PRACTICESWhen 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

Page 18

BUSINESS CONTINUITY (CONT)

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.

Load Balancing

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.

Automatic Failover

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.

HYBRID DEPLOYMENTSA 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

Page 19

BUSINESS CONTINUITY (CONT)

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 & ENCYRPTION KEY MANAGEMENTIn 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.

“A mixture of hardware, virtual, and cloud

deployments of encryption key management

production and HA servers has become the

most common type of deployment.”

Page 20

VENDOR CONSIDERATIONS

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.

LICENSINGVendors 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 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.

DOCUMENTATIONDocumentation 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.

TRAININGWhile 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 key management vendor has a program to

deliver training in a timely fashion.

CUSTOMER SUPPORTMany businesses have devalued the customer

support experience and this can present a problem

for MongoDB users. When you have a problem with

encryption or key management, it is likely to affect

your application service levels. Before acquiring your

MongoDB encryption key management 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.

Page 21

SERVICESThe 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.

“Be sure you understand the licensing terms of each solution you evaluate, and be sure to understand your long term needs.”

VENDOR CONSIDERATIONS (CONT)

MORE INFORMATION

WEBINAR:SIMPLIFIED ENCRYPTION & KEY MANAGEMENT WITH MONGODB

VIEW WEBINAR

Page 22

“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.”- CERTAIN

TOWNSEND SECURITY IS HELPING MONGODB

Enterprise customers with Alliance Key Manager. The

solution offers unparalleled security, flexibility and

affordability for all users of MongoDB Enterprise data-

base. 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.

30-DAY EVALUATION

ALLIANCEKEY MANAGER

REQUEST EVALUATION

• FIPS 140-2 and KMIP compliant enterprise key manager

• Available as an HSM, VMware, or in the cloud (AWS, Microsoft Azure)

• Affordably priced, with no restrictions on server connections or client side applications

• Meet compliance regulations like PCI DSS, HIPAA, GDPR, and more

ALLIANCE KEY MANAGER

Page 23

TOWNSEND SECURITY CREATES DATA PRIVACY

solutions that help organizations meet evolving

compliance requirements and mitigate the risk of data

breaches and cyber-attacks. Over 3,000 organizations

worldwide trust Townsend Security’s NIST and FIPS

140-2 compliant solutions to meet the encryption and

key management requirements in PCI DSS, HIPAA/

HITECH, FISMA, GLBA/FFIEC, SOX, GDPR and other

regulatory compliance requirements.

CONTACT TOWNSEND SECURITY

www.townsendsecurity.com

@townsendsecure

724 Columbia Street NW, Suite 400

Olympia, WA 98501

360.359.4400

“Townsend is a full service security provider that remains on the cutting

edge and has demonstrated exceptional customer service.”

- CSU FRESNO

ABOUT TOWNSEND SECURITY