We’re hearing more and more about services that are not based on traditional server models, such as Amazon S3 buckets—basically big buckets of storage in the cloud, and the concept of serverless computing. The good thing about what are now considered serverless services, like AWS Lambda, is that they allow developers to write and run code to deliver any type of application, functionality or backend service, with zero administration, and without having infrastructure or platforms to worry about.
So how does serverless work in the real world?
A serverless application can use several cloud services to do things such as serve website content from a storage bucket, authenticate users, and handle backend calls via a server-less lambda function that accesses data stored in a relational database.
As you can see, this so called serverless application isn’t really serverless, as it still has traditional server-based components, in this case a database server instance. Since serverless is usually stateless, the application needs a place to store its data, and that could be Amazon Elasticache, S3 storage, or databases such as RDS.
Based on the previous application example, let’s take a look at some of the potential vulnerabilities that could be leaving your organization exposed, along with some security considerations for your serverless application.
What are the Risks to Misconfigured AWS Lambda Functions?
- Limited or No Visibility into the Inventory of Your AWS Lambda Functions: If you do not have comprehensive visibility into your inventory, you cannot identify any publicly accessible Lambda functions, which means you cannot protect them.
- Without the ability to answer key questions you will not be able to spot malicious activity nor respond effectively to incidents: How many functions do you have? Are they new functions? Should they be there? What region are they in? What AWS Identity and Access Management (IAM) role are they using?
- Assigning Admin Permissions to Your Functions: Without assigning the right execution role, you cannot control the privileges assigned to your Lambda function. If you are providing administrative permissions you may be granting the role more permissions than the function really needs.
- Multiple Functions Sharing Same Execution Role: Using an AWS IAM execution role with more than one Lambda function will violate the Principle of Least Privilege (POLP). Without the right IAM execution role you cannot control the privileges that your Lambda function has.
- Tracing Not Enabled: If you are not enabling tracing through AWS X-Ray, you will not have visibility into, nor monitoring capabilities for, your AWS Lambda functions.
How Halo Can Help
CloudPassage Halo Cloud Secure monitors AWS Lambda functions to ensure they are properly configured and to make sure that their activity is tracked so any unusual activity can be fully understood. Halo also monitors the permissions the Lambda functions operate under to ensure minimum necessary access for specific functions.
- Identify any publicly accessible AWS Lambda functions and update their access policy in order to protect against unauthorized users that are sending requests to invoke these functions.
- Allowing anonymous users to invoke your AWS Lambda functions is considered bad practice and can lead to data exposure, data loss and unexpected charges on your AWS bill. To prevent any unauthorized invocation requests to your Lambda functions, restrict access only to trusted entities by implementing the appropriate permission policies.
- Ensure that your Amazon Lambda functions do not have administrative permissions (i.e. access to all AWS actions and resources) in order to promote the Principle of Least Privilege and provide your functions the minimum amount of access required to perform their tasks.
- The permissions assumed by an AWS Lambda function are determined by the IAM execution role associated with the function. With the right execution role, you can control the privileges that your Lambda function provisions. Instead of providing administrative permissions you should grant the role the necessary permissions that your function really needs.
- Ensure Your Amazon Lambda functions do not share the same AWS IAM execution role in order to promote the POLP by providing each individual function the minimal amount of access required to perform its tasks. There should always be a one-to-one relationship between your AWS Lambda functions and their IAM roles, meaning that each Lambda function should have its own IAM execution role and should, therefore, not be shared between functions.
- The permissions assumed by an AWS Lambda function are determined by the IAM execution role associated with that function, which is why using the same IAM role with more than one Lambda function will violate the Principle of Least Privilege. By using the right IAM execution role, you can control the privileges that your Lambda function has, thus instead of providing full or generic permissions you should only grant each execution the permissions that your function really needs.
- Ensure that tracing is enabled for your AWS Lambda functions in order to gain visibility into the function’s execution and performance. With the tracing feature enabled, Amazon activates Lambda support for AWS X-Ray, a service that collects data about requests that your functions perform, and provides tools you can use to view, filter and gain insights into the collected data to identify issues as well as opportunities for optimization.
- With tracing mode enabled, you can save time and effort debugging and operating your functions as the X-Ray service support allows you to rapidly diagnose errors, identify bottlenecks, slowdowns and timeouts by breaking down the latency for your Lambda functions.
Learn more about how Halo Cloud Secure can give you security visibility into your inventory of your AWS Lambda functions and help you identify any that may be publicly accessible. Read our AWS solutions here, or request a customized demo.