AWS Lambda Security
The security of an application is one of the most important non-functional requirements. Every application and underneath infrastructure has to go through strict security guidelines to secure the whole system. Serverless architecture is getting more attention from the developer community, so do hackers as well and AWS Lambda is a widely used service that hosts serverless architecture applications.
There are several myths around Lambda and serverless architecture and the most common one is that whole security for these apps relies on AWS. But that is not correct. AWS follows the shared responsibility model where AWS manages the infrastructure, foundation services, and the operating system. And the customer is responsible for the security of the code, data being used by Lambda, IAM policies to access the Lambda service.
By developing applications using a serverless architecture, you relieve yourself of the daunting task of constantly applying security patches for the underlying OS and application servers. And concentrate more on the data protection for the application.
In this article, we are going to discuss many different aspects of the security of the Lambda function.
Data Protection in AWS Lambda
As part of data protection in AWS Lambda, we first need to protect account credentials and set up the individual user accounts with IAM policies enabled. We need to ensure that each user is given the least privileges to fulfill their jobs.
Following are different ways, we can secure the data in Lambda:
Use multi-factor authentication (MFA) for authentication to each user account.
Use SSL/TLS to have communication between Lambda and other AWS resources.
Set up CloudTrail service with API and user activity logging.
Use the AWS server-side and in-transit encryption solutions, along with all default security controls within AWS services.
Never put sensitive identifying information such as account numbers, credentials of the services in the code.
Encryption in Transit
Lambda API endpoints are accessed through secure connections over HTTPS. When we manage Lambda resources with the AWS Management Console, AWS SDK, or the Lambda API, all communication is encrypted with Transport Layer Security (TLS).
When a Lambda function connects to a file system, It uses encryption in transit for all connections.
Encryption at rest
Lambda uses environment variables to store secrets. These environment variables are encrypted at rest.
There are two features available in Lambda while encrypting the environment variables:
AWS KMS keys -
For each Lambda function, we can define a KMS key to encrypt the environment variable. These keys can be either AWS managed CMKs or customer-managed CMKs.
Encryption helpers -
By enabling this feature, environment variables are encrypted at the client-side even before sending it to Lambda. This ensures secrets are not displayed unencrypted on AWS Lambda console or in CLI or through API.
Lambda always encrypts files that are uploaded to Lambda, including deployment packages and layer archives.
Amazon CloudWatch Logs and AWS X-Ray used for logging, tracing, and monitoring logs also encrypt data by default and can be configured to use a CMK.
IAM Management for AWS Lambda
IAM management in AWS typically handles users, groups, roles, and policies. For a new account by default, IAM users and roles don't have permission for Lambda resources. An IAM administrator must first create IAM policies that grant users and roles permission to perform specific API operations on the Lambda and other AWS services. The administrator must then attach those policies to the IAM users or groups that require those permissions.
There are a few best practices to handle the IAM policies:
AWS has already created many managed policies for the Lambda function. So to start quickly attach these policies to the users.
Start with the least privileges rather than being too lenient initially and trying to tighten them later.
For sensitive operations, enable multi-factor authentication (MFA).
Use Policy conditions to enhance security. For example - allow a request to come only from a range of IP addresses or allow a request to come only within a specified date or time range.
Auto-Generate Least-Privileged IAM Roles
An open-source tool for AWS Lambda security is available that automatically generates AWS IAM roles with the least privileges required by your functions. The tool:
Saves time by automatically creating IAM roles for the function
Reduces the attack surface of Lambda functions
Helps create least-privileged roles with the minimum required permissions
Supports Node.js and Python runtimes for now.
Supports Lambda, Kinesis, KMS, S3, SES, SNS, DynamoDB, and Step Functions services for now.
Works with the serverless framework
Logging and Monitoring for AWS Lambda
In AWS, we have two logging tools relevant to watch for security incidents in AWS Lambda: Amazon CloudWatch and AWS CloudTrail.
For Lambda security, CloudWatch should be used to:
Monitor “concurrent executions” metrics for a function. Investigate the spikes in AWS Lambda concurrent executions on a regular basis.
Monitor Lambda throttling metrics
Monitor AWS Lambda error metrics. If you observe a spike in timeouts, it may indicate a DDoS attack
When we enable data event logging, CloudTrail logs function invocations and we can view the identities invoking the functions and their frequency. Each invocation of the function is logged in CloudTrail with a timestamp. This helps to verify the source caller.
One of the most significant benefits of enabling CloudWatch and CloudTrail for your AWS Lambda serverless functions comes from the built-in automation. Notifications, messages, and alerts can be set up that are triggered by events in your AWS ecosystem. These alerts enable you to react to potential security risks as soon as they are introduced.
Securing APIs with API Gateway
AWS API Gateway along with AWS Lambda enables us to build secure APIs with a serverless architecture. With this, we can run a fully managed REST API that integrates with AWS Lambda functions to execute business logic.
Following are controls that can be used to control access to APIs:
Generate API keys and use it with usage plans with usage quota limiting
Use AWS IAM roles and policies to grant access to user
Use Cognito user pools to enable authentication. It has features to authenticate using third party providers like Facebook, Twitter, GitHub, etc..
Use Lambda authorizer functions for controlling access at API methods levels. It can be done using token authentication as well as header data, query string parameters, URL paths, or stage variables.
Summary
Serverless architecture takes away a lot of pain in operation management. This also offloads the onus of patching OS and other infrastructure levels of security concerns. However, it opens new vectors for attacking like events injection and many others which are not known yet. But security basics remain the same and application and data-level security have to be enabled and monitored regularly to avoid any security attacks.
No comments: