3 Reasons Why Security is Key When Writing AWS Lambda Functions

Serverless computing is popular among developers for freedom from thinking about infrastructures when building and running applications. But there are risks.

Serverless computing services are a favorite among developers as they eliminate infrastructure management tasks like capacity provisioning and patching, and offer automatic scalability, high availability, and a granular pay-for-use billing model.

Amazon Web Services (AWS) Lambda is a popular event-driven serverless computing platform that allows users to run code without the need to manage infrastructure. Within Lambda, code is stored in a code deployment package. All interaction with the code occurs through the Lambda API (application programming interfaces) and there is no direct invocation of functions from outside of the service. Lambda functions have many use cases, but the main one is to respond to and process events. While it is popular among the DevOps community for the many benefits it offers, it comes with a spectrum of security risks that are too often neglected.

Why Consider Security When Using AWS Lambda?

Security is a key consideration when using AWS Lambda for three primary reasons.

• AWS Lambda functions are used to build applications: AWS Lambda provides a highly reliable service, allowing users to deploy serverless applications with confidence. The managed runtime environment model enables Lambda to manage much of the implementation complexity of running serverless workloads. A security incident that compromises your Lambda functions can result in widespread disruption to several mission-critical aspects of your business.
• AWS Lambda functions process sensitive data: Sensitive data includes personal identifiable information (PII) such as customer names, social security numbers, driver’s license numbers, financial information, and medical records that can identify an individual. If this data were to be accessed or modified by an unauthorized party, it could result in serious harm to individuals and your business.
• AWS uses a shared responsibility model for security: Security and compliance is a shared responsibility between AWS and the customer. What this means is that Amazon Web Services (AWS) owns “security of the cloud” and handles protecting the infrastructure that runs all the services offered in the AWS Cloud. On the other hand, “security in the cloud” is always customer’s responsibility. As an example, for abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS runs the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data while customers handle managing their data (including encryption options), classifying their assets and using identity and access management (IAM) tools to apply the right permissions. When it comes to Lambda, data integrity, and confidentiality is the responsibility of the AWS customer. Therefore, AWS and its customers have a shared responsibility to ensure the continuous security of Lambda implementations, ensuring that they are protected from potential security threats.

Using a serverless computing platform does not absolve developers from the responsibility of ensuring failsafe security. So, what are some security risks that your unsecured AWS Lambda functions could be exposed to? My next post dives into the most common security risks that arise in a serverless computing environment.