What is Multi-Tenancy and Why Should You Care?
As businesses continue to deliver their products, services, and data through customer-facing, cloud-based web applications and APIs, they face continuous pressure to ensure that each customer’s data remains safe. Customers expect their information to be kept away from not only external hackers with malicious intent, but from other customers as well. It would be catastrophic to the reputation of a health provider or financial institution, or even a travel business, to have a customer’s medical record, checking account, or flight plans revealed to another customer. And once that trust is lost, customers will walk away from the business forever.
The need to keep one customer’s data from exposure to another customer requires that web applications and APIs be architected with multi-tenancy in mind. Multi-tenant architectures evolved from the need to allow each customer a certain degree of customization in an application, but with the advent of modern, massively scalable, cloud-based applications, it also encompasses this aspect of data security.
Multi-Tenancy architectures fall into one of several categories:
- Per-client application and database instances – Provide a separate application and database instance to each client. These solutions work well with a limited number of clients. Because of the time and cost to set up and the cost of the infrastructure to support them (even in cloud environments), this design tends to be used in B2B situations. With this architecture, there is a tendency to allow each client’s application to evolve separately. This, combined with new feature releases and defect fixes can lead to heavy maintenance and support costs that must be built into the business model.
- Single Application Instance / per-client database – Provide a single application instance for all clients, but each client has a separate database instance. This solution is useful in situations where there is no per-client customization, but each customer’s data must be physically segregated. The software must still ensure that each client, and only that client, properly accesses their database. While reducing the cost associated with maintaining multiple customized versions of an application, this solution still has scale out issues with a large number of clients due to the multiple database instances.
- Single Application / Single Database Instance – A single application instance and database supports all clients. The software must handle all multi-tenancy features, including per-client configuration and extensibility and data security. This is the most architecturally complex solution, but provides the lowest maintenance and highest scalability in cloud infrastructures. It is most often used in B2C scenarios which have large numbers of customers.
The challenge with the Single Application / Single Database architecture is that developers often do not design in data security at the start of development. These implementations inevitably rely on each developer correctly implementing tenancy rules for each API call. These checks can be easily forgotten, left out, or simply bypassed. One way to reduce this risk is to centralize the tenancy checks in a central repository used by all parts of the application.
Given the damage to a business’ reputation that can be caused by inadvertently disclosing a customer’s data to other customers, software teams need to take the time up front to design in multi-tenancy. Pick a tenancy model that works for the business. Make sure the application supports the model. Design the necessary maintenance and support processes. By considering these security needs, the business can ensure their customers that their data is safe from unwanted exposure.
By Doug Gregory