8 mins to read
There’s no question that AWS Lambda remains the incumbent leader for serverless computing. Lambda’s recent enhancements, including the ability to allocate up to 10 GB of memory to a Lambda function (a threefold increase) and the ability for users to have up to six CPUs in each execution environment for faster multithreaded and multi-process applications, will continue to lead its growth. This blog will cover AWS Lambda threats and provide the security considerations you need to reduce security risks and get the most out of your AWS Lambda service.
AWS Lambda: A brief overview
If you have experience in AWS Lambda, feel free to skip over this section. For those new to the service and looking to learn, here is a quick primer on how the service works.
In short, AWS Lambda is a service that lets you run code without having to provision or manage your own servers. It’s great for processing workloads that are memory or computationally intensive.
Since its release in November 2014, Lambda has become increasingly popular due to the variety of benefits the service offers:
- Continuous Scaling: AWS Lambda lets you scale applications by running code according to each event for more precision depending on the size of the workload.
- No Backend Management: Lambda offers a cloud-native experience, enabling you to run code without being responsible for managing any infrastructure. All you have to do is write code and upload it to Lambda as a .zip file or container image.
- Subsecond Metering: Lambda’s model allows you to only pay for the compute time that you consume, meaning you won’t have to worry about overpaying for infrastructure. Lambda charges are calculated by every millisecond your code executes and the number of times your code is triggered.
Shared responsibility model + Lambda
As an AWS customer, security is a shared responsibility between AWS and your organization. The shared responsibility model describes this as security of the cloud and security in the cloud, but what does that mean when it comes to Lambdas?
- Security ‘of’ the cloud: AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS compliance programs. To learn about the compliance programs that apply to AWS Lambda, see AWS Services in Scope by Compliance Program.
- Security ‘in’ the cloud – Your responsibility is through the AWS services that you use. You are responsible for other factors, including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This chart helps you understand how to apply the shared responsibility model when using Lambda.
Check out Sonrai’s Guide to the AWS Shared Responsibility Model.
The AWS shared responsibility model applies to data protection in AWS Lambda. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. Your organization is responsible for maintaining control over the content that it hosts on this infrastructure. This content includes the security configuration and management tasks for the AWS services that you use, including AWS Lambda and other serverless functions.
What are AWS Lambda URLs?
This year AWS launched a new feature allowing teams to set up simple, dedicated application endpoints for Lambda functions called Lambda function URLs. This new feature is similar to what the other big CSPs offer, like GCP HTTP cloud functions and Azure functions HTTP triggers.
Lambda URLs allow users to quickly process with minimal overhead for straightforward use-cases like webhook handlers, although Lambda functions can be externally at risk via API gateways and load balancers. Additionally, Lambda URLs allow developers to focus on core functionality and postpone dealing with validation and authorization requirements to later stages of development. Because it’s easy to make mistakes in development and serverless functions have grown in popularity and seem to be drawing the attention of bad actors, who naturally see value in taking advantage of their popularity.
The risks of insecure Lambda function URLs
Lambda URLs are simple, but they must be secure to prevent risk. Serverless functions residing behind an API gateway or load balancer rely on the secure configuration of these frontend services- however, Lambda functions must have their own security measures in place because there is no guarantee that any one service will work properly across all environments. If you don’t take care with how your lambdas access data from other sources (such as databases), then bad actors could pose as much danger trying to steal information through compromised instances.
An AWS Lambda function URL could be at risk under the following circumstances:
- A bad actor discovers the Lambda function URL in your environment and figures out how to use it.
- Your AWS Lambda function is misconfigured to accept HTTP requests without authentication.
- Your function’s resource policy authorizes invocation by unauthenticated principals.
- Your function “leaks” information on its use.
AWS Lambda security best practices
As you can see, AWS Lambda is a pretty powerful and widely used service. And because the service runs on AWS, it’s inherently very secure through Amazon’s high-quality architecture. That said, here are some AWS Lambda security best practices to consider:
Use an API gateway
Using an API gateway is a no-brainer for this type of service. A gateway can serve as a front door to the Lambda function, ensuring that only authorized identities are accessing it. Amazon offers its own API Gateway to create and document web APIs that route requests to specific Lambda functions.
Using the API Gateway, you can secure access to each Lambda function and maintain strict authorization authentication. For more information on how to use AWS Lambda with the Amazon API Gateway, read the docs.
Tighten IAM governance
AWS Identity and Access Management (IAM) enables administrators to control access to AWS resources. This service enables administrators to control who is authenticated and authorized to use Lambda resources and configure what the lambda’s themselves are privileged to do.
For further protection, you can also use the Sonrai Dig platform to streamline IAM governance with AWS Lambda functions and all other AWS services. Sonrai Dig uses AWS APIs to integrate with AWS and delivers advanced analytics to help security teams provision and manage permissions. Sonrai integrates seamlessly with AWS for a powerful and centralized IAM experience.
There are several ways to secure Lambda function URLs and protect your environment from the abovementioned scenarios. Generally speaking, best practice is to always require both authentication and authorization for invocation of a Lambda function, and to host it in a private subnet within a VPC. If your function needs public internet access, for example, to query an external non-AWS API, then you should expose it through a NAT gateway in a public subnet within the same VPC.
Manage IAM authentication
Authenticated users can access features that require a certain level of permissions. With IAM authentication enabled, the function’s URL itself will only accept HTTP requests if they come from an AWS access key and have been signed off by one with effective permissions. This means same account holders need their identity policy approved while cross account ones do too–unless granted otherwise through resource policies.
If IAM authentication for the Lambda function is disabled via the AWS console, AWS will automatically attach a resource policy granting public access. This is obviously not recommended and risk. For this reason, make sure that the function has minimal permissions in your environment so as to minimize the risk, especially if yourorganization allows an unauthenticated invocation of the function via its URL. This is not a best practice.
Utilize IAM authorization
You can explicitly limit invocation to specific principals by configuring an IAM resource policy that determines who is authorized to invoke a function, under what conditions, and whether directly or via its URL. By doing so, you’ll reduce the risk of public exposure. You should avoid using overly permissive resource policies, such as setting a wildcard (*) as principal for invocation, either directly or via a URL, as this would authorize any authenticated AWS identity to invoke the function. By doing so, anyone can create an AWS account. This is not a best practice but a risk.
Enable CORS
If cross-origin resource sharing (CORS) configuration is enabled, by default, the function URL will accept HTTP requests from any domain. Therefore, you should configure additional CORS constraints, such as only allowing HTTP requests from specific origins or requests containing specific headers and HTTP methods. Failure to do so would mean big risks for your environment. However, CORS is not a strong security barrier on its own, and a bad actor could discover the specifics of how to invoke the function.
Reserve concurrency
By reserving concurrency for every function with a URL and limiting it to a maximum value, you can ensure that even if a function URL is somehow invoked repeatedly by a bad actor attempting to cause disruption, any organizational impact will be limited to the specific compromised function while unrelated operations in the same region will remain unaffected. When choosing a maximum value, you should adjust it depending on the function’s specific usage.
Keep your Lambdas separate
To avoid data leaks, AWS recommends that you don’t store user data, events, and other data with security implications in the execution environment. AWS recommends creating separate functions and separate function versions for each user. Functions that rely on a mutable state that can’t be stored in memory within the handler.
Be selective in your field use
You should never put confidential or sensitive information, such as your customers’ email addresses, into tags or free-form fields such as a Name field. This includes when you work with Lambda or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
Manage access
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines its permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is ‘allow’ or ‘denied.’ Every IAM entity (user or role) starts with no permissions. By default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group with the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions. Be sure you understand those effective permissions and can effectively manage access to your Lambda functions.
Securing functions and reducing risks
Sonrai Security provides your organization with coverage across identity, data, platform, and workloads showing you pieces of compute and areas of data exposure. We simulate every attack path, whether it starts at a Lambda function risk or a user, so you don’t have to model each risk separately – we do it for you on our Cloud Identity Graph. Lambda function URLs are just another exposure path that your organization faces as it develops in AWS. Sonrai helps teams make sure they are using Lambda function URLs securely by providing pre-built controls and out-of-the-box configurations that alert you to toxic combinations of resource configuration, identity, data access, and more.
For example, you can use Sonrai to check for Lambda functions with the following toxic combination:
- Exposed to the internet via a URL, load balancer, or API gateway.
- Proper authentication or authorization is not required.
- Over privileged identity access to serverless functions.
Most cloud teams have access entitlements they don’t need and probably shouldn’t have, but with over 40% of machine identities being overprivileged, securing non-person identities is a massive part of Cloud Infrastructure Entitlement Management and managing serverless function access.
A mature CIEM solution, like Sonrai, can inventory all non-person identities, like Lambda URLs and functions, and map out their end-to-end permissions. Then, using graphing technologies, map out these permission chains for easy visualization. Understanding and assessing the priorities of identity risks allows you to work towards achieving Least Privilege for all non-person identities. This entails machines and functions possessing the minimum privileges necessary to complete their job for the minimum amount of time. With a CIEM solution, after your organization has reached its desired policy, the CIEM tool will monitor against the desired baseline to notify you any time a Lambda function accesses a resource it shouldn’t or never has before.
Learn what’s different about Sonrai’s CIEM solution.
With Sonrai’s intelligent workflows and automated remediation, a deviation from the baseline would be presented to the team responsible for the issue – and promptly. To ensure a concern is addressed immediately, where a manual ticket would have been issued for a security team to respond to, Sonrai’s automated remediation capability would strip access or suspend the machine’s identity to prevent further risk.
This is just one of the many ways that Sonrai makes development easier, safer, and faster for AWS teams. Sonrai can serve as your organization’s complete end-to-end total cloud security solution. To continue your learning on AWS risks and read how Sonrai works with AWS.
