Serverless cloud computing is a new arena for many enterprises, which makes it difficult for IT professionals for securing it due to lack of decent exposure, and most of the information about it is intended for developers thus making it difficult for the security professional to get a grasp how serverless computing works.
This raises queries for the practitioners like, does the security compare to Virtual machines or containers? What measures can they take to evaluate if their organization is secured enough?
Getting answers to such questions needs an understanding of how the serverless model works, what specific purpose it serves and how an organization can employ and benefit from it.
A developer’s job in serverless is to deploy code without provisioning operating systems, compute instances, etc. and the Infra Operations do not need to be bothered either. The serverless application is dynamically scalable as per the cloud workloads.
Serverless computing is not a sure-fire way to eradicate all traditional security problems, as the code is being executed and this is mostly a potential vulnerability. Let us explore the security aspects which IT Professionals need to keep in mind while working in an organization that is considering serverless computing as their next step.
Few things you have to consider when addressing serverless
cloud security. To begin with, this approach makes use of Web-Assembly or JavaScript while using them on the edge, making use cases a necessity but constrained to a specific degree. Because you are probably not going to write thousands of lines JavaScript code for running a legacy funds transfer system interfacing with the back-end mainframe.
Secondly, segmentation is a significant factor to consider in a multi-tenant environment. Segmentation model is essential in multi-tenancy as undermining it could allow customers to access data from other segments. A hypervisor draws the segmentation boundary between multiple virtual OS instances. Container engines like Docker, draw those boundaries at the process level instead of so that multiple processes can run within one operating system instance under the scope of multiple containers.
Isolates push the segmentation boundary further. With Isolates, the segmenting boundary that separates the data and execution state between customers can exist within the single operating system process.
This is neither a good nor a bad thing for security. In recent years, segmentation attacks have been reported that challenge the segmentation models of container engines as well as hypervisors. This does not happen on a regular basis, but it can and occasionally does.
There have been instances of side-channel attacks allowing data leakage across Rowhammer techniques and processes that can possibly cause data manipulation across segmentation boundaries. There is a possibility that such leaks could occur just as they may with any other tech in the multi-tenant context.
It is of utmost importance that customers comprehend segmentation, and combine that understanding with information on the application being developed. You can evaluate usage by systematically analyzing, and usage of the application planned by the organization – E.g. when employing methodology for application threat modeling –, where implementing countermeasures would be appropriate if you need to strengthen the segmentation model and ensure robust application security.
