Senior Solutions Architect, MongoDB

John Page

Securing Your MongoDB Deployment

Securing MongoDB: an Agenda.

Why do I Secure ?

How can I secure ?

When do I Secure ?

Why? – Trust No One

• The cyber blackmailer.

• The IPR thief.

• The identity thief.

• The Vandal – or careless explorer.

• The accident prone employee.

Why – we live in an insecure world.

• Zero day exploits.

• Lack of accountability for actions.

• Accidental exposure to data.

• Fear the enemy within.

Why – many people care.

• Your compliance requirements.

– Data Protection Act, Sarbanes Oxley.

• Due diligence requirements.

– RMADS

– ISO27001

• Reputational value.

• Protect yourself and your employees.

When do you implement security.

Plan and design security as early as possible.

ImplementDesign Test Deploy

YES! NO!

When – incrementally increase rights.

• Like Test Driven Development.

• Start with too much security – open up as little as

possible.

• Keep documentation – someone will want it.

• Automate – never manually adjust permissions.

Obey the principle of least privilege.

Why so early.

• Security is hard to add later – just like tests.

• The later you add it the more it costs.

• Retroactive security is hard to have faith in.

• Security – requirements, part of your design.

How do I secure my system.

• The whole system should be secured – not a part.

• Security has layers.

• Be aware – many people good and bad know more

than you.

– Auditors.

– Criminals.

– Pen testers do!

Layered security

Firewall

Transport Level Security

Environment Security

Authentication

Authorisation

Storage Security

Accountability

Application Functionality

The Network Firewall

• Think of it as a Perimeter fence.

• Assume it will be breached.

• Ensure it’s just as hard to get out as in.

• Don’t trust it – it’s no defense against many attacks.

• Do have one though, and make sure you understand

it.

Transport Encryption with SSL

• MongoDB 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 EncryptionEncrypt communications (SSL)

Authenticate connections (x.509)

Environmental Security

• Run MongoDB with the lowest rights.

• Do not have a password for that user.

• All admins need their own logons.

• Use sudo and sudo logging.

• Remove MongoDB binaries / change permissions.

• Restrict permissions on everything.

• Avoid root.

Data Protection - Encryption at rest

Alternatives

• Encrypt data client side

• Use partner or independent solution for file and

OS level encryption

Database Authentication

Built-in authentication methods

• Password challenge response

• x.509 certificates

Or integrate with existing authentication

infrastructure

Database Access Control (RBAC)

• Create a new role for your application user.

• Give them NO permissions.

• Open up until the application works.

• Repeat for each process – e.g. backup.

• Human users should get suitable permission sets – don’t restrict too much.

• Keep a system high user – and a password in a safe.

 Internal Access Control

Server-server authentication use shared keyfile

or x.509.

Security Auditing

The Audit Log

• Log to console, syslog or file (JSON/BSON)

• Always log to a secured location

• Events include authentication, commands and CRUD.

• Access control is not required, authentication is

Audit Log – details.

• Can be filtered by different criteria

• Events are ordered within a connection.• Audit event written to disk BEFORE writing to the

journal• A write will not complete before it has been

audited

Application ‘security’ - $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

Walkthrough a secure System - Firewall

Walkthrough a secure System - Transport

Walkthrough a secure System - Environment

Walkthrough a secure System - Storage

Walkthrough a secure System - Authentication

Walkthrough a secure System - Authorisation

Walkthrough a secure System - Auditing

Walkthrough a secure System - limitation

The Art of Securing a System

Security is not an Art – it’s a science.

“If I have seen further it is by standing on the shoulders of Giants”

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

Senior Solutions Architect, MongoDB

John Page (@johnlpage)

Thank You