Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS Application
•Download as PPTX, PDF•
24 likes•27,266 views
MongoDB introduces new capabilities that change the way micro-services interact with the database, capabilities that are either absent or exist only partially in high-end commercial databases such as Oracle. In this session I will share from my experiences building a cloud-based, multi-tenant SaaS application with extreme security requirements. We will cover topics including considerations for storing multi-tenant data in the database, best practices for authentication and authorization, and performance considerations specific to security in MongoDB.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS Application
Similar to Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS Application (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS Application
- 1. 1© 2014 Cisco and/or its affiliates. All rights reserved. Securing MongoDB to servean AWS based multi tenant security fanatic SaaS application Doron Levari, Data Architect, Cisco
- 2. © 2014 Cisco and/or its affiliates. All rights reserved. 2
- 3. © 2014 Cisco and/or its affiliates. All rights reserved. 3 FW1 FW2 FW4 Cloud Customer Datacenter(s) Onboard Customer Discover CPE Normalize configuration and Policy Add new Device Orchestrate FW3 Simplify, unify, and orchestrate policy for Cisco security products from the cloud
- 4. © 2014 Cisco and/or its affiliates. All rights reserved. 4 REST API Micro Services Device plugins Configuration Classification Normalization
- 5. © 2014 Cisco and/or its affiliates. All rights reserved. 5 • Why MongoDB? • Why security? • Security considerations • Tenant isolation considerations • Implementation of security with MongoDB Encryption of data at rest and at flight Strong authentication Fine grained authorization Audit trail
- 6. © 2014 Cisco and/or its affiliates. All rights reserved. 6 • Agile development, agile deployments • Data requirements are decent 1000s of corporates, 10Ks of registered users, 1M of devices Size ~5 TB • Store raw config files Tag inside config files full text search • JSON is all over the app REST APIs, JavaScript, D3.JS • Simplicity! MMS is awesome!
- 7. © 2014 Cisco and/or its affiliates. All rights reserved. 7 • Our clients Corporates and their sysadmins, security admins Security experts • Sell more products, $$$ Convince our customers to let us keep the keys to their kingdom Meet security compliance (such as PCI-DSS) • Stay alive as a business • Address threats Leaked or hijacked passwords, impersonation Network sniffing Memory or storage dumping • Isolate, detect, prevention
- 8. © 2014 Cisco and/or its affiliates. All rights reserved. 8 • Encryption of data at rest and at flight • Strong authentication • Fine grained authorization • Audit trail • We need all of the above in a multi tenant application • Tenant isolation
- 9. © 2014 Cisco and/or its affiliates. All rights reserved. 9 Mongod Replica Set Mongod Replica Set Acme Foo Bar Acme Foo Bar Mongod Replica Set All Data Mongod Replica Set Acme Mongod Replica Set Foo Mongod Replica Set Bar Database per tenant Collection(s) per tenant Shared collections Cluster per tenant Isolated Shared
- 10. © 2014 Cisco and/or its affiliates. All rights reserved. 10 Isolated Shared Cluster per tenant Database per tenant Collections per tenant Shared collections Less Prone to query injection and bugs Disk, memory, CPU isolation Data at rest encryption done storage level, key per tenant Tenant Portability (carve out a tenant to another stack) Scale out by horizontal partitioning by tenant ID Sharding by tenant ID Sharding big tenants by a secondary key Cross-tenant queriesProgrammatic aggregation or ETL to an analytical platform Database level RBAC and Audit No resource isolationDisk, memory isolation Application-level encryption would blind the database Common database user conn Per tenant connection with x.509 Certificate, key per tenant Common database user conn Diminishing low cost per tenantHigh constant cost per tenant SecurityOperations $
- 11. © 2014 Cisco and/or its affiliates. All rights reserved. 11 • It was a happy medium when it came to operations and cost- effectiveness • We’re B2B aiming for customers in the Ks not Ms • We just care too much about security Need to exceed our customers expectations • We don’t care much about cross-tenant queries Our customers would see it as a security risk! • Now, we have to implement these ----> https://www.pcisecuritystandards.org/security_standards/documents.php?document=pci_dss_v2-0#pci_dss_v2-0
- 12. © 2014 Cisco and/or its affiliates. All rights reserved. 12 • At rest storage.directoryPerDB Stores files of each database in its own folder in the data directory With simple Linux gymnastics we can: Create multiple volumes, encrypt each one with a different key Mount those volumes as directories under the data root directories • At flight net.ssl.mode = requireSSL SSL for Client Server communications SSL for Server Server communications (replica set) http://docs.mongodb.org/manual/reference/configuration-options/#storage.directoryPerDB http://docs.mongodb.org/manual/tutorial/configure-ssl/
- 13. © 2014 Cisco and/or its affiliates. All rights reserved. 13 • I need each tenant to authenticate with different credentials to MongoDB • This means: every working thread connects to MongoDB with different database credentials • Hmm… • Will I still be able to leverage connection pools‽ • Will I be able to make it generic in a low-layer app infrastructure?
- 14. © 2014 Cisco and/or its affiliates. All rights reserved. 14 App Server Connection Pool Worker threads Mongod Replica Set All Data REST Call SpringFramework Browser/Client Authorization Server Authenticate Get OAuth Token REST Call Send OAuth Token Browser/Client
- 15. © 2014 Cisco and/or its affiliates. All rights reserved. 15 • MongoDB completely separated the actions of "connect” and “authenticate” Connect: heavy operation of creating the channel to the database Authenticate: lightweight operation of creating an authenticated context • Leverage connection pools Upon appserver startup, a pool of “blank” connections is created A connection borrowed from the pool is authenticated as the current tenant • Result: each database session is authenticated when-needed, and with different credentials http://docs.mongodb.org/manual/reference/method/db.auth
- 16. © 2014 Cisco and/or its affiliates. All rights reserved. 16 • Creating and closing of blank connections to Mongo: Repetitions: 10000: Connection avg (ms): 0.580, Close avg (ms): 0.218 Repetitions: 10000: Connection avg (ms): 0.539, Close avg (ms): 0.196 Repetitions: 10000: Connection avg (ms): 0.604, Close avg (ms): 0.223 • Authentication (creating MongoTemplate serial random context switches between 5 tenants): Repetitions: 10000: MongoTemplate avg (ms): 0.171, Read avg (ms): 0.309 Repetitions: 10000: MongoTemplate avg (ms): 0.166, Read avg (ms): 0.306 Repetitions: 10000: MongoTemplate avg (ms): 0.174, Read avg (ms): 0.309
- 17. © 2014 Cisco and/or its affiliates. All rights reserved. 17 Mongod Replica Set Acme Foo Bar API Server Connection Pool Worker threads MT Infrastructure Authorization Server Authenticate Get OAuth Token REST Call SpringFramework Send OAuth Token Key Manager Use Oauth token to retrieve a key to authenticate to the database and encrypt traffic. Connections in the connection pool are unauthenticated. Requires key to access DB. Browser/Client
- 18. © 2014 Cisco and/or its affiliates. All rights reserved. 18 • Mongo object hold the pool of blank connections • A MongoTemplate object is created with the Mongo object and with a database name and UserCredentials MongoTemplate object is used to access the database MongoTemplate object is discarded at the end of use, blank connection is returned to pool http://docs.spring.io/spring-data/mongodb/docs/current/api/org/springframework/data/mongodb/core/MongoTemplate.html <mongo:mongo replica-set="mongo0:27000,mongo1:27000,mongo2:27000"> <mongo:options connections-per-host="8" threads-allowed-to-block-for-connection-multiplier="4" connect-timeout="1000" max-wait-time="1500" socket-keep-alive="true" slave-ok="true" write-number="1" write-timeout="0" write-fsync="true"/> </mongo:mongo> ---- @Autowired private Mongo mongo; MongoTemplate mongoTemplate = new MongoTemplate(mongo, tenantDatabase, new UserCredentials(tenantUser, tenantPassword));
- 19. © 2014 Cisco and/or its affiliates. All rights reserved. 19 • Ah with authenticated users – it’s easy! • MongoDB employs Role-Based Access Control (RBAC) • A user is granted one or more roles that determine the user’s access to database resources and operations http://docs.mongodb.org/manual/core/authorization/ db.createRole( { role: "accessSomeColls", privileges: [ { resource: { db: "acme", collection: "inventory" }, actions: [ "find", "update", "insert" ] }, { resource: { db: "acme", collection: "orders" }, actions: [ "find" ] } ], roles: [] } ) db.grantRolesToUser( "acme", [ "accessSomeColls" ])
- 20. © 2014 Cisco and/or its affiliates. All rights reserved. 20 • Cool important feature in MongoDB Enterprise • Can audit everything schema (DDL) replica set authentication and authorization general operations • Audit Guarantee Before adding an operation to the journal, MongoDB writes all audit events on the connection that triggered the operation • By default, the auditing system records all these operations Filters are set up to restrict events captured http://docs.mongodb.org/manual/core/auditing/ http://docs.mongodb.org/manual/reference/audit-message/ http://docs.mongodb.org/manual/reference/audit-message/#audit-event-actions-details-and-results Audit Message Structure: { atype: <String>, ts : { "$date": <timestamp> }, local: { ip: <String>, port: <int> }, remote: { ip: <String>, port: <int> }, users : [ { user: <String>, db: <String> }, ... ], roles: [ { role: <String>, db: <String> }, ... ], param: <document>, result: <int> }
- 21. © 2014 Cisco and/or its affiliates. All rights reserved. 21 • Sample config • Additional atype examples: authenticate, authCheck, createCollection, createDatabase, createIndex, renameCollection, createUser, grantRolesToUser, createRole, grantPrivilegesToRole, replSetReconfig, shardCollection, addShard, shutdown http://docs.mongodb.org/manual/tutorial/configure-auditing/#audit-filter security: authorization: enabled auditLog: destination: file format: JSON path: data/db/auditLog.json filter: '{ atype: "authCheck", "param.command": { $in: [ "insert", ”remove" ] } , “param.ns”: ”acme.devices” }' setParameter: { auditAuthorizationSuccess: true }
- 22. © 2014 Cisco and/or its affiliates. All rights reserved. 22 • Why MongoDB? • Why security? • Security considerations • Tenant isolation considerations • Implementation of security with MongoDB Encryption of data at rest and at flight Strong authentication Fine grained authorization Audit trail
- 23. © 2014 Cisco and/or its affiliates. All rights reserved. 23 Doron Levari https://www.linkedin.com/in/doronlevari @doron_levari
Editor's Notes
- First a little bit about myself, some numbers and data about me, they all true and tell something, after all I’ve been with data and databases my entire life…….
- Data velocity is moderate not high... Agile – there is no other way! I’m not a guy that is afraid of complex databases but Application enable optimistic locking, no need for database (pessimistic) locks No updates, always inserts with versions
- Incidents... We used to be all about resiliency, stability - but so many things have happened, so many incidents – security is a must... Threats are there. Things will go wrong. These are mere examples… Analyze the perpetual trade off between performance and security
- One leaked password would compromise data of one tenant and not the entire data set, as data is really isolated. One impersonation will expose 1 tenant One bug of a developer, will cause damage to one tenant Hardeninig?
- We are a multi tenant application, there is an opportunity to enjoy good economics and share resources, but we need to maintain security, which is better with isolation
- The x.509 client authentication allows clients to authenticate to servers with certificates rather than with a username and password.
- Rest: If I, Cisco, was reckless and lost the drive, the thief will have to work very hard to decrypt one tenant’s data! Others are completely isolated and protected A database is a file in the filesystem by default From mongo docs: Use this option in conjunction with your file system and device configuration so that MongoDB will store data on a number of distinct disk devices to increase write throughput or disk capacity. Flight: new in 2.6 So this means I need to connect with a diff cert for every user….. sslMode = <disabled|allowSSL|preferSSL|requireSSL>
- In other words, this put the sole security responsibility on application server, and made the database completely blind. That way, it was possible to create a pool of connections authenticated by a generic "appserver" but now this generic user has no data access privileges! Only privileges it had is to other users such as ”Foo" or ”Bar" which had their own RBAC permissions and their actions in the database were audited with the user name. This is a neat feature, I have used it quite a bit when in multi-tenant applications when high security and tenant data isolation was required. More about this feature here: Creating a new connection between a client and the database is a heavy operation as it involves networking stuff, several roundtrips, driver client-server (+SSL?) handshake, server-side thread management, etc. Traditional databases such as MySQL, PostgreSQL and Oracle - all require authentication as part of the creation of the connection. To avoid the expensive price of frequent creating and closing database connections Backend applications, create and maintain a pool of reusable connections to be handed to arbitrary worker threads to access the database The only alternative to create those generic pooled connections was to authenticate them with some generic credentials (let's call is "appserver" user) that would have full privileges to all data This would immediately expose the entire data in the database, and eliminate any security such as RBAC or audit in the data and database level In it's version 9, Oracle introduced a mechanism called "proxy authentication”, allowing generic authentication for all pooled connections, but re-authentication on that same connection in context
- I got lucky. Not really, MongoDB helped a lot, being designed from the ground up for this.
- I ran a benchmark that created a MongoTemplate with a borrowed connection from the pool For a comparison, I added a standard read call of a document from the database (Both require a roundtrip to the database, authentication is hypothesized to be lighter as it does not involve parsing, data access) The benchmark tested serial random context switches between 5 tenants I also tested the times of creating and closing a client connection to MongoDB To make sure the authentication context switching does not really reconnect the DB As a comparison between connection creation and authentication I stopped after 1000 repetitions…
- Pooled long lived connections are blank Authenticated just upon use, There is no way a connection from the appserver can access all data set. Always a single tenant. Other data is just not available, even in case of a bug or an exploit of a vulnerability in the system… But what about performance‽
- Every worker thread must ask a database connection from a common infrastructure This common infrastructure would: Examine the security context of this thread and the injected principal Borrow a connection from the pool, authenticate it with the current tenant Hand it over to the requesting worker thread When done, the worker thread discards this authenticated connection A blank connection is returned to the pool
- Sure it’s easy! When I have different users connecting to the DB. When I have the database being aware to whoever is now connected, authorization (and also audit BTW) are a breeze! MongoDB does not enable authorization by default. You can enable authorization using the --auth or the --keyFile options, or if using a configuration file, with the security.authorization or the security.keyFile settings
- These auditing guarantees require that MongoDB run with journaling enabled.