Securing Your MongoDB

Deployment

Andreas NilssonLead Security Engineer, MongoDB

3

The Art Of Securing A System

“If you know the enemy and know yourself,

you need not fear the result of a hundred battles.

If you know yourself but not the enemy,

for every victory gained you will also suffer a defeat.

If you know neither the enemy nor yourself,

you will succumb in every battle.”

Sun Tzu, The Art of War 500 BC

4

Securing The Application: Agenda

Securing a Database Access Control

AuditingData Protection

How can we make data accessible securely?

6

Timeline

Plan and design security as early as possible.

Hadoop

Event

Processing

Engine

Analytics

Execution

(R, Python & Pig)

Distributed

File System

HDFS

Stream Analytics

Yellow

Restricted Zone

Green

Controlled Zone

Web Application

REST Web Service

Even Processing

J2EE Tomcat

MongoDB to Hadoop

Connector

MongoDB to Hadoop

Connector

ETL

ETL

Orders

ETL

Operational

Data Store

MongoDB

Content

Management

System

Web Logs

Profiles

Reference Data

Real-time

Event Data

Designing the Infrastructure

8

Access Control

Configure Authentication and Authorization.

9

MongDB Configuration

Authentication - Who are you in MongoDB?

• Application user, administrator, backup job,

monitoring agent.

Authorization - What can you do in MongoDB?

• CRUD operations, configure the database,

manage sharding, user management.

10

Enable Authentication

Built-in authentication methods

• Password challenge response

• x.509 certificates

Or integrate with existing authentication infrastructure

11

Enable Access Control

Design

• Determine which types of users exist in the system.

• Match the users to MongoDB roles. Create any

customized roles.

Deployment

• Start/restart MongoDB with access control enabled.

• Create the desired users.

12

Role Based Access Control

Built-in roles

• read, readWrite, dbAdmin, clusterAdmin, root, etc..

User defined roles

• Customized roles based on existing roles and privileges.

Internal Authentication

Server-Server authentication

use shared keyfile

or x.5909.

14

Sharding, upgrading, and other fancy topics

Users in a sharded system

• live on the config servers, not the query routers (mongos)

• local shard (replica set) users can still exist

Users in 2.4

• located in different DBs and in a different format than:

Users in >= 2.6

• all reside in the admin DB and hence are always replicated.

15

Field Level Redaction - $redact

$redact

• New aggregation framework operator

• Conditionally filter user documents

Use cases

• Implement user-based document level, content filtering.

• Create egress filter, redacting sensitive information.

Access Control – Field Level Redaction

17

Data Protection

Encrypting data in transit (SSL) and data at rest.

Data Protection End to End

19

Transport Encryption with SSL

• Possible to protect client-server, server-server

communications with SSL.

• Support for commercially and internally issued x.509

certificates

• Possible to run the server in FIPS 140-2 mode.

• Support for mixed SSL and non-SSL clusters.

• Self-signed certificates provides no trust!

• Omitting to provide a CA file to MongoDB disables validation!

Data Protection – Transport Encryption

• Encrypt Communications (SSL)

• Authenticate connections (x.509)

21

Data Protection –Encryption at rest

Alternatives

• Encrypt data client side

• Use partner or independent solution for file and OS level

encryption

22

Security Auditing

23

The Audit Log

• Security events can be written to either the console, the

syslog or a file (JSON/BSON)

• By default, all security events are written to audit log when

enabled.

• Events include Authentication failures and some commands.

• Access control is not required for auditing.

• They are separate components.

24

Audit Log Properties

• Can filter based off of different criteria

– Action Type, TimeFrame, IP Address/Port, Users

• Events Have Total Order Per Connection

• Audit Guarantees (AKA Writes/config)

– Audit event written to disk BEFORE writing to the

journal

– A write will not complete before it has been audited

Some Final Tips

26

Some tips along the way

1. Do not directly expose database servers to the Internet

2. Design and configure access control

3. Enable SSL

4. Provide SSL CA files to the client and server as trust base

5. Disable any unnecessary interfaces

6. Lock down database files and minimize account privileges

27

DO YOU NEED: YES NO

Advanced security? ✓

Disaster Recovery? ✓

Monitoring for system performance and availability? ✓

Automated lifecycle management? ✓

Guaranteed response time SLA? ✓

Platform certification ✓

Enterprise Decision Checklist

28

MongoDB Enterprise Advanced

Features

MongoDB Ops Manager ✓

Advanced Security ✓

On-Demand Training ✓

SLA (24x365)1 hour

(faster times optional)

License Commercial

Price $10,000 / Server / Yr.

29

What Did We Talk About?

Securing a Database Access Control

AuditingData Protection

30

The Art Of Securing A System

“All men can see these tactics whereby I conquer,

but what none can see is the strategy out of which victory is

evolved.”

Sun Tzu, The Art of War 500 BC

31

Next Steps

MongoDB Security Manual

http://docs.mongodb.org/manual/core/security-introduction/

MongoDB Security Whitepaper -

http://info.mongodb.com/rs/mongodb/images/MongoDB_Se

curity_Architecture_WP.pdf

Thank You!

Andreas NilssonLead Security Engineer, MongoDB