How secure is serverless computing?

Security considerations must be taken into account in every line of code for any app developer, no matter what the application or where it is to run. This much is standard operating practice today. With serverless computing, however, it becomes even more important.

Serverless functions, delivering microservices, are modular pieces of code that behave in particular ways when provided with particular inputs. They reside in a Function-as-a-Service (FaaS) service provider's cloud platform and, as such, are protected to a degree by the provider's own security infrastructure.

So you can expect the physical infrastructure wrapper components - data centre, network, servers and operating systems - to be secured. This on its own reduces the likelihood of a successful exploit, as unpatched servers are counted among the biggest vulnerabilities.

Security challenges

That said, security challenges remain for the serverless app developer. Developers are still responsible for the secure execution of their code, including application logic, code and data. They must also bear in mind that the serverless architecture brings with it a set of unique security vulnerabilities.

In particular, the modular nature of serverless applications means that they present an increased attack surface as a consequence of their interconnectedness. They can draw data from multiple sources, which could include for example cloud storage, IoT devices, or a variety of APIs and message queues. Many of these can be difficult for traditional firewalls to inspect. Additionally, serverless means that data moves around more - between functions and third-party services, for example - so that data is more exposed to potential interception.

And because serverless applications operate amid a complex web of connections, it makes full security testing difficult before release into a real-world environment. For example, a function will often rely on third-party libraries as well as connecting to API-connected remote web services, the dependencies of which may be challenging to ascertain.

Best practices

So adherence to best practices - such as never trusting any input, failing securely, and adhering to the principle of least privilege - remains important.

The trust issue means that encryption as a means of securing secrets, such as API and encryption keys, configurations, and database access credentials, is essential: no secrets should ever be stored in plaintext. Preferably, they should be stored only when strictly necessary, preferably, a variety of secrets management systems are available. Data from any function or service should also be encrypted in order to prevent the build-up of a fragile chain of functions; one weak link breaks the security chain.

Least privilege means that only enough privileges should be granted for the intended behaviour, so helping to avoid, for example, the execution of system-level functions. This implies robust authentication: access control should be applied across the board to triggers, functions and events, as appropriate.

This complex environment can also be challenging to monitor, visualize and debug, which is another security hazard. So adequate logging to help with debugging in this complex environment is essential, as visibility into individual functions is likely necessarily to be limited. Detailed logging will also enhance visibility into the actions of intruders and help prevent breaches.

Further, the complexity of serverless environments means that checking the dependencies of any external libraries and web resources for vulnerabilities is highly advisable. And of course, input validation remains essential.

However, serverless is not all doom and gloom. There are security benefits to the technology. Apart from those mentioned above - such as the ability to leave the problems of securing the infrastructure to the FaaS provider - because a serverless function spins up, does its work and spins down quickly means it will be less vulnerable to long-lived attacks, such as DDOS.

Functions tend to be relatively small pieces of code, making it easier to define exactly what it will and will not do, which helps reduce the attack surface. By the same token, however, it is very easy to deploy a function, and other applications may well become dependent on it, making its removal risky - which in turn means you may end up with lots of functions in deployment with ill-defined connections, but which are difficult to shut down.

Summary

Serverless computing remains a fairly new technology, and some security issues remain to be addressed. However, it offers huge business benefits and, over time, you can expect the domain-specific security technology to mature and enable the benefits of serverless to fully emerge.