1. var bob = new Person();
2. bob.sayHello();
3. bob.wave();
##################################################################################################################

Security with Serverless

Introduction to the benefits and disadvantages to security when using serverless

##################################################################################################################
4. var cup = new Coffee();
5. bob.drink(cup);
6. var cupTwo = new Coffee();

Cloud security is a big topic at the moment, with many organizations trying to port their on-prem models over to the cloud and finding it doesn’t work. The price of finding this out can be absolutely brutal, with user data leaked across the internet and your reputation ruined.

So how do you avoid this? Luckily OWASP have some good advice on the principles of security by design when building new software here. I’m not going to go through every principle in detail but there’s some key things I’d like to extract:

  • Minimize the Surface Area. Basically leave as little as possible vulnerable to attack, and its less likely it will be successfully attacked
  • Defence in Depth. Try and have multiple interlocking security measures, so that if one is breached other’s kick in and save you.
  • Least Privilege. Each component should only have the permission required to do its job and nothing else.

These three principles form the basis of most of the modern approach to security. You’ll probably have seen them in action - you are likely an admin of your home computer, but at work your IT department will have exercised the least privilege principle and reduced your powers to what you need to do your job. This limits the downside of your account being hacked - if you had god rights and got hacked, your account would be a colossal danger to the company.

How does Serverless fit in?

Let’s kick off with what Serverless helps with on the security front.

  • Serverless applications have a massively minimized Surface Area in terms of vulnerabilities compared to traditional architectures (i.e Bare Metal, Virtual Machines or Containers). A serverless function has no operating system to attack, with the entire responsibility for security of the platform outsourced to the provider. I didn’t even notice when Heartbleed and the various Intel vulnerabilities were published, my cloud provider patched them seamlessly. Compare this to even containers, the next best option, and you see the 10 most popular Docker Images on DockerHub are riddled with security vulnerabilities. Let’s not even get into the vulnerabilities of a windows server running in a cupboard somewhere that everyone has the username and password to because its on a post-it on the outside of said cupboard.
  • Serverless architectures actively encourage the use of role based access, with each function having a tiny set of permissions to just do it’s job effectively. This is great for Least Privilege.
  • The use of Managed Services to solve problems is actively encouraged. These managed services notably include login systems, which are developed and maintained by some of the best engineers in the world - these are significantly more secure than individual developers creating their own login systems and making massive errors like storing passwords in plaintext. This minimizes surface area and increases defence in depth (each managed service you use is a fortress, whereas often architectures have hard outsides and then use the default username and password to access the database, which itself is 15 versions behind the latest release and very vulnerable)
  • Defence in depth is strong, but hidden. Underlying a serverless product are many layers of defence, but because they are abstracted away it sometimes looks like they aren’t there. For example a serverless database will have many layers of physical security protecting the servers, layers of software-based protection and active monitoring for malicious activity. This is more than most organizations could ever hope to achieve, but it looks like only one box on an architecture diagram, rather than 27.

This all sounds good, and I truly believe Serverless Architectures are some of the most secure available. There are some issues though:

  • Serverless functions encourage lots of small components that are each possible targets. This could be said to increase surface area (although arguably this is cancelled out by the fact that each of these has a much lower permission set than a traditional system which would have only a few components but each of them having a much wider permission set)
  • Serverless tends to not play nicely with firewalls and network restrictions. These are put in place by most IT departments so that only employees on the company network can access internal company applications - if you’ve ever had to connect through a VPN to access a website at work that is network restrictions in action. This is because to scale elastically they need to allocate network addresses dynamically and this is very challenging to do inside a private network. This makes it impossible/very hard to use network restrictions, which is a common way of improving Defence in Depth.

Are those issues addressable?

Yes, but not quite at the moment. AWS has recently taken a leap forward in being able to provide Lambda’s (Their Function-as-a-Service product) inside firewalls/private networks with a reasonable cold start time. The trouble is the problem is challenging for each serverless service on the market, and I’d question whether you are exposing yourself to more risk by refusing to use the service until the networking issues are resolved. If you decide to use Kubernetes with Docker instead of Azure Functions to build a Web API due to the networking issues, you are exposing yourself to far more risk than a Serverless function which has a completely managed runtime - and once you begin to be dragged down the serverless stack you begin either having, or thinking you have to, use non-managed services. For example once you have decided to use Docker on Kubernetes to host your apps Web API, before you know it you are running your MySQL database on there, despite there being a much more secure and much more reliable managed service for MySQL on your cloud provider. You won’t use the cloud provider load balancer, you’ll use one you built yourself, which I’m sure is just as capable at coping with Distributed Denial of Service Attacks.

A decent compromise currently is to use a Platform-as-a-Service like Azure App Services. These have a managed runtime, but impose fewer restrictions and are designed to accept common MVC (Model View Controller) Web Apps using frameworks like ASP.NET or Django. Because they impose fewer restrictions, they are not able to exhibit the same autoscaling behaviour. This means you have to do some form of capacity planning, i.e. you need to choose how many cores and how much RAM you want. You will pay for capacity that you don’t actually use because it’s on all the time.

They do have more vulnerabilities than Azure Functions. A Distributed Denial of Service attack could easily bring them down. You’re able to do anything that you can do on a ASP.NET or Django (or whatever web framework you use), which is a wider set of abilities than an Azure Function. With wider abilities comes more opportunity for mistakes. They run more as ‘Servers’, which means they have a long life and fundamentally behave in a similiar way to the servers for which most attacks and malware are designed.

Their advantage is that due to the lack of autoscaling, you can use network restrictions. Whilst this is an OK compromise, I still prefer going full serverless. The advantages to development speed, operational efficiency and security outweigh massively the benefits of knowing what IP range someone is from, which is relatively easy to get round as a security measure anyway.

Overall whilst there are some small issues, approaching your architecture with the serverless mindset, to offload operational overhead and choose managed services where possible is a massive net benefit to security. These managed services are significantly more secure than anything an individual company whose business is not providing these services could do without incurring a massive loss of focus and an enormous increase in TCO.

© 2022 - Built by Daniel Bass