Security is more critical than ever with new computing environments in the cloud and expanding access to the internet. There are a number of security protection mechanisms available for MongoDB to ensure you have a stable and secure architecture for your deployment. We'll walk through general security threats to databases and specifically how they can be mitigated for MongoDB deployments. Topics will include general security tools and how to configure those for MongoDB, an overview of security features available in MongoDB, including LDAP, SSL, x.509 and Authentication.

1. Securing Your MongoDB
Deployment
John Page
Senior Solutions Architect,MongoDB

2. Securing MongoDB: an Agenda.
Why do I Secure ?
When do I Secure ?
How can I secure ?

3. Why? – Trust No One
• The cyber blackmailer.
• The IPR thief.
• The identity thief.
• The Vandal – or careless explorer.
• The accident prone employee.

4. Why – we live in an insecure world.
• Zero day exploits.
• Lack of accountability for actions.
• Accidental exposure to data.
• Fear the enemy within.

5. Why – many people care.
• Your compliance requirements.
– Data Protection Act, Sarbanes Oxley.
• Due diligence requirements.
– RMADS
– ISO27001
• Reputational value.
• Protect yourself and your employees.

6. When do you implement security.
Plan and design security as early as possible.
Design Implement Test Deploy
YES! NO!

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

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

9. 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!

10. Layered security
Firewall
Transport Level Security
Environment Security
Storage Security
Authentication
Authorisation
Accountability
Application Functionality

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

12. 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!

13. Data Protection - Transport Encryption
Encrypt communications (SSL)
Authenticate connections (x.509)

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

15. Data Protection - Encryption at rest
Alternatives
• Encrypt data client side
• Use partner or independent solution for file and OS level
encryption

16. Database Authentication
Built-in authentication methods
• Password challenge response
• x.509 certificates
Or integrate with existing authentication infrastructure

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

18. Internal Access Control
Server-server authentication use shared keyfile or x.509.

19. Security Auditing

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

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

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

23. Access Control - Field Level Redaction
Note: Need to understand the application better

24. Walkthrough a secure System - Firewall

25. Walkthrough a secure System - Transport

26. Walkthrough a secure System - Environment

27. Walkthrough a secure System - Storage

28. Walkthrough a secure System - Authentication

29. Walkthrough a secure System - Authorisation

30. Walkthrough a secure System - Auditing

31. Walkthrough a secure System - limitation

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

33. Next steps
• MongoDB Security Manual -
http://docs.mongodb.org/manual/core/security-introduction/
• MongoDB Security Whitepaper -
http://info.mongodb.com/rs/mongodb/images/MongoDB_Security_Archi
tecture_WP.pdf

34. Thank You
John Page (@johnlpage)
Senior Solutions Architect, MongoDB