The single-tenancy vs. multi-tenancy debate still rages on. It used to be a stalemate, with SaaS vendors equally choosing between either architecture. But that’s changed, thanks to advancements in storage infrastructure and cloud computing.
To understand why multi-tenancy has been gaining lots of traction lately over single-tenancy, you might want to understand the difference between the two and most importantly, what’s meant when people talk about multi-tenancy security.
We define multi-tenancy as a mode of software operation where multiple instances (read: tenants or customers) of one or more applications operate in a shared environment, with a single datastore.
Logically, the tenants are isolated; but physically, they’re still integrated.
It differs from single-tenancy in the sense that resources, display, backend database, and sometimes users are shared among the instances, which makes it both cheap and easy to maintain.
Multi-tenancy security refers to data safety or privacy of tenants’ data in a multi-tenancy environment.
The biggest driving force of multi-tenancy hosting is efficiency and low maintenance cost, while the first risk that comes to mind when someone broaches up the idea is security.
Offering dozens or hundreds of tenants access to the same application or database other tenants are using raises the possibility of one of them using someone else’s data either by malice or accident.
This makes security a primary concern in multi-tenancy. In recent times, there has been a fundamental shift in how SaaS vendors protect their tenants’ data. Still, many customers don’t understand or trust some of these changes.
As a leading business intelligence platform with many years of experience in the industry, we came to realize that tenants operating in a cloud-based multi-tenant environment have many security concerns related to the protection and confidentiality of sensitive data.
We’ve outlined several privacy and security risks associated with multi-tenant hosting that needs to be adequately addressed:
In this section of the post, we’ll be providing a series of prescriptive steps to follow in evaluating and managing the privacy and security concerns of users in a multi-tenant cloud system.
Yurbi is a modern BI platform that supports both single-tenant and multi-tenant architectures.
If you have adopted a multi-tenant architecture, Yurbi has built-in dynamic data level security policies which can restrict each user to seeing just the data they are authorized to see. You can learn more about the details here.
Yurbi allows you to segment tenants into isolated units, where users can not only view but also build reports and dashboards.
Users can schedule reports and have visibilities only to the data, reports, and users that are contained within their tenant. Even when all the data is centrally stored in a multi-tenant database.
If you have adopted a single-tenant architecture Yurbi supports that as well. There are multiple what you can leverage Yurbi in a single-tenant environment. If you provide wholly separate environments per tenant, simply install a separate Yurbi server as part of your tenant environment.
However, a Yurbi server per tenant is not needed.
A single Yurbi server can support many single-tenant environments due to our Yurbi App/Data Source model. You can learn more about the Yurbi App here, but essentially each client database has a unique connection with Yurbi and all permissions can be applied to allow a single user or group of users to only have access to that data source. Security is built-in to isolate data between tenants due to the single-tenant architecture.
If all your schemas are the same, you can even define the data source connection per user and leverage the same Yurbi App, this makes the source of data dynamic per user. However, if you do customize per customer, simply cloning a master Yurbi App allows you to customize the schema just for that customer.
If Yurbi sounds like the embedded analytics that may fit your requirements, reach out to us and let’s discuss further.