Serverless/Serviceful architecture could be said to be the art/science of constructing systems that deliver business value fast whilst incurring the lowest possible management overhead. Why am I starting a post about security with this statement? Well, as far as I’m concerned, this optimizes for a lot of security concerns too.

Let’s take the classic example of a Serverless service, the Function-as-a-Service platform. In Azure’s case this means Azure Functions. What security concerns are there? Well, if you read the OWASP report, you can see there’s some around SQL injection etc, but basically there’s none that are serverlesss specific - they are all generic application logic problems. That’s encouraging in itself. For me there are two key ways that Azure Functions are more secure than other ways of doing compute on Azure, or in general:

1. The underlying runtime is entirely managed and patched by Azure. When the most recent round of Intel vulnerabilities and corresponding patches got announced, I did not notice. That’s because Microsoft patched it all for me (and incidentally took the performance hit, cheers Microsoft). For non-serverless, or rather non-managed, approaches this would have been panic stations as I’d have to desperately try and apply the patches before a piece of malware exploiting the vulnerability was released. The most common security vulnerability is servers running out-of-date, unpatched software.
2. There is no conventional ‘server’ to attack. FaaS just executes the code given to it and nothing else. Obviously if that code is insecure itself, then thats a problem, but theres no other background services or backdoors that are often the source of exploits.

There’s another reason serverless/serviceful approaches are more secure too. In my second book, I show you how to use Azure Active Directory B2C to implement a login flow. Managing logins is a very dicey problem to solve yourself, as there are a bunch of ways you can get it wrong, beyond the usual of storing passwords in plaintext in a SQL server that still has the Server Admin role on it. In a serverless/serviceful approach, you simply use the service and don’t expose yourself to the possible security concerns caused by faulty application logic.

Why firewalls won’t save you

I see a lot of people creating application diagrams and thinking, ‘I need this to be secure. I’ll wrap it in a Virtual Network with a firewall around it - that’ll sort it’. They then block off all traffic except for from the companies internal network. There’s some key issues I have with this. For a start it can instantly be the death of serverless approaches, due to their general lack of a fixed network presence. In the old days of the on-prem world it was very difficult to harden each application, so wrapping the entire datacenter in a firewall with a small hardened DMZ was the best approach. These days, implementing Azure Active Directory authentication for every application on Azure is almost trivial. Most services now come with active monitoring for malicious activity, like Azure SQL PaaS. You can also user something like Azure Front Door or Akamai for DDoS protection. This means it is now straightforward to harden each individual component.

So now that its easier to harden each component, what role does the firewall play? Well evidently in terms of making life more difficult for an attacker, defence in depth is a good principle - so why not put a firewall in as well as the AAD integration and active malicious use monitoring? Well there’s actually quite a few reasons why you might not want to and why doing so may actually weaken your security:

1. You restrict access to modern cutting edge serverless services. Azure Functions literally just got the ability to attach to a virtual network through preview Premium Functions. Logic Apps still don’t have the ability. AAD B2C doesn’t have the ability. Any future autoscaling services are unlikely to have this ability as well. This has a potential impact on your security as your engineers jump for things like VM’s which are fundamentally less secure than serverless services.
2. Every attempt at integration you ever do in future will be x times more painful. You will have to faff with routing things through Virtual Networks every single time you want to do anything new at all. This will increase all future delivery times for something which may not be necessary. Any link to security here will be tenuous, this is just a reason you probably don’t want to do it!
3. Firewalls can act as a dangerous security blanket. You’re operating in a multi-tenant public cloud environment that you don’t have control over. Your services are available by default to the internet at large. If a team gets used to just wrapping stuff in a virtual network with firewall, then when they deploy by accident to outside that firewall they may have no other hardening.
4. If you open access to your corporate network you are exposing your service to tens of thousands of potentially compromised services. It is trivial to include some javascript in a page that a business user visits which calls services inside your firewall from their browser - I’m then inside your network with little to zero chance of a malware alert.

There is a setting on Azure Virtual Networks which lets you ‘allow access to Azure Services’. If you tick this, you don’t need a Virtual Network with firewall. How do I know this? It opens the app to entirety of the Azure data centre - if you really needed a firewall you wouldn’t open access to any mid-twenties bloke in the U.K. (me!) with an Azure account.

This is the first cut of a number of ideas that have been rolling around in my head for a while - it definitely shouldn’t be treated as definitive. I hope it helps people debating serverless security approaches.