Using serverless architecture for web applications comes with a generous amount of security features that, when well implemented, gives more protection against threats than a classic server architecture could. This article looks at specific AWS serverless services and how they can be used in conjunction with others in order to uphold to security best practice.
When setting up an architecture for a serverless service, in order to respond to user requests, the first point of contact is often a CloudFront distribution that would allow user requests to be cached, compressed, organised and other operations before they hit any other part of the web application.
A CloudFront distribution by itself will not give any extra protection - it will merely facilitate the communication between the user and the application. From the moment a user request hits AWS CloudFront distribution and becomes a database operation however, it’s important to know that all layers of the architecture can employ seamless protection on each respective level.
For example, AWS offers the first line of protection by placing an AWS Web Application Firewall (AWS WAF) between the Internet and the web application itself. This firewall will provide protection against the various types of attacks, including SQL injections and Cross-site Scripting. In addition to that, AWS offers AWS Shield Standard service to protect the web application from the most common DDoS attacks, where it can further be enhanced by the Advanced version of this service.
AWS API Gateway
The next stage of the request will be an interface that will be able to translate the URL and all the parameters that come with it to the serverless application. The AWS service in charge of that is AWS API Gateway, which allows endpoints to trigger events down the line.
This important layer takes whatever the data (request holds, query strings, request body and header) and brings into a data format that the application will understand. This is a really great stage to filter data that could be maliciously sent to the application. By using API Gateway Request templates, any non-authorised data can be filtered out and cleaned up before processing.
In addition to that, the API Gateway can be configured to use an Authorizer. The Authorizer sits between your application and the API Gateway endpoint, and takes a configured parameter as an input and verify that the request is authorised to perform the requested action. A common usage would be to verify that a JWT token sent via the Authorization header is valid, and the user trying to access the resource is effectively allowed to do so.
A Lambda function should hold the code needed to execute an event, and only the code that is intended to be executed. Maintaining this design best practice of keeping the logic embedded into the Lambda function simple, practically eliminates the risk of dead code or unintended code to run. This is major for attacks and vulnerabilities that could go under the radar.
A Lambda function needs an AWS IAM Role for successful execution, and, in keeping with the Principle of Least Privilege best practice, the role needs to hold only the minimal level of permission. For example, a Lambda function used to read records from a database, review the results and send it back to the client would only require read-only permissions to the database. Further, the role would only allow read operations on a particular table only, reducing the risk of function coercion.
No doubt the code needs to hold all necessary validations in order to ensure clean data is entered into the system. This part is up to the developer’s due diligence and not related to the inherent security of the serverless application.
There are many ways data could be securely stored in a serverless architecture. The obvious choice will usually start with a DynamoDB table; the AWS NoSQL solution for storing all sorts of data. There is no maintenance and no security patches to apply - just store, read and manipulate the data as needed.
As mentioned in the section above, the correct IAM role used to read/write data is needed for access from the table down to the record level.
Another storage alternative is to use AWS S3. If latency is not a concern, AWS S3 is a good way to store your data, and whether in text, JSON or binary format, your data can be secured by specifying appropriate S3 bucket policies to restrict permissions from the bucket level down to the files (objects) level.
I have scratched the surface of how security can be handled in a serverless environment on AWS, showing how different aspects of the security pillar of the Well Architected Framework can be implemented. Data cleaning, filtering, validation can be done on some building blocks when access permission can be handled on other blocks. By working with these approaches each step of the way, a robust security model can be set up in order to ensure your web application is resistant to the most common threats.
Cloud Conformity can help you ensure your AWS serverless infrastructure is compliant with security best practices giving you deep insights and step-by-step resolution guide to increase your compliance.The Well-Architected Framework is embedded in the platform, including its 500-plus Knowledge Base rules and remediations. The free 14-day trial provides full access to the platform including the API, Auto-Remediation and Real-Time Monitoring.