Posted by: Hasan Sameer
November 30, 2022
Adopting the multi-cloud environment can have multidimensional effects. First of all, it can resolve reliability and redundancy issues and prevent downtime and disruptions in case of outages. For instance, if you are operating on one cloud, and it goes down; you are out. But multi-cloud support gives you the buffer to stay online even if there is an outage in one cloud. So, if you look at it from an operational and infrastructure costs perspective, a multi-cloud strategy is the ideal one to adopt. Some organizations also choose the multi-cloud route to enable cloud bursting. Furthermore, this approach also allows you to pick and choose the best of each cloud platform.
of organizations in a survey were reported to use the multi-cloud strategy in 2019.
of cloud-using organizations are now choosing the multi-cloud strategy as their primary approach.
of organizations are reporting that multi-cloud security configurations led to data breaches or exposures.
of them are not confident in their ability to apply consistent security across multi-cloud environments.
The traditional Cloud Security practices are not adequate to ensure the complete security of serverless functions. They require essential security tools that provide real-time and in-context information on vulnerabilities and the threat landscape. It is important to maintain the security health of the multi-cloud environment to secure the serverless functions. This includes the processes to identify misconfigurations, control API access, enforce network boundaries, prevent malicious actors from lateral movement, and more.
The following are the best practices to secure multi-cloud in reference to serverless functions:
Instead of being deployed in isolation, serverless functions are triggered to carry out a task responding to an action or an event. These functions work as a binding force between different components of the application within a typical distributed architecture. It becomes important to enforce the principle of least privilege to scope the permissions associated with a function.
For instance, let’s say there is a function that needs to get only read access to your database. But it has been granted permission to also create or delete cloud resources in your account. In such a case, it can turn out to be disastrous if a malicious code is deployed to this function. It might potentially compromise your entire system.
Developers are in control of programming serverless functions to perform arbitrary tasks. Along with that, they might also grant arbitrary permissions to the functions. In order to ensure that only authorized entities can interact with the function, you need to secure API access to the function itself.
It is not recommended to give an external user or service account the authority or accessibility to invoke your function or even deploy a new version of your function. This might end up catastrophically if a malicious user or service gets access to your functions.
It is important to enforce network boundaries on your serverless functions based on the level of sensitivity of the data processed by those functions. This is as important as locking down network access on your hosts and VMs. Enforcement of well-defined boundaries will retain an attacker from sending confidential data outside organizational boundaries.
Suppose you find a critical misconfiguration of a serverless function. Without having any additional context on the violating object, it would be difficult to mitigate the issue. If you are having one-click access to the resource configuration history, you will get comprehensive resource metadata over time. This enables you to find gaps in your administrative workflows that allow critical security misconfigurations to enter your environment. To avoid any misconfigurations propagating through your Cloud Security posture, you need to restrict administrative privileges within your multi-cloud premises.
