securing your mongodb deployment
DESCRIPTION
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.TRANSCRIPT
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