Moving to serverless, including AWS Lambda, makes security both easier and harder, as I outlined in our Serverless Security Scorecard. In deploying serverless apps, you cede control over most of the stack to your cloud provider, for better and for worse. You no longer own OS hardening, admin rights, SSH, and segmentation. The exception where you retain control is configuration and the application, and that is where security must come from. Least privilege, in particular, is a key component to AWS Lambda security best practices.
So, What Can You Do for AWS Lambda Security?
You must ensure security is tightly wrapped around your application and applied correctly, specifically to each resource, function, S3 bucket, etc. Those IAM roles are critical in ensuring your app is as secure as possible.
“Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.”
— Jerome Saltzer, Communications of the ACM
This definition presupposes there’s something that enforces a differentiation of privilege within each part of the application in a way that limits what they can do. Assuming that infrastructure exists, least privilege dictates that we apply the smallest possible privilege so that it can function correctly, but can do nothing else.
While least privilege is critical, it’s rarely achieved, making it the unicorn of security configuration.
Let’s look at the following function as an example.
A ‘quick-and-dirty’ developer might write something like:
This allows all actions on S3 to all buckets on S3. That gets the job done. The code will run, and not fail or give errors because of lack of permission. However, a slightly better, more secure version might be:
But a least privilege version of this would allow only GetObject, and only for this particular bucket.
In the last case, an injection attack into this area of the code could only read files from this particular bucket. The function can’t read files from any other bucket, and can’t write to or delete the bucket. That will significantly shrink what an attacker can do.
Why Least Privilege is Hard
Perhaps most critically, security is, in a way, the opposite of development, because security is the process of limiting, whereas development is creating and enabling. A developer’s instinct is to enable and remove obstacles, and it can therefore be challenging to ask them to apply security restrictions at the same time. I’ll be posting a blog in the future on this controversial stance. However, part of AWS Lambda security best practices includes having developers consider what they don’t need, and what they can therefore carve away.
Here are some additional reasons least privilege is always hard:
- Security takes time, developers don’t have time
- Security gets in the way, so the easiest thing to do is wildcard it
- Lack of visibility, to even know what permissions you need
- Lack of granularity of access controls
- Lack of awareness or mindfulness to the problem
While it’s always hard, least privilege is even harder in serverless. Have a look at one of my previous posts, “Least Privilege for AWS Lambda Security”, for further details. The key issues here are:
- You have many (many) more resources
- Your developers are updating them more frequently
While serverless requires a complete shift in your security approach, it also brings to the table a large number of opportunities for creating better, more granular and in-context security. Let’s compare serverless to containers. If a large container executes many functions, then you must enable it to do many things.
Moving to smaller microservices enables you to do more fine-grained IAM around them all. More importantly, it means, that if there is a vulnerability in one of your functions, an attacker will only get access to the limited capabilities of that function, not the large set of permissions each container had.
You have the opportunity to apply security policies to each of those small things. AWS Lambda, along with most of the cloud providers, enables you to significantly shrink the attack surface. The opportunity for least privilege to be meaningful and mitigate a tremendous number of attacks is much more powerful with AWS Lambda than in a monolithic app.
Training Developers in AWS Lambda Security Best Practices
While security may be difficult for developers, I don’t advocate that we take the whole thing out of their hands so that someone else owns it. Automatic tools, such as our own Protego Proact, play an important role. But at the end of the day, it remains important to train developers to think about security. I recommend the following best practices:
- Look for low-hanging fruit
- Try to do this as you develop
- Easier in tandem with the development process
- Try to do this as you develop
- Run tools
- All the training in the world won’t will close the gap as much as running a few tools, so definitely do both
- Run tools
- Focus on permissions from the bottom up
- Start from the assumption that the function needs nothing
Last year I presented a webinar, Serverless Security Quick Wins, which included AWS Lambda best practices. The recording is available on demand. Additionally, sign up for email updates and check out our existing resources, which feature additional serverless security best practices. And as always, I encourage you to challenge me on something via Twitter.
Lastly, if you would like to see a demo of our automated security solution, request a 1-1 demo.