SSecuring Your MongoDB Deployment
Download as PPTX, PDF2 likes967 views
The document outlines strategies for securing a MongoDB deployment, emphasizing access control, data protection, and auditing. Key components include enabling authentication, configuring roles, encrypting data in transit and at rest, and utilizing audit logs to track security events. It also provides essential tips for designing and implementing a secure MongoDB environment.
SSecuring Your MongoDB Deployment
- 1. Securing Your MongoDB Deployment Andreas Nilsson Lead Security Engineer, MongoDB
- 2. 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
- 3. Securing the Application: Agenda Securing a Database Access Control Data Protection Auditing
- 4. How can we make data accessible securely?
- 5. Timeline Plan and design security as early as possible. Design Implement Test Deploy YES! NO!
- 7. Access Control Configure Authentication and Authorization. Design Implement Test Deploy
- 8. 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.
- 9. Enable Authentication Built-in authentication methods • Password challenge response • x.509 certificates Or integrate with existing authentication infrastructure
- 10. 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.
- 11. Role Based Access Control Builtin roles • read, readWrite, dbAdmin, clusterAdmin, root, etc.. User defined roles • Customized roles based on existing roles and privileges.
- 12. Internal Authentication Server-server authentication use shared keyfile or x.509.
- 13. 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.
- 14. 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.
- 15. Access Control - Field Level Redaction Note: Need to understand the application better
- 16. Data Protection Encrypting data in transit (SSL) and data at rest. Design Implement Test Deploy
- 17. Data Protection End to End
- 18. 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!
- 19. Data Protection - Transport Encryption Encrypt communications (SSL) Authenticate connections (x.509)
- 20. Data Protection - Encryption at rest Alternatives • Encrypt data client side • Use partner or independent solution for file and OS level encryption
- 22. 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.
- 23. 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
- 24. Some final tips…
- 25. 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
- 26. What did we talk about? Securing a Database Access Control Data Protection Auditing
- 27. 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
- 28. 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
- 29. Thank You Andreas Nilsson Lead Security Engineer, MongoDB
Editor's Notes
- #3: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #4: Common process, tooling and management across the data lifecycle from ingestion to presentation Ensuring data provenance Supporting repeatable transformation processes Enabling reliable access for real-time query and reporting
- #5: Common process, tooling and management across the data lifecycle from ingestion to presentation Ensuring data provenance Supporting repeatable transformation processes Enabling reliable access for real-time query and reporting
- #6: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #8: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #9: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #10: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #11: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #12: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #13: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #14: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #15: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #16: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #17: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #19: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #20: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #21: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #22: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #26: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #27: Common process, tooling and management across the data lifecycle from ingestion to presentation Ensuring data provenance Supporting repeatable transformation processes Enabling reliable access for real-time query and reporting
- #28: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?
- #29: Call to action is about thinking where there is opportunity and what are you anchoring your data hub around?