This post was originally published here by gregg rodriguez.
Many organizations are in a transition, operating somewhere between traditional and modern application environments, and asking some of the same questions you likely have about how serverless computing environments work.
Most companies are not actually 100% serverless, or even 100% cloud-based yet. Instead many have opted for an infrastructure model that is part serverless and part server based..
You may still be wondering what that actually means:
- If there’s no server, what’s left to protect?
- How will I know that my data and applications interfacing with serverless services, such as AWS Lambda, are secure?
- If there’s no server, can you install an agent?
Let’s take a look at serverless computing in the context of our new modern application environment, and how serverless interacts with traditional IT technologies.
While I don’t believe enterprises will be moving everything to a serverless environment anytime soon, we will continue to see more and more of it as the need for a faster and more agile computing infrastructure becomes more critical. So it’s important to look at serverless computing within the context of both a cloud computing environment and traditional server-based environments. Let’s start with the basics.
Serverless Isn’t Truly ”Serverless” for Two Reasons:
- Even in a serverless computing model, a server somewhere is still required to run your functions and related services. The difference is, it’s not a server that you happen to own. Instead, it’s one controlled by your cloud service provider (CSP). That being the case, you won’t necessarily know what kind of operating systems, or networking, these servers are using, as they are proprietary secrets of the CSP. The reality is that, servers in a datacenter somewhere are actually running the functions you need to support your serverless computing functions.
- Your “serverless” application may likely still interact with your server-based components (controlled by you), as it’s very unlikely you’ll have applications that don’t rely on other cloud services or server instances. Therefore, it’s extremely important for you to have security visibility into both types of components. The compromise of one part of your application could easily lead to the compromise of other parts of your application.
Benefits of Using a Serverless Service:
- Cost Savings: You can save money, as you only pay for the compute resources you use. Unlike in a traditional model where your resources are often underutilized and you still have to pay for them.
- Scalability On-Demand: Since everything is on-demand, your serverless functions can scale up or down instantly, without you having to deploy any additional infrastructure—the cloud provider takes care of all of that.
- Security Benefits: Serverless functions are typically stateless, that is, conditional routing and state management remain external to the function and are instead managed entirely by the integration engine, with some exceptions of course. What this means is that if your serverless function or underlying infrastructure is compromised, the attacker or their back door won’t be able to persist for very long because the serverless instance is typically destroyed/recreated for every function call. So even if you are compromised, the attacker would need to deploy their back door over and over again, which would then increase the risk of failure or detection.
- No Underlying Infrastructure to Protect: The cloud providers take care of protecting the infrastructure as their part of the shared responsibility model.
Security in the Age of Serverless
So if serverless is so beneficial, and you don’t have to patch servers, why do you have to worry about security?
In a nutshell, part of your application is controlled by your CSP, and the other part is controlled by you. What this really means is that there is a shared responsibility for security between you and your cloud provider.
Both of you are responsible for taking reasonable steps towards protection your applications and content in the cloud. For AWS Lambda, AWS takes care of securing their foundational services based on the shared responsibility model, but it is your responsibility to use those foundational services correctly and in a secure way, ideally according to best practices, in order to reduce your risk of exposure as your serverless environment grows.
Photo:IFSEC Global
