Creating a Single View Part 3: Securing Your Deployment


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Creating a Single View Part 3: Securing Your Deployment

  1. 1. Lead SecurityEngineer,MongoDB Andreas Nilsson #MongoDBWorld Creating a single view:
 Securing the Application
  2. 2. How can we make data accessible securely?
  3. 3. Securing the Application: Agenda Securing a Database Access Control Data Protection Auditing
  4. 4. 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
  5. 5. Timeline Plan and design securityas earlyas possible. ImplementDesign Test Deploy YES! NO!
  6. 6. Infrastructure matters
  7. 7. Access Control ConfigureAuthentication andAuthorization. ImplementDesign Test Deploy
  8. 8. Access Control Authentication-Who areyou in MongoDB? • Application user,administrator,backup job,
 monitoring agent. ! Authorization-What canyou do in MongoDB? • CRUD operations,configure the database,
 manage sharding,user management.
  9. 9. Enable Authentication Built-in authentication methods • Password challenge response • x.509 certificates Or integrate with existing authentication infrastructure
  10. 10. Enable Authorization Design • Determine which types of users exist in the system. • Match the users to MongoDB roles.Create anycustomized roles. Deployment • Start/restart MongoDB with access control enabled. • Create the desired users.
  11. 11.  Internal Access Control Server-server authentication use shared keyfile or x.509.
  12. 12. Access Control - Field Level Redaction Note: Need to understand the application better
  13. 13. Data Protection Data in transit and data at rest. ImplementDesign Test Deploy
  14. 14. Data Protection End to End
  15. 15. Data Protection - Transport Encryption • Possible to protect client-server,server-server communications with SSL. • Support for commerciallyand internallyissued x.509 certificates • Possible to run the server in FIPS 140-2 mode. • Support for mixed SSLand non-SSLclusters.
  16. 16. Data Protection - Transport Encryption Encrypt communications (SSL) Authenticate connections (x.509)
  17. 17. Data Protection - Encryption at rest Alternatives • Encrypt data client side • Use partner solution for file and OS level encryption !
  18. 18. Security Auditing Monitor securityevents in the system. ImplementDesign Test Deploy
  19. 19. Security Auditing
  20. 20. The Audit Log • Securityevents can be written to either the console,the syslog 
 or a file (JSON/BSON) • By default, all events are written to audit log when enabled. • Events include Authentication failures and some commands. • Access control is not required for auditing. • Theyare separate components.
  21. 21. Audit Log Properties • Can filter based off of different criteria – Action Type,TimeFrame,IPAddress/Port,Users • Events Have Total Order Per Connection • Audit Guarantees (AKAWrites/config) – Audit event written to disk BEFORE writing to the journal – Awrite will not complete before it has been audited
  22. 22. What did we talk about? Securing a Database Access Control Data Protection Auditing
  23. 23. Some last tips along the way… 1. Do not directlyexpose database servers to the Internet 2. Design and configure access control 3. Enable SSL 4. Disable anyunnecessaryinterfaces 5. Lock down database files and minimize account privileges
  24. 24. Next steps • MongoDB SecurityManual- ! • MongoDB SecurityWhitepaper- MongoDB_Security_Architecture_WP.pdf
  25. 25. Lead SecurityEngineer,MongoDB Andreas Nilsson #MongoDBWorld ThankYou