Securing Serverless Applications
Securing Serverless Applications
Under lock and key. Operating in the cloud provides consistent updates and patches, but what other concerns should enterprises be aware of?
Join the DZone community and get the full member experience.Join For Free
We've seen time and again how serverless architecture can benefit your application: graceful scaling, cost efficiency and a fast production time are just some of the things you think of when talking about serverless. But what about security? What do I need to do to ensure my application is not prone to attacks? This is exactly what I'm going to try to address today, so let's jump right in!
"Serverless security is not inherently better or worse, it's just different. " —Guy Podjarny
From a developer perspective, switching to serverless is a great move as it allows them to focus on the product itself while the platform on which the code executes is run by the province provider. What this means for security is that the patches themselves are being applied on time everytime which is one of the biggest "challenges" for traditional servers. Basically, the people responsible for the security updates either forget or just ignore said updates, leaving you and your data at great risk.
"Most attacks exploit known vulnerabilities that have never been patched despite patches being available for months or years" — Verizon
It's Not All Fun and Games!
While the architecture has some clear advantages over its traditional counterpart, serverless has some security disadvantages (yeah, let's call them that). I'll quickly go over a few but if you want to go into details you can check out Adnan's article on the issue where he talks about finding the biggest security risks in serverless.
Event injection — Solved with input validation and predefined database layer logic, such as an ORM or stored procedures.
Broken authentication — Solved with built-in authentication/authorization solutions and avoiding dangerous deployment settings.
Insecure deployment settings — Solved with never using public read ACLs and keeping files encrypted.
Misuse of permissions and roles — Solved with the "least privilege principle."
Insufficient logging — Solved with 3rd party tools such as Dashbird, or becoming well versed in using CloudWatch.
Insecure storing of app secrets — Solved by using AWS KMS to encrypt your application secrets.
DoS attacks and financial exhaustion — Solved with writing efficient code, using timeouts and throttling.
Improper exception handling — Solved by logging stack traces only to the console or dedicated log files. Never send stack traces back to the end user.
One of the many companies that do serverless security, Protego came up with an analogy I really like.
"It's a bit like riding in an Uber vs. taking your own car. Sure, the drivers are probably more professional, and perhaps better trained. And the flexibility of paying for a car only when you need it is great. At the same time, you don't get to choose which safety features the car has, or how many airbags you'll have around you."
To summarize, with serverless, the new kid on the block, a lot of things got easier from a security perspective. Things like the need to patch servers are now done by the service providers, the microservices got smaller and easier to control, and not to mention the fact that each container is stateless and ephemeral.
And while all these are really cool, with serverless we need to look for security flaws in a different place and this is something that doesn't come easily to anyone. Having to manage deployment permission alongside the many new points of attack is going to prove challenging but not impossible if you know where to look. Here's where Dashbird comes into play. It gives you the observability you lack in your serverless environment while providing monitoring and alerting to help you get the most of your new serverless application.
Published at DZone with permission of John Demian , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.