Serverless architectures take the need to manage infrastructure-related operations out of the equation and allows the organizations and their application developers to focus more on developing quality code.
This model of computing brings a myriad of benefits like faster deployment, increased flexibility, scalability and accessibility. No need to worry about server-level security either.
As we adopt the world of serverless, it is important we understand that securing such architectures is a shared responsibility. The cloud or serverless service provider is responsible for securing the data center, network, servers, operating systems, and their configurations. However, the application logic, code, data, and application-layer configurations still need to be secured and made resilient to attacks by the application owners.
What Has Changed For Good In Serverless Architecture
At its core, serverless moves significant responsibilities from the application owner to the platform, including some important security responsibilities. Let’s check some which has changed for good.
1. Vulnerable Operating System (OS) Dependencies
Operating systems allow users to install utilities in a variety of ways, say installing a full database via a dedicated installer on a Windows machine. These utilities are in turn used by the applications or systems administrators and are referred to as operating system (OS) dependencies.
Since these dependencies become vulnerable over time, they can be fixed or patched with regular updates. With the serverless model, patching servers is no longer a responsibility of the application owners.
2. Denial Of Service (DoS)
DoS attacks attempt to use up an application’s resources, therefore keeping it from serving legitimate users. Overwhelming network bandwidth, through parallel compute-heavy actions, to infinite loops in apps, these attacks exhaust resources.
Because serverless is extremely elastic, it naturally fends off most DoS attacks. Resource capacity is expanded as quickly as it’s taken up.
3. Long-Lived Compromised Servers
With many long-standing servers, compromised systems often remain undetected for very long periods. With serverless, long-standing servers simply don’t exist. Servers are launched, briefly used, and then discarded and cleared. Attackers cannot simply compromise a machine and continue penetrating deeper.
What Still Needs Attention In Serverless Architecture
While the use of serverless architectures helps mitigate quite a few security concerns, the following areas however, still need to be addressed, or stay unaffected despite this paradigm shift.
1. Access And Permissions
Serverless functions need to be configured for the resources they need access to. This in turn requires adding permissions for the said resources. Mapping permissions or fine-graining resource access for each function becomes a tedious task. In such scenarios, organizations may define global roles and permissions applied to all functions—essentially granting each function full access to all other system components.
When all functions share the same set of permissions with a few being over-privileged, a vulnerability in a single function can eventually escalate into a system-wide security catastrophe.
Granting granular permissions as well as roles and enforcing the “least privilege” principle will diminish a probable attack’s surface or “blast radius”.
2. Code Vulnerabilities
Although CSPs take ownership of server security, network security, and an overall secure infrastructure, execution runtime can still be a weak point for security breaches. Developers must follow standard coding conventions, including injection (testing code quality or vulnerability in written source code) and broken authentication flaws (preventing someone to edit or delete a part of an application without having it’s permissions). Perimeter is yet another practice to be implemented and each function should be treated as its own security perimeter to avoid security vulnerabilities in code due to work order of execution.
3. Application Secrets Storage
The cloud vendor provides the serverless platform and therefore we don’t get any details regarding how the functions are executed, and their underlying mechanics with regard to resource allocation. For this reason, we should consider tasks as short-term. In most circumstances, saving any type of state in a function’s own runtime is an antipattern that you should not follow. Instead, you should always store data in external resources.
4. Insecure Third-Party Dependencies
Serverless takes vulnerable server dependency patching off your hands, and that’s a huge advantage. Unfortunately, an extremely similar problem remains under your responsibility: vulnerable application dependencies fetched from npm, Maven, PyPI and similar sources. These are bundled into your function, are not maintained by the platform, and can grow stale and vulnerable just like their server dependency peers.
Functions are meant to be small in scope and responsibility, which in part frees us from the restrictions of sticking to a single language, and opens the gateway to a great opportunity for polyglot development. This means that to successfully secure serverless apps, software composition analysis solutions need to support a wide range of language ecosystems while considering the technicalities and nuances per ecosystem that comes with package versioning.
Final Words
When building the idea and thought process around implementing a serverless architecture, one must take time to ensure the architecture is gathering proper controls when speaking about security measures and how to adopt a program that can assist in maintaining the longevity of applications.
Serverless application architectures are suitable for a wide range of services and can scale elastically as cloud workloads grow. Ensuring sound security procedures and practices hence allow you to bring efficiency in development and deployment, business agility and cost optimization as well.
Check also the Importance Of Implementing Cyber Security In Cloud.
