Lead Security Engineer, MongoDB

Andreas Nilsson

Creating a single view:Securing the Application

How can we make data accessible securely?

Securing the Application: Agenda

Securing a Database Access Control

Data Protection Auditing

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

Timeline

Plan and design security as early as possible.

ImplementDesign Test Deploy

YES! NO!

Designing the Infrastructure

Access Control

Configure Authentication and Authorization.

ImplementDesign Test Deploy

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.

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

Enable Authentication

Built-in authentication methods

• Password challenge response

• x.509 certificates

Or integrate with existing authentication

infrastructure

Role Based Access Control

Builtin 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.509.

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

Note: Need to understand the application better

Data Protection

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

ImplementDesign Test Deploy

Data Protection End to End

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.

Data Protection - Transport EncryptionEncrypt communications (SSL)

Authenticate connections (x.509)

Data Protection - Encryption at rest

Alternatives

• Encrypt data client side

• Use partner solution for file and OS level encryption

Security Auditing

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.

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…

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. Disable any unnecessary interfaces

5. Lock down database files and minimize account

privileges

What did we talk about?

Securing a Database Access Control

Data Protection Auditing

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

Lead Security Engineer, MongoDB

Andreas Nilsson

#MongoDBWorld

Thank You