One of the key benefits of the cloud is focus. Spinning up a virtual server in the cloud lets you focus on the operations and security of the operating system, you applications, and your data. Similarly migrating to a SaaS productivity suite lets you focus on your data and getting work done.
This is the beauty of the shared responsibility model .
Applied equally to operations and security, the model provides a simple guide to understanding where you need to focus your energies and where your cloud service provider will focus theirs.
This leads to a simple approach to building in the cloud…”Use SaaS services where ever possible, only paying the cost of the PaaS and IaaS dynamic when absolutely necessary”.
This above all else has led us to serverless designs.
Serverless?
The name is a bit controversial but it is a handy way to describe a cloud application where your custom code (running as functions in the cloud) uses a number of services and APIs to solve a specific problem.
With serverless apps, you’re taking the building blocks offered by various services and glueing them together in AWS Lambda , Microsoft Azure Functions , Google Cloud Functions , IBM OpenWhisk , or something similar.
It’s a fast, cost effective way to get a highly scalable, highly available application in the hands of your users.
In addition to the benefits, it raises a lot of questions around operations and security.
NoOps?
When serverless applications first started to gain popularity, there was a push for a term called “NoOps”. The idea being that in these designs all operational–and thus security–tasks had been delegated to the cloud service provider.
That’s a dangerous way of thinking.
While serverless designs do significantly reduce the operational and security impact on your team, it does not eliminate them.
Charity Majors gave a fantastic talk at the first Serverless.conf on this very issue. Looking at the security angle, we know from the shared responsibility model that our data is always our responsibility.
How do we make sure that we are fulfilling our responsibility in a serverless design?
Areas of Focus
There are 4 critical areas of focus for serverless security;
|
|
I’ve written about these areas before and will be speaking to them at RSA 2017. These areas shouldn’t be new to anyone building a modern application, the difference here is these are the only areas where you can make an impact on the security of your application.
Because a serverless application is made of SaaS level services, you don’t have the ability to apply controls to the operating system or the application layer.
You can’t adjust the configuration of httpd or MongoDB or any other foundational tools in your application because they have been abstracted away as services provided by a 3rd party.
That’s a win operationally but a major shift for security.
Security in serverless designs is far more about making sure that the services you use have adequate security controls built in and that you’ve configured those controls correctly. This stands in stark contrast to traditional applications where you can simply add more security controls as need.
In addition to trust, provider choice, and configuration, monitoring plays a critical role in serverless security. Once you understand a design, monitoring ensures that your operational and security controls continue to work in production as you expect…and only as your expect.
As you can see, there is still security and operational overhead in serverless designs but the nature of the work has changed.
Next Steps
Serverless designs are maturing and becoming more commonplace. As a part of that process, the community is gaining a better understanding of the security and operational consequences alongside the business benefits.
There is a lot going for these designs and–I believe–they will quickly become the design pattern of choice for most applications.
What do you think about serverless designs and security? Let’s chat on Twitter where I’m @marknca. I’m always happy to discuss cloud, security, and other technologies.
