1. var bob = new Person();
2. bob.sayHello();
3. bob.wave();
##################################################################################################################
##################################################################################################################
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:
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.
Let’s kick off with what Serverless helps with on the security front.
This all sounds good, and I truly believe Serverless Architectures are some of the most secure available. There are some issues though:
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