Multi-Tenant Data Security for Databases with Record-Level Encryption
Multi-tenant databases are commonly used by SaaS vendors for the sake of cost-efficiency. Having a separate database instance for each of their customers, while ensuring each customer’s data is isolated, is prohibitively expensive. So, having a database instance with multiple customers’ information in it is the way to go from a cost perspective.
But, what about data isolation? Well, it depends on the policies and safeguards built into the database and the SaaS application. Increasingly, that’s not good enough. Larger customers, especially in highly regulated industries like finance and healthcare have compliance requirements to meet on their data, even if it is stored in an application / infrastructure they don’t control, such as SaaS. These customers are demanding more security and control over their data.
This is where Multi-Tenant Data Security (MTDS) for databases comes in. With MTDS, each customer’s data (typically a set of records or rows in the database) are cryptographically protected. A field in the row, usually something like an entity_ID column, identifies the owner (customer) of the record. A single key, owned by the customer and held either by the customer or by the SaaS vendor momentarily, is associated with each value of entity_ID and controls decrypting some or all of the data, based on policy. Customers of SaaS vendors generate and control their own Key Encryption Keys (KEKs) in their infrastructure. The KEKs are then used to encrypt Data Encryption Keys (DEKs).These encrypted DEKs are also stored in the SaaS customer’s infrastructure. The DEKs are decrypted by the SaaS vendor’s application (using Baffle) during runtime. Thus the SaaS vendor’s customers have full control over their data and can disable their KEKs at any time which will then cause the DEKs to be inoperable and effectively “shredding” their data and making it unusable in the SaaS provider’s infrastructure (such as multi-tenant databases or data lakes).
This is above and beyond data-at-rest or data-in-motion encryption, this is data-in-use encryption! With MTDS, when data is loaded into the database, it is still encrypted. When the customer, with the proper authentication and access authorization, retrieves the data through the SaaS application, the customer’s KEK is used by the SaaS application to decrypt DEK that will, in turn, decrypt the data. This ensures that each customer can see only their data. Even administrators at the SaaS vendor (e.g. DBAs) aren’t able to see decrypted data; a critical compliance requirement for enterprises moving sensitive data to a SaaS. Also, privacy regulations guarantee a data owner’s ‘right to be forgotten’. In this scenario, if the customer revokes their KEK, the DEK is only available in the encrypted state and the data in the SaaS vendor’s multi-tenant database is still encrypted or effectively ‘shredded’ allowing them to implement this additional critical capability. This is the best way to isolate each customer’s data. SaaS vendors get the benefit of application-level encryption for each customer’s data, but without the time, complexity, and cost.
Baffle provides a complete solution for Multi-Tenant Data Security, including managing the entire key lifecycle through creation, rotation, and retirement over time. Any company evaluating, purchasing, and/or deploying SaaS should demand MTDS from the vendor. SaaS vendors can guarantee that their customers’ data is protected when it is being used, moved, and stored. In short, MTDS is a “win-win” for everyone involved with SaaS – vendors and customers.