SaaS: protecting data from other tenants and the service

Much has been written here and elsewhere about the subject, and all this has been great food for thought. However, have not found a question which deals with our scenario specifically or indeed provides clear answers so bear with me.

Background

• Node.js backend with multiple frontends but with the overall SaaS theme.
• Multiple users but in the low hundreds not millions.
• Data being held is very sesitive and its security and integrity is both a legal/regulatory concern as well as one of our key selling points against the competition.
• Every user's schema is quite a bit different so initial plan is to settle for a a NoSQL solution like MongoDB.

The Security Ladder

1. Level one: soft protection from other users. The bare minimum in any multi-tenant app is to ensure no user can view another user's data. This should be accomplished by the app and its Data Access Layer. (But there's always the possibility of a bug creeping in here or there and successful malicious attacks that foil all protections carefully vowen into the DAL.)
2. Level two: hard protection from other users. In database-per-tenant strategies we have slightly better walls between users (different db connections, etc) which decreases attack surface. In our particular case this also makes sense from a document integrity point of view (each user has quite a different schema).
3. Level three: system intrusion. Protection from attackers who manage to gain physical access to database files. Most major DBaaS provide hardware-backed disk encryption and key rotation strategies for encryption at rest so even if someone gets the files they're of limited use.
4. Level four: SaaS intrusion. Combines database-per-tenant with encryption-at-rest where only the user holds the decryption key to prevent SaaS personnel from reading data. May sound a little extreme but some data is too sensitive to risk a dbo being able to do a casual SELECT *. A user holding and providing decryption keys for on-the-fly data decryption also helps ensure no malicious client is able to escape their sandbox and do harm to other clients' data.

Road to Encryption Heaven

Azure Table Storage offers Transparent Data Encryption but entrusts access to encryption keys to everyone who has access to the Azure portal. Hence, only Level 3.

We came across MongoDB's Encrypted Storage Engine which sounded just like what we wanted: data encrypted at rest, decrypted data resides only in memory, keys could be user-managed at a KMIP-compliant third party. However, keys are per-mongod process and would require a new mongod instance per every user. Not ideal.

Another solution we considered was something like mongoose-encryption (roughly equivalent to column encryption in SQL Server) where sensitive collections have some or all columns en/decrypted. Sounds promising but our gut feeling says it would be better to have this functionality at a database engine level and not as a DAL plugin. Moreover, it 'only' offers column-level encryption; we'd prefer encryption where it's not visible what collections reside inside a database and how many rows they have.

What Else Is There?

Having spent two days googling and asking many of the major DBaaS for help I turn to SO.

1. Do you think we are climbing the wrong mountain? In other words, perhaps it would be more beneficial to put all business logic in a client app and have it connect to a database directly rather than go through a server-side intermediary that has temporary access to sensitive data? (But then we're not a SaaS anymore and all our assets can be downloaded.)
2. Do you know of any database engine or provider that does not assume the app and any database admin should have unfettered access to customer data? Witnessing encryption-at-rest only now becoming a feature are we still a few years away from enabling data access strategies (almost) taking apps out of the equation and allowing users to truly protect their data?
3. For brevity I skip the entirety of key management logistics: how users should give the app temporary access to decryption keys held by a third party, how to deal with decryption over multiple requests, etc. I realise this is a can of worms in and of itself.
4. Apologies for the long read!

via Dav