Inventive Designers has been a traditional software vendor for a long time. We developed applications that got installed on-premise on our customers’ hardware. More recently we started developing and operating a cloud service. As a software vendor that made the transition, we are in a unique position to comment on the differences in risk between traditional software and an on-premise installation and a cloud setup.
Transitioning to a cloud setup changes the risks you’re exposed to. Exposure to the big bad internet is what comes to mind first; script-kiddies will be incessantly hammering the endpoints, and criminals will bring your service to its knees with a DDoS unless you pay some ransom. The next set of risks that come to mind are those caused by the realization that the cloud provider now needs access to data that is normally very closely guarded. While those are far from trivial, the most interesting set of risks from a software development point of view are those introduced by multi-tenancy.
With multi-tenancy I mean the sharing of resources and services between multiple users and customer organizations (tenants). The biggest driver for multi-tenancy is cost reduction by sharing and reusing resources and supporting personnel among tenants.
The first risk is to data isolation. Because the data of different tenants is sitting side by side on the same systems, it is not unthinkable that one tenant gains access to data of another tenant, or that data is accidentally returned to the wrong tenant. The key to mitigating this risk is logical segregation at as many levels as possible. This requires an architecture that is tenant-aware from top to bottom.
Interference between tenants is another risk that gets introduced by multi-tenancy. Because tenants share the same systems and hardware, a run-away process or an overload situation created by one tenant can have a negative effect on another tenant. Apart from good monitoring and auto-scaling to quickly detect and compensate for increased demand, controls like rate-limiting requests per tenant can avoid a situation where a single tenant causes an overload situation impacting other tenants.
A system that gets shared between tenants also makes change management riskier; a configuration change or upgrade necessary for a single tenant might cause unwanted behaviour for another tenant. The solution to this increased risk is even more testing, gradual roll-outs, and making sure a change is always capable of being rolled back on short notice. Having more frequent but smaller changes supported by an automated deployment process is what makes mitigating this risk possible.
The increased risk and the need to take security to a higher level was readily acknowledged when we started thinking about moving our software to the cloud and supporting multiple tenants on the same systems. Not only did we invest heavy in additional product functionality like the introduction of the tenant concept in the authentication and authorization parts of our product, we also started with an internal security program and made sure all operational safeguards and controls were in place to bring down the risk to an acceptable level.
Want to know more about our steps closer to the cloud? Read it in Nick Hofstede’s previous blog!
Inventive Designers has been a traditional software vendor for a long time. We developed applications that got installed on-premise on our customers’ hardware. More recently we started developing and operating a cloud service. As a software vendor that made the transition, we are in a unique position to comment on the differences in risk between traditional software and an on-premise installation and a cloud setup.
Transitioning to a cloud setup changes the risks you’re exposed to. Exposure to the big bad internet is what comes to mind first; script-kiddies will be incessantly hammering the endpoints, and criminals will bring your service to its knees with a DDoS unless you pay some ransom. The next set of risks that come to mind are those caused by the realization that the cloud provider now needs access to data that is normally very closely guarded. While those are far from trivial, the most interesting set of risks from a software development point of view are those introduced by multi-tenancy.
With multi-tenancy I mean the sharing of resources and services between multiple users and customer organizations (tenants). The biggest driver for multi-tenancy is cost reduction by sharing and reusing resources and supporting personnel among tenants.
The first risk is to data isolation. Because the data of different tenants is sitting side by side on the same systems, it is not unthinkable that one tenant gains access to data of another tenant, or that data is accidentally returned to the wrong tenant. The key to mitigating this risk is logical segregation at as many levels as possible. This requires an architecture that is tenant-aware from top to bottom.
Interference between tenants is another risk that gets introduced by multi-tenancy. Because tenants share the same systems and hardware, a run-away process or an overload situation created by one tenant can have a negative effect on another tenant. Apart from good monitoring and auto-scaling to quickly detect and compensate for increased demand, controls like rate-limiting requests per tenant can avoid a situation where a single tenant causes an overload situation impacting other tenants.
A system that gets shared between tenants also makes change management riskier; a configuration change or upgrade necessary for a single tenant might cause unwanted behaviour for another tenant. The solution to this increased risk is even more testing, gradual roll-outs, and making sure a change is always capable of being rolled back on short notice. Having more frequent but smaller changes supported by an automated deployment process is what makes mitigating this risk possible.
The increased risk and the need to take security to a higher level was readily acknowledged when we started thinking about moving our software to the cloud and supporting multiple tenants on the same systems. Not only did we invest heavy in additional product functionality like the introduction of the tenant concept in the authentication and authorization parts of our product, we also started with an internal security program and made sure all operational safeguards and controls were in place to bring down the risk to an acceptable level.
Want to know more about our steps closer to the cloud? Read it in Nick Hofstede’s previous blog!