Serverless Security — Challenges and Best Practices
Provisioning and maintaining virtual cloud infrastructure are bygone. Well, almost. Now with Serverless, routine tasks such as managing, patching, and securing infrastructure, are taken care of by the cloud providers. This gives developers newfound freedom, to focus on innovation and rigorous application development.
Serverless is a cloud-native approach to application development and deployment based on Functions-as-a-Service. Sure, it brings distinct benefits such as faster deployment, increased scalability, reduced costs and so forth, but the question remains: how does it impact security?
Since Serverless development is fundamentally different from the traditional infrastructure orchestration approach, security in serverless needs to be looked at differently too.
What Is Serverless Security?
To make a serverless environment secure, developers need security strategies that account for the unique aspects of serverless computing. Unlike traditional applications, where the main focus is to build security around the application using IDS or IPS tools and firewalls, serverless security is all about building security around functions within the application.
The following are two primary factors that make up the bedrock of building security around functions:
- Authorization: Ensuring the functions can only access services that they require to perform their jobs
- Authentication: Ensuring the functions or the part of the application that they contribute to, can only be accessed by eligible users or roles
Let’s take an example of a basic serverless architecture built on AWS.
The architecture shown in the above diagram, makes use of a combination of AWS services to implement authentication and authorization around Lambda functions:
- Amazon Cognito: To authenticate users trying to access the customer-facing endpoints of the API gateway.
- AWS IAM roles and permissions: To authorize AWS Lambda to access other AWS services. Each Lambda function has an IAM role called the execution role which defines the minimum permissions they need to perform their job.
In the above diagram, each Lambda is given permission to access only their respective DynamoDb tables, and S3 bucket, in addition to Amazon CloudWatch for logging.
Learn more about architecting secure serverless architectures on AWS.
Apart from leveraging security services offered by cloud vendors to secure serverless functions, there are other attributes of serverless architectures that also need to be optimized and protected for all-round serverless security implementation. For example:
- Code
- Data
- Infrastructure
- Logging and Monitoring
Now, this is to note that a developer is only responsible for optimising and protecting some of the above-mentioned attributes. Serverless is a cloud-native model. This means that it inherits the main USP of the Cloud computing model, i.e., a lot of the operational workload shifts to the cloud vendors. This also applies to the security of serverless on the cloud.
As a result, serverless enforces a new cloud-based, security value-system which is conceptually different from traditional deployment models. The security of serverless on the cloud is based on the shared responsibility model. The shared responsibility model is a security and compliance framework, that outlines the responsibilities of the cloud vendors and cloud users, for securing their cloud environments. With the shared responsibility model, the cloud vendor and the developer share the security responsibility throughout the entire serverless architecture.
Let’s look into the cloud vendors’ and developers’ side of the serverless security responsibilities respectively.
Serverless Security of the Cloud
For serverless services, cloud vendors manage the underlying infrastructures, the operating systems, and the application platform. The responsibilities include(but are not limited to):
- Physical security of the hardware and facilities
- Maintaining Service Level Agreements (SLAs)
- Data encryption features for content in transit and at rest
Serverless Security in the Cloud
Traditionally, developers would protect their applications by employing infrastructure and network-based tools and agents. With serverless, server or infrastructure-based protection tools are out of the question, instead, the developers rely more on permissions, access management and more. The responsibilities include(but are not limited to):
- Security of the code
- The storage, accessibility, and encryption of sensitive data
- Identity and access management (IAM)
The following diagram summarizes the shared responsibility model for the security of serverless.
Note that it is only in the case of serverless architectures, that cloud providers assume security responsibility for the attributes inside the dotted box in the above image. For non-serverless cloud architectures, the security for these attributes will fall under Developers’ purview.
While the serverless model hasn’t really created any new security concerns, it does require a bit of shuffling in the security priorities for a developer, in order to adequately mitigate potential security challenges. That said, serverless has also evidently fixed many security threats because of its transient nature and the shared responsibility model.
Let’s take a look at the security problems that serverless fixed.
Security Advantages of Serverless
OS Patches: Vulnerabilities caused by unpatched servers and applications are common reasons for systems getting exploited. With serverless, OS patching is offloaded to the pros, i.e. cloud vendors. So developers can rest easy, when it comes to OS patches.
Denial of Service (DOS): DOS attacks are caused by attackers flooding the systems by sending large amounts of traffic in order to maximize a server’s capacity. These attacks are easily subdued by the virtual infinite scaling capacity of serverless.
Smaller attack surface: Stateless and short-lived systems translate to smaller attack surfaces for hackers. Most security breaches rarely happen in single attempts, and serverless being stateless, doesn’t provide attackers with the luxury of time.
Security Challenges of Serverless
Now that we have discussed the security concerns that are inherently mitigated by serverless because of its architectural nature, let’s talk about what’s left to be protected.
Broken authentication: Serverless applications are distributed architectures containing hundreds of services and functions. Some of these may be public-facing components of the application, while some may act as proxies for other functions. In this type of architecture, robust authentication is crucial to protect and provide proper access control.
Over Privileged Functions: A serverless architecture is composed of multiple functions and serverless services. Each function and service has its own roles & responsibilities and requires granular permissions. If a function gets provisioned to be over-privileged within its rights, it could be at risk of being exploited by an attacker.
Security Misconfiguration: Cloud vendors offer numerous security settings and features that can help secure architectures from the ground up. But if any crucial settings and configurations are left unattended it may act as an entry point for attackers.
Inadequate function monitoring: Monitoring and logging security-related events is crucial as it can aid in identifying known and unknown vulnerabilities and issues in functions. However, monitoring serverless architectures can become challenging as you scale up, even with cloud-native monitoring services as they have their own limitations.
Tools like KloudMate are purpose-built for serverless observability and monitoring. Here’s what a secure serverless architecture, made observable using KloudMate, looks like:
Serverless Security Best Practices
So far, we have discussed both the security concerns that serverless has already solved and the security concerns that need to be mitigated by serverless developers. Here are some best practices that serverless developers can adopt, to overcome the security challenges of serverless.
- API gateways as security buffers: API Gateways provide multiple function-specific authorization and authentication mechanisms. It acts as an added security layer between the function and the users. By leveraging API Gateways as security buffers, we can significantly reduce direct attacks on functions.
- Secure coding conventions: Following the standardized guidelines and best practices for a specific programming language can help reduce vulnerabilities in the code and keep it secure and impenetrable.
- Functions in minimal granularity: Keep the function small by keeping it focused on just the business logic. By keeping the code small, one can reduce the attack surface and the information that can be exploited if the function gets compromised.
- Custom function permissions: One-size-fits-all approach to assign permissions to different functions, can effectively increase the attack surface. Think lean, employ the principle of least privilege, and customize function-level permissions for each function.
- Isolated function parameters: When multiple functions are deployed to create an aggregative workflow, perimeter security must be applied at the function level. By maintaining isolated perimeters of each function, we can ensure that vulnerability in one function doesn’t compromise others.
Conclusion
The serverless development model opens up infinite possibilities and developers are still exploring its benefits, challenges, and use cases. But, from what has already been tried, tested and said, we know that serverless is here to stay. And, as mentioned above, serverless hasn’t introduced any new security issues, nor has it worsened the existing ones. Though it does require a very intentional approach to building applications, in order to keep the application reliable and secure.
Make proper use of security features that cloud providers offer, follow the best practices, keep the system observable at all times, and you’re prepped for great application security and performance.
